Subject: Re: draft-zhu-kerb-enctype-nego: enctype negotiation

From: Martin Rex <[email-masked]>
Date: Mon, 4 Apr 2005 16:22:35 +0200 (MET DST)

Was the option for GSS-API's PROT_READY entirely removed from krb5-cfx,
or will this paragraph need a "caveat" to indicate that the server may
have to process messages sent by initiator protected under the original,
initiator-asserted subsession key in case the initiator used the
PROT_READY feature in GSS-API.

-Martin

Liqiang wrote:
> 
> At IETF 62, we agreed to add text to say that the server-asserted subkey
> must win.
> 
> I proposed to change section 3 to have the following:
> 
>    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 MUST be
>    used for subsequent communication.
> 
>    This negotiation extension MUST NOT be used when the client does not
>    expect the subkey in the AP-REP message from the server.
> 
> -- Larry
> 
> 
>

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 4 Apr 2005 10:18:19 -0500

> PROT_READY feature in GSS-API.

CFX has text on PROT_READY.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Apr 2005 12:10:44 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Was the option for GSS-API's PROT_READY entirely removed
    Martin> from krb5-cfx, or will this paragraph need a "caveat" to
    Martin> indicate that the server may have to process messages sent
    Martin> by initiator protected under the original,
    Martin> initiator-asserted subsession key in case the initiator
    Martin> used the PROT_READY feature in GSS-API.

Being a bit more verbose than Nico, CFX has text on prot_ready already
pointing out exactly this issue.

---

From: Martin Rex <[email-masked]>
Date: Mon, 4 Apr 2005 21:45:21 +0200 (MET DST)

> pointing out exactly this issue.

I think that the term "subsequent communication" might be too vague in

:   This negotiation extension MUST NOT be used when the client does not
:   expect the subkey in the AP-REP message from the server.

without any examples/hints.

From the discussion of PROT_READY, it seems to me that it is somewhat
uncommon for traditional kerberized apps to have an initiator use
message protection before an authentication exchange that did
involve AP_REP is complete.

I'm a little worried about the locality of relevant information.
a "MUST" is pretty strong.  If a must has any caveats (like uncertainty
at what point it can really be enforced), then this should be directly
mentioned in a sufficiently clear fashion, so that it does not lead
to non-interoperable implementations for (new) implementors that
haven't yet fully absorbed the *entire* set of documents around the
technology.

-Martin