Subject: RE: CIFS and the krb5 PRF

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Thu, 30 Jun 2005 20:10:27 -0700

What about adding a flag argument to GSS_Pseudo_random(), thus we can
allow implementations to *optionally* expose the raw session key via the
PRF. I am saying so assuming folks genuinely need to support a way to
interop with existing applications that expose the direct Kerberos key
today, Kerb-TLS, to think of it, is one of them.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Andrew Bartlett
Sent: Monday, June 27, 2005 3:37 AM
To: Jeffrey Altman
Cc: [email-masked]; Sam Hartman
Subject: Re: CIFS and the krb5 PRF

On Mon, 2005-06-27 at 05:27 -0400, Jeffrey Altman wrote: 
> Andrew Bartlett wrote:
> 
> > Given the strongly held views of represented here that Samba4 (in
> > particular) should not be locked into a particular Kerberos/GSSAPI
> > implementation, where should I address discussion about the changes
that
> > Samba4 requires?
> > 
> > I have already made a number of experimental modifications to
Heimdal
> > kerberos (a copy of which we will ship built into Samba4 for initial
> > release).  While I already get some good feedback from Love, I know
> > others have views.  
> > 
> > The 'CIFS Session key' export is just one of these required
extensions -
> > we also need to change the GSS_Wrap arguments to support AEAD, and
> > closer control over the underlying Kerberos behaviour.
> > 
> > Andrew Bartlett
> 
> Discussions of proprietary mechanism extensions for Kerberos 5 such as
> access to the Kerberos 5 ticket (or ticket parts) that you wish to be
> adopted by both Heimdal and MIT Kerberos should take place on the
> [email-masked] mailing list. &#-1;&#-1; 
>
> The same is true for anything other
> change that would be incompatible with implementations of GSS API
> version 2 update 1.
> 
> Discussions that are appropriate for the Kitten list are any changes
> this working group should consider for GSS API version 3.

Well, I certainly would like to see GSS API version 3 being flexible
enough to provide the facilities that Samba4 requires.  That would seem
to be a desirable outcome.  Clearly not all the things Samba4 requires,
fit into that category, but I think some do.

I'll continue hacking my way though GSSAPI as I move forward, let me
know if you want to hear about what things I'm finding.

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 30 Jun 2005 22:23:46 -0500

> today, Kerb-TLS, to think of it, is one of them.

We've discussed this before I think, and we concluded that a difference
function should be used for that.

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 30 Jun 2005 23:26:16 -0400

The raw session key has very different properties than the output of
GSS_Pseudo_random().   We all agree that there is a need for
implementations of the krb5 mechanism to be able to expose the raw
components of the ticket.  The components that applications need access
to are no limited to the session key.  That is the reason the MIT
implementation is going to provide a implementation specific extension
to access all of the components of the ticket associated with the GSS
Context.   Let's not try to mix apples and oranges.

As for RFC 2712 (Kerberos Ciphers for TLS), this protocol does not use
GSS.  It would therefore provide no benefit to add this functionality.
What we do need to do is scrap RFC 2712 and replace it with something
either based on GSS or at least something that makes use of the KCrypto
PRF.  That discussion is not within the bounds of the Kitten charter.

Jeffrey Altman