Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-extensions-00.txt

From: [email-masked]
Date: Mon, 25 Jun 2001 07:10:40 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title		: TLS Extensions
	Author(s)	: S. Blake-Wilson et al.
	Filename	: draft-ietf-tls-extensions-00.txt
	Pages		: 21
	Date		: 22-Jun-01
	
This document describes extensions that may be used to add
functionality to TLS. It provides both generic extension mechanisms
for the TLS handshake client and server hellos, and specific
extensions using these generic mechanisms.

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

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-ietf-tls-extensions-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-ietf-tls-extensions-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.
---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 25 Jun 2001 15:37:55 +0200

>                              TLS Extensions
> 
>                    <draft-ietf-tls-extensions-00.txt>

> 4. Error Alerts

>    - "certificate_unobtainable" - this alert is sent by servers who are
>      unable to retrieve a certificate chain from the URL supplied by
>      the client (see Section 3.3). This message is always fatal.

Why is it always fatal?  In practice, client certificates are often
optional: If the client can identify itself, then it may be granted
additional rights, but if it can't, it may still make sense to
continue the connection (sometimes just for sending an HTTP error
message, sometimes for more).

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Mon, 25 Jun 2001 23:43:34 -0400

Can we adapt the language from the "client cert" section in TLS:

"If client authentication is required by the server for the handshake to
continue, it may respond with a fatal handshake failure alert."

Something like:

"If client authentication is required by the server for the handshake to
continue and the server is unable to retrieve the cert chain, it should send a
fatal "certificate unobtainable" alert."

?

Best regards. Simon

David Hopwood <[email-masked]> on 06/25/2001 10:32:39 AM

Please respond to "IETF Transport Layer Security WG"
      <[email-masked]>

To:   "IETF Transport Layer Security WG" <[email-masked]>
cc:    (bcc: Simon Blake-Wilson/Certicom)

Subject:  [ietf-tls] Re: I-D ACTION:draft-ietf-tls-extensions-00.txt

-----BEGIN PGP SIGNED MESSAGE-----

> message, sometimes for more).

That's a reasonable point. Any objection to deleting "This message is
always fatal." here?

- --
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

---

From: Eric Rescorla <[email-masked]>
Date: 25 Jun 2001 21:19:44 -0700

> fatal "certificate unobtainable" alert."
By analogy the RFC 2246, this should say "may" instead of "should".

-Ekr

---

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 26 Jun 2001 10:21:09 -0400

> By analogy the RFC 2246, this should say "may" instead of "should".

Is this a bug in 2246?  The premise is that client authentication is required
by the server, ergo if the client can not be authenticated the connection WILL
be aborted.   The question is then, given that the connection will be aborted
for lack of authentication, the server {may | should} be polite and send an
alert before tearing down the TCP connection.

"Should" seems appropriate here.  If the TCP connection is persistent, there
could be long hangs if the server aborts a handshake without sending some
(not necessarily informative) fatal alert.

---

---

From: Eric Rescorla <[email-masked]>
Date: 26 Jun 2001 07:50:09 -0700

> alert before tearing down the TCP connection.
I think this probably is a bug but I don't think just doing "may" -> "should"
is the right thing here.

There seem to me to be four things the server might do:
[BAD] Drop the connection
[GOOD] Throw a fatal handshake alert
[BAD] Throw some other alert.
[GOOD] Continue and have the application throw an error.

I agree that the "required for the handshake to continue" rules out
the last case but I think that if we're going to change 2246 we should
lay that case out as well.

> (not necessarily informative) fatal alert.
I don't see how this would be the case. The server would presumably send
a TCP FIN. This would cause an error on the client.

-Ekr

---

---

From: "Rene G. Eberhard" <[email-masked]>
Date: Wed, 27 Jun 2001 11:01:30 +0200

Hi 

The problem is that the application is also involved in
the correctness of the handshake. This might be a potential
security hole.

More comments below.

> I'd like to revisit the case
> 
>     Continue and have the application throw an error.
> 
> I have a server application layered over TLS. The server supports
> SASL/EXTERNAL but also simple password and anonymous 
> authentication methods.
> 
> The server cannot know which method is going to be used until the TLS
> handshaking is over. It has to request a client certificate in case
> SASL/EXTERNAL is proposed. In the case of the other two methods, 
> the client
> needn't send a certificate. I would argue that the server may continue the
> handshake if the client does not return a certificate in response to the
> certificate request. If SASL/EXTERNAL is proposed and the client 
> didn't send
> a certificate, the server may return an application error.

I don't agree. (See next chapter). If you have multiple
client authentication methods it's not enough to just throw an error
to the application. It's also necessary to tell the application what
kind of client authentication occurred. IMHO it's always up to
the server to "request for a specific client authentication" instead of
"request for any client authentication and act accordingly". 

In one of our our own product "TESS" (www.tess.ch) we moved the whole 
security decision stuff up to the application. We now are able to ask 
for a client certificate on application level (within an existing TLS 
session) and not just at the very beginning of the TLS session. Because
we are on application level we can also ask for any other authentication
schemes (e.g. password based authentication). These "other authentication
schemes" are not part of TLS (because they are application specific).

Regards Rene

---

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 27 Jun 2001 14:01:31 +1000

I have a server application layered over TLS. The server supports
SASL/EXTERNAL but also simple password and anonymous authentication methods.

The server cannot know which method is going to be used until the TLS
handshaking is over. It has to request a client certificate in case
SASL/EXTERNAL is proposed. In the case of the other two methods, the client
needn't send a certificate. I would argue that the server may continue the
handshake if the client does not return a certificate in response to the
certificate request. If SASL/EXTERNAL is proposed and the client didn't send
a certificate, the server may return an application error.

Ron.

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]]
Sent: Wednesday, 27 June 2001 0:50
To: IETF Transport Layer Security WG
Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-extensions-00.txt

> alert before tearing down the TCP connection.
I think this probably is a bug but I don't think just doing "may" ->
"should"
is the right thing here.

-Ekr

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 28 Jun 2001 11:27:57 +1000

Thanks, Rene.

I'd just like to make one point. Our application does not interfere with the
TLS handshake. In fact, we do not interact with the TLS layer at all.
However, we also do not accept any authentication.

We setup the server to request a client certificate but not to require it.
The client connects and handshaking completes. If the client requests
SASL/EXTERNAL, we ask the TLS layer whether a certificate was supplied (and
validated). (I said we don't interact with the TLS layer, so let's call this
monitoring!) If one was, that becomes the basis of the authentication. If
not, the connection is rejected. Conversely, if the client supplies a
certificate and the requested authentication is anonymous, there is no
interaction with the TLS layer and the connection is accepted

I can't see a security problem because we are not trying to adjust to the
information supplied by the client. We simply verify that the client has
supplied the information required by the authentication method they've
requested.

This is OK, yes?

Ron.

-----Original Message-----
From: Rene G. Eberhard [mailto:[email-masked]]
Sent: Wednesday, 27 June 2001 19:02
To: IETF Transport Layer Security WG
Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-extensions-00.txt

Hi 

More comments below.

Regards Rene

---

---