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

From: Mike Eisler <[email-masked]>
Date: Tue, 25 Feb 2003 12:48:46 -0800

http://www.ietf.org/internet-drafts/draft-eisler-nfsv4-ccm-00.txt

Last December (2002), there was a discussion about whether the
per RPC overhead of RPCSEC_GSS could be avoided if the
data connection was protected with IPsec. The
aforementioned i-d proposes a method for doing
so. With10G network media are coming, the
overhead of an integrity checksum of a even just
an RPC header becomes significant. What I'm
proposing allows NFSv4 implementors to
use the existing security model. I would
appreciate comments, either to me, or to
the nfsv4-wg alias. Thanks.

    -mre

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Feb 2003 22:45:53 -0600

Cool.

Comments.  Nits first.

Section 1, paragraph 3, sentence 5, "content" should be "context".
Section 1, paragraph 3, sentence 6, second appearance of "CCM" should be "GSS".

Section 2, paragraph 3, sentence 2, "content" should be "context".

Section 3.1.1, paragraph 1, sentence 2, I'm not sure what this
    "mechanism independent token" is that is referenced.

Section 4.1, paragraph 1, sentence 3, "... uses for match initiator ..."
    is grammatically incorrect and I cannot guess what exactly was meant.

Section 4.1 - since the CCM_ict_t type (initial token) is supposed to
refer to an application-level GSS context "handle" identifier, it makes
most sense [to me] to use that as the initiator's name.  This the
application would gss_import_name() with the CCM_ict_t value as the
name, then gss_acquire_cred(), then gss_init_sec_context().  A new GSS
name type may be required for this, or perhaps the existing exported
name type could be used...  This would avoid the "response_token"
boolean union discriminator you're currently using.

Also, it makes sense to me that the initiator name *is* the application
level GSS context handle name negotiated at the app level by the
initiator and acceptor.  Not only is there a clean way for the client to
refer to this handle when initiating CCM, but there is also a clean way
for the acceptor to obtain this information.  Unfortunately, the
semantics of the acceptor name and credential in CCM are not yet clear
to me; GSS_C_NO_CREDENTIAL could be used, but the problem is that when
gss_accept_sec_context() returns it should return GSS_S_COMPLETE since
this is CCM and it's a one-round-trip exchange and
gss_accept_sec_context() cannot know a priori if the initiator's token
is valid unless the acceptor provides the CCM handle via the acceptor
credential, which then brings up the question of how to make that
credential, which would be done via gss_acquire_credential, but since
GSS-API lacks a concept of credential sets how could the server know
which CCM accpeptor cred to use without inspecting the token?!  The
answer may be to treat GSS acceptor creds as a set and use
gss_add_cred() to add those app-level handle identifiers to the CCM
acceptor cred as they are created; this seems right to me, but RFC2743
says that gss_add_cred() "should" [not MUST, or even SHOULD] be used
with the same desired_name as the name used in the initial
gss_acquire_cred(); though a GSS cred can be construed to be a set of
creds for different names, RFC2743 seems to intend them to be a set of
creds of different mechanisms for the same principal.

The more I think about it (and I have not thought about it that much
yet), treating the app-level GSS ctx handles as CCM names and using
gss_add_cred() to build a single CCM acceptor cred representing all the
current app-level GSS ctx handles is the right way to go.  I don't see
this as prohibited by RFC2743, in any case, though this is certainly
stretching the original purpose of gss_add_cred().

Here [section 5] I stop reviewing the draft.  I'll read the rest some
other time.

Cheers,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 26 Feb 2003 08:16:06 -0600

More thoughts on this matter:

 - Do treat the app-level (e.g., RPCSEC_GSS) GSS ctxt handles as CCM
   initiator and acceptor names, if you want to be able to use CCM
   through the GSS API.

 - I think that initial CCM tokens should include a MIC of the applevel
   GSS ctxt handle made using the GSS context referred to by the CCM
   token.  RFC2203 allows the server to destroy GSS ctxts on an LRU
   basis and seems to allow the server to reuse GSS ctxt handles, so it
   seems to me that sending the handle name while initiating a CCM ctxt
   is not enough, that the client should prove it has the named GSS
   ctxt.

 - If the server maintains a single, global namespace for app-level GSS
   context handle names then the GSS credential set approach I mentioned
   will do, otherwise the server will have to first try accepting
   contexts using its normal GSS handle, then if gss_accept_sec_ctx()
   returns GSS_S_NO_CRED, try accepting using a CCM acceptor cred that
   refers only to the app-level handle names corresponding to the
   client (this is still a GSS credential set, but smaller than a single
   global one).

   NOTE: There is no gss_remove_cred()... so the single global GSS CCM
         cred set approach is problematic anyways...  Perhaps RPCSEC_GSS
	 servers should attempt not to reuse GSS ctxt handle names and
	 should construct handles in such a way as to make reuse
	 extremely unlikely.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 26 Feb 2003 12:48:09 -0600

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

Oh, and, such a mech's name would have to be different from CCM.

Cheers,

Nico

[*] So you'd have KerberosV and CCM-KerberosV, and SPKM-1 and
    CCM-SPKM-1, and so on and so forth.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 26 Feb 2003 12:05:32 -0800

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

> better positioned to determine the level of protection afforded by the

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