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

From: Sam Hartman <[email-masked]>
Date: Fri, 23 Sep 2005 13:56:57 -0400

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.

however there's a case where that's not true.

* client supports prot_ready
* client  runs init_sec_ctx
* The client calls gss_wrap
* the server calls gss_acceept_sec_cxt
* the server tries to unwrap the client token

Note that you end up with a wrap token from the client that has the
acceptor_asserted_subkey flag cleared.  Also note that this can happen
even when the server does not support prot_ready.

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 turns out that this is made more complicated by Larry's enctype
negotiation draft.  Is it OK for a client to send a non-CFX token as
part of prot_ready and then later to send a CFX token after
negotiation completes?

What if all the enctypes are CFX?  Is it OK for a client to propose an
aes-128 subkey, send a wrap token and then later receive an aes-256
subkey from the server?

Larry claims all these combinations are hard to implement.  I
certainly agree the non-CFX->CFX conversion is really hard to
implement.

He proposes that we add a restriction preventing his negotiation
mechanisms be used in cases where the client will use the session key
or subsession key before processing the ap_rep from the server.  I
think such a restriction is reasonable.

Ken believes that some day we may want to support prot_ready in these
situations.  He proposed adding a flag indicating the level of support
for key use before negotiation completes required by the client.  The
idea would be that if the server did not support the appropriate level
of key use it would ignore the negotiation.

Larry said that such a change would be problematic for him from
implementation timing reasons.

I pointed out that we could always define a new negotiation authz_data
type with different key usage requirements if we need this
functionality.

I tend to believe that prot_ready will be important long-term but
believe this will be an acceptable compromise.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 23 Sep 2005 16:23:21 -0500

> both sides of a connection support prot_ready before using it.

Oh no, it *is* a protocol level feature -- that is precisely why we
added that acceptor_asserted_subkey flag.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 23 Sep 2005 16:27:49 -0500

> added that acceptor_asserted_subkey flag.

Furthermore, PROT_READY is very important, both for a message-efficient
SASL/GSS bridge and for stackable pseudo-mechanisms.

This is a bug in Windows, not in the spec.  Please fix the bug in
Windows.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 23 Sep 2005 16:36:12 -0500

> This is a bug in Windows, not in the spec.  Please fix the bug in

Also, it's not an urgent bug -- but it has a good chance of hurting
eventually.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 23 Sep 2005 16:48:56 -0500

> aes-128 subkey, send a wrap token and then later receive an aes-256

All uses of PROT_READY that I've seen are about sending additional data
of similar nature to what is already sent in the AP-REQ -- whether it be
SASL security layer negotiation, or channel bindings, and so using the
weaker enctype for the PROT_READY per-message token is no more a
security problem than it is to try to upgrade the sub-session enctype
through Larry's negotiation draft is in the first place.  (What a
mouthful.)

Even in other circumstances, I can't imagine any application using more
than one, or a small handful of small pre-GSS_S_COMPLETE per-message
tokens.  For such applications using the weaker key for such per-msg
tokens is no more a problem, from a cryptogranalytic p.o.v., than is
using that same weaker enctype for the AP-REQ and AP-REP.

So, I'd only really worry about applications that send large amounts of
data protected with pre-GSS_S_COMPLETE per-message tokens.  I can't
even imagine any such applications.

> certainly agree the non-CFX->CFX conversion is really hard to

Oh I agree about non-CFX->CFX conversion -- let's not do that, please.

Besides not specifying non-CFX->CFX conversion I might agree to a limit
on how many pre-GSS_S_COMPLETE per-message tokens an initiator is
allowed to send, but I do seem to recall us discussing this at dinner
some meetings back and deciding not to.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Mon, 26 Sep 2005 22:33:54 +0200 (MET DST)

> 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

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 Sep 2005 22:15:26 -0500

>      establishment with mutual-authentication

RFC4121 (CFX) has a flag in per-msg tokens used to indicate which of the
two sub-session keys was used so that the acceptor can tell
pre-GSS_S_COMPLETE, PROT_READY per-msg tokens from others.

> is being used by the initiator:

The facilities needed to avoid any ambiguity are there, but the language
isn't -- we're missing a sentence that says that acceptors MUST select
a key for unwrapping/verifying wrap/MIC tokens according to the
presence/absence of the AcceptorSubkey flag in the token header.  Still,
that is strongly implied.  Grr.

> on an incomplete security context).  

Right, it's optional for the initiator, but can't be optional for the
acceptor because...

> for security context establishment.

...it isn't negotiable.

Argh

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Sep 2005 12:37:23 -0400

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

    Martin> Sam Hartman wrote:
    >> 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.

    Martin> The acceptor will have to process protected messages with
    Martin> the initiator-asserted subkey in two situations: (1) with
    Martin> uni-directional authentication single-token security
    Martin> context establishment and 

Everyone handles this today.

    Martin> (2) when the initiator used
    Martin> PROT_READY on a two-token security context establishment
    Martin> with mutual-authentication

Agreed.  I think we all agree that the acceptor needs to handle this.
  We found a case where it interacted badly with Larry's enctype
  negotiation draft.  Fortunately that's still a draft.  The whole
  point of interop events is to find these kind of bugs and fix them.

So you should not be surprised when bugs happen; you should simply
help us fix the specs.

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

And I think we all agree on what should happen.  What we hadn't seen
was the interaction with the enctype negotiation draft.

    >>  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.

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

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

Understood and agreed.

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

Nor really in any other situation for that mechanism.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Sep 2005 14:30:13 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Fri, Sep 23, 2005 at 04:27:49PM -0500, Nicolas
    Nicolas> Williams wrote:
    >> This is a bug in Windows, not in the spec.  Please fix the bug
    >> in Windows.

    Nicolas> Also, it's not an urgent bug -- but it has a good chance
    Nicolas> of hurting eventually.

I agree that if you don't use Larry's enctype negotiation then Windows
must accept packets with the acceptor asserted subkey flag clear.  I
think Larry agrees to this too.

However I don't see why we need to force everyone implementing his
enctype negotiation draft to support prot_ready even when one of the
implementers claims that is very difficult to do.

What I'm proposing is that you as a client choose either prot_ready or
enctype negotiation.

If there is interest later we can specify allowing clients to choose
both.

Nothing in your arguments addresses why this is a bad idea.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Sep 2005 13:41:50 -0500

> implementers claims that is very difficult to do.

Wether enctype negotiation is used or not there are two keys: the
initiator sub-session key and the acceptor sub-session key and the
acceptor has to keep both for prot_ready support.

The only difference when enctype negotiation is used is that those keys
are of different enctypes.

How can that one difference make it difficult to implement prot_ready +
enctype negotiation?  I don't see it.

> What I'm proposing is that you as a client choose either prot_ready or

How can it choose?  There are no req_flags for either PROT_READY or
enctype negotiation.  So it's not the client that chooses then but the
implementor?  Sorry, but that's just not acceptable.

> Nothing in your arguments addresses why this is a bad idea.

I give one above.  Larry may then propose adding a GSS_C_FLAG_* for
enctype negotiation.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Sep 2005 13:55:09 -0500

> enctype negotiation?  I don't see it.

Supposing for one minute that it is indeed difficult to implement
acceptor support for prot_ready + enctype negotiation then I suggest
dropping enctype negotiation.

Prot_ready is an important feature of the API and protocol whereas
enctype negotiation is gravy, and there is an alternative to enctype
negotiation anyways: upgrade your KDCs and update the host principal KDB
records.

I don't think we can make the initiator choose prot_ready or enctype
negotiation.  Short of Larry changing his mind about implementation
complexity or dropping enctype negotiation I see no other solution
(well, I've not searched for one).

RFC1964->RFC4121 conversion through enctype negotiation seems more
likely to be difficult to implement (though I have not thought about
it).  Not having RFC1964->RFC4121 conversion means that enctype
negotiation is really only useful for AES-128->AES-256 upgrading, which
does not seem so useful, not useful enough to sacrifice PROT_READY IMO.

Nico
--