Subject: [nfsv4] [new] New I-D: draft-adamson-nfsv4-spkm3-00

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Tue, 18 Oct 2005 15:11:13 -0400

A new internet draft for SPKM-3 is now available. It describes SPKM-3 mutual 
authentication using version 3 X.509 credentials, and provides some
clarifications regarding the SPKM-3 semantics. 

We intend to issue a revised SPKM-3/LIPKEY RFC with Mike Eisler that provides 
one-stop shopping for all the information necessary to implement SPKM-3.

We would appreciate any feedback, comments, etc.

-->Andy

A New Internet-Draft is available from the on-line Internet-Drafts  
directories.

     Title        : Low Infrastructure Mutual Authentication Using SPKM-3
     Author(s)    : W.Adamson, O.Kornievskaia
     Filename    : draft-adamson-nfsv4-spkm3-00.txt
     Pages        : 12
     Date        : 2005-10-14
 
	This memorandum describes a method whereby one can use GSS-API 
        [RFC2078] to supply a secure channel between a user on a client 
        and a server, authenticating both the user and server with public 
        key certificates [RFC3280], without the need for an external Public 
        Key Infrastructure for certificate verification. The method 
        leverages the existing Simple Public Key Mechanism Version 3 
        (SPKM-3) [RFC2847]. In addition to describing the use of SPKM-3 
        for mutual authentication, this memorandum updates RFC2847, reflecting
        implementation experience.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-adamson-nfsv4-spkm3-00.txt

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Oct 2005 15:43:05 -0500

> We would appreciate any feedback, comments, etc.

I thought there was to be an I-D clarifying SPKM generally.  As I recall
from every discussion we've ever had on this SPKM is rife with
underspecification problems, or worse.

General comment:  I thought SPKM-1/2 were about mutual authentication,
and SPKM-3 was about anonymous initiators, so why revise SPKM-3 to add
mutual authentication when SPKM-1/2 already provide this?

Comment on section 1: you don't have to have an introduction; if its
body is the same as the abstract then get rid of the intro.

Comments on section 3.1:

SPKM got naming all wrong -- it just gave new names to the generic name
type OIDs.  From your I-D:

   In this section, we clarify the construction and verification of
   names in SPKM-3.

But you don't :), er, :(

You refer to GSS_SPKM_NT_*, but these are aliases of the generic
GSS_C_NT_* so they refer to generic name syntax, so then the obvious
question that is not answered in this section is: how do you map generic
GSS name syntax to certificate DNs and SANs (subjectAlternativeName)?
Your text seems to address only hostbased service names, which is the
crucial one, but see below.

You might be able to specify new name-type OIDs for application use of
raw DNs and clarify that RFC2025 got them wrong.

More:

     ...  The initiator retrieves its source name information (ie., the
   Distinguished Name) from its own certificate which the initiator
   acquired by calling GSS_acquire_cred().  The initiator should encode
   the source name in a single RDN sequence and use a
   GSS_SPKM_NT_USER_NAME name type.  The target, like the initiator,
   constructs the target name using its certificate, but uses a
   GSS_SPKM_NT_MACHINE_UID_NAME name type.

Again with the incorrect name types (see above).  To use RDNs at the
application you'd need:

a) A more exact description, possibly by reference, of the query/display
   syntaxes for 'RDN' -- presumably the application wouldn't have to
   construct BER-encoded RDNs for use with GSS_Import_name() or know how
   to parse that when output by GSS_Display_name().

b) An OID for this name type (or GSS_C_NULL_OID).

And what about the exported name token contents for SPKM names?  Another
thing that's missing in RFC2025...

More:

   During the validation of a name (either when the target validates the
   name of the initiator or vice versa), a match occurs:

   o  if the target name is the same as the subject name or a DN entry
      for the subject alternate name in the target certificate.

Are there any deployed implementations of SPKM to be interoperable with?
Is it possible to be interoperable with them?  Because it's mighty
tempting to revise SPKM to use GeneralName in its tokens instead of
Name, then assign GSS name type OIDs to all choices of GeneralName and
use OtherName OIDs as name types...  If revised so that it uses a CHOICE
of a Name or a GeneralName (without additional tagging) this might even
work backwards compatibly.  (Actually, it's mighty tempting to me to
throw SPKM out and start over but you knew that.)

Comment on section 3.2:  I'm not sure how certificate chains are sent in
SPKM-1/2, and this section depends on that be clear (rfc2025 speaks of
CertificatePair for CA certs...).

Nico
--

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Thu, 20 Oct 2005 14:03:28 -0400

> underspecification problems, or worse.

we plan to address the underspecification problems via SPKM-3's use of rfc2025.

> mutual authentication when SPKM-1/2 already provide this?

as stated in the tile, abstract (and intro!): "Low Infrastructre" is the 
reason we revise SPKM-3 to include mutual authentication. SPKM-1/2 require the 
ability for both the initator and target to obtain the others certificate 
externally to SPKM - e.g. "High Infrastructure". SPKM-3 using the 
dhKeyAgreement will be able to service low infrastructure PKI users such as 
the University of Michigan, and the Globus Grid community.

>    In this section, we clarify the construction and verification of

this is a beginning.

> crucial one, but see below.
^^^^^^^^^^^^^
and an ok beginning. you bring up a good point. we will certainly investigate 
how to map generic GSS name syntax to RDN's.

> Is it possible to be interoperable with them?  

there might be some overlap, but in general, SPKM-1 interoperates only with 
SPKM-1, SPKM-2 interoperates only with SPKM-2, and SPKM-3 will interoperate 
only with SPKM-3.

> Because it's mighty

thanks for your comments nico, we'll be sure to address these issues.

-->Andy

---

From: Mike Eisler <[email-masked]>
Date: Thu, 20 Oct 2005 11:18:40 -0700 (PDT)

> we plan to address the underspecification problems via SPKM-3's use of rfc2025.

I think SPKM-1 and -2 should be deprecated and -3 replace it.
I think a future new SPKM-3 I-D ought to be a complete specification that
doesn't need RFC2025.

> > mutual authentication when SPKM-1/2 already provide this?

I don't believe there is anything in SPKM-3 that prevents mutual
authentication. Even if I'm wrong, mutual authentication certainly my intent. From
RFC 3530:

3.4.  Callback RPC Authentication

   Except as noted elsewhere in this section, the callback RPC
   (described later) MUST mutually authenticate the NFS server to the
   principal that acquired the clientid (also described later), using
   the security flavor the original SETCLIENTID operation used.
   
   [...]

   Because LIPKEY is layered over SPKM-3, it is permissible for the
   server to use SPKM-3 and not LIPKEY for the callback even if the
   client used LIPKEY for SETCLIENTID.

> externally to SPKM - e.g. "High Infrastructure". SPKM-3 using the 

Right. The ability to exchange certificates without an external directory
service is what distinguishes SPKM-3 from -1 and -2. Not mutual authentication.

Remember, SPKM-3 is about an SSL experience via GSS-API.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Oct 2005 13:41:49 -0500

> the University of Michigan, and the Globus Grid community.

Er, well, I'm confused.  SPKM-3 was supposed to have anonymous
initiators (i.e., they have no certificate) and authenticated servers so
that a separate mechanism, LIPKEY, could then do basic username/password
authentication protected by SPKM-3.

I.e., LIPKEY is the GSS equivalent of Basic-over-SSL.

LIPKEY is the Low Infrastructure Public Key Mechanism.

SPKM-3 is merely the enabler for LIPKEY.

I don't understand your notion of "Low Infrastructure."

Speculation: you want a single mechanism OID that represents the two
choices -- Basic-over-SPKM w/o user certs and SPKM with user certs -- to
avoid having to negotiate mechanisms.

But if that's what you want then what you propose does not achieve that
-- LIPKEY still has it's own OID separate from SPKM-3's.

> >    In this section, we clarify the construction and verification of

Understood :)

> > crucial one, but see below.

Note that the modern way to map GSS hostbased service names to PKIX is
to map the service name to an EKU OID and the hostname to an rfc822Name
subjectAltName.

I'm afraid that SPKM may just be too old and out of whack w.r.t. PKIX.

And from a developer's p.o.v., it seems a lot simpler to build a
replacement for SPKM using specs for which there are off-the-shelf
tools, like DTLS and CMS.

> SPKM-1, SPKM-2 interoperates only with SPKM-2, and SPKM-3 will interoperate 

For each of those, is interop really possible?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Oct 2005 14:06:18 -0500

> I think SPKM-1 and -2 should be deprecated and -3 replace it.

Ok.

> I think a future new SPKM-3 I-D ought to be a complete specification that

How similar to the original messages in RFC2025 should SPKM-3's be?

> authentication. Even if I'm wrong, mutual authentication certainly my intent. From

Ok, but it's not RFC3530 that matters in that respect, but RFC2847.
You're its author, so I'll assume you're right.

> Remember, SPKM-3 is about an SSL experience via GSS-API.

Right.  In the past building a GSS mechanism out of TLS was out of the
question (though Globus did it!) because TLS is stream oriented while
the GSS-API is message oriented -- a huge impedance mismatch.

Now that we have DTLS (Datagram TLS) this impedance mismatch is gone.

Development of a GSS mechanism out of DTLS should now be orders of
magnitude simpler than SPKM.  Open source projects can easily use
off-the-shelf open source implementations of DTLS (e.g., OpenSSL).

Nico
--

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Thu, 20 Oct 2005 16:05:39 -0400

[email-masked] said:
> question (though Globus did it!) because TLS is stream oriented while the
> GSS-API is message oriented -- a huge impedance mismatch.

> Development of a GSS mechanism out of DTLS should now be orders of magnitude
> simpler than SPKM.  Open source projects can easily use off-the-shelf open
> source implementations of DTLS (e.g., OpenSSL).

i'm quite familar with GIS, the Globus GSS SSL mechanism, having spent a good 
deal of time debugging and adding kx509 usage. they called into OpenSSL in a 
mode where SSL packets were placed into a buffer, but not sent over the wire. 
instead, Globus used the packets as the InternalContextToken for their 
GSSAPI_SSL. not having to ASN.1 the InternalContextToken is certainly an 
easier way to go. is this what you are refering to?

-->Andy

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Oct 2005 16:16:23 -0500

> easier way to go. is this what you are refering to?

Yes, it just isn't what I propose.

The GSI thing did this:

 - Take SSL/TLS messages and call them GSS tokens; as long as GSS apps
   just write the tokens w/o any additional framing then their traffic
   looks just like SSL/TLS on the wire and so a GSS/GSI app can talk to
   an SSL/TLS app!

Not adding any framing means that the initial context token lacks the
little header with the mechanism OID, so it can't be a standard GSS
mechanism.

And since SSL/TLS are stream oriented there's no way to do out-of-order
token processing.

With DTLS this problem goes away and we can build a true GSS mechanism
out it.

Nico
--

---

From: Mike Eisler <[email-masked]>
Date: Thu, 20 Oct 2005 15:38:35 -0700 (PDT)

> With DTLS this problem goes away and we can build a true GSS mechanism

Leveraging TLS is goodness. But I checked the TLS WG page,
and didn't see it.

Before I conceived of SPKM-3/LIPKEY, one of my earlier ideas
was to hack openssl into producing GSS tokens. That is
until a colleague convinced me that SPKM-3 would be lower
impedance. :-) It actually would have been if the prototype
SPKM-[12] I had to work with 10 years ago hadn't been bit rotted.

Andy and Olga have got some running code, and that
needs to be a prime consideration.

In any case GSS, RPC, and NFS are open to all comers.