Subject: [nfsv4] CCM and TLS

From: Nicolas Williams <[email-masked]>
Date: Sun, 18 May 2003 16:34:27 -0700

I just looked at rfc2246 (TLS v1.0) for something we can use as GSS-API
channel bindings for TLS.

TLS defines a session ID that can be used as bindings for CCM-KEY, but
it is only provided for restartable TLS sessions.  We can probably
define the GSS-API channel bindings to TLS as the session ID in question
and require CCM-KEY be used with TLS bindings only when the TLS server
has assigned a session ID.

Cheers,

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 May 2003 00:05:36 -0500

I withdraw this suggestion.  A MITM spoofing the server could ensure
that the client and server agree on a TLS session ID.

It may be necessary to define a TLS session ID for use as channel
bindings in a way similar to SSHv2 or to what I specified for IKEv1.

The IKEv2 bindings I proposed may suffer from the same problem.  I will
seek advice from persons more familiar with IKEv2.

Note that a MITM could not cause SSHv2 or IKEv1 peers to agree on the
same channel bindings.  This is because in order to insert itself as an
MITM the attacker has to complete DH exchanges with both peers such that
the key exchange message hashes end up having the same values for the
client and server, which can only happen if the MITM knows the exponents
chosen by both, the client and the server - else the SSHv2 session ID or
IKEv1 HASH_I/HASH_R values would not match and the CCM-KEY context setup
would fail.

Cheers,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 May 2003 23:29:52 -0500

Yes, I believe I got the IKEv2 GSS-API channel bindings specification
wrong.

There is an IKEv2 equivalent to the IKEv1 HASH_I and HASH_R values: the
AUTH values used in the second phase of the key exchange as defined in
section 2.15 of the IKEv2 draft.  (I'd missed this entirely because
section 2.15 uses English text to describe the constrution of AUTH
values rather than notation (except for cases where pre-shared keys are
used) and it was not clear to me that that text describes these AUTH
values.)

Anyways, there are two IKEv2 AUTH values, one for the initiator and one
for the responder - unfortunately the draft does not refer to these as
AUTHi and AUTHr.  I propose the concatenation of these two AUTH values
as the GSS-API channel bindings for IKEv2.

Cheers,

Nico