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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 27 Sep 2005 17:06:23 -0700

Here is my position:

Proto_ready is optional and it is not negotiable. It would be
unacceptable to require implementations to support proto-ready when they
want to do etype negotiation. 

RFC 4121 does not require the support of proto_ready, if the client
supports prot_ready and the server does not, and the client sends
messages protected by the proto_ready session key, the server can fail
to verify the message, and it has the right to do so.

I believe vista is compliant at the same time I can also accommodate
that proto_ready is a useful thing to have, we can certainly support
more features but we do not want to go out of our way to support
proto_ready, nor should any other implementers.  I believe supporting
proto-ready when we have non-cfx and cfx transition falls into the later
category.

Nico, to answer your question, SSPI does not support proto_ready today.

I do not think the acceptors MUST support proto_ready if the client
chooses to. 

This does not mean proto_ready is not useful, just like any other
non-negotiable and *optional* features, you just have to make sure both
the client and the sever support it before using it. But I would suggest
proto_ready is the first one in such category that we have encountered
this far.

-- Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Tuesday, September 27, 2005 1:59 PM
To: Liqiang(Larry) Zhu
Cc: Sam Hartman; [email-masked]
Subject: Re: prot_ready, CFX and Larry's enctype negotiation draft

On Tue, Sep 27, 2005 at 12:57:02PM -0700, Liqiang(Larry) Zhu wrote:
> Nicolas Williams wrote:
> > RFC1964->RFC4121 conversion through enctype negotiation seems more
> > likely to be difficult to implement
> 
> This turns out to be true, as it creates a lot more branches and makes
> the code fairly difficult to understand and maintain.

I can see that.  The same would probably be true for us.

> > Supposing for one minute that it is indeed difficult to implement
> > acceptor support for prot_ready + enctype negotiation then I suggest
> > dropping enctype negotiation.
> 
> I agree we should just drop enctype negotiation if you want
proto-ready
> for this upcoming release.

Here's what I want:  I want to see to it that we don't drop prot_ready
from the standard.  That was my fear.

As for your implementation, I would like prot_ready to work, of course,
but I have no urgent need for it.  I don't know what the likelihood of
this bug's fix falling through the cracks might be if you defer it; if
it might only be fixed in SP2, then yes :) do drop enctype negotiation
now and allow prot_ready to work.

Does the SSPI support prot_ready?  If not then one possibility, which I
find really icky, would be that only you implement enctype negotiation
until you fix your bug.  Problem is, there's no way to enforce that,
it's not a very good precedent, and looks really bad -- one participant
gets to implement a feature that they then get to trumpet, however
minor, and which noone else gets to implement, even though it's intended
to be an IETF Standards-Track (or Informational?) RFC...

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Sep 2005 00:05:37 -0500

On Tue, Sep 27, 2005 at 05:06:23PM -0700, Liqiang(Larry) Zhu wrote:
> 
> Here is my position:
> 
> Proto_ready is optional and it is not negotiable.

For the RFC1964 mechanism it was optional for the initiator only and the
acceptor couldn't tell if the initiator used it.

(Note, it's prot_ready, not proto_ready.)

>                                                   It would be

You forget that we have a standards-track API that supports prot_ready
(RFCs 2743, 2744, 2853) and a standards-track Kerberos V GSS-API
mechanism (RFC1964, now RFC4121) that has heretofore supported
prot_ready, and that the enctype negotiation extension to RFC4121 is not
an option for the initiator application[*] (it's an option for the
implementor), therefore the two features, in your proposal, become
mutually exlusive at the implementor's discretion only.

Those of us who make compatibility guarantees to users can't then
implement enctype negotiation since doing so would mean forgoing
prot_ready for a mechanism OID that users expect to see support
prot_ready (behaviour like prot_ready rises to the level of an
interface).

I think the backwards compatibility issue for applications using the
GSS-API (as opposed to the SSPI) and the Kerberos V mechanism _OID_
should make it clear that the lack of relevant text in RFC4121 is an
oversight -- we cannot have RFC4121 be backwards-incompatible with
RFC1964 at the API level.

Now, I grant that RFC2744/2853 implementors can simply never return the
prot_ready flag until the context is fully established, but not if
prot_ready is behaviour that applications expect of a given mechanism
and have rightly expected of it all this time.

And I grant that such implementors can simply choose to forgo enctype
negotiation.  But they'd be forced to, and that on the strength of your
not wanting to fix what is, in my view, a bug in your implementation,
while also wanting to use call your implementation compliant with the
relevant specs on a technicality.  This can be acceptable, but only if
the enctype negotiation I-D is limited to progressing to Informational
(or Experimental) RFC status.

In other words:  I propose that you either fix the bug in your
implementation, drop enctype negotiation or settle for it progressing no
further than Informational.

And let me repeat: I can accept your fixing that bug later, as long as
you commit to fixing it.  Martin may not find this so agreeable; Martin?

[*]  The enctype negotiation I-D provides no flag for the req_flags
     input parameter of GSS_Init_sec_context(), and any such flag would
     be very much Kerberos V specific -- allowable, *perhaps*, but
     problematic, not least because the application may not be in a
     position to know local policy w.r.t. enctypes and application
     implementors may not want to create a control knob for this.
     Martin?

> to verify the message, and it has the right to do so.

See above.

> proto-ready when we have non-cfx and cfx transition falls into the later

See above.

> Nico, to answer your question, SSPI does not support proto_ready today.

Fine.

> I do not think the acceptors MUST support proto_ready if the client

I don't agree.  See above.

> proto_ready is the first one in such category that we have encountered

RFC1964 initiators have never had to count on acceptors possibly not
supporting initiator use of prot_ready.  Since the OID for the mechanism
stayed the same in RFC4121 what you propose is tantamount to saying that
RFC4121 is not backwards compatible with RFC1964 at the API level.

Martin has already dug up past e-mail on this subject, so I'll refrain
from doing the same.  I think the backwards compatibility argument is
solid.

Cheers,

Nico
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 27 Sep 2005 22:37:36 -0700

Nico wrote:
> therefore the two features, in your proposal, become
 
Nico perhaps you have misunderstood Sam and me. we believe we can support prot_ready within the framework of CFX, you can do etype negotiation within the framework of CFX and support prot_ready at the same time. Prot_ready, CFX, etype negotiation can work very well together.
 
What we do not want is to retrofit the legacy RFC1964 implementations to support prot_ready. Prot_ready is broken with RFC1964, the acceptor can not tell which key the client has chosen, therefore I venture to say prot_ready has never worked with RFC1964. I doubt anybody has ever implemented prot_ready within the framework RFC 1964. 
 
These issues should be noted in the etype negotiation draft, I would be glad to add text saying you should not support prot_ready if the session key in the service ticket is not "newer", and nothing more and nothing less than that. For now, irronally the main rationale for adopting etype negotiation is to convert to use CFX. At the present, it is difficult to implement prot_ready in these cases, but I firmly believe RFC1964 implemenations are going away, 5 years from now, I would expect, all these are going to be non-issues. 
 
-- Larry

________________________________

From: Nicolas Williams [mailto:[email-masked]]
Sent: Tue 9/27/2005 10:05 PM
To: Liqiang(Larry) Zhu
Cc: Sam Hartman; [email-masked]
Subject: Re: prot_ready, CFX and Larry's enctype negotiation draft

See above.

See above.

Fine.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Sep 2005 01:14:20 -0500

On Tue, Sep 27, 2005 at 10:37:36PM -0700, Liqiang(Larry) Zhu wrote:
> Nico perhaps you have misunderstood Sam and me. we believe we can
> support prot_ready within the framework of CFX, you can do etype
> negotiation within the framework of CFX and support prot_ready at the
> same time. Prot_ready, CFX, etype negotiation can work very well
> together.

You've said that you don't believe that acceptors must support initiator
use of prot_ready.  I take issue with this.  Why did we bother with the
AcceptorSubkey per-message token flag then?

> What we do not want is to retrofit the legacy RFC1964 implementations
> to support prot_ready. Prot_ready is broken with RFC1964, the acceptor
> can not tell which key the client has chosen, therefore I venture to
> say prot_ready has never worked with RFC1964. I doubt anybody has ever
> implemented prot_ready within the framework RFC 1964. 

IIRC RFC1964 did not say much about acceptors asserting sub-session keys
and in general they did not, thus use of prot_ready was of no
consequence to acceptors.

> These issues should be noted in the etype negotiation draft, I would
> be glad to add text saying you should not support prot_ready if the
> session key in the service ticket is not "newer", and nothing more and
> nothing less than that. For now, irronally the main rationale for
> adopting etype negotiation is to convert to use CFX. At the present,
> it is difficult to implement prot_ready in these cases, but I firmly
> believe RFC1964 implemenations are going away, 5 years from now, I
> would expect, all these are going to be non-issues. 

RFC1964 implementation may well be gone in five years, but prot_ready
should not go away now, nor then.

As to enctype negotiation, if it is only for RFC1964->RFC4121 conversion
in the face of legacy KDCs, then pursue Informational status only and
I'll be happy.

Nico
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 27 Sep 2005 23:34:52 -0700

> in the face of legacy KDCs, then pursue Informational status only and
 
first on the technicality, it is not just about legacy KDCs, it is about the KDC can not decide if the server supports a given stronger enctype.

your statement is still incorrect. let's say, 5 years in the future, hypothetically we introduce the AES256-with-sha512-256 cipher, we will still want to use etype negotiation, but we will be able to support prot_ready at the same time, since we are not doing the RFC1964 -CFX conversion anymore.
 
I do not see a reason not to pursue this on the standards track,
 
because this draft has already passed WGLC, Sam brought this up on this list and suggested for me to add text noting the issues discussed here.

From: Nicolas Williams [mailto:[email-masked]]
Sent: Tue 9/27/2005 11:14 PM
To: Liqiang(Larry) Zhu
Cc: Sam Hartman; [email-masked]
Subject: Re: prot_ready, CFX and Larry's enctype negotiation draft

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 28 Sep 2005 16:16:05 +0200 (MET DST)

Liqiang wrote:
> 
> What we do not want is to retrofit the legacy RFC1964 implementations to
> support prot_ready. Prot_ready is broken with RFC1964, the acceptor can
> not tell which key the client has chosen, therefore I venture to say
> prot_ready has never worked with RFC1964. I doubt anybody has ever

RFC-1964 requires an initiator-asserted subkey and prohibits
an acceptor-asserted subkey.  Therefore within rfc-1964 PROT_READY
was an implementation option for the initiator, and it did not
require any changes to the acceptor.  The acceptor gss-api mechanism
is unable to tell whether the initiator used PROT_READY or not.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Sep 2005 11:42:44 -0500

Larry,

You don't seem to be reading my e-mail.

I cannot agree to seeing RFC4121 progress unless we all agree that the
acceptor MUST support use of prot_ready by the initiator.  That is my
bottom line, everything else is about accomodating you to some degree.

I'd like to hear from others.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Sep 2005 11:49:20 -0500

> is unable to tell whether the initiator used PROT_READY or not.

Er, I don't see where it does, but I agree that in practice that is how
it was, and I insist on backwards compatibility for this feature.

---

From: Martin Rex <[email-masked]>
Date: Wed, 28 Sep 2005 19:36:05 +0200 (MET DST)

> it was, and I insist on backwards compatibility for this feature.
 
I claimed that in rfc1964
 (1) initiator is required to assert a subkey
 (2) acceptor is prohibited from asserting a subkey

You're partly correct in that (1) ought to be there but is missing
and (2) is there but worded differently:

According to rfc-1964, an acceptor-asserted subkey may be present,
but MUST be ignored for the purpose of message protection:

see section 1.2 Per-Message and Context Deletion Tokens

   Several variants of cryptographic keys are used in generation and
   processing of per-message tokens:

        (1) context key: uses Kerberos session key (or subkey, if
        present in authenticator emitted by context initiator) directly

        (2) confidentiality key: forms variant of context key by
        exclusive-OR with the hexadecimal constant f0f0f0f0f0f0f0f0.

        (3) MD2.5 seed key: forms variant of context key by reversing
        the bytes of the context key (i.e. if the original key is the
        8-byte sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the seed key
        will be {hh, gg, ff, ee, dd, cc, bb, aa}).

According to this part of rfc-1964, only the subkey asserted by the
initiator may be used for the creation of the context key, from
which the message protection keys are derived.

However, the use of the (ticket) session key for message protection
would be allowed--although doing that would open a vulerability:
a message replay attack accross successive independent security
contexts established with the same service ticket (and therefore same
session key).  Because of this vulnerability, the initiator should
always create and include a subkey in the AP_REQ.

In 1996 the creation of a subkey during gss_init_sec_context()
was hardcoded in MIT Kerberos 5 (I specifically asked Ted Ts'o about
the cross-session replay vulnerability if the session key of the
service ticket was used and he confirmed that it couldn't happen
with MIT Kerbeors 5).

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Sep 2005 13:41:57 -0400

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

    Martin> Liqiang wrote:
    >>  What we do not want is to retrofit the legacy RFC1964
    >> implementations to support prot_ready. Prot_ready is broken
    >> with RFC1964, the acceptor can not tell which key the client
    >> has chosen, therefore I venture to say prot_ready has never
    >> worked with RFC1964. I doubt anybody has ever implemented
    >> prot_ready within the framework RFC 1964.

    Martin> RFC-1964 requires an initiator-asserted subkey and
    Martin> prohibits an acceptor-asserted subkey.  Therefore within

That's not quite my reading of RFC 1964.  Nothing I find in RFC 1964
forbids the acceptor from asserting a subkey.

The closest I could find is  the definition of the context key:

However from that text I'm honestly not clear whether the authors of
RFC 1964 intended to forbid ap_rep subkeys or whether they simply
forgot that could happen.

It is my understanding that rfc 1964 significantly predates prot_ready
as a feature.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 28 Sep 2005 11:14:43 -0700

> It is my understanding that rfc 1964 significantly predates prot_ready
 
I agreed. The behavior when the acceptor asserts a subkey is unspecified in RFC1964, the acceptor is not prohibited by RFC 1964 from asserting a subkey.

From: Sam Hartman [mailto:[email-masked]]
Sent: Wed 9/28/2005 10:41 AM
To: [email-masked]
Cc: Liqiang(Larry) Zhu; [email-masked]; [email-masked]
Subject: Re: prot_ready, CFX and Larry's enctype negotiation draft

---

From: Martin Rex <[email-masked]>
Date: Wed, 28 Sep 2005 20:29:02 +0200 (MET DST)

> > It is my understanding that rfc 1964 significantly predates prot_ready

On the contrary.  PROT_READY was brought up by Bob Blakley on the
33rd IETF July 1995 meeting in Stockholm, discussed and added added to the
GSS-API v2 draft in August 1995.

The Kerberos GSS-API was last called in early 1996.

>
> I agreed. The behavior when the acceptor asserts a subkey is unspecified =
> in RFC1964, the acceptor is not prohibited by RFC 1964 from asserting a =
> subkey.

As I wrote in a previous Email, the acceptor is not prohibited from
asserting a subkey, but both, acceptor and initiator are MUST derive
the context key relevant for the message protection ONLY from the
initiator-asserted subkey.

De-facto, the acceptor-asserted subkey must be entirely ignored, if present.
This is what MIT Kerberos code has been doing (it correctly creates the
context key for the security context during the initial call to
gss_init_sec_context() and entirely ignores whether the AP_REP (in
the mutual auth case) contains a subkey.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Sep 2005 09:38:47 -0500

> which the message protection keys are derived.

Thanks!

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Sep 2005 11:15:00 -0500

> The Kerberos GSS-API was last called in early 1996.

I find Martin's arguments quite convincing.  I conclude that prot_ready
*is* a feature of the Kerberos V mechanism.

Because applications may rely on it, because it is an initiator option,
because the application doesn't get to request it, and because it is not
negotiated (in part because the application doesn't get to request it) I
think it must work reliably.

Yes, the acceptor could reject per-message tokens due to token
corruption, say, but it can't reject pre-full context establishment
per-message tokens out of hand as applications that rely on prot_ready
may simply fail (and retry only to fail again).

If RFC1964 essentially guaranteed that acceptors can honor initiator use
of prot_ready, then RFC4121 must as well, implicitly as it stands
(though it should have been explicit) -- RFC4121 uses the same mechanism
OID and applications can rightfully rely on mechanism support for
prot_ready.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Sep 2005 16:12:05 -0500

Does any of this matter?  Larry can claim compliance, and if any of our
(the WG's other participants') customers ever complains about prot_ready
interop problems we can always direct them to Microsoft.

So maybe all I should be asking for is that when RFC4121 progresses that
we respin it to add the missing explicit requirement for acceptor
support of initiator use of prot_ready (remember, I think such a
requirement is implied already).  Maybe we can defer that discussion
till then -- I sure don't have the bandwidth available for having it
now.

Cheers,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 29 Sep 2005 18:26:13 -0400

> till then -- I sure don't have the bandwidth available for having it

I've been planning on rereading this discussion and making some comments, 
but just haven't had the bandwidth for it this week.  However, I'll make a 
couple, and leave the rest for later.

RFC4121 is published.  We're not going to change it.  As far as I'm 
concerned, there is no WG decision to be made about what it should say; it 
says what it says.

Based on discussions during last week's WG meeting (for which I'll prepare 
minutes next week), we will need to spin a new version of the CFX document 
in order to progress to Draft Standard.  At that time, we will have ample 
opportunity to clarify whether acceptors are required to correctly process 
per-message tokens prepared using a key other than the acceptor-asserted 
subkey.  Note that I am not taking a position at this time on what the 
answer should be, but I do believe it should be clarified, particularly 
since it has apparently led to different interpretations by two people who 
should be extremly familiar with this protocol.

As far as enctype negotiation goes, it is true that we ran a WGLC back in 
July.  There were some comments during last call, which hopefully were 
addressed in the version of the document submitted soon after.  However, 
one of the properties of our process is that it is (almost) never too late 
to make comments.

So, Nico's comments about interactions between GSSAPI-CFX and enctype 
negotiation are not out of order.  To the extent that there is a conflict 
between the two documents, if any, we need to resolve it before enctype 
negotiation document can move forward.  Again, I'm not taking a position at 
this time on whether there is a conflict and, if so, what to do about it.

It does seem to me that the discussion has gotten rather heated, and maybe 
it is time to step back for a moment.  I don't think it is critical to 
address this right away.  Perhaps it would be better to go back to 
finishing PKINIT?

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Sep 2005 17:40:31 -0500

> this time on whether there is a conflict and, if so, what to do about it.

Technically the only IETF-related issue is: does RFC4121 require,
implicitly or otherwise, that acceptors support initiator use of
prot_ready?

The conflict is this: Larry claims that it does not and that,
furthermore, it's too hard to implement that when the initiator also
implements enctype negotiation, therefore the two features are mutually
exclusive in his implementation, which he considers to be within spec,
while I disagree about 4121 and so consider his proposed resolution a
bug in his implementation.

None of this need be resolved until the WG proposes that 4121 be moved
to Draft-Standard.

> address this right away.  Perhaps it would be better to go back to 

Yes (I've been AWOL from that discussion -- it's taken this controversy
to reel me back in).

---

From: Sam Hartman <[email-masked]>
Date: Fri, 30 Sep 2005 13:00:39 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> I don't think it is critical to address this right away.
    Jeffrey> Perhaps it would be better to go back to finishing
    Jeffrey> PKINIT?

If Larry is going to comply with the result he needs to know what the
result is right away.

AS an implementer, I consider this issue absolutely critical.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 30 Sep 2005 12:20:19 -0500

> If Larry is going to comply with the result he needs to know what the

As I've said, I don't think this is urgent -- he can fix the code later,
and to be compliant but for this one issue does not seem like a big deal
to me, from a marketting point of view.  Of course, Larry may see it
differently -- being able to claim full compliance may be a big deal to
him.

Shall we have a consensus call on whether RFC4121 acceptors MUST, SHOULD
or MAY support initiator use of prot_ready prior to full security
context establishment?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 30 Sep 2005 13:26:23 -0500

Er, well, maybe there is no issue.

PROT_READY is a per-context feature, not per-mechanism.

So what Larry proposes can work interoperably and backwards-compatibly
manner as long as it is documented in the enctype negotiation I-D.

Nico
--

---

From: Chaskiel M Grundman <[email-masked]>
Date: Fri, 30 Sep 2005 15:46:24 -0400

> manner as long as it is documented in the enctype negotiation I-D.
Eh? if the implementation uses enctype negotiation behind the applications 
back, then either
a) it needs to not report PROT_READY, or
b) it will lose when talking to MS's implementation.

Earlier, you seemed to rule out option (a):
> (though it should have been explicit)

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 30 Sep 2005 15:01:56 -0500

> Eh? if the implementation uses enctype negotiation behind the applications 

I can only do it behind the app's back.

> a) it needs to not report PROT_READY, or

Yes.