Subject: [nfsv4] Comments on CCM draft -00

From: Nicolas Williams <[email-masked]>
Date: Wed, 7 May 2003 09:04:26 -0700

1) CCM is dangerous without mandating the use of channel bindings.

2) CCM does not require any token structure, really - just prefix CCM's
   OID to the underlying mechanism's OID, OR make the CCM token's
   contents be the token from the underlying mechanism.

3) The channel bindings data for IKEv1 should be the octet string
   resulting from concatenating HASH_I with HASH_R (from the IKEv1
   spec).  That is, the value of the gss_channel_bindings_struct used
   with gss_init_sec_context() and gss_accept_sec_context should be as
   follows:

   {
	initiator_addrtype	    = NULL,
	initiator_address.length    = 0,
	acceptor_address.value	    = NULL,
	acceptor_address.value	    = NULL,
	application_data.length	    = <length of HASH_I|HASH_R>,
	application_data.value	    = HASH_I|HASH_R
   }

   I haven't yet determined what channel bindings value to use
   for IKEv2.

4) IKEv1 and IKEv2 do support anonymous mode IPsec: by using self-signed
   certificates.

5) It should be possible to configure IPsec with self-signed
   certificates (and random names even) without having to have a
   full-fledged PKI infrastructure provided that IPsec is only used in
   conjunction with GSS-API or any other generic security system that
   provides for secure verification of channel bindings.

6) SPKM (1 and 1, and therefore 3) will require clarification as to the
   expected contents of the Channel-Id field (type: OCTET STRING).  I
   propose that network address channel bindings being useless[*]
   only binding to "transformations of encryption keys" will ever be
   useful with SPKM, so the SPKM Channel-Id's value when used in
   connection with CCM should be just the value of the
   "application_data" field of the gss_channel_bindings_t structure
   (RFC2744).

   [*] See past discussions on network address channel bindings at the
       IETF KRB WG and MIT kerberos (a.k.a. comp.protocols.kerberos)
       and krbdev mailing lists.

The combination of RPCSEC_GSS with the use of GSS-API channel
bindings to IPsec sessions therefore moves authentication from the
IPsec layer up to the RPCSEC_GSS layer and session integrity/privacy
protection from the RPCSEC_GSS layer down to the IPsec layer.

CCM should be viewed as a GSS-API pseudo-mechanism whose purpose is
negotiating the use of GSS-API channel bindings and the non-use of
GSS-API for session integrity/privacy protection.

Mike,

I continue to utterly fail to understand your opposition to the use of
channel bindings.  The use of channel bindings to IPsec prevents
men-in-the-middle attacks against RPCSEC_GSS w/ CCM and therefore
resolves the most important security issues with CCM.  [**]

[**] I seem to remember arguments about those IKE hash values not being
     exposed to applications via socket options.  However, I see that,
     for example, Solaris exposes a great deal of IPsec information to
     the application - ensuring that HASH_I and HASH_R are also exposed
     would be a small extension to this interface.  Therefore I do not
     consider this argument to hold any water.

I also fail to see the use for the "short" token format.  GSS-API
context establishment is not particularly expensive and CCM will greatly
reduce the number of GSS-API contexts that NFS w/ RPCSEC_GSS clients
will establish for each user anyways, thus rendering the utility of CCM
"short" tokens meaningless.  Besides, as you yourself pointed out when
you posted the first version of CCM this past winter, it is difficult to
use this feature of CCM with the GSS-API.  Removing the notion of
creating new CCM contexts based on previously established GSS-API
contexts removes any and all need for CCM tokens to be structured (see
comment (2) above).

Cheers,

Nico
-- 
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 12 May 2003 11:06:01 -0500

> 1) CCM is dangerous without mandating the use of channel bindings.

So, I'd like to clarify this.  I think there needs to be an option for
channel bindings.  Around the time of this past Connectathon I offered
three options:  negotiate no bindings, negotiate network address channel
bindings and negotiate the use IPsec/... bindings.

Negotiating no bindings and no session crypto can be useful in some
environments.

>    contents be the token from the underlying mechanism.

This is true of the channel bindings negotiation.  The "short" CCM
option does require some structure.  See below.

> resolves the most important security issues with CCM.  [**]

I should clarify this.  I think it's important to have an option to
negotiate no session crypto with no channel bindings, and an option to
negotiate no session crypto with channel bindings.

> contexts removes any and all need for CCM tokens to be structured (see

I take this back.  A comment from Mike convinced me that the "short" CCM
option could be useful.

So now I think that this option is worth specifying.

Cheers,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 12 May 2003 11:51:02 -0700

On Mon, May 12, 2003 at 02:21:19PM -0400, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
> 
>     Nicolas> So, I'd like to clarify this.  I think there needs to be
>     Nicolas> an option for channel bindings.  Around the time of this
>     Nicolas> past Connectathon I offered three options: negotiate no
>     Nicolas> bindings, negotiate network address channel bindings and
>     Nicolas> negotiate the use IPsec/... bindings.
> 
>     Nicolas> Negotiating no bindings and no session crypto can be
>     Nicolas> useful in some environments.
> 
> 
> I'd love to push for mandating the use of channel bindings.  I suspect
> I'd be alone in that desire.

I don't mind mandating that implementations support binding to IPsec
channels.  BUT, while we can define channel bindings to IKEv1, we can't
really define channel bindings to IKEv2 just yet - not if we want this
protposal to progress independently of IKEv2.

BTW, here's my proposal for channel bindings for IKEv2: {SPIi | SPIr}

Cheers,

Nico

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 May 2003 14:21:19 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, May 07, 2003 at 09:04:26AM -0700, Nicolas

What I do think is reasonable to require is that implementations must
implement some real channel bindings.  If you want to turn it off, say
because you have some box that you want to tap your traffic on, that's
fine.

But I as a user want to have a guarantee that if I buy two CCM-capable
devices that both support IPSEC, I can configure both devices to talk
to each other using channel bindings.  To get this I need mandatory to
implement channel bindings even if they are not mandatory to use.

--Sam