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

From: Luke Howard <[email-masked]>
Date: Sat, 27 Dec 2008 10:49:13 +1100

RFC 4537 says:
    If the EtypeList is present and the server prefers an enctype from
    the client's enctype list over that of the AP-REQ authenticator
    subkey (if that is present) or the service ticket session key, the
    server MUST create a subkey using that enctype.  This negotiated
    subkey is sent in the subkey field of AP-REP message, and it is then
    used as the protocol key or base key [RFC 3961] for subsequent
    communication.

    If the enctype of the ticket session key is included in the enctype
    list sent by the client, it SHOULD be the last on the list;
    otherwise, this enctype MUST NOT be negotiated if it was not  
included
    in the list.
I found this a little ambiguous to implement.

If the AP-REQ authenticator subkey is present but its enctype is  
absent from the EtypeList, is it OK to negotiate? The first paragraph  
suggests yes.

If the enctypes of the AP-REQ authenticator subkey and the ticket  
session key are the same, and this enctype is absent from EtypeList,  
is it OK to negotiate?

How does one distinguish between a conforming RFC 4537 implementation  
(that avoids negotiating the ticket session key enctype if absent from  
EtypeList) and an implementation that doesn't understand RFC 4537 at  
all (which will use the subkey or ticket session key enctype)?

Preliminary implementation for MIT is in mskrb-integ branch, feel free  
to test (I have tested against W2K8, against itself, and negotiating  
the experimental AES-CCM enctype).

-- Luke
--
www.padl.com | www.fghr.net

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Mon, 29 Dec 2008 00:18:58 -0800

Luke wrote:

Ø  If the enctypes of the AP-REQ authenticator subkey and the ticket session key are the same, and this enctype is absent from EtypeList, is it OK to negotiate?

It falls out the circumstances described in RFC4537. Why would you do that? I guess that the answer is that given you run into a situation not prescribed in RFC4537, it is an undefined behavior based on RFC4537.

Ø  How does one distinguish between a conforming RFC 4537 implementation (that avoids negotiating the ticket session key enctype if absent from EtypeList) and an implementation that doesn't understand RFC 4537 at all (which will use the subkey or ticket session key enctype)?

The behavior is defined by RFC4121, the client MUST pick up the etype that the server asserts or fail. For RFC1964 however,  the behavior is undefined (or implementation defined :)). For MIT RFC1964 implementations, the server asserted key is dropped' for MS implementations, it  basically does what RFC4121 says in this regard, and honors the server's assertion.

--larry

From: Luke Howard [mailto:[email-masked]]
Sent: Friday, December 26, 2008 3:49 PM
To: Larry Zhu
Cc: [email-masked]
Subject: RFC 4537 question

RFC 4537 says:

   used as the protocol key or base key [RFC 3961<http://www.rfc-archive.org/getrfc.php?rfc=3961>] for subsequent

   communication.

   otherwise, this enctype MUST NOT be negotiated if it was not included

   in the list.

If the AP-REQ authenticator subkey is present but its enctype is absent from the EtypeList, is it OK to negotiate? The first paragraph suggests yes.

If the enctypes of the AP-REQ authenticator subkey and the ticket session key are the same, and this enctype is absent from EtypeList, is it OK to negotiate?

How does one distinguish between a conforming RFC 4537 implementation (that avoids negotiating the ticket session key enctype if absent from EtypeList) and an implementation that doesn't understand RFC 4537 at all (which will use the subkey or ticket session key enctype)?

Preliminary implementation for MIT is in mskrb-integ branch, feel free to test (I have tested against W2K8, against itself, and negotiating the experimental AES-CCM enctype).

-- Luke
--
www.padl.com | www.fghr.net<http://www.fghr.net>
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Luke Howard <[email-masked]>
Date: Tue, 30 Dec 2008 01:46:27 +1100

Hi Larry,

> Luke wrote:
> Ø  If the enctypes of the AP-REQ authenticator subkey and the ticket  
> It falls out the circumstances described in RFC4537. Why would you  
> do that? I guess that the answer is that given you run into a  
> situation not prescribed in RFC4537, it is an undefined behavior  
> based on RFC4537.

I'm not sure I understand this.

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.

> Ø  How does one distinguish between a conforming RFC 4537  
> implementation (that avoids negotiating the ticket session key  
> enctype if absent from EtypeList) and an implementation that doesn't  
> understand RFC 4537 at all (which will use the subkey or ticket  
> session key enctype)?
>
> The behavior is defined by RFC4121, the client MUST pick up the  
> etype that the server asserts or fail. For RFC1964 however,  the  
> behavior is undefined (or implementation defined J). For MIT RFC1964  
> implementations, the server asserted key is dropped’ for MS  
> implementations, it  basically does what RFC4121 says in this  
> regard, and honors the server’s assertion.
>

So, the MIT code will use the server subkey in the following cases:

(a) an encryption type that requires RFC 4121 was used (s.4.2.2  
notwithstanding)
(b) the initiator specified GSS_C_DCE_STYLE
(c) if an encryption type different from the AP-REQ subkey or ticket  
session key was negotiated via RFC 4537

I believe this to be identical to the MS behaviour.

-- Luke

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 29 Dec 2008 21:18:31 -0500

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

---

From: Larry Zhu <[email-masked]>
Date: Mon, 29 Dec 2008 21:57:15 -0800

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:[email-masked]]
Sent: Monday, December 29, 2008 6:19 PM
To: Luke Howard
Cc: Larry Zhu; [email-masked]
Subject: Re: [Ietf-krb-wg] RFC 4537 question

Ken

---

From: Luke Howard <[email-masked]>
Date: Tue, 30 Dec 2008 22:48:48 +1100

Option #2 is essentialy what I implemented.

Sent from my iPhone

On 30/12/2008, at 4:57 PM, Larry Zhu <[email-masked]> 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.
>
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 30 Dec 2008 20:42:18 -0500

--On Monday, December 29, 2008 09:57:15 PM -0800 Larry Zhu 
<[email-masked]> 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.

First, it is worth noting that a client subkey, if present, should always 
have the same enctype as the ticket session key, because that is the only 
enctype which the client knows the server can support.  Ordinarily, the 
same would be true of the server subkey; the purpose of this extension is 
to give the server enough knowledge to select a better enctype.

The first paragraph Luke quoted is the one that causes negotiation to take 
place at all -- the server is expected to pick the best enctype available 
from among those listed by the client.  The MUST there is superfluous; it's 
not like there's any alternative behavior.

To the best of my recollection, the point of the second paragraph was to 
allow the client to signal, by omitting the session key enctype from the 
list, that it does not consider that enctype suitable, and to require in 
that situation that the server pick something that _is_ suitable.  This is 
not unreasonable; the enctypes suitable for authentication may be different 
from those suitable for ongoing communication.

Luke asks how to tell the difference between a conforming implementation of 
RFC4537 and an implementation which doesn't understand it at all.  In the 
specific case where the etypelist does not include the session key enctype, 
this is easy -- a conforming implementation will never use that enctype, 
while an RFC4537-unaware implementation will never use anything else.

But, it's not clear to me that you need to be able to tell the difference. 
The important thing is to decide what you're willing to accept, signal that 
correctly, and then act accordingly.  If a client is willing to accept the 
session key enctype, then it should include it in the etypelist and accept 
an AP-REP which either asserts a subkey using it or (depending on the 
application's requirements) does not assert a subkey at all.  If it is not 
willing to accept the session key enctype, then it should omit it from the 
etypelist and reject an AP-REQ which does not assert a server subkey of an 
enctype included in the list -- regardless of the reason.

It is pointless to say "I'm going to support the session key enctype, but 
only if the server doesn't know how to negotiate, and not if the server 
does know how to negotiate but doesn't like any of the alternatives I 
offer".

-- Jeff