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

martin.rex@sap.com

From: Martin Rex <martin.rex@sap.com>
Message-Id: <200305271350.PAA04935@uw1048.wdf.sap-ag.de>
Subject: [nfsv4] CCM/GSS: draft-ietf-nfsv4-ccm-00.txt
Date: Tue, 27 May 2003 15:50:50 +0200 (MET DST)

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.

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.

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.

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

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:

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.

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.

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