Subject: draft-zhu-kerb-enctype-nego-04 changes from 03

From: Ken Raeburn <[email-masked]>
Date: Mon, 24 Oct 2005 17:06:10 -0400

Larry has submitted version -04 of this document.  It contains some  
changes he made based on some comments I made.  A quick summary:

The enctype list no longer needs to contain all the supported  
enctypes.  Specifically, enctypes less desirable to the client than  
the session key enctype, and any local-use (negative) enctype numbers  
not known to be supported by the server, are left out.

The session key enctype may be excluded from the enctype list at the  
client's choice; if it is excluded, this tells the server that it  
MUST NOT use that enctype (or, in other words, if it sends a subkey,  
and it supports this extension, it must use a different enctype,  
chosen from the list).  If the session key enctype is included, it  
goes at the end of the list.

New reference to X.680 as well as X.690 for ASN.1 DER.  Fixed  
reference to X.690.  Fixed spelling of Sam's last name.

Ken

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 24 Oct 2005 17:19:37 -0400

On Monday, October 24, 2005 05:06:10 PM -0400 Ken Raeburn <[email-masked]> 
wrote:

> The enctype list no longer needs to contain all the supported  enctypes.
> Specifically, enctypes less desirable to the client than  the session key
> enctype, and any local-use (negative) enctype numbers  not known to be
> supported by the server, are left out.
>
> client's choice; if it is excluded, this tells the server that it  MUST
> NOT use that enctype (or, in other words, if it sends a subkey,  and it
> supports this extension, it must use a different enctype,  chosen from
> the list).  If the session key enctype is included, it  goes at the end
> of the list.
>
> New reference to X.680 as well as X.690 for ASN.1 DER.  Fixed  reference
> to X.690.  Fixed spelling of Sam's last name.

We already did a last call on this document, but the changes decsribed
above are substantive in nature.  In addition, we have an outstanding
issue related to how enctype negotiation interacts with RFC4121 and 
prot_ready, which is on our agenda to discuss in Vancouver.  Once that
is resolved, we should be able to send this document on to the IESG.
In the meantime, comments on the above change are welcome.

-- Jeff

---

From: Chaskiel M Grundman <[email-masked]>
Date: Mon, 24 Oct 2005 17:57:09 -0400

> the list).  If the session key enctype is included, it  goes at the end

Unless some future specification makes this extension mandatory, the MUST 
seems silly. since there is no extension-specific data in the AP_REP, the 
client cannot tell if the server supports the extension unless the server 
changes the subkey type. (and so from a protocol point of view, there is no 
difference between the server not supporting the extension and ignoring 
this MUST)

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 24 Oct 2005 19:21:21 -0400

On Oct 24, 2005, at 17:57, Chaskiel M Grundman wrote:
> Unless some future specification makes this extension mandatory,  
> the MUST seems silly. since there is no extension-specific data in  
> the AP_REP, the client cannot tell if the server supports the  
> extension unless the server changes the subkey type. (and so from a  
> protocol point of view, there is no difference between the server  
> not supporting the extension and ignoring this MUST)

Right.  I mentioned this when talking with Larry.  I think the idea  
is, "this enctype from the KDC is too weak for exchanging lots of  
data, so if you don't come back with a different enctype, I'm just  
going to close the connection".  I'd prefer a SHOULD here, with an  
explanation of that case.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 Oct 2005 19:53:37 -0500

> difference between the server not supporting the extension and ignoring 

Since the client knows all the enctypes it supports it should suffice
for the client to say "pick one of these or I'll go away" -- there' no
need to say "do not pick one of these or I go away" and, besides, that
would cause problems if the server supported enctypes that the client
didn't ("the server picked an enctype I don't know" -> oops).