Subject: [TLS] Comments on draft-nir-tee-pm-00

From: EKR <[email-masked]>
Date: Sat, 10 Mar 2007 12:32:31 -0800

$Id: draft-nir-tee-pm-00-rev.txt,v 1.2 2007/03/10 20:44:21 ekr Exp $

This document describes a proposed mechanism for using EAP
authentication with TLS. The general strategy is to do an initial TLS
handshake and then once a TLS session is established send EAP payloads
in the TLS handshake channel. If the EAP authentication method outputs
a key that gets fed into the TLS channel keying material. Here's
the picture from the draft:

         Client                                               Server
         ------                                               ------

         ClientHello(*)             -------->
                                                      ServerHello(*)
                                                       (Certificate)
                                                   ServerKeyExchange
                                            EapMsg(Identity-Request)
                                     <--------       ServerHelloDone
         ClientKeyExchange
         (CertificateVerify)
         ChangeCipherSpec
         InterimAuth
         EapMsg(Identity-Reply)     -------->
                                                    ChangeCipherSpec
                                                         InterimAuth
                                          EapMsg(MS-CHAP-v2-Request)
                                    <--------
         EapMsg(MS-CHAP-v2-Reply)   -------->
                                                     EapMsg(Success)
                                    <--------               Finished
         Finished                   -------->

This draft seems to me to be more on the right track than the 
recent GSS-API draft (draft-santesson-tls-gssapi), but there are
still two things that make me uncomfortable:

1. There's still a significant amount of interlocking of the
   EAP state machine and the TLS state machine because the
   Finished is delayed until EAP is Finished (though arguably
   the InterimAuth serves the role of the Finished).
2. The EAP key gets fed back into the TLS key. It's not clear
   to me why this is necessary. We need some form of channel
   binding but TLS is quite capable of establishing a secure
   session key. There's no need to mix the key back into
   TLS.

The second is obviously easily fixed, but I think the first could
be fixed as well. For instance, see Pasi Eronen't proposal for
GSS of March 9.

At a higher level, this is the second proposal we have before us to
graft a generic authentication layer onto TLS. It seems to me that
what's appropriate here is for the TLS WG to decide whether this kind
of combination is appropriate and if it is to provide a single
abstract mechanism which works for GSS, EAP, and whatever else people
come up with. 

Without prejudging the conclusion that this is worth doing,
as I understand it, the requirements here are threefold:

1. There needs to be a way inside of TLS to signal that you want
   to authenticate via EAP, GSS, etc.
2. The external authentication exchanges have to occur out-of-band
   from the application traffic carried over the TLS channel.
3. The external authentication needs to be cryptographically bound
   to the underlying TLS channel.

Putting these together we get that TLS needs to provide two things:

1. An extension or cipher suite to signal you want external auth.
2. A way to carry the external auth inside TLS (e.g., a new handshake
   message.)

In terms of the state machine, I suspect Pasi is mostly correct: do
the TLS and then let the external auth protocol run.

Thoughts?

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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 12 Mar 2007 08:15:09 +0200

Thanks for the review, Eric.

>    the InterimAuth serves the role of the Finished).

The InterimAuth does serve the role of Finished. I agree that there  
is no technical reason not to use a Finished message there, except to  
illustrate that the handshake phase is not done, and that data can  
not yet be sent.
If it makes people more comfortable, we could call it Finished, and  
either use another Finished message at the end of EAP or call it  
ExtAuthFinished or some such.  We thought that it would be cleaner to  
keep the current TLS behavior that application data follows the  
Finished message.

>    session key. There's no need to mix the key back into

This is a feature of the GSS-API draft. In our draft the EAP MSK is  
used only for signing the Finished message. The master secret is not  
changed.

Hope this helps

Yoav

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 12 Mar 2007 10:40:25 +0100

> abstract mechanism which works for GSS, EAP, and whatever else people

I believe it would be useful to work on this.  There has been several
authentication protocols that use TLS internally; incidentally I've
authored both EAP and SASL mechanisms that do this.  I believe there
would be better interop and better security if those authentication
mechanisms could start TLS and then negotiate the authentication
mechanism inside TLS.

>    to the underlying TLS channel.

That seems to be a good summary.  Here is a "nice property":

4. The mechanism should permit the double-handshake capability of TLS,
to further protect the authentication step.

There are several weak authentication mechanisms (including CRAM-MD5
and MS-CHAP) that could be enhanced by being done under TLS.  I
believe that there is considerable deployment of CRAM-MD5 and MSCHAP
that it is easier to protect those installations instead of replacing
them, at least in the short run.  Negotiation them inside TLS is one
way to protect them.  If a solution to that problem coincide with a
solution that is good in the long run too, all the better.

> the TLS and then let the external auth protocol run.

We already have one TLS extension defined and deployed that seem to
fit these requirements: the TLS Inner Application extension:

http://tools.ietf.org/wg/tls/draft-funk-tls-inner-application-extension-03.txt

I believe it could support GSS-API too.  After implementing it, I
don't think it fits well with the TLS model -- IIRC it violates the
TLS extension mechanism for resume operations -- and some careful
review is necessary to make sure it fits within the GSS-API model too.
The chose to re-use RADIUS/Diameter AVP's may also be sub-optimal for
non-EAP uses.

I wouldn't argue that we should use TLS/IA, but we can surely learn
from the design and improve it.

/Simon