Re: CIFS and the krb5 PRF
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CIFS and the krb5 PRF



>>>>> "Matt" == Matt Peterson <mpeterson at vintela.com> writes:

    Matt> Hi,
    >> > Jeffrey Altman wrote: > I have started a discussion with you
    >> on the krbdev at mit.edu 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 krbdev at mit.edu
    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 Kitten at lists.ietf.org
    Matt> https://www1.ietf.org/mailman/listinfo/kitten


_______________________________________________
Kitten mailing list
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.