Re: [nfsv4] CCM/GSS: draft-ietf-nfsv4-ccm-00.txt

Nicolas.Williams@sun.com

From: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Re: [nfsv4] CCM/GSS: draft-ietf-nfsv4-ccm-00.txt
Message-ID: <20030527120805.A4352@binky.central.sun.com>
Date: Tue, 27 May 2003 12:08:06 -0700

Martin,

A new version of this draft, -01, is out that is sufficiently different
from -00 that some of your comments may not be applicable.

On Tue, May 27, 2003 at 03:50:50PM +0200, Martin Rex wrote:
> Hi Mike,
> 
> (I'm not subscriber of nfsv4@ietf.org, I got the I-D announcement
>  through the ietf-announce mailing list)
> 
> I've been quick-reading over your I-D draft-ietf-nfsv4-ccm-00.txt 
> and here's some initial feedback from a former CAT-IETF activist:
> 
> 
> First of all, please remove "GSS" from the name and title of the
> I-D because according to Section 6. of your document CCM has so
> many restrictions that it is worlds apart from the meaning of
> Generic as defined by rfc-2743/2744.

This comment, for example, does not, IMO, apply to version -01 of this
draft.

> Summing up Section 6, this mechanism is only usable as part of
> a middleware such as RPCSEC_GSS which has full control over
> the transport that is being used.  GSS-API as defined by
> rfc-2743/2744 is explicitly seperate from any transport and
> channel bindings are a purely optional feature that portable
> application will never supply and which some gssapi mechanisms
> (e.g. Microsoft W2K Kerberos) doesn't even implement.

Neither does this one.

draft-ietf-nfsv4-ccm-01.txt defines two new families of GSS-API
mechanisms:

 - CCM-BIND, a family of three trivial pseudo-mechanisms for negotiation
   of channel bindings use;

 and

 - CCM-MIC, a mechanism for light-weight sec context establishment based
   on currently unexpired, established sec context.

The first one, CCM-BIND, is fully within the GSS-API spec.  The second
one, CCM-MIC, requires a minor extension to the API to be usable.

> One of the primary features of GSS-API is that it is conceptually
> seperate from any kind of transport (an aspect that can not be
> fully supported by Kerberos-like mechanisms), so that an application
> only needs to know who it wants to talk to and a direction in
> which to open a communication channel, but it doesn't need
> to know how many intermediaries (proxies) there are between
> initiator and acceptor and where the acceptor actually is
> located.  This facilitates load balancing for large scale
> services by magnitudes -- just look at what amount of
> technical hacks are necessary to load balance HTTPS in
> sub-optimal fashion.

This is almost right.  GSS-API channel bindings are all about proving
that the initiator and acceptor are using the same underlying transport
session, whatever that might be (IPv4, IPv6, some layer that provides
session integrity or privacy, etc...).

> There's nothing wrong with writing such a piece of code
> in a small interest group for a very specific area of use
> and discussing and/or publishing a specification how it was done,
> but CCM is definitely not a real "GSS" Mechanism, because it's
> definitely not "Generic".

See above.

> 
> 
> 
> Feedback on specific sections of the document where the
> currently specified behaviour doesn't align with rfc-2743:
> 
> Per-Message Tokens (Section 3.3. and 3.4.):
> 
>   The CCM spec says that GSS_GetMIC() will produce an octet string of
>   zero length, however that is a clear violation of the high-level
>   GSS-API spec, both the intention behind it and the wording:

My proposal was to have the MIC tokens for the CCM mechanisms be
constant, non-zero length strings.  I tend to agree that zero-length MIC
tokens violate rfc2743.

> 
> See rfc2743 "Section 2.3 Per-message calls" last paragraph:
> 
>    Although zero-length tokens are never returned by GSS calls for
>    transfer to a context's peer, a zero-length object may be passed by a
>    caller into GSS_Wrap(), in which case the corresponding peer calling
>    GSS_Unwrap() on the transferred token will receive a zero-length
>    object as output from GSS_Unwrap().  Similarly, GSS_GetMIC() can be
>    called on an empty object, yielding a MIC which GSS_VerifyMIC() will
>    successfully verify against the active security context in
>    conjunction with a zero-length object.
> 
> 
> This same clear and explicit paragraph prohibits GSS_Wrap()
> from returning exactly the input token, because in the case of an
> empty input message this would result in an empty output token which
> is prohibited.
> 
> 
> Delete-Context Token (Section 3.5.)
> 
> These tokens have been deprecated by GSS-API v2 and there never
> was a guarantee in v1 that an application caller would transfer
> such a token to the peer at all.  The delete context token
> are simply useless as they were defined.  If there is a necessity
> to signal end-of-transmission on a secure communication channel,
> then the method first used by FTP-GSS-API extensions to
> send an "Empty message" is the way to go.

There's nothing wrong with defining delete context tokens though.

> 
> The recommended behaviour in GSS-API v2
> see rfc-2743 Appendix B: Compatibility with GSS-V1) the paragraph
> about GSS_Delete_sec_context() on page 94:
> 
>       GSS_Delete_sec_context() facility for context_token usage,
>       allowing mechanisms to signal context deletion, is retained for
>       compatibility with GSS-V1.  For current usage, it is recommended
>       that both peers to a context invoke GSS_Delete_sec_context()
>       independently, passing a null output_context_token buffer to
>       indicate that no context_token is required.  Implementations of
>       GSS_Delete_sec_context() should delete relevant locally-stored
>       context information.
> 
> I would strongly recommend not to transfer Delete Tokens at all
> in CCM, simplyfying the spec.

CCM is a mechanism; it transfers nothing.  In the context of this WG you
might want to direct this one comment to ONC/RPC w/ RPCSEC_GSS (i.e., it
is RPCSEC_GSS that should not bother exchanging delete context tokens).

Nico
-- 
_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4