Subject: [nfsv4] RDDP and mandatory security

From: Sam Hartman <[email-masked]>
Date: Tue, 04 Dec 2007 11:50:03 -0500

I had a meeting with Thomas Talpey and Spencer Shepler yesterday on
the rdma drafts.

Speaking as an area director, I plan to introduce a blocking comment
on these drafts because there is no mandatory to implement security
mechanism that is likely to meet the performance characteristics of
the RDMA protocol.

Speaking as an individual, let me try and explain that and explain a
way forward.

The IETF has a requirement document called BCP 61 that requires we
provide mandatory to implement security services for our protocols
suitable for deployment on the Internet.  NFS has decided that the
appropriate security services for NFS are authentication, integrity
and confidentiality.

It's not stated in BCP 61 but is generally accepted that the security
solution needs to meet the design requirements of the protocol.  For
example if you have a protocol that focuses on auto-discovery, you
need a security mechanism that works in that environment.  If you have
a protocol that focuses on performance you need a security mechanism
that is consistent with these goals.

We don't have that.  rpcsec_gss involves a lot of copies.

However we do have a lot of the parts of a mechanism that could
provide reasonable performance for RDMA and NFS.  In particular,
channel binding could do that.

I propose as an individual that we work to together to finish that
solution and make it the mandatory to implement security solution.

So, here are the parts of the solution:

1) IPsec; already required  by RRDDP.

2) The basic channel binding framework; RFC 5056

3) A channel binding type for IPsec.  The channel binding framework
   says that draft-ietf-btns-connection-latching defines this but the
   draft doesn't actually do so.  We do have proposals from the past
   floating around.

4) Connection latching, which is required to actually get an IPsec
   channel.  See draft-ietf-btns-connection-latching.  This draft is
   stuck in BTNS needing some additional review.

5) A GSS mechanism (previously called CCM) that can be used to signal
   the use of channel binding and that can  replace gss_wrap with null
   operations when channel binding is used.  We have old text floating
   around for this, but no current draft.  I'd be happy to sponsor
   this draft as an AD-sponsored standards track document.

n6)  NFS specific text discussing when the CCM mechanism should be
    offered and how this interacts with NFS and RDMA.

We're going to need your help reviewing some drafts in order to make
this a reality.

I realize that this is going to be more work than the working group
was hoping for, but I think that we need to meet the IETF's security
requirements.

If people want me to attend tomorrow's NFS V4 session I can do so.
Chairs, please let me know if I need to attend by 5 PM today.

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 4 Dec 2007 11:17:43 -0600

>    this draft as an AD-sponsored standards track document.

Alternatively a change to RPCSEC_GSS to support channel binding
directly.

The lack of an IPsec channel and channel binding will make this painful
for the NFSv4 WG -- that is, the NFSv4 w/ RDDP document may end up
sitting on the RFC-Editor queue waiting for blocking dependencies for a
while.  The blocking dependencies (one or two BTNS WG documents),
however, should move quickly _provided_ that we can get reviews of the
relevant BTNS WG work.

Nico
--

---

From: Mike Eisler <[email-masked]>
Date: Tue, 4 Dec 2007 09:40:35 -0800 (PST)

> mechanism that is likely to meet the performance characteristics of

[...]

> appropriate security services for NFS are authentication, integrity
[...]
> channel binding could do that.

Correct me if I am wrong, but iSCSI has integrity and privacy requires,
and has its own authentication method (CHAP) and does not rely on
channel bindings. Why does it not suffice for NFS over RDDP?

Will all protocols that make normative requirements to RDDP (RFC5040)
be subject to blocking comments?

>     offered and how this interacts with NFS and RDMA.

We will do whatever it takes, and for my part, now that the NFSv4.1
stuff is winding down, I can focus on CCM starting in January, if
necessary.

But I will say that CCM was conceived at time when it was believed
that wire-speed IPsec (using CBC) would be ubiquitous by now.
It hasn't happened. I don't think it will ever happen. The wires
are getting faster and the TOEs with IPsec are not keeping up.

So the practical use of the six things Sam has presented above
is doubtful. I doubt we'll ever see two inter-operable implementations.

I'd like to see some analysis that says that the laws of physics
are consistent with the laws of IETF on this matter.

> If people want me to attend tomorrow's NFS V4 session I can do so.

This would be a good idea.

   -mre

---

From: Sam Hartman <[email-masked]>
Date: Tue, 04 Dec 2007 12:54:01 -0500

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

    Mike> Correct me if I am wrong, but iSCSI has integrity and
    Mike> privacy requires, and has its own authentication method
    Mike> (CHAP) and does not rely on channel bindings. Why does it
    Mike> not suffice for NFS over RDDP?
I don't think that CHAP without channel binding would be sufficient
today.  The problem is that you have two security infrastructures
required at two different levels.

    Mike> Will all protocols that make normative requirements to RDDP
    Mike> (RFC5040) be subject to blocking comments?

Obviously, if the protocol includes the appropriate security
solutions, it won't get blocked.

Having security solutions at two different layers that are not bound
together would tend to be a sign of a problem, yes.

---

From: "Talpey, Thomas" <[email-masked]>
Date: Tue, 04 Dec 2007 14:02:20 -0500

>Alternatively a change to RPCSEC_GSS to support channel binding

I wholeheartedly agree. It could help plain old Ethernet too, imagining an
IPsec-capable TOE adapter servicing an NFS/TCP connection, for instance.

>however, should move quickly _provided_ that we can get reviews of the

Yes, I'm concerned about this too. Even with a new document inserted as
a shim between RFC5056 and RPCSEC_GSS to manage channel bindings,
there are at least two BTNS documents needed, I believe CONN-LATCH
and also the BTNS-IPSEC API work, which at this point is only at the
requirements stage.

That said, I wholeheartedly agree that mapping out the means by which
NFSv4/RPCSEC_GSS can leverage the IPsec capabilities of RDDP adapters
does need to be updated in light of the new specs available to be
normatively referenced. It's the ones _not_ yet available that concern
me. My understanding is that Sam will be bring this up at BTNS on Thurs.

Tom.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 04 Dec 2007 14:14:32 -0500

>>>>> "Talpey," == Talpey, Thomas <[email-masked]> writes:

    Talpey,> Yes, I'm concerned about this too. Even with a new
    Talpey,> document inserted as a shim between RFC5056 and
    Talpey,> RPCSEC_GSS to manage channel bindings, there are at least
    Talpey,> two BTNS documents needed, I believe CONN-LATCH and also
    Talpey,> the BTNS-IPSEC API work, which at this point is only at
    Talpey,> the requirements stage.

Why do you believe the API document is required?  If so, I'd like to
find a way to avoiding the requirement.

---

From: "Talpey, Thomas" <[email-masked]>
Date: Tue, 04 Dec 2007 14:19:24 -0500

>find a way to avoiding the requirement.

Oh that would be my preference too. I thought you indicated it was
going to be required due to its definition of the OID naming, which
would enable the IPsec property recognition by the RPCSEC_GSS
layer above. Perhaps I misunderstood.

Tom.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 4 Dec 2007 13:27:51 -0600

> Yes, I'm concerned about this too. Even with a new document inserted as

I didn't say that I was concerned, only that the NFSv4 WG probably would be :)

---

From: Sam Hartman <[email-masked]>
Date: Tue, 04 Dec 2007 16:08:35 -0500

Talpey,> At 02:14 PM 12/4/2007, Sam Hartman wrote:
    >> Talpey,> RPCSEC_GSS to manage channel bindings, there are at
    >> least Talpey,> two BTNS documents needed, I believe CONN-LATCH
    >> and also Talpey,> the BTNS-IPSEC API work, which at this point
    >> is only at Talpey,> the requirements stage.
    >> 
    >> Why do you believe the API document is required?  If so, I'd
    >> like to find a way to avoiding the requirement.

    Talpey,> Oh that would be my preference too. I thought you
    Talpey,> indicated it was going to be required due to its
    Talpey,> definition of the OID naming, which would enable the
    Talpey,> IPsec property recognition by the RPCSEC_GSS layer
    Talpey,> above. Perhaps I misunderstood.

No, I think the CCM OID comes from the CCM draft if we go that route.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 4 Dec 2007 17:55:07 -0600

> IPsec-capable TOE adapter servicing an NFS/TCP connection, for instance.

Either way you can offload ESP/AH handling to any hw that can do it.

That's not the issue.  The issue is whether it might be better to change
RPCSEC_GSS to know how to do channel binding and leave on-the-wire data
protection to the underlying channel, OR to have a GSS-API pseudo-
mechanism to do the same without having to change RPCSEC_GSS.

I used to advocate the latter, but I'd like to explore the former.

I think a change to RPCSEC_GSS would be more straightforward for most
NFS implementors than CCM.

Basically, I have in mind this:

      enum rpc_gss_proc_t {
              RPCSEC_GSS_DATA = 0,
              RPCSEC_GSS_INIT = 1,
              RPCSEC_GSS_CONTINUE_INIT = 2,
              RPCSEC_GSS_DESTROY = 3,
   new -----> RPCSEC_GSS_BIND_CHANNEL = 4
      };

      enum rpc_gss_service_t {
          /* Note: the enumerated value for 0 is reserved. */
          rpc_gss_svc_none = 1,
          rpc_gss_svc_integrity = 2,
          rpc_gss_svc_privacy = 3,
   new -> rpc_gss_svc_channel_prot = 4
      };

The RPCSEC_GSS_BIND_CHANNEL rpc_gss_proc_t would be used when you have
an established security context to try to do channel binding.

RPCSEC_GSS_BIND_CHANNEL requests and replies would be very similar to
RPCSEC_GSS_CONTINUE_INIT ones, but instead of context tokens what's
exchanged is a MIC of the channel binding data.  If the channel binding
does not match on the server side then the server should respond with an
AUTH_BADCRED reply, otherwise it should respond with an MSG_ACCEPTED
reply with RPCSEC_GSS_BIND_CHANNEL and the MIC of its view of the
channel bindings (so the client can confirm).

Servers that don't support RPCSEC_GSS_BIND_CHANNEL should respond with
an error.  I've confirmed (by code inspection) that Solaris' RPCSEC_GSS
library and kernel module do just that (AUTH_FAILED).  I suspect other
implementations do the same.  I doubt there are implementations that
would silently drop the request, but this would be something to check.

Once a context handle has been bound to an underlying channel then the
client may send RPCs with rpc_gss_svc_channel_prot as the RPCSEC_GSS
service, in which case no MIC token and no wrap token are used -- the
data is sent unprotected with the expectation that the underlying
channel will.  Replies to such RPCs would use the same RPCSEC_GSS
service and, again, no MIC nor wrap tokens.

Nico
--

---

From: Mike Eisler <[email-masked]>
Date: Wed, 5 Dec 2007 15:46:43 -0800 (PST)

> would silently drop the request, but this would be something to

If we decide we want to change RPCSEC_GSS, then bump the version
number inside the RPCSEC_GSS protocol, and change it.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 5 Dec 2007 17:55:46 -0600

> number inside the RPCSEC_GSS protocol, and change it.

I don't think we need to.  That is, I think what I proposed works with
fewer round-trips than bumping the RPCSEC_GSS version.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 5 Dec 2007 16:25:44 -0800 (PST)

> fewer round-trips than bumping the RPCSEC_GSS version.

Cool. I'll change draft-18 of the NFSv4.1 spec, to leave the
minor version at zero.  The presence of new ops should
be detectable by the server, without a new version. :-)

Apparently I'm going to regret not specifying 
versioning rules in RFC2203. :-)

Anyway, regarding the number of round trips, if using RDMA and
RPCSEC_GSS with integrity or privacy is desired, then either
an RPCSEC_GSS_INIT with version 2 of RPCSEC_GSS protocol is accepted
or it isn't. If it is, then RPCSEC_GSS_BIND_CHANNEL can proceed.
Indeed, version 2 of RPCSEC_GSS could attempt to do the channel
binding in with the context creation if the initiator is not
anonymous.

If it target is not prepared to support RPCSEC_GSS version 2, then
then the context creation fails, which is what you want to have happen
if the desire is to use RDMA and be secure. Automatically backing off
to RPCSEC_GSS version 1 (using the _none service presumably)
does not make sense given Sam's objections.

Not I've decided whether doing this through RPCSEC_GSS is the
right thing or not. 

Why can't this all be done at the GSS level? Just request channel
bindings when initiator creates a context, and once the
initiator has a key, it can pass and sign the channel
material in the context token. The GSS-API context creation handshake
might take more round trips if the initiator is anonymous.

Yes, it might require changes to GSS, but we are considering
infrastructure changes in lots of places anyway. Changing GSS at least
allows other apps to leverage it beyond ONC RPC.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 5 Dec 2007 18:33:46 -0600

> versioning rules in RFC2203. :-)

:)

> does not make sense given Sam's objections.

I can live with bumping the RPCSEC_GSS version.

> might take more round trips if the initiator is anonymous.

I'll explain tomorrow -- basically, getting the number of copies down
isn't as easy with CCM as I'd thought (wrap tokens can't be zero
length).

---

From: Sam Hartman <[email-masked]>
Date: Wed, 05 Dec 2007 20:17:37 -0500

Mike> --- Nicolas Williams <[email-masked]> wrote:

    >> On Wed, Dec 05, 2007 at 03:46:43PM -0800, Mike Eisler wrote: >
    >> If we decide we want to change RPCSEC_GSS, then bump the
    >> version > number inside the RPCSEC_GSS protocol, and change it.
    >> 
    >> I don't think we need to.  That is, I think what I proposed
    >> works with fewer round-trips than bumping the RPCSEC_GSS
    >> version.
    >> 

    Mike> Cool. I'll change draft-18 of the NFSv4.1 spec, to leave the
    Mike> minor version at zero.  The presence of new ops should be
    Mike> detectable by the server, without a new version. :-)

Versioning rules are good guidelines but should not be thought of as
hard and fast rules.

I think what Nico is proposing is reasonable, as would violating the
NFS versioning rules if it produced the results you needed.  However I
don't see a strong argument for violating versioning rules in the NFS
case.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 6 Dec 2007 02:44:09 -0600

> Versioning rules are good guidelines but should not be thought of as

Yup.  Basically, we need interoperability, and safety.

I believe my proposal gets us that.

The only things that the server can do, in response to new extensions to
RPCSEC_GSS, that hurt the client are: not respond at all, or close the
connection.  The only other option is to respond with an error (or to
crash, but that'd be an unacceptable bug.  There is no way that a server
that doesn't understand this extension could unintentionally respond to
it with the right message that makes the client think that channel
binding succeeded.

> don't see a strong argument for violating versioning rules in the NFS

Right -- there are big differences between RPCSEC_GSS and NFSv4 when it
comes to versioning: the former is a very small spec while the latter is
a huge spec, and the envisioned changes to the former are incremental
while the changes in the works for the latter are not.

Nico
--

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 6 Dec 2007 08:03:17 -0500

> versioning rules in RFC2203. :-)

We did specify them in RFC3530 and then decided we had been a tad too
strict about some things and regretted that.

I don't know how this applies to the RPCSEC_GSS issue but the lesson I
draw is that versioning rules should focus on a structure that allows
people to always be clear about what version they are using, and about
what is interoperable with what, and to simply support multiple
versions.  In RFC3530, we had a number of things that went beyond this
and imposed a vision of what sort of things we might want to do with
versioning (e.g. no infrastructural changes) and those turned out to be
shown pretty quickly to be bad ideas. 

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 7:26 PM
To: Sam Hartman; [email-masked]
Subject: Re: RPCSEC_GSS channel binding ext. vs. CCM (Re: [nfsv4] RDDP
andmandatory security)