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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 27 Sep 2005 12:57:02 -0700

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.

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

-- larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Tuesday, September 27, 2005 11:55 AM
To: Sam Hartman; [email-masked]
Subject: Re: prot_ready, CFX and Larry's enctype negotiation draft

On Tue, Sep 27, 2005 at 01:41:50PM -0500, Nicolas Williams wrote:
> How can that one difference make it difficult to implement prot_ready
+
> 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
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Sep 2005 15:58:53 -0500

> the code fairly difficult to understand and maintain.

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

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