Subject: RE: draft-eisler-nfsv4-ccm-00.txt

From: [email-masked]
Date: Thu, 27 Feb 2003 15:02:11 -0500

Here are some thoughts of mine from a rather high level.

1. Lack of authentication in CCM context initialization

According to Section 4, the way the CCM context initialization works over
RPCSEC_GSS, it is not too difficult for a malicious user to cheat the server
into establishing a new CCM context with him. All he has to do is to get an
IPSec association with the server and fake a handle (opaque bytes with no
cryptographic protection) to a previously established authentication
context.

The problem here is the lack of binding between the authentication context
established through traditional GSS mechanisms and the secure transport
channel used in CCM.

In order to provide this binding, we must integrity protect the application
context handle among other things passed in the rpc_gss_init_arg. For
example, we could generate a checksum over the application context handle,
among other things if the handle does not have enough bytes, using the
session key found in the soon-to-be-replaced authentication context, and
pass the whole thing as the opaque token in rpc_gss_init_arg. In the
response, the server has to do the same with the CCM status.

2. Implementation caveats

A new mechanism that leverages IPSec to provide user-based authentication
does provide comparable security to that of the traditional GSS mechanisms.
Yet there are some caveats unique to this new mechanism that should be
avoided when it comes to implementation.

a. The new mechanism does away with compute intensive cryptographic
operation needed for authentication using a traditional GSS mechanism.
However, it would be wrong to think authentication is totally obsoleted. I'd
like to think authentication takes a different form now - ensuring the
binding between the CCM context and the secure transport channel is legit
for each incoming request. In other words, the CCM context referenced in the
request has been established using the same secure transport channel as the
request.

b. When the same secure transport channel is multiplexed on the client side
for multiple users, the client has to ensure the CCM context is only
accessible to the user that has established it in the first place. One
possible way to ensure that is by placing CCM contexts in the privileged
address space offering only controlled indexed access. Imagine a user level
process faking a CCM context handle (established by a legit user locally)
through a shared secure transport channel without having to break into local
privilege boundary and no cryptographics involved. It is much harder to do
the same using for example Kerberos since that requires local privilege to
access other user's ticket cache.

3. Security consideration

Properly implemented CCM can offer comparable security.

a. CCM does not unnecessarily inflate the scope of the trust domain, as does
for example AUTH_SYS over IPSec. By requiring the authentication in the CCM
context initialization (using a previously established context), the trust
domain does not extend to the client.

b. Both the traditional mechanisms and CCM rely on the security of the
client to protect locally logged on users. Compromise of the client impact
all users on the same client. CCM does not make the problem worse.

c. For CCM, users on the same client may share the same secure transport
channel, meaning all traffic is protected with the same session key at a
given time. However, IMHO, it does not make cryptoanalysis of the traffic
easier compared to say Kerberos. Assuming reasonable NFS usage and typical
ticket lifetime of several hours, the attacker would have gathered a lot of
traffic anyways. On the other hand, the secure transport may provide added
benefits of automatic key exchange (AKE) management. For example, the
lifetime of an IPSec session key can be adjusted based on the traffic. This
can be made shorter than the CCM context lifetime if necessary.

Peng

> -----Original Message-----
> From: Mike Eisler [mailto:[email-masked]]
> Sent: Wednesday, February 26, 2003 3:06 PM
> To: Nicolas Williams
> Cc: [email-masked]
> Subject: Re: draft-eisler-nfsv4-ccm-00.txt
> 
> 
> 
> Nicolas Williams wrote:
> 
> > It seems to me that the point of CCM is to use GSS for 
> authentication
> > but negotiate the non-use of GSS integrity/privacy services 
> when such
> > services are demonstrably provided by the network (e.g., 
> IPsec secures
> > the initiator's and acceptor's communication with each other).
> >
> > So here's an alternative CCM mechanism design: let CCM be a trivial
> > wrapper around another mechanism, much the way SPNEGO is a
> > pseudo-mechanism that uses other mechanisms, but simpler.
> >
> > The point of such a mechanism would be that after a CCM context is
> > established the initiator and acceptor would delete the 
> underlying GSS
> > context, thus freeing resources, and that CCM would not support
> > integrity or privacy protection, expecting, nay, requiring 
> the network
> > (IPsec) to provide those services instead.
> >
> > The biggest benefit to this model is that it would not change the
> > GSS-API model in the least; and existing RPCSEC_GSS codes 
> would have to
> > change very little as well, perhaps not at all. There would 
> only be a
> > new set of mech OIDs, one for each GSS mech, prefixed with 
> the OID for
> > CCM[*].
> >
> > The only problem I find with this is that there may well be 
> no way for
> 
> 
> There is no way at all under existing GSS-API C and Java bindings, but
> see below, I don't think that's an issue.
> 
> >
> > the CCM mechanism to actually determine whether the the network is
> > providing integrity/privacy for a given initiator/acceptor pair. The
> > current draft already leaves that determination to 
> RPCSEC_GSS, for this
> > very reason I'm sure - the application, RPCSEC_GSS in this case, is
> > better positioned to determine the level of protection 
> afforded by the
> > network.
> 
> 
> Well, my initial reaction is that your approach is better. 
> The impact on
> implementations is far less than my approach.
> 
> Regarding the problem you find, I don't think it is a problem.
> The application (e.g. the NFS server and client) makes the decision
> whether to create CCM vs krb5 contexts based on the presence of
> network layer integrity/privacy protection. If network level 
> protection
> is present, then client can optimistically try to use CCM, 
> and the server
> can optimistically downgrade the client to CCM. You'll still
> see krb5i being downgraded to CCM-krb5 (note, no trailing 'i').
> If network level protection disappears, the client and server can
> delete the CCM-krb5 contexts.
> 
> Thanks. I'm going to change the i-d accordingly. During the
> course of changing the i-d, I might find issues, and if so, 
> report back to
> the wg.
> 
>     -mre
> 
>

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 27 Feb 2003 14:32:44 -0600

Dai,

I think Mike has agreed to change the CCM draft to do something rather
very different from what appeared in -00.

The new approach is to have CCM be a trivial wrapper around other GSS
mechanisms, with the implication that those mechanisms, when wrapped
with CCM, will only be used for authentication and not for integrity or
privacy protection; it will be up to the clients and servers to ensure
that the network provides integrity and/or privacy and therefore that
use of CCM is acceptable.  I believe the new approach takes care of all
your concerns below; you can read more about it in the last two posts on
this subject prior to yours.

Cheers,

Nico