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

From: [email-masked]
Date: Thu, 27 Feb 2003 16:05:35 -0500

Nico,

Yes, I am also in favor of the wrapper approach. Since it requries one
context initialization rather than two as proposed with CCM, it does make
issue #1 void.

However, if my understanding is correct, we are only using the wrapper
mechanism for the initial authentication (the one involving cryptographics
anyways) during context initialization. Subsequent data requests will not
involve any cryptographics whether for authentication/integrity/privacy, at
least not at the RPCSEC_GSS and GSS level, for performance reasons. This
does introduce some significant differences from RPCSEC_GSS over a
traditional GSS mechanism. Because of this, I'd like to think issue #2 and
the security assessment in #3 still apply.

Peng

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 3:33 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-eisler-nfsv4-ccm-00.txt
> 
> 
> 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
> 
> On Thu, Feb 27, 2003 at 03:02:11PM -0500, [email-masked] wrote:
> > 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 16:20:15 -0600

> the security assessment in #3 still apply.

Look at how "krb5," krb5i" and "krb5p" are defined.  You'll see that
RPCSEC_GSS already allows for using GSS only for authentication and not
for integrity or privacy protection, if desired.  If anything, CCM
(formulated as a GSS mechanism that wraps others) adds security because
it provides for high performance without having to sacrifice integrity
or privacy.  CCM should specifically be used only when the network
demonstrably provides integrity or privacy as required by local
administrative policy.

With respect to your issue #2(a), CCM is a GSS mechanism which provides
authentication services (it can [or should] only be used to wrap GSS
mechanisms which provide authentication services).

With respect to your Issue #2(b), this is, or should be, a security
consideration of RPCSEC_GSS or GSS-API, and not a security consideration
of a GSS mechanism.

With respect to your issue #3(a), new GSS mechanisms should not have to
state this; #3(a) is a feature of RPCSEC_GSS, not of GSS mechanisms.

Similarly, with respect to your issue #3(b), new mechanisms should not
have to state this; #3(b) is a feature of GSS-API, not of GSS
mechanisms.

As for your issue #3(c), this is a security consideration for use of
RPCSEC_GSS with GSS mechanisms that do not provide integrity or privacy
protection.  However, CCM should state that acceptors should not accept
contexts with CCM acceptor credentials unless they can confirm that the
underlying transport provides the requisite integrity or privacy
services.

Cheers,

Nico
--