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

[Larry Zhu <[e-mail]>]

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