OpenSolaris

1. Community: OS/Net (ON)
   1. Blogs
   2. Development Process
   3. Developer's Reference
      1. Introduction
      2. Prerequisites
      3. The Source Tree, part 1
      4. The Source Tree, part 2
      5. Building OpenSolaris
      6. Installing and Testing OpenSolaris
      7. Integration Procedure
      8. Best Practices and Requirements
      9. Glossary
   4. Discussions
   5. Installation (from source) Quickstart
      1. Annotated nightly(1) Mail Example
   6. Currently Known Issues
   7. CRT
      1. Advocates & Sponsors
      2. Becoming a CRT Advocate
      3. Charter
      4. RTI nits to avoid
      5. Sponsor Tasks
      6. Becoming a Sponsor
   8. Schedule
   9. ONNV Flag Days, Heads Ups, and Project Integration History
      1. All
      2. Builds 91-95
      3. Builds 86-90
      4. Builds 81-85
      5. Builds 76-80
      6. Builds 71-75
      7. Builds 66-70
      8. Builds 61-65
      9. Builds 56-60
      10. Builds 51-55
      11. Builds 46-50
      12. Builds 41-45
      13. Builds 36-40
      14. Builds 31-35
      15. Builds 26-30
      16. Builds 21-25
   10. Leaders
   11. Observers
   12. Putback Logs
   13. Developing Solaris
       1. Quality Death Spiral
   14. wx
   15. findunref and unreferenced files
   16. Bourne/Korn Shell Coding Conventions

heads up regarding 6548599 putback

Date: Fri, 9 Nov 2007 11:47:14 -0600
From: Will Fiveash <William.Fiveash at sun dot com>
To: onnv-gate at onnv dot eng dot sun dot com
Subject: heads up regarding 6548599 putback

Unless you are in the Kerberos Early Adopters program or otherwise know
that you are using NFS sec=krb5* mounts with a AES Kerberos enctype you
can probably stop reading this.

The putback for:

6548599 AES encrypt function in kmech_krb5 is broken for 16 byte input, causes NFSsec interop problems

breaks backwards compatibility with earlier versions of the Kerberos
kernel module that do not have the fix when doing NFS sec=krb5* with a
Kerberos AES enctype key.  The criteria for affected systems are:

1. They are running S10 or higher.
2. They are using a NFS share where sec is any of krb5, krb5i or krb5p.
3. The Kerberos enctype is either aes128-cts-hmac-sha1-96 or
   aes256-cts-hmac-sha1-96 (use klist -e to see the enctype on the NFS
   client side, klist -ke to see the NFS service key enctypes).

Note that S9 and earlier systems are not affected at all by this since
they do not support the AES Kerberos enctype key.

The two strategies for dealing with this are to update all systems,
client and servers with the fix or temporarily downgrade the NFS service
principal keys until all dependent NFS clients and servers are patched.

To downgrade, have the NFS server administrator add a new set of NFS
service principal keys for the NFS server that do not contain AES keys
to the /etc/krb5/krb5.keytab file.  The administrator then waits for the
NFS service tickets acquired by the NFS clients to expire (usually one
week) then apply the patch on the server and clients (this does not have
to happen simultaneously).  Once all the clients and the server are
patched then the administrator adds another set of krb keys for the
server this time including AES enctype keys.

Example of downgrading (assuming the NFS service principal has AES keys
in the keytab already, nfsserv.central is the example NFS server host):

kadmin -k -p nfs/nfsserv.central.sun.com -q 'ktadd -e arcfour-hmac-md5:normal -e des3-cbc-sha1-kd:normal -e des-cbc-md5:normal nfs/nfsserv.central.sun.com'

To restore AES support on NFS server:
kadmin -k -p nfs/nfsserv.central.sun.com -q 'ktadd nfs/nfsserv.central.sun.com'


For the S10 version of the fix, check with Peter Shoults
<Peter.Shoults at Sun dot COM>.

-- 
Will Fiveash
Sun Microsystems               Office x64079/512-401-1079
Austin, TX, 78727              (TZ=CST6CDT), USA
Internal Solaris Kerberos/GSS/SASL website: http://kerberos.sfbay
Info about krb-diag: http://kerberos.sfbay/krb-tool-info.html