Subject: RE: prot_ready, CFX and Larry's enctype negotiation draft

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 28 Sep 2005 17:38:21 -0700

Martin Rex wrote:

> And before we submitted CFX I asked for confirmation that the there
was

> no ambiguity in which situations the acceptor will have to process

> tokens protected under the initiator-asserted subkey when prot_ready
(2)

> is being used by the initiator:

It is crystal clear in RFC 4121 which key is used (namely the acceptor
subkey always wins). 

Out of the existing RFC1064 implementations, the acceptor asserted
subkey gets ignored by MIT Kerberos.

IIUC, Nico and I have difference in opinion only for the question
whether we can say the acceptor that implements RFC4121 MUST support
prot_ready.  Nico, if I did not summarize our discussion here correctly,
please let me know.

Also, it seems to me that only Nico and I were talking for this subject,
I would appreciate others to chime in here as well.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Monday, September 26, 2005 1:34 PM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: prot_ready, CFX and Larry's enctype negotiation draft

Sam Hartman wrote:
> 
> We ran into an interesting issue at the interop event yesterday.
> 
> Microsoft does not currently support prot_ready.  For this reason they
> thought they didn't need to consider the case where the acceptor
> asserted subkey flag is clear in CFX per-message tokens.

Now that is really amazing!
It is a long-known characteristic, I have brought up this issue several
times starting in 2003 and it has been extensively discussed.

The acceptor will have to process protected messages with the
initiator-asserted subkey in two situations:
 (1) with uni-directional authentication single-token
     security context establishment and
 (2) when the initiator used PROT_READY on a two-token security context
     establishment with mutual-authentication

This is what Larry answered on issue (1):
:   Date: Fri, 31 Oct 2003 09:06:29 -0800
:   Subject: RE: comments on draft-ietf-krb-wg-gssapi-cfx-02.txt
:   From: "Liqiang\(Larry\) Zhu" <[email-masked]>
:   To: <[email-masked]>
:   Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>,
:       <[email-masked]>, <[email-masked]>, <[email-masked]>
:
: Martin Rex wrote:
: >> Could you please address the issue of unidirectional one-token
security
: >> context establishment (which is purely at the discretion of the
initiator
: >> in rfc1964).
: 
: In that case, the acceptor won't have a chance to assert a subkey and
it
: is allowed.
: 
: Note in the last IETF interim meeting, we decided not to discuss how
to
: negotiate acceptor-asserted-subkey and
: acceptor-enforced-subkey-without-replay-cache in the CFX draft, and
: leave those to the extensions or other future drafts. Unfortunately
this
: was not mentioned in the meeting minutes.
: 
: Does this make sense now?
: 
: Larry

And before we submitted CFX I asked for confirmation that the there was
no ambiguity in which situations the acceptor will have to process
tokens protected under the initiator-asserted subkey when prot_ready (2)
is being used by the initiator:

:
:   Date: Mon, 4 Apr 2005 21:45:21 +0200 (MET DST)
:   From: Martin Rex <[email-masked]>
:   Subject: Re: draft-zhu-kerb-enctype-nego: enctype negotiation
:   To: [email-masked] (Sam Hartman)
:   Cc: [email-masked], [email-masked]
:
: Sam Hartman wrote:
: >
: > >>>>> "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.
: 
: 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

> 
> Put another way, prot_ready is not a protocol level feature, it is an
> implementation feature.  There is no requirement that you make sure
> both sides of a connection support prot_ready before using it.

It is both.  It is a protocol level feature -- in that the protocol
dictates if and when it can be done at all.  The way PROT_READY was
designed for rfc-1964, it was optional-to-implement for the
initiator and transparent for the acceptor (since rfc-1964 did not
have a situation where an acceptor could call message protection
on an incomplete security context).  

PROT_READY was never designed to be negotiable, although one could
think about it for protocols that require multiple token exchanges
for security context establishment.

Actually, NONE of the security context attributes in rfc-1964 are
negotiable when the initiator requests uni-directional authentication
that uses only a single context token from initiator to acceptor.

-Martin