IETF Logo Mail Archive

[SPKM] RE: [TLS] DTLS and GSS-API

"Liqiang(Larry) Zhu" <lzhu@windows.microsoft.com> Tue, 31 October 2006 22:11 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1pI-0003wK-8a; Tue, 31 Oct 2006 17:11:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1hx-0005ZM-5U; Tue, 31 Oct 2006 17:03:45 -0500
Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf1hq-0006HB-Jd; Tue, 31 Oct 2006 17:03:45 -0500
Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.665.7; Tue, 31 Oct 2006 14:03:34 -0800
Received: from IGT-HUB-01.redmond.corp.microsoft.com ([157.54.69.154]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 31 Oct 2006 14:03:34 -0800
Received: from tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) by IGT-HUB-01.redmond.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2786); Tue, 31 Oct 2006 14:03:33 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.5; Tue, 31 Oct 2006 14:03:33 -0800
Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 31 Oct 2006 14:03:30 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 31 Oct 2006 14:02:32 -0800
Message-ID: <CAAAEFE273EAD341A4B02AAA9CA6F7330348EECB@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <tsliri0tnue.fsf@cz.mit.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] DTLS and GSS-API
Thread-Index: Acb9D/YDziFLQ/yXR1CKfbjIbuT32gAJ/1Gg
From: "Liqiang(Larry) Zhu" <lzhu@windows.microsoft.com>
To: Sam Hartman <hartmans-ietf@mit.edu>, tls@ietf.org, spkm@ietf.org
X-OriginalArrivalTime: 31 Oct 2006 22:03:30.0664 (UTC) FILETIME=[66853680:01C6FD38]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
X-Mailman-Approved-At: Tue, 31 Oct 2006 17:11:16 -0500
Cc:
Subject: [SPKM] RE: [TLS] DTLS and GSS-API
X-BeenThere: spkm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Low Infrastructure Public Key GSS mechanism <spkm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/spkm>, <mailto:spkm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/spkm>
List-Post: <mailto:spkm@ietf.org>
List-Help: <mailto:spkm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/spkm>, <mailto:spkm-request@ietf.org?subject=subscribe>
Errors-To: spkm-bounces@ietf.org

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:hartmans-ietf@mit.edu] 
Sent: Tuesday, October 31, 2006 9:08 AM
To: tls@ietf.org; spkm@ietf.org
Subject: [TLS] DTLS and GSS-API



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

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls

_______________________________________________
SPKM mailing list
SPKM@ietf.org
https://www1.ietf.org/mailman/listinfo/spkm

v2.23.0 | Report a Bug | By Email