Subject: [SPKM] DTLS and GSS-API

From: Sam Hartman <[email-masked]>
Date: Tue, 31 Oct 2006 12:08:25 -0500

Monday morning at IETF 67 there is a really important BOF: SPKM.

The purpose of this BOF is to decide how we will get a standards track
solution for NFSV4 to use PKI credentials.  Two modes are important: a
mode where both parties have credentials and a mode where the server
has a certificate and the client has a password.

The current proposal is based off draft-adamson-rfc2847-01.txt.
Several reviewers including Eric Rescorla and myself have expressed
concerns about this draft.

An alternate proposal for solving this problem was discussed in the
past: construct a GSS-API mechanism based on DTLS.  Advantages of this
solution include reuse of code and specification between GSS-API and
TLS implementations.  When new ciphers are specified for TLS they
would be available for NFS.  We would not need to keep updating a GSS
mechanism as public-key algorithms evolve and problems are found.

There are two main drawbacks I've heard to the DTLS proposal.  First,
we don't have a draft.  Second, it would not be interoperable with
SPKM-3 deployments.

I hope the BOF will answer the question of how much we care about
SPKM-3 deployments.

I only want to see one standards track solution in this space.
Currently, there does not seem to be enough interest in the DTLS
proposal for it to be a viable alternative.  I would like to encourage
the TLS community to take a look at draft-adamson-rfc2847-01 and to
consider how a DTLS approach would work and think about whether
advocating for such an approach would be a good idea.  If so, someone
at least needs to be prepared to give a brief presentation by next
Monday on such a proposal.

The BOF chair wanted to hear about anyone giving an alternative
presentation by Wednesday of this week.  I'm hoping he will be a bit
flexible as I was supposed to write this message last Friday.

Thanks for your consideration,

--Sam

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 31 Oct 2006 15:45:22 -0500

> flexible as I was supposed to write this message last Friday.

Sooner is better, but if I have a message in my inbox when I get off of the 
train on Sunday morning, I'll be happy.  Note that I will need slides by 
Monday evening, so I can put them up on the IETF web site before the BOF 
begins.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Oct 2006 15:15:00 -0600

> flexible as I was supposed to write this message last Friday.

I will have a presentation on a DTLS-based GSS mechanism in time for the
meeting.  However, I will only be able to participate via jabber.

Nico
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 31 Oct 2006 14:02:32 -0800

We have a different proposal for this problem space, it is PKU2U,

It is similar to PKTAPP, except it does NOT use port 88.

It is similar to DTLS, in that it can use certificates.

It is a GSS-API mechanism because it just uses RFC4121.

I will have a draft ready by this coming Monday, and we have a
proto-type of PKU2U.

We will have a short presentation for this proposal this coming Monday.

-- Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Tuesday, October 31, 2006 9:08 AM
To: [email-masked]; [email-masked]
Subject: [TLS] DTLS and GSS-API

The purpose of this BOF is to decide how we will get a standards track
solution for NFSV4 to use PKI credentials.  Two modes are important: a
mode where both parties have credentials and a mode where the server has
a certificate and the client has a password.

An alternate proposal for solving this problem was discussed in the
past: construct a GSS-API mechanism based on DTLS.  Advantages of this
solution include reuse of code and specification between GSS-API and TLS
implementations.  When new ciphers are specified for TLS they would be
available for NFS.  We would not need to keep updating a GSS mechanism
as public-key algorithms evolve and problems are found.

There are two main drawbacks I've heard to the DTLS proposal.  First, we
don't have a draft.  Second, it would not be interoperable with
SPKM-3 deployments.

I only want to see one standards track solution in this space.
Currently, there does not seem to be enough interest in the DTLS
proposal for it to be a viable alternative.  I would like to encourage
the TLS community to take a look at draft-adamson-rfc2847-01 and to
consider how a DTLS approach would work and think about whether
advocating for such an approach would be a good idea.  If so, someone at
least needs to be prepared to give a brief presentation by next Monday
on such a proposal.

--Sam

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Oct 2006 16:39:21 -0600

> It is a GSS-API mechanism because it just uses RFC4121.

Does it re-use the Kerberos V mechanism OID?

IMO this is a new mechanism and needs a new OID.  IMO you still have
naming issues to sort through, but that is true whether we go with the
SPKM, DTLS or PKU2u approaches, and they are definitely solveable.

> We will have a short presentation for this proposal this coming Monday.

Excellent, thanks.  I look forward to it,

Nico
--