RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt]

"Linn, John" <jlinn@rsasecurity.com> Tue, 27 June 2006 13:14 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDOE-0006eF-Ey; Tue, 27 Jun 2006 09:14:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDOD-0006e9-1c for tls@ietf.org; Tue, 27 Jun 2006 09:14:01 -0400
Received: from tholian.rsasecurity.com ([216.162.240.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvDOB-0006XQ-PI for tls@ietf.org; Tue, 27 Jun 2006 09:14:01 -0400
Received: from hyperion.rsasecurity.com by tholian.rsasecurity.com via smtpd (for ietf-mx.ietf.org [156.154.16.150]) with ESMTP; Tue, 27 Jun 2006 09:12:59 -0400
Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by hyperion.na.rsa.net (MOS 3.7.4b-GA) with ESMTP id CPT17085; Tue, 27 Jun 2006 09:16:38 +0500 (GMT-5)
Received: from rsana-ex-hq2.NA.RSA.NET (rsana-ex-hq2.na.rsa.net [10.100.8.51]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id k5RDDvDU007536; Tue, 27 Jun 2006 09:13:57 -0400 (EDT)
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt]
Date: Tue, 27 Jun 2006 09:13:57 -0400
Message-ID: <CBF06F06E674C948AD89E671645B785F0103E7E1@rsana-ex-hq2.NA.RSA.NET>
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F2402D6371D@esebe105.NOE.Nokia.com>
Thread-Topic: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt]
Thread-Index: AcaKbfivbRGYQd5jT9u31k4wgZdHeQEoADYAAolPiLAAKn0foA==
From: "Linn, John" <jlinn@rsasecurity.com>
To: <Pasi.Eronen@nokia.com>, <tls@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: =?iso-8859-1?Q?Nystr=F6m=2C_Magnus?= <mnystrom@rsasecurity.com>
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

Pasi,

Thanks for the review and comments, which we'll consider as input to a subsequent draft revision; in particular, we can include more quantitative discussion on OTP hardening. 

Rather than defining new ciphersuites that would parallel those defined in RFC-4279, we'd thought that it was feasible and appropriate to define how inputs to RFC-4279 could be constructed to support OTP scenarios, thereby achieving a modular approach that could layer on TLS-PSK rather than duplicating it. As RFC-4279, Sec. 5, begins, "It is expected that different types of identities are useful for different applications running over TLS.  This document does not therefore mandate the use of any particular type of identity...".  Against this backdrop, and noting that RFC-4279 (e.g., Secs. 5.2 and 5.4) explicitly contemplates use in conjunction with application profiles, we set out to profile the use of the identity field so as to represent OTP-related attributes along with the identity itself.  As noted, the draft also proposes error alerts (to be used only when use of OTP-TLS is indicated) and (optional) use of TLS extensions, so extends more than just TLS-PSK; this can be clarified.  With regard to the proposed structure for OTP-TLS PSK_Identity, however, we'd considered this as an example of a TLS-PSK application profile which RFC-4279 did not appear to preclude.  

--jl

-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] 
Sent: Monday, June 26, 2006 11:23 AM
To: Linn, John; tls@ietf.org
Cc: Nyström, Magnus
Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt]

Since the document quite significantly changes how the PSK
ciphersuites work (identity field is re-used to carry a number of
other attributes; new alert messages are added; key-exchange related
information is carried in new TLS extensions; etc.), I think it would
be better to treat OTP as a new TLS key exchange algorithm (and define
new ciphersuites like TLS_OTP_WITH_AES_128_CBC_SA). As it's currently
written, this document certainly is not a "profile" of RFC 4279
in any usual sense of the word...

Couple of additional comments:

- See RFC 3979 section 11: "No IPR Disclosures in IETF Documents"

- Text about "hardening" should give concrete advice on how secure
OTP-TLS actuallly is, given some realistic parameter values (just
talking about "economically unattractive" is very vague).

Best regards,
Pasi 

> -----Original Message-----
> From: ext Linn, John [mailto:jlinn@rsasecurity.com] 
> Sent: 14 June, 2006 14:17
> To: tls@ietf.org
> Cc: Nyström, Magnus
> Subject: [TLS] OTP-TLS I-D [Was: FW: I-D 
> ACTION:draft-linn-otp-tls-00.txt]
> 
> This recent I-D constitutes a profile layered on TLS-PSK, 
> intended to authenticate TLS connections with the general 
> class of One-Time Password (OTP) methods.  We'd like to 
> invite review and comment in the TLS WG.   
> 
> --jl

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