DES phase-out and 1.8

[Ken Raeburn]

Your plan for 1.8 sounds good to me.

On Jan 3, 2010, at 17:27, ghudson at MIT.EDU wrote:
>  * Remove single DES from default_tkt_enctypes.  This is to prevent
>    the attack (mentioned by Nico and others in past conversations)
>    where you (1) spoof an AS reply to say "preauth is required, and
>    only single DES is allowed" to get the client to encrypt a
>    timestamp in the single-DES string-to-key of the password; (2)
>    conduct an offline brute-force search against that plaintext to
>    find the DES key; and (3) use that key to spoof KDC replies to
>    future AS requests from that principal.
>
>    This change may be disruptive to sites which still need to use DES
>    in AS exchanges (client or service principals with only DES keys,
>    or client code which can only do DES); they may need to add DES
>    back to default_tkt_enctypes.  Protecting more modern deployments
>    takes priority.

A random thought:  It'd be nice to be able to describe in my client- 
side krb5.conf, "realm A needs DES; don't use it for initial ticket  
requests otherwise".  This may just be a variation on Simon's  
suggestion, but he might have been referring to the KDC only, and I'm  
definitely thinking of the client configuration, since users needing  
only one identity in one realm has turned out to be fantasy thus far.   
It may also be simpler to do by realm than by principal names or name  
patterns generally.  (The "for initial ticket requests" bit is  
important for me, at least, because the realm where I'd like to mostly  
shut off DES still has an AFS service to support.)

> * (Nico) Adding realm policy information which clients can retrieve at
>  realm-join time to determine what enctypes to allow for AS requests.
>  Not really possible for 1.8 at this point, and I think a simpler
>  approach is acceptable.
>  (http://mailman.mit.edu/pipermail/krbdev/2009-January/007419.html)

You'd want to be able to get the lists updated... maybe instead of  
passing information at realm-join time, it could be conveyed during  
some of the FAST exchange using the host key?  Or we write some client- 
side software to refresh the info now and then.

Ken