Subject: RE: comments on draft-ietf-krb-wg-gssapi-cfx-02.txt

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 14 Oct 2003 01:27:35 -0700

Jeffrey Hutzelman wrote:

> I think maybe we want a new OID after all.  Under CFX, both OID's 
> would indicate support for the same mechanism, except that the use of
the "new"
> mechanism OID would indicate support for new token formats. 

Nicolas Williams wrote:

>> A new OID would be fine in addition to the negotiation by Kerberos V 
>> minor version / Kerberos V ticket session key enctype.

Using a new OID would make this mechanism very hard to deploy and would
delay MIT's ability to implement.  The difficulty of deployment makes
that the wrong call for the IETF.

Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Monday, October 13, 2003 8:52 AM
To: Jeffrey Hutzelman
Cc: Ken Raeburn; Liqiang(Larry) Zhu; [email-masked]; Douglas E.
Engert
Subject: Re: comments on draft-ietf-krb-wg-gssapi-cfx-02.txt

On Sun, Oct 12, 2003 at 11:44:51AM -0400, Jeffrey Hutzelman wrote:
> 
> 
> On Friday, October 10, 2003 19:09:50 -0400 Ken Raeburn
<[email-masked]> 
> wrote:
> 
> >Jeffrey Hutzelman <[email-masked]> writes:
> >
> >>>Section 6:
> >>>
> >>>What does "use of Kerberos Version 5 extensions" mean?  I think I
know
> >>>what you mean by it, but the spec should be useful to an
implementor
> >>>(now, or 10 years in the future) who isn't keeping tabs on the
working
> >>>group discussions.
> >>
> >>Well, you can't actually refer to kerberos-extensions without
waiting
> >>for it.  Fortunately, you don't have to:
> >>
> >>"use of a version of Kerberos later than Kerberos Version 5
> >>Specification 2".
> >
> >In other words, we're declaring plain old RFC 1964 to be a pre-5.3
> >application, so a KDC or service shouldn't indicate that the service
> >principal supports 5.3 until the GSSAPI mechanism is upgraded.
Right?

Well, almost.  The new mech will be used with pre-extensions Kerberos V
for new enctypes and it will be used with extended Kerberos for all
enctypes by clients that support it (any clients that don't have to be
pre-extensions clients and must not support new enctypes).

> Hm.  That does seem to be what I said, doesn't it.  I'm not sure we 
> actually want that, though.  It's not precisely the same -- the GSS
mech 
> could be upgraded before or after the Kerberos implementation, and the

> 5.3-supported flag should really apply to the service's Kerberos 
> implementation.

I'm willing to make the tie between the Kebreros V mechanism and the
Kerberos V implementation.  There aren't very many implementations of
either that don't also implement the other (though Samba comes to mind).

> Perhaps it would be best for the GSSAPI mechanism _not_ to make
assumptions 
> about what the other side is running.  Of course, then we're stuck
until 
> the end of time, since there is no standard API for indicating support
for 
> new features.

This is something that we hope is fixed by the new mechanism - i.e.,
it's extensible (though I'm not thrilled by the details).

> 
> I think maybe we want a new OID after all.  Under CFX, both OID's
would 
> indicate support for the same mechanism, except that the use of the
"new" 
> mechanism OID would indicate support for new token formats. 

A new OID would be fine in addition to the negotiation by Kerberos V
minor version / Kerberos V ticket session key enctype.

> Implementations which support CFX would be expected (REQUIRED) to
support 
> both OID's; naturally, an RFC1964 implementation will support only the
old 
> OID.  Note that this doesn't directly solve the problem of knowing
when 
> both sides support CFX, but it does provide a way for the application
to 
> indicate that via appliation-specific knowledge such as out-of-band 
> mechanism negotiation or knowledge that the application protocol will
only 
> be used with sufficiently new GSSAPI implementations.  And, of course,
you 
> get that negotiation for "free' in applications which use SPNEGO.

(And for SSHv2 gss keyex/userauth, and for NFSv2/3/4, and any app that
 does its own GSS-API mechanism negotiation.)

Agreed.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Oct 2003 08:19:07 -0700

> that the wrong call for the IETF.

Larry, you misunderstood.  The new OID would be for apps that explicitly
want to use the new mech regardless of ticket session key enctypes or
the use of extended Kerberos.  The new mech would still be negotiated
using enctypes and Kerberos extensions as discussed.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Oct 2003 08:19:07 -0700

Nico
--