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

From: Mike Eisler <[email-masked]>
Date: Wed, 7 May 2003 10:45:05 -0700 (PDT)

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 7 May 2003 11:13:47 -0700

> I plan on presenting this stuff at the Ann Arbor wg meeting

I'm planning to be there.

> token, and aother CCM OID for short tokens.

I believe (as I described towards the end of my previous post) that the
"short" token form is unnecessary and very difficult to use.

> available"), there will be a variant of CCM that uses session key-based

I disagree:

A) We can define what the IPsec channel bindings should be in the
   context of CCM.  I also believe that defining the IPsec channel
   bindings is nigh trivial, so trivial that we'd be irresponsible if we
   did not do so and so specified CCM w/o channel bindings.

   Worst case scenario we get it wrong and have to introduce a second
   version of CCM.  But CCM is so simple...  Also, we can always ask for
   input from IPsec types, and since there is no urgent need for CCM, we
   can certainly afford to wait until we have solid input from people
   who are closer to IPsec than we are.

B) I believe we can get away with defining the contents of the SPKM
   Channel-Id field in the context of CCM.  This is a bit more iffy, but
   noone really uses SPKM, certainly not with channel bindings (and if
   so, not interoperably).  (Are there even two implementations of SPKM??)

   Worst case scenario a separate draft will be needed to define the
   contents of the SPKM Channel-Id field.  No big deal.

> a chicken and egg problem.

Huh??  My model is that CCM is to be used for negotiating the use of
GSS-API channel bingings and the non-use of GSS-API MICs/wraps.

>     - specifications for aforementioned

I propose that we write them.  What's wrong with that?

> 	channel bindings, across Linux, Windows, and the UNIXes.

This is silly.  We cannot predicate protocol design on API availability;
if you don't have the API, tough - add it.

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

The Kerberos V mechanism (and all current implementations that I know
of) fully support channel bindings.

As for SPKM, noone uses it now and it's trivial to clarify how to do
channel bindings with SPKM.

> is going to materialize into something real in the timeframe when we

Huh??  See above - the Kerberos V mech has full support for channel
bindings.  AES does not enter the picture here.

> mean that third party NFS implementors are too be shut out? I don't think

I think the 3rd party implementor simply does not get to implement CCM;
no big deal.  Or they can implement IPsec too.

> on SPKM-3/LIPKEY vapor. Three is too many).

You wrote a largish document based on vapourware and now refuse to write
a short, trivial description of the Channel-Id field of SPKM??

> few bytes of the nonce which is what the short token involves.

I believe that CCM is needed primarily to reduce the number of crypto
contexts needed for Secure NFS down from as many as a dozen per-{client,
user, server} tuple to 1 per {client, server} tuple.  The reason that
many NFS w/ RPCSEC_GSS client implementations establish so many GSS-API
contexts per-user has to do with multi-threading; obviously, going down
to one crypto context per-{client, server} tuple removes the need to
establish so many GSS-API contexts (the multi-threading issue does not
necessarily go away, unless you have HW-accelerated IPsec, which is most
definitely needed on very large, high-bandwidth Secure NFS servers).

> But that's not really the point ...

Well, that is the point, for me.

> let's go back to something Peng wrote on February 27:

You continue to predicate your opposition to channel bindings on this
notion that we cannot specify them.  I have offered a specification for
IKEv1 channel bindings and a clarification for SPKM and, rather than
evaluate this you keep shaking your head and saying "the spec doesn't
exist".  Well, no, it doesn't, so let's create it and move on.

[...]
> as challenged as my knowledge of iSCSI).

The Kerberos GSS-API context establishment is not much more heavy duty
than the MIC; I suppose the same is not true for SPKM, which might
therefore justify it.  Do you think that clients will establish
multiple, concurrent TCP connections to the same server when CCM is
available?  If so then perhaps the short option is still worthwhile in
the context of SPKM, and in that case I would prefer to have two CCM
mechanisms: one being a trivial wrapper (the "long" option) and the
other being a context-handle-ID/MIC exchange (the "short" option).

> Difficult, hence optional.

I think that use of the "short" option through the GSS-API or extensions
to the GSS-API needed for the same SHOULD be described in the spec for
the "short" CCM option.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 7 May 2003 13:19:41 -0700

On Wed, May 07, 2003 at 03:53:50PM -0400, Sam Hartman wrote:
> I'm failing to see a strong justification for ever using CCM without
> channel bindings and am concerned that unless they are mandated that
> vendors will take the quick route to implementation and not implement
> them.
> 
> Unless there is something I'm missing on this issue, I don't think I
> could go along with a CCM draft that did not mandate implementing
> channel bindings.

Sam, I'm beginning to think that the opposition to using channel
bindings stems from a fear that using channel bindings would require
this WG to wait for other WGs to define IPsec channel bindings and/or
clarify how channel bindings are used with the SPKM mechanism.  (There
also appears to be a misconception that the Kerberos mechanism doesn't
universally support channel bindings, but I hope it is clear now that
this is not remotely the case).

I believe that the GSS-API RFCs (specifically, RFC2744) allow the
application to define the contents of the application_data[*] field of
the channel bindings structure, and therefore this allows this WG to
define IPsec channel bindings for use with CCM in the same document as
CCM.  Perhaps any such draft defining GSS-API channel bindings for IPsec
should be last-called in the IPSEC WG, or its successor, as well as in
the NFSv4 WG, but I see no reason whatsoever why this WG (NFSv4) could
not define such channel bindings (or, for that matter, the
interpretation of the SPKM Channel-Id field).

Perhaps I am missing something about IETF processes that would mean that
GSS-API channel bindings for IPsec could not be defined in this WG in
any context.  But I don't think so; not only can this WG do this work,
but the definition of IPsec channel bindings seems rather simple.  If
I'm wrong about this, please correct me.

Nico

[*] I don't view IPsec channel bindings as a network address type, which
    leaves us with the application_data field of the channel bindings
    structure to pass the IPsec channel bindings to
    gss_init/accept_sec_context().
-- 
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 May 2003 15:53:50 -0400

>>>>> "Mike" == Mike Eisler <[email-masked]> writes:

    Mike> Thanks for the quick feedback.  I plan on presenting this
    Mike> stuff at the Ann Arbor wg meeting in June.

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

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