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

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Oct 2005 17:42:02 -0500

On Thu, Oct 20, 2005 at 03:32:37PM -0700, Eisler, Michael wrote:
>  
> > With DTLS this problem goes away and we can build a true GSS mechanism
> > out it.
> 
> Leveraging TLS is goodness. But I checked the TLS WG page,
> and didn't see it.

Look again: it's not a WG item, but it's in the RFC Editor's queue:

https://datatracker.ietf.org/public/idindex.cgi?command=do_search_id&filename=rescorla-dtls&id_tracker_state_id=-1&wg_id=0&other_group=&status_id=0&last_name=&first_name=

# I-D Title: Datagram Transport Layer Security
# I-D Status: Active
# I-D Intended Status at Publication: Proposed Standard
# RFC Number:
# I-D Tracker State: RFC Ed Queue

The I-D and URL are:

http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt

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

The situation appears to have flipped:

 - we now have a Proposed Standard version of TLS -- DTLS --  that does
   what we need
 - we now have open source implementations of this

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

Yes.  But so do lots of other things.  Alignment with PKIX, for example.
Can I use existing TLS server certs with SPKM?  Yes, no, why?  Can we
clarify SPKM?  Etc.

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

Indeed.

Nico
-- 

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

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Fri, 21 Oct 2005 11:01:54 -0400

[email-masked] said:
> Can I use existing TLS server certs with SPKM?  

existing TLS certs - e.g. version 3 X.509 certificates: absolutely!

> Yes, no, why?  Can we clarify
> SPKM?  Etc.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Oct 2005 10:44:13 -0500

> existing TLS certs - e.g. version 3 X.509 certificates: absolutely!

How do you express the service name of a hostbased service name?

---

From: Mike Eisler <[email-masked]>
Date: Fri, 21 Oct 2005 08:56:58 -0700 (PDT)

> http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt

Good. I didn't see (but didn't dig too hard) for whether this could
in fact be adapted to GSS-API. I.e. does DTLS insist on being the wrapper
(of datagrams) or can something else wrap it? GSS-API requires
the latter.

>  - we now have open source implementations of this

Again, I looked, not too hard, for the APIs in the dtls1 sources
of the latest openssl, and wasn't illuminated. The man 
pages don't say much about DTLS.

The barrier to DTLS's entry into my own mindshare is pretty
high. If it does what it needs, it has to prove it too me. 

> Yes.  But so do lots of other things.  Alignment with PKIX, for example.

For me, code trumps all. We know SPKM can be implemented because there
are at least 4 that have been done in history. We know NFS over SPKM
works, at least as a proof of concept. We also have two developers
willing to to work on an open source (of the non-viral form)
implementation. If Andy and Olga want to do mech-DTLS instead of
SPKM, great.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Oct 2005 11:02:11 -0500

> (of datagrams) or can something else wrap it? GSS-API requires

We can wrap it to our heart's content.

I've been thinking of a DTLS-based GSS mech for a while.

> high. If it does what it needs, it has to prove it too me. 

Ok.

> are at least 4 that have been done in history. We know NFS over SPKM

I'd only ever heard of one or two.  Did they interop?

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Oct 2005 12:08:59 -0500

> pages don't say much about DTLS.

Yeah, the man pages haven't been updated, but then, they still don't
document the TLS APIs, really, and the man page is listed as incomplete.

The code is there though, and the dtls1 API very similar to the tls1_ API.