Subject: CIFS and the krb5 PRF

From: Andrew Bartlett <[email-masked]>
Date: Sat, 16 Apr 2005 09:44:03 +1000

I'm not a kerberos or a GSSAPI guru, simply one who has to clean up
various bits of the puzzle that has been placed in front of me regarding
the use of GSSAPI on CIFS and other Samba-implemented protocols.

In particular, I'm concerned to try and get out of the GSSAPI game, and
would some day love to put Samba back outside the 'implements some
variant of GSSAPI' box.  

Currently, Samba implements a very shoddy GSSAPI wrapping, as well as
SPNEGO, partly because it requires access to the raw Kerberos session
key for use particularly in the CIFS protocol.

CIFS uses the Kerberos session key for encrypting specific data portions
on DCE/RPC named pipes, as well as to key the SMB signing system.

My question is this (because I can't make heads or tails of the draft,
sorry):  Is the proposed PRF compatible with microsoft's existing use in
this area, or will Samba forever-more be making calls to
krb5_auth_con_getremotesubkey(context, auth_context, &skey) and
krb5_auth_con_getlocalsubkey(context, auth_context, &skey)?

Thanks,

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
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: Fri, 15 Apr 2005 20:12:24 -0400

Andrew:

The PRF is not going to be compatible with Microsoft's existing use.
The idea behind the PRF is to allow the session keys negotiated by the
mechanism to be used to produce additional keys which could then be
used safely by the application calling GSS.  New PRF generated keys
can be generated as needed to satisfy rekeying requirements without
requiring that the session shutdown and re-authenticated with GSS.

The problem you face is that due to the lack of a functionality like
PRF, the CIFS developers were forced to extract the raw krb5 keys
for the purpose of providing encryption and data signing.  Unless
Microsoft chooses to support a PRF based replacement for a future
CIFS protocol and you choose to abandon the existing clients, you
will have to continue using your existing hacks.

Jeffrey Altman

Andrew Bartlett wrote:
> ------------------------------------------------------------------------
>

---

From: Andrew Bartlett <[email-masked]>
Date: Sat, 16 Apr 2005 10:27:32 +1000

> will have to continue using your existing hacks.

This is disappointing.  Can this limitation be more fully described in
the draft, so that those that come after me in this game don't waste
time on it?

My understanding is that particular MIT and Heimdal versions have some
other function (I need to look it up again) that should allow me access
to the key material, it's just a pity that we can't get a common
standard on the point, and that I can't find something that would in
theory accommodate future GSSAPI mechs that may be developed.

I have no expectation that Microsoft will change on this point,
particularly due to the way NTLMSSP is also tied into this mess, let
alone the further need to negotiate such a change...

Andrew Bartlett

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 15 Apr 2005 21:25:11 -0400

> the draft, so that those that come after me in this game don't waste

I do not believe this is a limitation.  The GSS PRF and GSS KRB5 PRF
drafts do not attempt to address the question of compatibility with the
CIFS utilization of NTLM or Kerberos.  The purpose of the specification
is to provide a secure method of accessing pseudo-random key data which
can be used by application level protocols regardless of the underlying
mechanism.

The mechanisms used in CIFS assume that the application has intimate
knowledge of the underlying mechanism.  This is not acceptable for a
general purpose GSS method.

> theory accommodate future GSSAPI mechs that may be developed.

You are thinking of the krb5 mechanism specific extension:

  OM_uint32 gss_krb5_get_subkey(const gss_ctx_id_t context_handle,
                                krb5_keyblock **key);

which exists in Heimdal but not MIT.  MIT will support this in a future
release to make things easier for Samba but that is off topic for this
list.

This function cannot be standardized as part of GSS because it is
krb5 mechanism specific and depends on the definition of the
krb5_keyblock within the krb5 implementation.  As there is no standard
krb5 api from which to obtain the definition of a krb5_keyblock, it is
not possible to generate a public standard.

> alone the further need to negotiate such a change...

I would not be surprised if the GSS PRF were used within future
protocols.  However, as we all know, once a protocol is deployed it
never dies.

Jeffrey Altman

---

From: Andrew Bartlett <[email-masked]>
Date: Sat, 16 Apr 2005 11:39:11 +1000

On Fri, 2005-04-15 at 21:25 -0400, Jeffrey Altman wrote:
> CIFS utilization of NTLM or Kerberos.  

I'm just asking that it be clarified 'this PRF key stream cannot be used
to obtain the original session key or it's length'.

> The purpose of the specification

Actually, they don't.  All I want the GSSAPI stack to communicate to me
is the 'session key', where each mech decides in a existing-
implementation-compatible way what that means.  All I need to get back
is a data,length pair.  

Samba4 has yet another abstraction layer, GENSEC, which simply returns
this to the parts of Samba that need a session key, entirely regardless
of what mech was selected.  There is no intimate knowlege required.

> not possible to generate a public standard.

I really don't care how the key is returned - nor what abstraction is
used.  What is wrong with using an existing data,length structure from
GSSAPI?  Nothing here has to be Kerberos specific.

Assuming that NTLMSSP became a GSSAPI mech, it would also present the
same interface - it certainly does in Samba4, which is where I make
exactly this abstraction.

> protocols.  However, as we all know, once a protocol is deployed it

Indeed, and I had this false hope that someone else might care about
making such existing use sane, on a more portable basis.

Andrew Bartlett

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 15 Apr 2005 21:55:05 -0400

> implementation-compatible way what that means.  All I need to get back

You are making the false assumption that it is safe to take a key
generated for one algorithm and use it with another algorithm.
Unfortunately, this is not true.  The key you obtain from the underlying
mechanism can only be safely used with the cipher for which it is
intended.

The intimate knowledge that you have of the underlying mechanism is
the negotiated cipher to which the key belongs.  This is part of what
is represented in the krb5_keyblock data structure.  It is not simply
a random bytes and a length.

As implementors, we do care about making it easier for Samba to
implement compatibility with Microsoft's products.  However, the IETF
is not the place for that to happen.  Samba is only going to be built
with a handful of implementations.  The Samba team should work with
those implementors to provide the interfaces it requires and ensure
that the implementations are compatible.

Jeffrey Altman

---

From: Andrew Bartlett <[email-masked]>
Date: Sat, 16 Apr 2005 12:24:41 +1000

> mechanism can only be safely used with the cipher for which it is

That may be so, but I have no choice but to build upon the false
assumptions of others.

> a random bytes and a length.

I have no such knowledge, and indeed if somebody had taught Microsoft's
developers these little details, they would not have so readily used
these keys as raw input into RC4 and DES encryption of short-runs over
user-specified data.  (Microsoft resets the keystream with the session
key at the start of every encryption for these ops).

I'm looking for an answer to 'When using GSSAPI in a CIFS context, you
can call X to obtain the session keys used'.  I'm not asking for a 'this
is the best way to design a new protocol', but as the question is at the
GSSAPI level, why can't a single GSSAPI way of obtaining those bytes and
length be specified?

Why should CIFS implementors (which do extend beyond Samba) have to
always kludge their way though this problem?

> that the implementations are compatible.

Samba already has a large collection of 'fix up' functions trying to
bridge the large gaps between implementations.  I had just hoped I might
avoid yet more as we move forward.

But I'm moving in both directions - we would much prefer that we can
build with any sane, standards conforming implementation of GSSAPI and
Keberos, but instead because of this kind of problem, I am instead
looking to build with only custom or specified snapshots of Heimdal
Kerberos.   I am yet to determine where this particular experiment will
end.

Andrew Bartlett

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 15 Apr 2005 22:40:58 -0400

Andrew:

The IETF does not standardize protocols which do things in an insecure
way.  That is not the purpose of standardization.   The purpose of
standardization in the IETF is to get vendors to do things in a way
which is secure and known to be interoperable.

You wrote "we would much prefer that we can build with any sane,
standards conforming implementation of GSSAPI" well there is your
problem.  Microsoft's CIFS is neither "sane" nor an implementation
of GSS.

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.

Jeffrey Altman

---

From: Andrew Bartlett <[email-masked]>
Date: Sat, 16 Apr 2005 12:54:29 +1000

> which is secure and known to be interoperable.

I wonder how CIFS ever got itself started down the IETF path then ;-)

> problem.  Microsoft's CIFS is neither "sane" nor an implementation

Indeed.  And we don't build against Microsoft CIFS to provide GSSAPI, we
just have to work with it on the other end of the network.  What is the
appropriate forum to discuss things I need from any local GSSAPI
implementation that I may want Samba to compile (that's what I meant by
build) against and use at runtime?

> without muddying the GSS standards track.

I'm happy to participate with a discussion there, and while it appears
that the 'world' is pretty much 'MIT and Heimdal', it just didn't seem
to be the 'right place' to try and discuss 'anybody doing GSSAPI'
issues.  

Oh well, I seem to have a poor track record of picking the right forums
(or understanding IETF policies/politics) in the past, so whatever...

Andrew Bartlett

---

From: Wyllys Ingersoll <[email-masked]>
Date: Fri, 15 Apr 2005 23:28:35 -0400

Jeffrey Altman wrote:

>  Andrew:
>
>  The IETF does not standardize protocols which do things in an
>  insecure way. That is not the purpose of standardization. The
>  purpose of standardization in the IETF is to get vendors to do things
>  in a way which is secure and known to be interoperable.
>
>  problem. Microsoft's CIFS is neither "sane" nor an implementation of
>  GSS.
>

I think Nico and I have an interest in pursuing this conversation a bit
further as it is eerily similar to a conversation we recently had with
a big customer.    Certain protocols and specificiations require access
to the raw key data, however, the lack of a "standard" Kerberos API
and the inability of GSSAPI to provide the necessary interface for
extracting this data has become problematic (to say the least).

I look forward to following this more on krbdev...

-Wyllys

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 15 Apr 2005 23:01:30 -0500

> not possible to generate a public standard.

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

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 15 Apr 2005 23:04:19 -0500

> I look forward to following this more on krbdev...

I think a forum is needed for this discussion, and krbdev is as good as
any (KITTEN is not chartered to do this work, so perhaps KITTEN's list
is not a good forum, but I'd be happy to take a personal I-D submission
to the IETF covering mechanism-specific GSS-API extensions relating to
Kerberos V).

Nico
--

---

From: Matt Peterson <[email-masked]>
Date: Thu, 21 Apr 2005 12:32:20 -0600

Hi,

> >  without muddying the GSS standards track.

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

I agree with Nico's post...

> On Friday 15 April 2005 22:01, Nicolas Williams wrote:
> [snip]

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

--
Matt

---

From: Matt Peterson <[email-masked]>
Date: Thu, 21 Apr 2005 12:32:20 -0600

Hi,

--
Matt

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Apr 2005 13:37:37 -0500

> at all.  It seems to me like a legitmate request for generic API 

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.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Apr 2005 13:38:07 -0500

> participants, and I do believe that this is pretty close to being the

this == krbdev

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 21 Apr 2005 14:50:52 -0400

>>participants, and I do believe that this is pretty close to being the

Nico:

Thank you for pressing send on your e-mail before I had a chance to
press send on mine.

Nico is correct on all counts.  When the preliminary work on a raw krb5
mechanism and associated GSS extensions get to the point where a
proposal can be made for standards action, those participating can do
one of the following:

* request that the Kerberos working group be re-chartered to do the work

* request that a new working group be chartered

* submit one or more individual drafts

The important part is that the conversation take place in an open forum
with the necessary participants.   [email-masked] is targeted at the
development of the MIT Kerberos implementation and is also frequented by
developers looking to implement or utilize the MIT APIs.

Jeffrey Altman

---

From: Matt Peterson <[email-masked]>
Date: Thu, 21 Apr 2005 14:54:22 -0600

> participants, and I do believe that this is pretty close to being the

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

Thanks for the clarification it wasn't clear in the thread (at least me) that  
movement to krbdev was targeted toward the recommendation of a Generic GSS 
extension that addressed the CIFS requirement. 

Will watch the thread on krbdev.  Thanks.

--
Matt

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Apr 2005 16:29:56 -0500

> forum makes sense. (I assume the discussion falls outside the scope of 

Well, you can read the KRB WG's charter yourself and see :), and though
I haven't just looked at it, I'm pretty sure that such work would,
indeed, not be in scope for that WG.

WG charters are not written in stone though, and can be changed.  But I
think it will be much more productive to proceed with this particular
work in krbdev for a while and then pop back up at the IETF, either
using individual submissions, a new WG, re-chartering an existing WG --
whatever.

Nico
--