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

[Luke Howard <[e-mail]>]

Option #2 is essentialy what I implemented.

Sent from my iPhone

On 30/12/2008, at 4:57 PM, Larry Zhu <[e-mail]> wrote:

> The client has to deal with servers that do not support RFC4537,  
> thus I tend to believe it is acceptable to ignore the etype list  
> from the client.  This is option #2 from the list Ken provided.
>
>
> -----Original Message-----
> From: Ken Raeburn [mailto:[e-mail]]
> Sent: Monday, December 29, 2008 6:19 PM
> To: Luke Howard
> Cc: Larry Zhu; [e-mail]
> Subject: 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
[e-mail]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg