Subject: [TLS] Comments on draft-linn-otp-tls-00

From: Eric Rescorla <[email-masked]>
Date: Sun, 02 Jul 2006 09:39:17 -0700

I've given this document a quick read. Comments follow.

1. Calling this an OTP mechanism is kind of confusing because
   the IETF already has a standard for OTP (RFC 2289) based
   on S/Key. Because the RFC 2289 scheme relies on the server
   storing the output of a digest and the client providing
   the preimage, it cannot be used with the mechanism in
   this draft. At minimum, you need to have a section 
   explaining that only systems in which both client and
   server can generate the same password sequence can be
   used here and preferably a name change would be appropriate.

2. I'm very uncomfortable with retroactively changing the 
   meaning of psk_identity--without any external signalling
   as far as I can tell. That doesn't seem like a good plan
   at all.

3. The new PSK identity encoding should be expressed using
   standard TLS structures, not an ASCII encoding. This 
   comment applies both to how to pack the structures and how
   to represent the time, which should be a 32-bit integer
   in accordance with TLS standard practice.

4. In S 3.3.2, what happens if I want to offer multiple 
   otp_algorithms? Impossible.

5. In S 3.3.3, making iteration_count a uint16 seems unwise.
   Better to future proof and make it a uint32.

6. I'm very uncomfortable with creating all these alerts. Note
   that the TLS alert space is only 8 bits wide. Note also
   that per RFC 4346 Alerts can only be created by Standards
   action.

-Ekr

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

---

From: "Linn, John" <[email-masked]>
Date: Wed, 5 Jul 2006 09:51:34 -0400

Thanks, Eric, for the review and comments.  Our thoughts embedded, with [JL] prefixes. 

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Sunday, July 02, 2006 12:39 PM
To: [email-masked]
Subject: [TLS] Comments on draft-linn-otp-tls-00

   on S/Key. 

[JL] Any confusion here was unintended.  A number of methods are commonly known and described as one-time passwords; the draft is intended to be able to support a range of choices.  RFC-2289's title, e.g., is "A One-Time Password System"; it's a particular method, rather than defining the entire class. To resolve the name conflict against RFC-2289, we could coin a new phrase for this draft, perhaps Single-Use Passwords (SUPs), but this would lack familiarity for readers.

   Because the RFC 2289 scheme relies on the server

[JL] Good observation.  The approach as described in the draft indeed requires that both client and server be capable of generating a common OTP/SUP value independently.  We'll make this explicit in a subsequent revision.

[JL] As RFC-4279 states, "This document does not mandate the use of any particular type of identity...".  We've tried to remain consistent with the encoding conventions that RFC-4279 prescribes, but it appeared that the content of psk_identity was not fully constrained.  Potentially, it could be possible to maintain the existing interpretation of psk_identity (basically, what the current draft prefixes with "UI="), and to accompany it with OTP-specific qualifiers only if signaled through use of an extension.  Would additional qualifiers within psk_identity seem acceptable in such a context?

[JL] This would be appropriate within the context of a new TLS key exchange method definition.  The current draft sought to represent this data within RFC-4279's overall character string encoding conventions for psk_identity.

[JL] Good point.  We'll investigate this in the context of a new extension, as suggested above. 

[JL] Agreed. 

[JL] Is there existing guidance and precedent to qualify definition of alerts that are specific to particular methods or ciphersuites?  I respect the need to conserve the alert space, and compression relative to the current proposal would be possible, but would like to identify a means to provide sufficiently descriptive indicators as to disambiguate failure cases. 

-Ekr

[JL] --jl

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 11 Jul 2006 18:14:13 +0200

> [JL] Is there existing guidance and precedent to qualify definition
> of alerts that are specific to particular methods or ciphersuites?
> I respect the need to conserve the alert space, and compression
> relative to the current proposal would be possible, but would like
> to identify a means to provide sufficiently descriptive indicators
> as to disambiguate failure cases. 

Consider client authentication using just plain old X.509
certificates.  When the server does not accept the client's
certificate chain, there generally are two possible ways to handle
this:

1. Send a fatal alert.

2. Continue with the TLS connection, but don't consider the client
   authenticated.  Depending on the application that is running over
   TLS, the error can be described on a higher level (i.e., as part of
   a higher-level protocol error message, or simply as text in a way
   that suits the application).

Shouldn't this work for one-time passwords as well to convey detailed
error information?

For the case that an alert is sent, you might consider overloading
some existing alerts.  Some new alerts may be warranted, such as
"unsupported_otp_algorithm"; but how about, for example, using
"certificate_expired" where your draft has "otp_key_expired"?
(Then in the case that a client uses *both* a certificate and a
one-time password, the alert loses some information since the client
may not be able to tell if it refers to the certificate or the
password.  But then, "certificate_expired" doesn't give all the
details anyway -- it could refer to any certificate in the client's
certification chain.  For a more complete error report with details
and explanations, you often can use option #2 with application-level
error reporting.)