Subject: Re: CIFS and the krb5 PRF

From: Sam Hartman <[email-masked]>
Date: Sun, 26 Jun 2005 19:35:51 -0400

>>>>> "Matt" == Matt Peterson <[email-masked]> writes:

    Matt> Hi,
    >> > Jeffrey Altman wrote: > I have started a discussion with you
    >> on the [email-masked] mailing > list. Let's take this
    >> discussion there. I am sure that we can work > with you to get
    >> the functionality you need into a future release > without
    >> muddying the GSS standards track.

    Matt> So can someone explain why this is a [email-masked]
    Matt> discussion and not something suited to the kitten list?  I
    Matt> don't think it is mudding the waters at all.  It seems to me
    Matt> like a legitmate request for generic API functionality.

I think the argument is that it is outside the kitten charter.

Speaking as an individual, I don't want to see kitten become a forum
for Microsoft interoperability.  I'd rather see the GSSAPI be a well
designed security API, not one forced to support all the mistakes
Microsoft made.  We'll be busy enough supporting the mistakes we make.

That said, I believe we may actually want an API for extracting the
key or at least something that maps on the EAP MSK and EMSK.

    Matt> I agree with Nico's post...

    >> On Friday 15 April 2005 22:01, Nicolas Williams wrote: [snip]
    >> *That* function cannot be standardized, but *a* function like
    >> it that did not use the 'krb5_keyblock' type *could* be made a
    >> standard mechanism-specific GSS-API extension.
    >> 
    >> And why not?  SPNEGO has mechanism-specific extensions too...
    >> 
    >> I'd have the function output an INTEGER corresponding to the
    >> key's enctype and an OCTET STRING corresponding to the key's
    >> value.  The C-bindings of that would be straightforward.

    Matt> I think that GSS-API needs to respond to the types of
    Matt> request being made by the Samba team for a usable API.  Why
    Matt> can't we talk about standardizing a function instead of
    Matt> shuffling the discussion off to an implementation specific
    Matt> mailing list?

    Matt> -- Matt

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

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

---

From: Sam Hartman <[email-masked]>
Date: Sun, 26 Jun 2005 19:39:46 -0400

Matt> On Thursday 21 April 2005 12:38, Nicolas Williams wrote:
    >> KITTEN is not charatered to design a raw krb5 mechanism and
    >> associated mechanism-specific GSS extensions.  Generic GSS
    >> extensions, OTOH, do fall under its charter.
    >> 
    >> There's no need to burden the KITTEN list subscribers with talk
    >> of a GSS-based API for raw krb5, at least not yet.
    >> 
    >> None of which means that a raw krb5 API based on the GSS-API
    >> couldn't be documented in IETF RFCs.  All we need is a forum
    >> with the right participants, and I do believe that this is
    >> pretty close to being the right forum.
    >> 
    >> this == krbdev

    Matt> Ok.  As a *mechanism-specific GSS extension* moving the
    Matt> discussion to a new forum makes sense. (I assume the
    Matt> discussion falls outside the scope of ietf-krb-wg charter?)

Note that the krb-wg or kitten chairs could decide that the discussion
was appropriate on their lists even if it is out of charter.  They
would typically do so if they expected the discussion to be relatively
short, contained and not to get in the way of the working group's
efforts.

--Sam

---

From: Andrew Bartlett <[email-masked]>
Date: Mon, 27 Jun 2005 19:11:44 +1000

> key or at least something that maps on the EAP MSK and EMSK.

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

-- 
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: Jeffrey Altman <[email-masked]>
Date: Mon, 27 Jun 2005 05:27:50 -0400

> closer control over the underlying Kerberos behaviour.

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

Jeffrey Altman

---

From: Andrew Bartlett <[email-masked]>
Date: Mon, 27 Jun 2005 20:36:55 +1000

On Mon, 2005-06-27 at 05:27 -0400, Jeffrey Altman wrote: 
> [email-masked] mailing list. &#-1;&#-1; 
>
> The same is true for anything other

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