Subject: Comments on draft-ietf-pppext-eap-ttls-00.txt

From: "Glen Zorn" <[email-masked]>
Date: Wed, 30 Jan 2002 02:07:00 -0800

This draft (and the protocol it describes) are so broken in so many ways
that I have despaired of including all mycomments in a single message.
Therefore, I have decided to comment on each section in a seperate message;
I apologize in advance for the mailbox clutter this may cause uninterested
parties...

~gwz

Glen Zorn
CTO Consulting Engineer
Security and Integrity Group
Consulting Engineering
Cisco Systems

PGP Key Fingerprint: 4F41 B93A 007D E2FC 9769  FB97 FBCF 7DA4 9A2D 1963

---

From: Paul Funk <[email-masked]>
Date: Wed, 30 Jan 2002 07:51:02 -0500

Glen,

There's nothing of substance in your several emails, and I'm surprised by 
your tone, which I did my best to reciprocate.

Nowhere do you even discuss the EAP-TTLS protocol. Your comments are 
limited to the draft's prefatory material, definitions, etc. Not that I'm 
encouraging you to plod on further.

My responses are inline.

Paul

>I apologize in advance for the mailbox clutter this may cause uninterested

Well, to help reduce the clutter, I've collected your separate messages in a 
single response. Only one of them was long, made up mostly of quotes from 
the TTLS draft; the three others were about the size of fortune cookies. For 
you to suggest that there are great number of flaws requiring a great
volume of 
response is disingenous, considering that your carping manages to avoid 
all discussion of the protocol itself.

At 02:07 AM 1/30/02 -0800, Glen Zorn wrote:
>Abstract
>--------
>The draft says: "The secure connection established by the handshake may then
>be used to allow the server to authenticate the client using existing,
>widely-deployed authentication infrastructures such as RADIUS.", implying to
>me that EAP is not supported by RADIUS, patently false.
>

Where in the above quote is EAP even mentioned? In what sense does 
the inference you take -- that the TTLS draft suggests that EAP is not 
supported by RADIUS -- even relevant to your assertion that the protocol is 
broken?

TTLS supports EAP, and it also supports PAP, CHAP, MS-CHAP, and 
MS-CHAP-V2. I think that makes it highly compatible with existing, 
widely-deployed authentication infrastructures such as RADIUS.

Perhaps you think the above quote is a sly criticism of your PEAP draft, 
which supports only EAP. I assure you it is not; why, the PEAP draft didn't 
even come out for months after the TTLS draft was published.

The point of supporting protocols other than EAP is that they are out 
there and heavily used. EAP is not exactly a hoary protocol that everyone 
has by now adopted, in deference to the wisdom of the IETF groups that 
like to deprecate things that have gained popularity. A small fraction of the 
extant RADIUS servers actually use EAP; everybody uses the legacy 
protocols, so why not support them? Through tunneling, TTLS makes even 
PAP secure.

At 02:07 AM 1/30/02 -0800, Glen Zorn wrote:
>Section 2
>---------
>Paragraph 3 says: "Users have also been willing to entrust their passwords
>to their service providers, or at least to allow their service providers to
>view challenges and hashed responses which are then forwarded to their home
>authentication servers using, for example, proxy RADIUS, without fear that
>the service provider will mount dictionary attacks on the observed
>credentials."  This statement is highly questiaonable: at least some people
>have been very leery of that trust, one of the reasons that RADIUS doesn't
>meet the criteria in RFC 2477.

If you're leery of trusting that a service provider won't mount a dictionary 
attack against your password, you shouldn't sign up with that service 
provider.

But when you do, at least you know who you are implicitly trusting. The 
point is that you shouldn't have to trust the guy sitting next to you in 
your local coffee shop cum access domain, or the barrista who knows 
how to run Ethereal on the coffee shop's LAN.

The statement you take exception to is hardly controversial, and still 
we haven't gotten to the protocol issues.

>"Because a user typically has a relationship with a single service provider,
>such trust is entirely manageable."  This passage leads me to believe that
>the authors are ignoring the general case of Internet roaming in favor of a
>very limited corporate dial outsource model.  In fact, they seem to think
>that brokers don't exist (or maybe it's just more convenient to ignore their
>existence, since EAP-TTLS is basically useless in that enviroment).

No, no, no. This is entirely about roaming. And TTLS is an ideal protocol 
for brokers, because the broker can act as a single point of trust for 
a user. In fact, it allows new brokerage models to come into being, in 
which the user, not the ISP, chooses the trusted broker.

>
>Paragraph 5 says: "Wireless connections...may enable channel hijacking, in
>which an attacker gains fraudulent access by seizing control of the
>communications channel after authentication is complete."  True, but
>irrelevant, since EAP-TTLS by itself does nothing to ameliorate this threat.

Of course TTLS mitigates the threat. 

It's not rocket science. TTLS is a protocol that results in keys that are 
shared between client and access point. These keys are securely based 
on the authentication that precedes their use. So an attacker can't jump 
into the middle of the session. EAP-TTLS does that, EAP-TLS does that, 
EAP-PEAP does that. The point of the paragraph is to set down the 
requirements that are salient in wireless networking.

>
>Paragraph 8 says: "In a wireless network, however, the user does not get to
>choose an access domain, and must connect with whichever access point is
>nearby;..."  It is not clear what is meant here by "wireless network", but
>both 802.11 WLANs (through the SSID) and GSM cellular networks allow the
>user to choose a provider in a roaming situation. Although the SSID doesn't
>provide authentication of the SPs, it does at least allow the user to
>distinguish between them; the user is not quite the weed blowing in the wind
>that this passage suggests.  The passage contiues: "...providing for the
>routing of the authentication from an arbitrary access point to the user's
>home domain may pose a challenge."  This is certainly true, but the authors
>neglect to mention that it is a challenge that has been overcome, both by
>cellular operators and Internet roaming brokers such as iPass.

The concept is that in 802.11 you don't get to dial a number, you simply 
connect to the ambient network at whatever hot spot you're at. In the dial-up 
case there are n providers, and you choose which of the n by dialing. In the 
802.11 case, there are n providers and m access points, and you don't get to 
choose which of the m. So you need a way to tell the access point which 
provider to proxy to, plus, you may have to tell the provider which home
domain to 
proxy to. That's why it's a challenge.

If you think the way to do this routing is to have the access domains provide 
a separate SSID for each provider, you should propose that. I'm sure people 
will find that approach interesting. It reminds me of a Popular Electronics 
article I once read, "Flip-Flop Doubles as Multivibrator".

The cellular operators are not comparable to the 802.11 network operators. 
The cellular operators run their networks all the way to the user. The 802.11 
network providers will rely on separately managed access domains that 
are run by hotels, airports, coffee shops, beauty parlors, and strip malls, 
any of whom might deal with multiple network providers. 

Yes, the Internet roaming brokers can do roaming, but 802.11 is a 
different problem domain and those solutions will be found wanting.

>
>Paragraph 14 says: "The authentication mechanism must support roaming among
>small access domains with which the user has no relationship and which will
>have limited capabilities for routing authentication requests."  Yet another
>red herring: while the user may not have a pre-established relationship with
>the "small access domains" (what does size have to do with it, anyway?), the
>"access domain" must have a relationship (either direct or brokered) with
>the user's home domain or roaming is impossible anyway.  Therefore, any
>limitations on the routing capabilities of the local domain are irrelevant:
>either thelocal domain can route to the user's home or not.
>

Not a red herring at all. In fact, TTLS's solution to the routing issues has 
more in common with a salmon's ability to swim upstream to its spawning 
ground.

How can limitations on the routability of the first hop of an authentication 
request be irrelevant?

Yes, either the routing is possible or not. The advantage of TTLS is that 
it makes that first hop more likely to be routed in a manner that results in 
the user being provided service. It accomplishes this by reducing the 
configuration requirements at the access domain down to typing in the 
addresses of a relatively small number of brokers. And the user gets to 
specify which broker -- this makes it routable.

If the broker is a TTLS agent, it can then untunnel the user's credentials 
and forward them to the home network based on the inner, encrypted 
NAI. So the user doesn't have to reveal his or her identity anywhere on 
the network leading up to the trusted broker.

At 02:08 AM 1/30/02 -0800, Glen Zorn wrote:
>Section 3
>---------
>The definition of "service provider" says "An organization with which a user
>has a business relationship, that provides network or other services. The
>service provider may provide the access equipment with which the user
>connects, may perform authentication or other AAA functions, may proxy AAA
>transactions to the user's home domain, etc." but there is no need for a
>user to have any business relationship with an entity for that enity to be a
>service provider (esp. in an Internet roaming situation).
>

Service providers with whom no one has a business relationship have thrived 
in the past, but I think most of them are out of business now.

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 30 Jan 2002 07:27:08 -0800

Paul Funk [mailto:[email-masked]] writes:

> Nowhere do you even discuss the EAP-TTLS protocol.

I haven't got there yet.  As I mentioned in my initial message, there's just
too much broken stuff to cover in a single message.

> Your comments are
> limited to the draft's prefatory material, definitions, etc.

Hmm.  So the requirements and definitions are not substantive to the
protocol?  I would imagine just the opposite, that the protocol would arise
from and be based upon actual requirements which are at least not
self-contradictory.

> Not that I'm

If you note, I've only finished section 3, page 7 of 38.  In fact, it took a
long time to decide how to approach this task: broken trust model first, or
violation of referenced RFCs, or...you see my problem.  At last, I decided
to begin at the beginning, running the risk of mixing relatively small
problems with the larger ones.

> widely-deployed authentication infrastructures such as RADIUS.

EAP itself is compatible with RADIUS.  Why bring RADIUS compatibility up as
if it was some special feature of TTLS?

...

> protocols, so why not support them? Through tunneling, TTLS makes even

By some definition of "secure", I'm sure it does.

> attack against your password, you shouldn't sign up with that service

Speaking of disingenuous, certainly you are aware that RFC 2477 deals with
roaming and that in the roaming case, I will _not_ have "signed up" with
that SP, not to mention the fact that SPs employ human beings: even if I
trust the corporate entity, why should I trust every perso who works for
them?

> which the user, not the ISP, chooses the trusted broker.

There is nothing new in this, it's been done for years, but...we'll get to
the trust model later...

> Of course TTLS mitigates the threat.

What mitigates the threat is cryptographic authentication of packets.  Does
TTLS do that?  No.

> EAP-PEAP does that.

So does EAP-SRP.  Keys can come from thin air, it doesn't matter; what
matters is how they are used.

> The point of the paragraph is to set down the

From your explanation above, it sounds like you expect m < n.  Is that
correct?

> article I once read, "Flip-Flop Doubles as Multivibrator".

As I'm sure you're aware, that is the approach widely taken right now, as
well as basically the same approach taken in GSM roaming.

> The cellular operators run their networks all the way to the
> user.

Right now, if I was to receive or make a call on my cell, I would be using
the AIS network.  I have absolutely no business relationship with AIS.  My
cellular operator (Nextel) is _not_ 'running his network all the way to me'
by any means.

> The 802.11

I wonder how many beuty parlors will be able to afford on-going relationship
with multiple SPs and how many airports will want to bother?

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 30 Jan 2002 18:06:30 -0800

...

...

> user. The 802.11

Re-reading this, it seems that you have a specific (if not unique) model of
network access and Internet roaming in mind; further, it appears that this
model is a) different from the classic model of Internet roaming developed
in the IETF and b) heavily dependent upon the concept of an "access domain".
If that's true, it would be _very_ helpful if you would make the model more
explicit, or at least define the term "access domain" (I can find that term
only once in the draft & not at all in the Terminology section.

~gwz

Glen Zorn
CTO Consulting Engineer

---

From: Paul Funk <[email-masked]>
Date: Thu, 31 Jan 2002 01:52:51 -0500

Glen,

By "access domain", I mean the network to which the user connects, 
i.e., that provides primary access to the network. This would be a hot 
spot in a hotel, airport, etc. 

Section 4 of the TTLS draft has an architectural model of the logical 
relationships of various entities involved in a TTLS authentication.

There are four logical entities: the client, the access point, the 
TTLS AAA server, and the AAA/H (home) server. (Both the AAA's are 
normally RADIUS servers, but they could be Diameter, etc.)

I'll try to flesh out the roaming concept with reference to that architectural 
model. 

The access domain maintains access points that, typically, would 
feed a local "aggregating" RADIUS server. The aggregating server isn't 
shown in the architectural model because it doesn't do anything special 
from the protocol point of view; but in practice it will be deployed to 
allow more flexible configuration. The access points will have a single 
proxy target -- the aggregating RADIUS server, and that server can be 
configured to proxy to the TTLS AAA servers maintained by various 
brokers.

A broker, in this scenario, is an entity that terminates the TLS portion 
of the EAP-TTLS protocol, untunnels the embedded authentication, 
and forwards that authentication to the AAA/H.

The user would have a trust relationship with two entities: the home domain 
and the broker. Possibly they are the same entity; possibly the user's 
relationship with the broker is via the home domain (user's ISP or enterprise).
In any case, the user has set up his client machine to trust the broker 
once the broker has authenticated itself via its server certificate.

The broker and home domain have a trust relationship through a RADIUS 
shared secret.

The client provides two NAIs during authentication: a clear-text one and 
a secret one. The clear-text NAI appears in the EAP-Response/Identity 
initially sent to the access point. It would be of the form:

	[email-masked]

In other words, the only information revealed is the name of the broker.

The secret NAI appears within the tunneled portion of the TTLS 
authentication, once TLS keys have been established. Depending on which 
tunneled authentication protocol is used, it can appear in User-Name or in 
EAP-Response/Identity. For example:

	[email-masked]

The local aggregating RADIUS server routes the authentication to the 
appropriate broker based on the realm in the clear-text NAI. 

The broker's TTLS AAA server performs the phase 1 TLS handshake with 
the client. When the handshake is over, phase 2 starts - the tunneled part. 
Now the client sends the secret NAI plus credentials via CHAP, MS-CHAP, 
EAP, etc. This credentials are invisible throughout the access domain and 
the network leading up to the broker. 

The broker untunnels the credentials, inspects the secret NAI, determines 
the home domain based on realm, and forwards the credentials to the AAA/H, 
which authenticates the client using whatever EAP or legacy protocol is being 
used. The broker acts as a gateway for the phase 2 authentication, protecting 
all the traffic between itself and the client, where it is most vulnerable
to attack.

So the idea is that you can have brokers who market their services to access 
domains, ISPs, enterprises, and individual users. The broker wants the 
access domain to support it by configuring its local aggregating server to 
proxy to it; a broker's ability to serve users is limited by the number of 
access domains that can proxy to it.

Users, enterprises and ISPs would choose a broker based on the broker's 
coverage at the access domains, and also based on whether they believe 
the broker can be trusted to handle their credentials. 

This roaming model is based on the idea that the broker doesn't only 
locate next hop domains and forward traffic; it also provides a gateway 
function that eliminates the need for home domains to deploy EAP-TTLS 
or any other new-fangled protocol, or to maintain a certificate infrastucture.
The broker outsources those functions; the home domain just does 
authentications against its existing database.

Other, more traditional, roaming models can also be used for scenarios 
in which they are useful. But the small access domain scenario seems 
to call for the kind of model described above. The fact that there are two 
NAIs allows both the routing from access domain to broker and from broker 
to home domain to be easily specified.

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]