Subject: RE: [nfsv4] More on CCM

From: [email-masked]
Date: Wed, 12 Mar 2003 12:21:32 -0500

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Wednesday, March 12, 2003 11:13 AM
> To: Mike Eisler
> Cc: [email-masked]; [email-masked]
> Subject: Re: [nfsv4] More on CCM
> 
> 
> On Tue, Mar 11, 2003 at 04:48:34PM -0800, Mike Eisler 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.
> > 
> > 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 
> 
> 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.
> 

Sounded like I missed all the fun. :)

I think the line here is obscure. Yes, eventually one can get around
it thru proper configuration; but it is by no means easy given the
POOR logging available (esp. if multiple enctypes are supported, such
as in MIT KDC). Although it is interoperable at protocol level, it
certainly is product level interoperability problem.

> > > > >
> > > > > - 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.
> 
> 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 disagree. The existence of a data structure by no means suggests
GSS-API has solid support for the kind of channel binding we need
for CCM. The differences are,

1. GSS-API has limited channel binding to be a context init time
concept; while the channel binding we need is both at context init
time and for each data request.

2. Also the GSS-API prescribed use of channel binding is for
initiator to pass channel binding in the initial token; in CCM,
the target and initiator should both be able to derive binding
from local network layer, without relying on info from the peer.

3. The authenticity of the channel binding info in GSS-API is
guaranteed by the crypto signature using the session key provided
by the GSS-API mechanism; in CCM, that should be offered by the
lower layer network independent of the GSS-API mechanism.

> 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.
> 
> > > 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).
> 
> Neither the GSS-API nor rfc1964 require extensions to handle channel
> bindings of this sort.
> 
> > > > 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.
> 
> 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.
> 
> > 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.
> 
> 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.
> 
> > > 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?
> 
> 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).

My understanding is iSCSI doesn't require access to lower layer
in the way that RPCSEC_GSS does because authentication context
is bound to each TCP connection.

> 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.
> 
> > > 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.
> 
> 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
> -- 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

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

> certainly is product level interoperability problem.

Let me make this real clear about Kerberos enctypes: Kerberos enctypes
are negotiated in the KDC exchanges.

Which means that making sure that the services' principals have, in the
KDC's database, only keys of the enctypes that the service has software
support for, *is* a requirement for proper operation (never mind
interoperation); this is a configuration issue.

The only ways in which there can be interop problems with Kerberos
enctypes are when a) there are implementation bugs or b) there is no
enctype common to the clients, KDCs and services.  (b) does not apply
because all Kerberos implementations support the DES enctypes.  (a) has
happened, but all such bugs that I know of are fixed and none reared up
their heads at Connectathon `03.

> for CCM. The differences are,

RFC2743 describes the two kinds of things that channel bindings can be.
RFC2744 describes a data structure for channel bindings which too
contains two kinds of things.

Those two kinds of things are: network addresses and "transformed
representations of enncryption keys" [rfc2743].

> time and for each data request.

We only need the channel binding at GSS context establishment time.
It is up to the application to make sure that subsequent [cleartext]
messages are sent over the same channel that was bound to during
authentication.

> from local network layer, without relying on info from the peer.

No.  GSS-API requires both the initiator and the acceptor to determine
the channel binding before calling gss_init/accept_sec_context() and
both must agree.  And in the case of CCM both can agree without prior
communication at the upper layer - how?  the binding is, essentially, a
hash of the lower layer's session keys/key exchanges and if there is no
man in the middle then both the initiator and the acceptor MUST have the
same hash.

> lower layer network independent of the GSS-API mechanism.

This makes no sense.  The channel bindings are proven by the actual
mechanism used; CCM is merely a pseudo-mechanism whose purpose is to
negotiate channel bindings [they're optional otherwise] and passes
everything through to the underlying mechanism, which in turn is
responsible for proving the channel bindings.

Cheers,

Nico