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

From: [email-masked]
Date: Thu, 27 Feb 2003 18:17:30 -0500

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 5:20 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-eisler-nfsv4-ccm-00.txt
> 
> 
> On Thu, Feb 27, 2003 at 04:05:35PM -0500, [email-masked] wrote:
> > 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.
> 
> 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

The goal for creating a new GSS mechanism here is for protocols such as
RPCSEC_GSS, that previously conduct user authentication for each request, to
authenticate once during context initialization and forego expensive user
authentication for subsequent data requests. To me, this is a major, major
difference from "krb5", by which I assume you mean the use of Kerberos v5 by
RPCSEC_GSS to provide various data services, not the Kerberos v5 mechanism
itself. The security implications as a result of this difference should be
examined carefully to determine how a protocol like RPCSEC_GSS should use
the new GSS mechanism.

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

The word authentication is overloaded. In GSS, it means authenticated
context initialization exchanges. In RPCSEC_GSS, it means using the session
key established during the context initialization to sign a checksum over
the RPC header. The goal is to get rid of the crypto checksum in RPCSEC_GSS
without sacrificing authentication.

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

I get what you are saying. My focus is more on RPCSEC_GSS or any such
protocols and how they could most efficiently use the new GSS mechanism
while retaining the security characteristics. However, I don't think this is
the wrong place for such discussions since this is the reason the new
mechanism is needed in the first place.

> Cheers,
> Nico
> -- 

Also for the current RPCSEC_GSS implementation to work with the new
mechanism with minimal change, it is necessary for the get_mic to return
empty string and verify_mic to be nop. Believe this was mentioned in Mike's
draft. IMHO, this should also be the case for the new wrapper mechanism in
the making.

Peng

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 27 Feb 2003 17:27:59 -0600

> examined carefully to determine how a protocol like RPCSEC_GSS should use

The security considerations for CCM with respect to not providing
integrity or privacy are the same as for any other GSS mechanism that
also fails to provide integrity or privacy services.  Nothing special
here.  It should suffice to state that CCM won't provide integrity or
privacy protection.

> without sacrificing authentication.

CCM (new formulation) provides whatever authentication services are
provided by whatever GSS mechanisms it is used to wrap.

[...]
> mechanism is needed in the first place.

Sure.  I'm merely pointing out that these issues aren't special to CCM,
or even specific to CCM.

[...]
> draft. IMHO, this should also be the case for the new wrapper mechanism in

RPCSEC_GSS should not even attempt to try to MIC with CCM, period,
because CCM won't provide the service.  There is no need to have a no-op
MIC or wrap function for CCM as GSS-API already provides for GSS
mechanisms that cannot provide integrity or privacy services.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 27 Feb 2003 17:40:46 -0600

I'm not even sure that a new GSS mechanism is even necessary.  Can't
NFSv4 negotiate the use or non-use of GSS-API integrity/privacy
services?  I think so.  So perhaps all that is needed is for the server
to force the non-use of GSS-API integrity/privacy services when IPsec is
in use between it and the client, and for the client to not bother with
GSS-API integrity/privacy in initial context establishment attempts when
IPsec is in use between it and the client.

Cheers,

Nico
--