Subject: RE: [nfsv4] Comments on CCM draft -00

From: "dai, peng" <[email-masked]>
Date: Thu, 8 May 2003 11:29:09 -0400

Mike,

CCM, as presented in your latest draft, is self-consistent and does not
present any new security risks, at least not apparent to me.

As for channel binding, the draft does require the simplest form, that is,
binding the context to the transport connection over which it is created.
Using this form of binding does not require any interface to IPSec. And we
know it is secure because this is pretty much bundling RPC, GSSAPI, and the
iSCSI connection model together.

A major concern with this form of binding is that it requires at least one
(usually more as Nico noted) transport connection per user credential. This
would almost certainly cause resource problems in large NFS servers. Another
practical problem is for imposing this new connection model over existing
RPC based applications that are used to multiplexing requests over a few
transport connections. A more sophisticated binding, such as based on IKE
session, would eliminate the problems. Such a binding would also eliminate
the need for the "short tokens" because it is no longer necessary to
authenticate each transport connection separately.

With this said, I agree with you on having the CCM relatively independent of
the channel bindings. CCM needs to lay out the channel binding requirements
without actually specifying them. One benefit of this modular approach is
new channel bindings (who knows what secure channels may come out in the
next 10 years) can be added effortlessly.

Peng

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Wednesday, May 07, 2003 1:45 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [nfsv4] Comments on CCM draft -00

Thanks for the quick feedback.

I plan on presenting this stuff at the Ann Arbor wg meeting
in June.

Nicolas Williams wrote:

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

Agreed, and I hope the Security Considerations captures the danger.
But if sometingis dangerous, it doesn't follow that it shouldn't be
done.

It is also the case that without channel bindings, CCM probably can't
be used over connectionless transports. At least, I cannot think
of a way to do so.

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

Structure certainly needs to be defined for mic and seal tokens, but
you were probably refering to the context tokens in the i-d.

For the "full token" route I agree. Assuming there is consensus that
short tokens are useful, a less complex way to deal with this is to
have a CCM OID for full tokens, which would use underlying mech's
token, and aother CCM OID for short tokens.

> 3) The channel bindings data for IKEv1 should be the octet string

[...]

> 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

[...]

> 6) SPKM (1 and 1, and therefore 3) will require clarification as to the

[...]

The common theme here is that there's work to be done in standardizing
channel bindings and anonymous IPsec, which is not the scope of the
current CCM i-d. As the i-d notes, then this stuff is figured out (and
the i-d does not say, but perhaps should:  "when it is generally
available"), there will be a variant of CCM that uses session key-based
channel bindings.

BTW, when I presented (perhaps misrepresented?) your position on
anonymous IPsec at the IETF wg mtg in SFO, there was a lot of head
shaking. I think the perceived problem with your model is that it is
dangerous and useless without something like CCM above it. So we've got
a chicken and egg problem.

> 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'm opposed to authoring specifications that rely on vaporware. The vapor
here
includes:
    - specifications for aforementioned
    - availability of API extensions to IPsec, SSH, and TLS for getting the
	channel bindings, across Linux, Windows, and the UNIXes.

    - availability of krb5 and spkm/lipey mechanisms that uses channel
bindings

There's no spec for AES extensions of RFC1964, and NIST selected AES
years ago. And AES support in Kerberos V5 is far more important than
channel bindings. So forgive me I suspend my belief that all this vapor
is going to materialize into something real in the timeframe when we
need CCM.

Let's suppose the standards stuff gets done, but an OS vendor refuses
to implement the APIs needed to acquire IPsec channel bindings. Does that
mean that third party NFS implementors are too be shut out? I don't think
that's right.

(And let me point out, before someone else does, I did author the
SPKM-3/LIPKEY RFC which depended on a generally accessible ASN to C
compiler, and then I co-authored two NFSv4 RFCs that depended in turn
on SPKM-3/LIPKEY vapor. Three is too many).

> I also fail to see the use for the "short" token format.  GSS-API
> context establishment is not particularly expensive and CCM will greatly

Given the existence of gssd for creating contexts on behalf of the
kernel in several operating environments, this is clearly not true.
It is particularly complex, and I suspect more expensive than signing a
few bytes of the nonce which is what the short token involves.

But that's not really the point ...

> 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

Sure, if channel bindings are present. Otherwise,
let's go back to something Peng wrote on February 27:

p> The problem here is the lack of binding between the authentication
context
p> established through traditional GSS mechanisms and the secure transport
p> channel used in CCM.
p> 
p> In order to provide this binding, we must integrity protect the
application
p> context handle among other things passed in the rpc_gss_init_arg. For
p> example, we could generate a checksum over the application context
handle,
p> among other things if the handle does not have enough bytes, using the
p> session key found in the soon-to-be-replaced authentication context, and
p> pass the whole thing as the opaque token in rpc_gss_init_arg. In the
p> response, the server has to do the same with the CCM status.

Then on 2/28 Peng wrote:

p> On the second thought, maybe you [mre] meant for the initial Kerberos
context
p> initialization also go thru the same IPSec channel and the binding
between
p> the kerberos context and the channel used to establish it is recorded
there?
p> If this is the case, then my concern would be unnecessary.

My takeaway was that unless the initiator and target can be certain
that two TCP connections are bound to same secure channel (i.e. unless
there are channel bindings), then re-authentication at the RPCSEC_GSS
level over the underlying mechanism needs to occur with each TCP
connection. Why create a full blown Keberos context with all the
aforementioned baggage, when we can use one to bind to another via a
mic? (The idea for this came from Julian Satran, or at least that was
my interpretation of what he was saying ...  his knowledge of GSS was
as challenged as my knowledge of iSCSI).

> 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

Difficult, hence optional.

> 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).
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: [email-masked]
Date: Fri, 9 May 2003 17:59:30 -0400

Folks,

> Telling those among us who can't change the IP stack "tough luck"
> is going to beg the rebuttal "how can iSCSI get by without channel
bindings?"
> (which as far as I can tell, aren't even optional ... at least the current
> i-d for CCM acknowledges their possibility).

Some of this reminds me of the tunnel mode vs. transport mode debate for
iSCSI and the other IPS protocols, which also got wrapped around the
end-to-end axle.  The eventual conclusion in that situation was that
end-to-end scope of a security association is primarily determined by
security policy, specifically which nodes have which credentials

In other words, to be specific about the iSCSI case, forcing the use
of transport mode to try to avoid introduction of intermediate security
gateways is the wrong way to approach this sort of design concern - if
one ensures that the possible intermediate gateways do not have the
credentials required to participate in the IPsec SAs involved, it's
not going to be possible for such an intermediate gateway to interfere
with the security of those SAs, even if every packet is forwarded
through the gateway.  OTOH, if the gateway has the credentials, use
of transport mode provides no additional security, as the gateway could
function as a transport-mode forwarding proxy.

I think the difference here is that iSCSI relies on appropriate and
correct configuration of the IPsec Security Policy Databases, and
appropriately controlled distribution/installation of IPsec security
credentials, in accordance with relevant security policy.  Channel
bindings appear to be intended to deal with an attacker who can
gain access to the IPsec keying material, but not NFSv4's - it
might be useful to phrase further discussion in terms of the level
of risk/threat posed by such attackers.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: [email-masked]
Date: Tue, 13 May 2003 18:47:48 -0400

Replying to my own post ...

> I agree, but what IPsec does know is the port on which the client
> contacts the NFS server, and it can control traffic at port
> granularity level.  Since simple administration is being emphasized
> here, one IPsec SPD entry can stop the SA setup to the MITM.

I found the fly in the ointment - per RFC 2401, the port selector
support in the IPsec SPD that's needed to do this is optional (MAY
be supported), so there's no guarantee that an IPsec implementation
will be able to do this, although the mechanisms are specified to
do so.  If this support is not present, and the MITM attack is
a risk, then channel bindings are needed to counter it.  It may
be possible to make this port selector support mandatory when
CCM is used with IPsec.

Sorry/Thanks,
--David

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2003 5:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [nfsv4] Re: Comments on CCM draft -00
> 
> 
> Nico,
> 
> > I grant you that IPsec does not itself use DNS, it's the client
> > application that [indirectly] initiates the IPsec SA that uses DNS.
> > 
> > So, here's a Solaris-specific (somewhat simplified) example:
> > 
> > Client					    Server
> > ------					    ------
> > 
> > userland->kernel (chdir("/net/server/blah/"))
> > kernel->autmountd
> > automountd->mount
> > mount[*]->DNS (resolve "server")
> > mount[*]->server (connect)
> > 
> > 		[IPsec SA establishment]
> > 
> > mount[*]->gssd (gss_init_sec_context())
> > mount[*]->server (context token)
> > 
> > 					    server->gssd (accept token)
> > 					    server->client 
> > (context token)
> > ...		[GSS context establishment] ...
> > mount->automountd (return)
> > automountd->kernel (return)
> > kernel->user (return)
> > 
> > [*] Parts of the mount may happen in the kernel, parts in user-land.
> > 
> > The one DNS operation above determines the IP address used 
> by the client
> > to reference the server, but the IPsec layer has NO WAY to 
> determine if
> > that really is what the client wants (the client wants "server", and
> > really doesn't care about the IP address - IPsec knows 
> nothing about the
> > hostname, just the IP).
> 
> I agree, but what IPsec does know is the port on which the client
> contacts the NFS server, and it can control traffic at port
> granularity level.  Since simple administration is being emphasized
> here, one IPsec SPD entry can stop the SA setup to the MITM.  That
> entry requires that all traffic to/from the ports used by NFS
> be over an SA authenticated to an IPsec identity whose keying
> material is only installed on the real NFS servers.  That stops
> IPsec SA setup to the MITM because the SPD entry requires an
> authentication that the MITM cannot perform.  If one wants to
> ensure at the IPsec level that NFS servers can't impersonate
> one another, it costs an SPD entry per server to identify
> each server's credentials.  To defeat the latter via DNS spoofing,
> one has to have an IPsec config tool that is using DNS without
> additional verification (not a great idea, but probably happens)
> and attack that tool at the crucial moment when it is
> being used to configure IPsec.
> 
> > If the problem is not clear by now, I don't know how to make it any
> > clearer; perhaps Sam can put this more eloquently or in 
> simpler terms
> > (Sam Hartman and Tom Yu[**] first pointed out this attack to me at
> > Cthon03, more or less concurrently with Dai Peng on the list).
> 
> And I hope it's equally clear that IPsec can be configured and
> managed to prevent this MITM attack.  I understand that much of the
> interest in anonymous IPsec is based on a desire to do as little
> IPsec admin as possible (ideally none), and if one does not
> administer/configure IPsec in a way that would prevent the MITM
> attack, then it obviously becomes possible.  However, I disagree
> with any assertion that this MITM attack is inherent in the
> use of IPsec underneath NFS.  On that basis, I think all of
> the requests for channel bindings come down to wanting to
> simplify IPsec administration and/or deal with situations in
> which IPsec administration has to be simplified and/or shouldn't
> be trusted.  That set of arguments is ok with me, but the MITM
> attack is not inherent to the use of IPsec. 
> 
> Thanks,
> --David