Re: [Ietf-krb-wg] RFC 4537 question

On Dec 29, 2008, at 09:46, Luke Howard wrote:
> Consider the case where the ticket session key enctype is absent  
> from EtypeList but the server prefers that enctype over any proposed  
> by the client. Presumably the server is free to ignore the EtypeList  
> and use that enctype (even though that may mean using the ticket  
> session key rather than a server subkey). As far as the client is  
> concerned this is identical behaviour to a server that doesn't  
> implement RFC 4537.

Yes, the spec is kind of unclear here, and I think this was an area I  
complained about when it was in draft status, though I didn't see the  
scope of it then.  If the server prefers the session key or client- 
subkey enctype over all of those in the proposed list, it MUST NOT  
"negotiate" that type, but it also is not required to pick one of the  
others unless in prefers that other.

So I see three options, none of them all that great:
  * Pick an enctype from the list anyways, despite it not being  
preferred; this seems counter-indicated by the "...and the server  
prefers an enctype from the client's enctype list" bit.
  * Don't "negotiate", and instead fall back to pre-4537 behavior,  
namely, using the same enctype or one known a priori to be supported  
(though the client might then choose not to continue talking to the  
server).  Which essentially negates the "MUST NOT be negotiated" part,  
and hinges on how you define "negotiate" in this context.
  * Treat it as an error, and refuse to finish the authentication  
exchange, which seems kind of silly given that a pre-4537  
implementation would succeed in authenticating (though the client  
might then choose not to continue talking to it).  And perhaps some  
error code should be recommended.

Of course, option #1 assumes that at least one of the indicated  
enctypes is known and supported by the server implementation.

We should also get the spec fixed.  While it's an important technical  
point without (IMO) a clear and obvious single solution, in terms of  
document changes it might be just one or two new sentences.   
Procedurally, I don't know if it would qualify as an erratum or if we  
need to republish.

So, when might this come up?  The only example I can come up with off  
the top of my head is a telnet client sending an authenticator with an  
AES session key, but sending a list of DES enctypes (I'm assuming here  
that server-supplied subkey would be used under that protocol spec)  
because that's all it supports for telnet encryption.  The server  
might be configured to prefer DES over AES for this one application,  
but if its telnet implementation has an update to support AES, or it  
hasn't been updated to know about RFC 4537 (but the Kerberos library  
has, and enables it by default, with AES preferred over DES by  
default), then, maybe not.  I guess the only approach that would work  
in this case (in the sense of letting the two parties talk) is #1 --  
select an enctype from the list even if you like the session key type  
better.

If none of the enctypes are acceptable at all (e.g., you disabled DES,  
or the enctypes are not recognized by the server implementation)...  
well, I think #2 might let the client give a better error message, and  
gives a more secure indication that the server can't fulfill the  
request than an unprotected KRB-ERROR (which I assume would be the  
result of #3), but that doesn't mean that's what the spec says....

Ken
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg