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

On Wed, Jul 05, 2006 at 09:51:34AM -0400, Linn, John wrote:

> 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.

> [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.)

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