Subject: RE: Refactoring Kerberos pre-authentication

From: "Eric Rosenfeld" <[email-masked]>
Date: Mon, 15 Sep 2003 16:43:14 -0600

Jeff,

True.  But one could reasonably argue that the reason why there is such
a large deployed base is because the Kerb WG was unable to meet the
needs, and timeline, of its users.  This same group should not now be
punished because the WG is just now catching up.

Of course, I won't make that argument.  I would just request that this
WG minimize the impact, as much as possible, to existing products.  The
impact to existing product is much less if some identifier values are
changed, as opposed to fundamentally changing message contents or
encoding, for example.  This is because the amount of code that needs to
be changed is far greater in the latter case, and thus the potential for
error is also far greater.

I don't believe any hands are being tied here, but I do believe
sensitivity towards an installed base should be part of the decision
making criteria.

Regards,
Eric

-----Original Message-----
From: Jeffrey Altman [mailto:[email-masked]] 
Sent: Monday, September 15, 2003 2:43 PM
To: [email-masked]
Subject: Re: Refactoring Kerberos pre-authentication

Eric, Sasha:

A deployed base is not justification for the IETF to publish a document 
as a Standards Track RFC.  I believe the position was made clear.  The 
PK-INIT document as it was at -16 is not ready for standards track.  We 
have already agreed that the values used to identify the "standards 
track" version of PK-INIT are going to be different from those used in 
-16.  The reason is that we do not want the working group to have its 
hands tied by a decision to ship code based upon a document which has 
not completed the IETF process. 

Jeffrey Altman

Eric Rosenfeld wrote:

>Obviously, I second Sasha's comment.  We have an entire industry that
>has implemented PKINIT 16, so I also hope that our goal is to progress,
>as much as possible, a bit-exact version to RFC.
>
>-Eric
>
>
>
>-----Original Message-----
>From: Medvinsky Alexander-MGI1174 [mailto:[email-masked]] 
>Sent: Thursday, September 11, 2003 4:08 PM
>To: 'Joel N. Weber II'
>Cc: [email-masked]
>Subject: RE: Refactoring Kerberos pre-authentication
>
>
>With a relatively large number of vendors that have already implemented
>PKINIT 16, I hope that it can advance to a standards track RFC without
>any significant changes, except for removal of some options that no one
>is using.  There could be a successor to PKINIT that is also on
>standards track, similar to Kerberos extensions vs. clarifications.
>
>
>-----Original Message-----
>From: Joel N. Weber II [mailto:[email-masked]]
>Sent: Thursday, September 11, 2003 2:20 PM
>To: Medvinsky Alexander-MGI1174
>Cc: [email-masked]
>Subject: Re: Refactoring Kerberos pre-authentication
>
>
>I believe it is probably desireable to get PKINIT 16 to a publishable
>state, regardless of whether we end up with a more general framework.
>If we do end up agreeing to a more general framework, we may want to
>publish a revised document that is essentially the PKINIT 16 protocol
>as an informational RFC.
>
>
>
>
>  
>

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 15 Sep 2003 22:37:36 -0400

Eric:

I really don't want to have this argument, but if you were concerned 
about the installed base you would have stopped at -9 which is the 
version implement by Microsoft since their installed base is 
significantly larger than the PacketCable installed base.

I am not going to go out of my way to force gratuituous changes to the 
protocol for the purpose of breaking compatibility.  However, given the 
issues on the table I think it is going to be very hard not to.  As we 
discussed on the phone, due to the widespread implementation of 
Microsoft's PKINIT we do not have a choice but to change the Preauth 
Type Identifiers.  This may not be a problem for PacketCable since your 
use of this protocol is (I believe) within a somewhat closed world but 
it is certainly an issue for the rest of us.

As for the Kerb WG being unable to meet the needs of PacketCable this is 
true.  The limited available time of the group members combined with the 
need to come to a consensus on Clarifications and Extensions prevented 
us from spending time on PK-INIT.  We had enough time to read the drafts 
and determine that there were serious problems with it.  We did not have 
time to spend to fix it.  We welcome the fact that PacketCable is now 
interested in contributing to the working group efforts.  Perhaps with 
the assistance of addition dedicated workers we can move things forward 
more quickly.  But moving quickly does not mean compromising on security 
or the integrity of the Kerberos protocol.

We will talk about the outstanding issues tomorrow.  See you then.

- Jeff

---

From: "Joel N. Weber II" <[email-masked]>
Date: Mon, 15 Sep 2003 22:10:07 -0400

> error is also far greater.

It all depends which user community you care about.  And I don't think
PacketCable is the only user of Kerberos.

For the user community which wants to be able to use Diffie-Hellman
with a variety of methods for the client to authenticate itself to the
server, sometimes using a public key to authenticate the client to the
server, and sometimes using a public key to authenticate the server to
the client, special casing certain stuff to be more similar to a
historical PKINIT spec is going to increase code complexity,
increasing the risk that there will be security bugs.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 16 Sep 2003 12:36:25 -0700 (PDT)

> increasing the risk that there will be security bugs.

Can I ask a really stupid question? Which user
community would that be? To my knowledge the only
communities actually using PKINIT are M$ and
Packetcable. I'd be glad to hear othewise.

		 Mike