Subject: Re: [nfsv4] More on CCM

From: Mike Eisler <[email-masked]>
Date: Tue, 11 Mar 2003 16:48:34 -0800 (PST)

> > > CCM should have three variations, each with their own OID, each being a
> > > trivial wrapper around an underlying GSS mechanism. The three
> > > variations should be:
> > 
> > These might be too many variations. Offering a wide array
> > of choices to the customer is just too confusing. And
> > even if we can design a way to remove confusion, requiring
> > all this array of choices reduces the chances of a particular
> > implementation supporting them and reduces chances of
> > interoperability. (An example of this is action was the
> > surprise at the last Connectathon, where several of us found that
> > 3DES keys were being created by the KDC, and as a result,
> > most of us NFS/krb5 implementors couldn't interoperate).
> > The goal is to minimize difficulty of implementation.

> See below.

> The 3DES issue you refer to is a configuration issue, perhaps a
> maddening one to you, but still not an interop issue.

When we creating "nfs/" server principles using the
pre-existing KDC interface, stuff stopped working. *I* didn't
misconfigure anything.

Stuff stopped interoperating. I'll leave it the developers
of the other bnfs/krb5 implementations 

> > >
> > > - CCM-with-session-hash-channel-bindings
> > >
> > > For use with IPsec, SSHv2, etc.. without regard to NAT.
> > 
> > I think hash-key bindings are very slick. I also think the API
> > support to retrieve them is far from ubiquitous. And there's no
> > existing GSS-API or krb5 infrastructure for them either, and
> > not even a specification.

> The GSS-API certainly supports channel bindings, though they are
> optional.  Your implementation may not, but if you want CCM to work

And there's no specification for hashed-session-key-based channel
bindings. If the support in GSS-API were as solid as you imply, you wouldn't
be having a vigorous discussion on the krb5 wg alias.

> securely then you'll have to add channel binding support.

> The specification of the IPsec, SSHv2, etc... hashes has to be done.
> I already know what that specification is for IKEv1 (IPsec) and SSHv2;
> only IKEv2 remains.  Specifying these hashes is not difficult.

> I will contribute text if you wish.

By all means, extend GSS-API and RFC1964 to add this stuff.
It's outside the scope of CCM though (since channel bindings are
are useful beyond CCM).

> > Following Dai Peng's and David Black's comments, and considering
> > that useful (NAT-less) GSS channel bindings don't really exist, my thinking
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> They are trivial to define.  To repeat:

Yes, but not trivial to get deployed. All of us GSS-API,
RPC, and NFS implementors don't control all the possible secure channel
methods that we want to use our stuff over.

One of reasons why TLS and SSH gained so much traction was precisely
because it did not require changes to the network layer stacks.
It's unreasonable to insist that to make forward progress
in high performing security, NFSv4 has to wait for IPsec and SSH
implementations to catch up.

> > is to specify the use of RPCSEC_GSS over CCM to limit its use
> > for the duration of the ULP's session. Most ULPs that use ONC RPC don't
> > have a session, but most ONC RPC ULPs do work over
> > connection oriented transports. So this effectively means that
> > sessionless ONC RPC ULPs must bind a particular CCM context to
> > a particular TCP or SCTP (whenever the wg gets around to
> > defining ONC RPC semantics for SCTP) connection.

> ULP?

upper layer protocol. Sorry about that.

> > (If it is good enough for iSCSI, it is good enough for ONC RPC).

> Wrong.  If some other protocol's spec has it wrong that is no excuse for

Well, after reading David Black's, and Dai Peng's explanations,
I don't think iSCSI got it wrong. As I understand it, iSCSI binds a
single authentication context to a single connection protected with
IPsec.  What is the weakness there?

> us to get it wrong also, particularly now that we've had this discussion
> in public (years from now others will be able to point the finger at us
> and say "they knew of the problem and chose to ignore it").  I don't
> find that acceptable.  Furthermore the IETF security ADs, or the IESG
> may also find it unacceptable; if, OTOH, they're ok with this, then
> fine, it won't be my fault :) :)

True, but IESG will have to explain away iSCSI, SASL, etc. If
they remove standards track designation for their previous "mistakes",
then that will be fair, and I'll happily embrace what they find to be
more secure, and wait 10 years for the secure channel infrastructure
to exist. Meanwhile, to cut of our nose, to spite our face, we'll
be left with using AUTH_SYS when 10Gbit/sec media arrive.

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 12 Mar 2003 10:13:11 -0600

> of the other bnfs/krb5 implementations 

This would have happened with MIT or MS ActiveDirectory KDCs as well.
It is a fact of life that currently only the DES enctypes are supported
throughout and it is hoped that the AES enctypes too will be as common
when they come out (it's possible that RC4 too will be as common).

This is not an interoperability problem though.  You may have been
unaware of it, sure, but it really is just a configuration problem.

> be having a vigorous discussion on the krb5 wg alias.

Yes there is.  I thought there wasn't either, but, there is:

   typedef struct gss_channel_bindings_struct {
      OM_uint32       initiator_addrtype;
      gss_buffer_desc initiator_address;
      OM_uint32       acceptor_addrtype;
      gss_buffer_desc acceptor_address;
      gss_buffer_desc application_data;
   } *gss_channel_bindings_t;

That "application_data" field couldn't have had any other purpose, nor
has it been used (but rfc1964 [the kerberos mech] supports it just fine
thank you).

I'll grant you that GSS-API has been lame in terms of negotiating the
use of optional features or even mechanisms to use, which is why SPNEGO
came about and why you invented CCM - to make mechanisms negotiable, in
the case of SPNEGO, and to make channel bindings negotiable when
negotiating mechanisms.

> It's outside the scope of CCM though (since channel bindings are

Neither the GSS-API nor rfc1964 require extensions to handle channel
bindings of this sort.

> methods that we want to use our stuff over.

I think it's too early to conclude this and that this view may be
colored by your view that GSS_API and rfc1954 require updates; see
above.

> implementations to catch up.

CCM will not require changes to the network layers.  It will require
having the ability to get at the IKE hashes, but looking at our IPsec
man pages, I see that we already have a very large number of socket
options and what not related to this sort of thing, and either we
already have the right one or it will be trivial to add it.

> IPsec.  What is the weakness there?

I have to study iSCSI to figure out where I stand on it.  But there is a
huge difference between iSCSI and RPCSEC_GSS: we're talking about
authenticating many users per-session in the RPCSEC_GSS case.  In the
iSCSI case it may be that the authenticated names in its layer are
required to match the names in the lower layer, which would be just
fine, thank you (and which too requires access to the lower layer, just
the same sort of access that would be needed for getting IPsec hashes).
But in the RPCSEC_GSS w/ IPsec and what not case that is certainly not
quite as easy; I've already described how you could get away with the
same hack in CCM, and I don't like it.

> be left with using AUTH_SYS when 10Gbit/sec media arrive.

You exagerate the difficulty in binding upper layer channels to IPsec.

I offered those three, trivial variations on CCM in part so we could
actually test and compare implementations and really see how difficult
each is to implement.  CCM could certainly be made an experimental I-D
with each of the three variants being optional, then we could where the
experiment takes us - probably to a standards track RFC with the useless
variants removed.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 13 Mar 2003 16:26:54 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Mar 11, 2003 at 04:48:34PM -0800, Mike Eisler
    Nicolas> wrote:
    >> > See below.
    >> 
    >> > The 3DES issue you refer to is a configuration issue, perhaps
    >> a > maddening one to you, but still not an interop issue.
    >> 
    >> Stuff stopped interoperating. I'll leave it the developers of
    >> the other bnfs/krb5 implementations

    Nicolas> This would have happened with MIT or MS ActiveDirectory
    Nicolas> KDCs as well.  It is a fact of life that currently only
    Nicolas> the DES enctypes are supported throughout and it is hoped
    Nicolas> that the AES enctypes too will be as common when they
    Nicolas> come out (it's possible that RC4 too will be as common).

    Nicolas> This is not an interoperability problem though.  You may
    Nicolas> have been unaware of it, sure, but it really is just a
    Nicolas> configuration problem.

    >> > > > > > > - CCM-with-session-hash-channel-bindings

Nico, I believe it was a client level interop problem.  Clients that
did not support 3des should *not* have asked for 3DES tickets.

In at least the Umich case, the correct fix is a change to their
GSSAPI library [*] not to their  configuration files.

ON the server side, it was a configuration problem on the part of
whoever generated keytabs.  Servers that did not support 3DES should
not have been given 3DES keys.  It is a deficiency in current Kerberos
admin software implementations that the server does not automatically
key itself and only request enctypes it supports.  Fortunately you are
working on a draft that will make that easier.

[*] Umich uses MIT's GSSAPI library.  The MIT GSSAPI library is
intended to be a pure userspace GSSAPI implementation and was never
intended to be used by an application that wanted to perform some
operations in the kernel.  Doing so is outside the design of the
library and if Umich wants to use the library in that manner they need
to either make appropriate changes so that it works or work with MIT
to make these changes for them.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 14 Mar 2003 13:50:24 -0600

> did not support 3des should *not* have asked for 3DES tickets.

No, this is something you were not involved in which happened during
NFSv4 w/ RPCSEC_GSS testing.  Basically, NetApps' server did not support
3DES, but our KDC did and when the NetApps' princ was created and a
keytab given to NetApps, that princ now had a 3DES key, and clients
started getting 3DES tickes which the NetApps box could not process.

A configuration problem, not an interop problem.

> working on a draft that will make that easier.

Ya.

Nico

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 14 Mar 2003 15:04:22 -0500

> A configuration problem, not an interop problem.

We also had 3DES-related problems testing a Linux client against a Sun
server, which I discussed with Sam, and as far as I know he's described
that particular problem accurately (though I haven't looked into it
again since discussing it with him).

Sounds like the Sun/NetApp problem was different, and was indeed just a
configuration problem.

--Bruce F.