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

From: "Linn, John" <[email-masked]>
Date: Wed, 14 Jun 2006 07:17:06 -0400

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 07, 2006 3:50 PM
To: [email-masked]
Subject: I-D ACTION:draft-linn-otp-tls-00.txt 

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

	Title		: OTP Methods for TLS
	Author(s)	: J. Linn, M. Nystroem
	Filename	: draft-linn-otp-tls-00.txt
	Pages		: 21
	Date		: 2006-6-7
	
This document describes means for applying One-Time Password (OTP)
methods to authenticate Transport Layer Security sessions, operating
in conjunction with Pre-Shared Key (PSK) ciphersuites defined for use
with TLS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-linn-otp-tls-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-linn-otp-tls-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-linn-otp-tls-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: <[email-masked]>
Date: Mon, 26 Jun 2006 18:22:38 +0300

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 

> From: ext Linn, John [mailto:[email-masked]] 
> Sent: 14 June, 2006 14:17
> To: [email-masked]
> 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

---

From: "Linn, John" <[email-masked]>
Date: Tue, 27 Jun 2006 09:13:57 -0400

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: [email-masked] [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 11:23 AM
To: Linn, John; [email-masked]
Cc: Nyström, Magnus
Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt]

Best regards,
Pasi

---

From: "Linn, John" <[email-masked]>
Date: Tue, 27 Jun 2006 10:39:02 -0400

Pasi,

Thanks for the background and discussion. Leaving error alerts and extension usage aside for the moment, there's an interesting distinction here.  Considering the phrase "key exchange" in a crypto-focused sense, the approach proposed in the draft wasn't intended to modify the underlying key establishment as defined in RFC-4279.  Rather, it describes a method that starts with OTP data and associated attributes, using these to construct the inputs to PSK, DHE_PSK, and/or RSA_PSK ciphersuites.  The same messages as in RFC-4279 are applied, with profiling (part of "key exchange" processing in a broader sense of the term) that is specific to the method rather than to the consuming layer.  Do you see an appropriate means to reuse an existing ciphersuite in this sort of layered fashion, rather than introducing a new and parallel definition that would be based on the same underlying crypto processing?  The basic primitives in RFC-4279 are general and flexible, and it seems attractive to take advantage of them as a basis for related work.  

--jl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, June 27, 2006 9:29 AM
To: Linn, John; [email-masked]
Cc: Nyström, Magnus
Subject: RE: [TLS] OTP-TLS I-D [Was: FW: I-D ACTION:draft-linn-otp-tls-00.txt]

Hi John,

The "application profile specifications" mentioned in Sections 5.2 
and 5.4 were intended to specify how to *use* the RFC4279 ciphersuites 
to secure some particular application/service/higher-layer-protocol,
without modifying anything in TLS. (In other words, something
like RFC 2818 or 4261, which are for certificate-based ciphersuites)

If you significantly modify how the TLS key exchange works (as
is done in this case), the architecturally right way to do so is to 
define a new "TLS key exchange algorithm". This was discussed way
back also during the PSK work (where another proposal was to tweak 
the session resumption mechanism instead of defining a key exchange
algorithm).

Best regards,
Pasi 

> Sent: 27 June, 2006 16:14
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Cc: Nyström, Magnus
> 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
>

---

From: <[email-masked]>
Date: Tue, 27 Jun 2006 16:28:46 +0300

Hi John,

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 28 Jun 2006 10:45:27 +0300

John,

I used "key exchange algorithm" in the TLS protocol sense: a key
exchange algorithm defines what information is sent in the handshake
messages, how they're processed, how the pre-master secret is
computed, and how exceptional situations are handled. In other words,
a TLS key exchange algorithm covers more than just the cryptographic
calculations.

Profiling RFC4279 (or building a layer on top of RFC4279) is an
appropriate thing to do if it's really _above_ the TLS layer, but if
there are changes to the handshake processing (e.g. in some situation
RFC4279 would send alert X, while OTP-TLS sends alert Y), then IMHO
defining a new key exchange algorithm would be a better idea.

Of course, the new key exchange algorithm could copy most of the
details from RFC4279, so it's not a question of whether RFC4279
should be re-used or not, but rather exactly how the re-use should
be done and the additional behavior negotiated in TLS...

Best regards,
Pasi

> Sent: 27 June, 2006 17:39
> Thanks for the background and discussion. Leaving error 
> alerts and extension usage aside for the moment, there's an 
> interesting distinction here.  Considering the phrase "key 
> exchange" in a crypto-focused sense, the approach proposed in 
> the draft wasn't intended to modify the underlying key 
> establishment as defined in RFC-4279.  Rather, it describes a 
> method that starts with OTP data and associated attributes, 
> using these to construct the inputs to PSK, DHE_PSK, and/or 
> RSA_PSK ciphersuites.  The same messages as in RFC-4279 are 
> applied, with profiling (part of "key exchange" processing in 
> a broader sense of the term) that is specific to the method 
> rather than to the consuming layer.  Do you see an 
> appropriate means to reuse an existing ciphersuite in this 
> sort of layered fashion, rather than introducing a new and 
> parallel definition that would be based on the same 
> underlying crypto processing?  The basic primitives in 
> RFC-4279 are general and flexible, and it seems attractive to 
> take advantage of them as a basis for related work.  
> 
> --jl
>