Subject: [Emu] Channel Binding Discussion at IETF 77

From: Sam Hartman <[email-masked]>
Date: Tue, 15 Jun 2010 15:29:07 -0400

Hi.  At IETF 77, I agreed to edit draft-ietf-emu-chbind.  Also, at that
meeting, I sat down with Glen to understand his concerns with the
document.  I'd like to write up my notes on that meeting and to discuss
what I think the critical next steps are for the document.

I presented two motivating examples, one of which is I think directly
within the previous discussions of channel binding and one of which is
my motivation for caring about the problem.

Consider a corporation that has an internal network and that also has
agreements with WIFI hotspots to provide its employees connectivity.
Policy requires that people use a different set of firewall rules and
VPN configuration when connecting at the WIFI hotspots than when
connecting to the home network.  Typically clients determine which
network is in use by the SSID.  They use the same EAP credentials in
both cases.

You can imagine  that the corporation would know the identities of its
own access points.  In particular, a combination of configuration on the
AAA servers and at the boundary firewall could mean that the AAA servers
know whether a given request for access is coming from the corporate
network or a WIFI hotspot.  Today, however, the corporate AAA
infrastructure does not know what the client thinks it is connecting
to.  If the client disclosed the SSID it sees then the corporation would
be in a position to enforce the security policy.

Glen agreed that channel binding could address this.  We'll come back to
whether  it's a good idea in a bit.

My motivation is related to the technology being developed by the
Moonshot project (http://www.project-moonshot.org ).
We'd like to use EAP as part of application authentication. With network
access, there are a lot of situations where one network is much the same
as another. However with application authentication the party you're
talking to matters a lot, especially in federations with relatively
liberal membership policies.  I might well be willing to send
information to my company's ERP system that I should not send to a rogue
machine at a competitor that is part of the same federation. I'd like to
know the difference in who I'm talking to.

Glen described several significant concerns about the way channel
binding has been handled.

First, there is the basic complexity concern.
EAP has grown and evolved over the years, in many cases with design
taking place after the fact. Adding a new facility has a high
cost. However, there are some things in the current draft that make that
cost even higher.

I, and a few others have argued that all EAP methods should gain channel
binding support. Glen points out that is a lot of work and argues it is
unnecessary.

Glen is also concerned that each EAP method will handle channel binding
differently.His assumption is that each method would have a different
set of channel binding attributes that it carried, a different mechanism
for carrying them, and different names/numbers for the attributes. So,
rather than just supporting channel binding in some deployment of EAP,
you would need to tie it to a particular method or small set of
methods. He acknowledged that we could have some standardized way of
dealing with new EAP methods but points out that we have a lot of
existing methods.

Glen and I had a long discussion about channel binding in EAP vs channel
binding as part of the secure association protocol.
That was a very useful discussion.

The interesting question is what  favors one approach vs another.

Channel binding always requires changing the client and the home AAA
server/EAP server.

Using a SAP requires:
1) changing all the NASes
2) Specifying an extension to each lower layer that may be used
3) Specifying AAA transport for this extension.

[As an aside, Glen proposed a mechanism for doing this at the AAA layer
that should get written up somewhere. I thought it was quite clever and
easier than any attempt to do this I had seen before. Of course I'm a
relative novice when it comes to AAA.]

Using channel binding inside EAP requires:

1) Changing/specifying channel binging for the EAP methods in use.

For most of the applications I care about (with the exception of the EAP
for non-network-access use case), avoiding having to change the NAS is a
huge advantage.
Also, from where I sit, not having to update the link layers is a big
deal.
However, the conversation was really useful because I now understand
situations in which both of those assumptions about complexity of change
would be different.

So, here are some ideas going forward for areas I'd like to improve the
draft:

1) The introduction does discuss use cases.  However I don't think it
does a particularly good job of describing concrete use cases; I'd like
to provide some explicit examples.

2) The draft doesn't currently motivate the secure association protocol
version of channel binding.  I will admit that my reaction when I read
that section of the draft was roughly "that's a stupid idea there to
placate people who don't think we can do this in EAP."  At this point I
feel I understand the use case well enough to describe it and would like
to attempt doing so.

3) It's not actually true that you need to cover all EAP methods in
order to use channel binding inside EAP.  In particular, if you have a
tunneled configuration, only one of the methods needs to support channel
binding.  There are complexities here: you either need cryptographic
binding or you need the channel binding to be part of the method that
provides authentication of the client to the server.  Still, it seems
like this is an area where we should explicitly consider what's going on
and see if we can use tunnel methods to reduce cases where we need to
implement channel bindings.

4) It seems clear to me that we want one namespace of channel binding
attributes that we carry in EAP methods and secure association
protocols.  The current draft implies that but doesn't really give
concrete mappings for how that will be carried in existing EAP methods.
It's my understanding that there has been work done in this space.  I
think that we need to go through that work and make sure it is sound to
address Glen's concern that we don't want the set of attributes to be
method-specific, nor do we want applications consuming channel binding
to need to pay attention to what their method supports.  Some methods
will support channel binding; some will not.  However for those that do,
we want a consistent interface provided to the lower layer.

There may be other open issues with the document.  I have not inherited
any such list if there is one.

I'd appreciate comments from the WG and chairs on this proposed
approach.

--Sam

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 15 Jun 2010 15:34:04 -0700

Hi Sam,

Thanks again for taking this on.  I think the approach below makes
sense.  I think one of the biggest sticking points has been around the
motivation and use cases.  I believe this has been holding up progress
more than anything else.  The next big issue has been around the
requirements for the bindings themselves and how they should be
designed.  The draft mainly focuses on these aspects.  

I think we've had pretty good agreement that we would like to have a
common names space for bindings so we don't have different methods doing
different things.  I think a tunnel method approach could be useful
here; we have had some discussion of this and I think we will have more
as we move further along in tunnel method development.   We had
previously deferred a concrete definition of channel bindings to a
follow-on document; I think some people would like to see the current
document include this as well.  

I'll go back and check to see what other issues are open, but I think
what you discuss below involves most of the large open issues.  Do you
think you can have a revision in time for discussion in Maastricht?

Cheers,

Joe 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sam
> Hartman
> Sent: Tuesday, June 15, 2010 12:29 PM
> To: [email-masked]
> Subject: [Emu] Channel Binding Discussion at IETF 77
> 
> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Jun 2010 09:14:30 -0400

I will definitely have a revision for IETF 78.  I may not have
everything I'd like to have done ready for that revision.

---

From: Stephen McCann <[email-masked]>
Date: Wed, 16 Jun 2010 18:22:18 -0500

Sam, Joe,
                I think the tunneled approach is a good concept and
allows extensibility.

However, I'd also like to encourage the creation of an updated
document for the July meeting, sounds a good move forward.  I'm
certainly willing to review such a revision.

Kind regards

Stephen

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 20 Jun 2010 00:41:16 +0700

Sam Hartman [mailto://[email-masked]] writes:

> Glen agreed that channel binding could address this.  

Indeed it could, but all you really seem to be asking for is a way for the
corporation to be able to control the configuration of the client.  
As you point out, it is reasonable to expect that the corporation knows the
identity of its own access points; why does it matter what the client
_thinks_ (for lack of a better word) that it is attached to?  I cannot see
any purpose for the client sending the SSID of the network to which it
attached.  In fact, it seems that all that is necessary is the ability to
remotely modify the configuration of a client; why is the job of EAP, again?

> We'll come back to
> placate people who don't think we can do this in EAP."  

I think that it has been fairly well established that people can & will do
virtually _anything_ in/to EAP; the question is whether or not it's a good
idea to do it (Hint: "it's just so convenient" is _not_ a justification
IMO).

> At this point I

3) has me really confused.  Would you mind explaining a bit further.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 19 Jun 2010 22:21:20 +0200

> be in a position to enforce the security policy.

  The client could disclose more than the SSID.  Location, cost, etc.
are all possible items of interest.

> binding support. Glen points out that is a lot of work and argues it is

  The charter requires us to focus on adding support for EAP channel
bindings to the tunneled method, and if possible, other TLS-based EAP
methods.

> for carrying them, and different names/numbers for the attributes.

  I'm not sure why each EAP method would require a different set of
channel binding attributes.  If they are the same, they should all use a
common mechanism.

> for non-network-access use case), avoiding having to change the NAS is a

  Changing the NAS is extremely difficult.

> to provide some explicit examples.

  OK.

> feel I understand the use case well enough to describe it and would like

  OK.

> implement channel bindings.

  The charter suggests this approach.

> protocols.

  I agree.

>  The current draft implies that but doesn't really give

  I agree.

> I'd appreciate comments from the WG and chairs on this proposed

  I think it's a good approach.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 19 Jun 2010 22:29:01 +0200

> corporation to be able to control the configuration of the client.  

  That is already done outside of the scope of EAP.  (VPN config,
Directory services, etc.)  The only requirement I see for EAP is that it
support channel bindings, and an indication that the home AAA approves
of the connection.

> attached.

  It's part of the channel binding.  It closes the loop between what the
NAS tells the AAA, and what the NAS tells the client.

  Right now in a commercial roaming scenario, the NAS could tell the
user "we're partner X: $0.05 / minute".  It could *really* be partner Y:
$5.00 / minute.  The user naively connects, and the bill is larger than
expected.  The partner gets paid, and the user gets blamed for not
paying attention.

>  In fact, it seems that all that is necessary is the ability to

  I don't think it is.  I think EAP might *motivate* changes in the
config.  i.e.  I could provision a machine to run a script after
authentication.  That script would check the SSID, and enforce a local
configuration for that SSID.

  But it's not the role of EAP to "change the configuration".

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 20 Jun 2010 12:25:09 +0700

> support channel bindings, and an indication that the home AAA approves

Hmm.  I could have sworn that this indication already existed, in the form
of "Access-Accept" (for RADIUS).

> NAS tells the AAA, and what the NAS tells the client.

Only in the special case where (in your roaming example, below) roaming
partners X and Y have direct relationships with the home network.  Suppose,
for example, that the client connects to partner X, which correctly
identifies itself.  The "channel binding" is duly reported by the client
through EAP & by the NAS through AAA; however, the AAA traffic passes
through an intermediate realm (say, Z).  So now the home AAA server has
received conflicting messages: the EAP "channel binding" says the attachment
is to X, as do the AAA attributes, but the AAA message came (as far as can
be determined) from Z.  Of course this problem can be solved using e2e-ish
AAA integrity protection ("-ish" modulo the level of trust between realms &
within each realm) but I can't think of another way.  No standard IETF AAA
protocol provides even e2e-ish security now, though.  

> expected.  The partner gets paid, and the user gets blamed for not

This is a legal/political problem, not a technical one.

...

---

From: Alan DeKok <[email-masked]>
Date: Sun, 20 Jun 2010 09:08:58 +0200

Glen Zorn wrote:
>> and an indication that the home AAA approves
>> of the connection.
> 

  And EAP-Success.  Exactly.

> through an intermediate realm (say, Z).

  This happens a lot in roaming configurations.

>  So now the home AAA server has
> be determined) from Z.

  It also contains a Called-Station-Id attribute with the SSID of X.  So
the home server can verify that SSID against the channel bindings.

> This is a legal/political problem, not a technical one.

  It motivates the technical solution.  Having a security protocol which
doesn't verify the identities of those involved is... surprising.

  Channel bindings closes a security issue in current deployments of the
EAP protocol.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 20 Jun 2010 15:45:11 +0700

Alan DeKok [mailto://[email-masked]] writes:

...

>   It also contains a Called-Station-Id attribute with the SSID of X.  

Is there an RFC that says this somewhere?  802.11-2007 doesn't mention
Called-Station-ID; 802.1X-2004 says this:

D.3.20 Called-Station-Id
For IEEE 802.1X Authenticators, this attribute is used to store the Bridge
or Access Point MAC address,
represented as an ASCII character string in Canonical format (see IEEE Std
802). For example, "00-10-A4-
23-19-C0." For 802.11 Access Points, the IEEE 802.11 SSID should be appended
to the Access Point MAC
address, separated from the MAC address with a ":". For example,
"00-10-A4-23-19-C0:AP1".

Note the use of "should".  In addition, there is no guarantee at all that
SSIDs are globally unique.

> So

Assuming that the SSID is actually in the Called-Station-ID Attribute (see
above) and that the NAS didn't just lie in the RADIUS message, too (given
that there is no way to detect such a lie in a >1 hop AAA scenario) and that
there is no collusion between X & Z.  We seem to be assuming a _lot_ of
honesty from our thieves.

...

---

From: Alan DeKok <[email-masked]>
Date: Sun, 20 Jun 2010 11:29:43 +0200

Glen Zorn wrote:
> Is there an RFC that says this somewhere? 

  RFC 3580, Section 3.20

 802.11-2007 doesn't mention

---

From: Alan DeKok <[email-masked]>
Date: Sun, 20 Jun 2010 11:33:27 +0200

(sigh, hit send too soon)

> Is there an RFC that says this somewhere?

  RFC 3580.

3.20.  Called-Station-Id

   For IEEE 802.1X Authenticators, this attribute is used to store the
   bridge or Access Point MAC address in ASCII format (upper case only),
   with octet values separated by a "-".  Example: "00-10-A4-23-19-C0".
   In IEEE 802.11, where the SSID is known, it SHOULD be appended to the
   Access Point MAC address, separated from the MAC address with a ":".
   Example "00-10-A4-23-19-C0:AP1".

> Called-Station-ID; 802.1X-2004 says this:

 Taken from 3580.

> Note the use of "should".

  Which is a common practice.

>  In addition, there is no guarantee at all that

  Agreed.  However, SSIDs are *likely* to be unique within a roamin
consortium.  This is because the parties talk to each other, and can
complain when the SSIDs are unknown, or re-used.

> honesty from our thieves.

  Yes.

  There are mitigating circumstances.  AAA relationships leverage trust.
 Continued trust depends on the parties continuing to meet expectations.
 Lying about SSIDs violates trust.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 20 Jun 2010 17:03:54 +0700

> > Is there an RFC that says this somewhere?

OK, thanks.  This appears to be identical to the section from 802.1X-2004
that I quoted below, though...

> Bridge

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 20 Jun 2010 17:29:13 +0700

Alan DeKok [mailto:[email-masked]] 

...

> > Called-Station-ID; 802.1X-2004 says this:

Whatever; 3580 says 

   This document provides suggestions on Remote Authentication Dial In
   User Service (RADIUS) usage by IEEE 802.1X Authenticators.  The
   material in this document is also included within a non-normative
   Appendix within the IEEE 802.1X specification, and is being presented
   as an IETF RFC for informational purposes.

Which suggests to me an opposite relationship, though.

>   Which is a common practice.

???

> complain when the SSIDs are unknown, or re-used.

What parties?  The BSSs?  Why?

>  Lying about SSIDs violates trust.

But fraud doesn't?

---

From: Alan DeKok <[email-masked]>
Date: Sun, 20 Jun 2010 18:05:59 +0200

>>   Which is a common practice.

  3580 says Called-Station-Id SHOULD include the SSID.  Most APs do
include the SSID.

>>   However, SSIDs are *likely* to be unique within a roamin

  The parties in a roaming consortium talk to each other.

>>  Lying about SSIDs violates trust.

  Yes, fraud violates trust.  My original post included an example of
fraud, stated why this was bad, and how channel bindings could help.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 21 Jun 2010 13:59:37 +0700

...

>   Channel bindings closes a security issue in current deployments of the

Is that true?  If all you want is to solve the case where "...the NAS could
tell the user "we're partner X: $0.05 / minute".  It could *really* be
partner Y:
$5.00 / minute.  The user naively connects, and the bill is larger than
expected.  The partner gets paid, and the user gets blamed for not paying
attention.", I think that that could probably be accomplished with EAP-TTLS
right now.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Jun 2010 12:13:16 +0200

> attention.", I think that that could probably be accomplished with EAP-TTLS

  There is no standardized mechanism to do that.

  Alan DeKok.

---

From: Stephen McCann <[email-masked]>
Date: Mon, 21 Jun 2010 13:00:22 +0100

Alan, Sam, Glen,
                          imho, I'd not place any trust in an SSID.
Its just a 32 octet string that can be set to anything, and provides
no guarantee about the identity of a WLAN.

Kind regards

Stephen

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Jun 2010 14:24:10 +0200

> no guarantee about the identity of a WLAN.

  It's useful as an example.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Jun 2010 15:42:43 -0400

During the discussion between Glen and Alan there was a lot of
discussion about transitive trust.

Alan gave a case where a user might be wanting to choose between two
vendors, X and Y. They charge different prices. If they are directly
connected to the user's home AAA realm, then the home AAA realm might be
in a position to validate a claim about which identity is involved.

Glen points out that if there are additional proxies then the home AAA
realm cannot make this validation.

Another argument tends to come up around this point: such matters should
be handled by business agreements, not by technical means. If someone
lies, sue them or terminate your business relationship.

I've been thinking a lot about transitive trust recently and have been
studying this problem in the Kerberos context for many years.

I have a few responses.  First, the technical system needs to support
auditing of the business agreements: when you want to file an action or
terminate a relationship because of fraud, you want the data necessary
to make that stick.

Business agreements are a good defense against fraud on the part of the
party you have a business agreement with.
However business agreements are a dreadful way of dealing with
compromised systems or social engineering attacks. You want to limit
the damage that a problem at one of your business partners can cause and
you do not want to trust them more than you need to.
Technical measures are important in  establishing this.

Also, technical measures allow you to establish pockets of greater trust
in systems of lesser trust. Without technical measures you have to
expect all your business partners to run their infrastructure at a level
sufficient to meet your strongest requirements, even if they are not
involved in that.  Put another way, without technical safeguards to
limit what statements you will allow a trusted third party to make, then
your overall level of trust decreases to the least trusted of your
trusted third parties.

Let's take the corporate network example from my first message as a case
in point.  The corporation has two levels of trust: internal and
everyone else. Internal entities may claim to be corporate access
points. People who are part of "everyone else," are not permitted to
make this statement. The corporation need not worry about what happens
if a roaming partner claimed in AAA attributes to be the corporation's
network: such a statement would simply be rejected by some proxy within
the corporate border.

More general, at each level in a proxy chain, you can consider whether
the party you receive a message from is permitted to claim the
attributes that are claimed in the proxy request.

I'll take a specific example from Kerberos.  In Kerberos, it's important
to understand what realm should be used for a given host and what the
set of realms should be traversed between a source and destination.
Vendors have found it important to limit the trust claims that can be
made. For example, Microsoft establishes a distributed database between
communicating realms to carry the trust information. That way, to the
extent possible, trust can be evaluated even for multi-hop
situations. Obviously if legitimate traffic would involve a particular
realm, then that realm can generate similar illegitimate
traffic. However, realms are not trusted more than they need to be.

We're looking at similar mechanisms for the non-network-access
federation project I'm involved in.

Is every AAA operator going to go out and deploy distributed databases
to make channel binding more useful? Absolutely not. However I do expect
that enterprises will filter AAA traffic to establish zones of trust. I
also expect that operators faced with customer demand (and revenue)
would be happy to do the same.

So, yes, transitive trust is not as good as direct trust. However,it
doesn't mean throwing things completely open in all environments.

Next, I'll cover tunnel issues.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Jun 2010 16:20:36 -0400

Glen asked me to explain my tunnel related comments more.

It would be desirable to reduce the number of methods we need to add
channel binding to. For example if eap-ttls supports channel binding [1]
and I'm running some other method inside it, then I may not care whether
that method supports channel binding.  Similarly, if I wish I had
channel binding in some method that does not have channel binding, I can
always tunnel it.

[1] I think it does, but I'm not sure it is in alignment with
draft-ietf-emu-chbind at the moment.

This seems like such a good idea we wrote it into the charter.

Unfortunately, it's never that simple.  Channel binding data is a
statement from the client to the EAP server about the client's
understanding of the entity the client is authenticating to/the
environment that the client is gaining access to.  the EAP server's job
is to verify that the channel binding is consistent and if not, reject
the access request.

This model depends on the server being able to confirm that the channel
binding statements are actually from the client. Clearly, if an attacker
could change channel binding, then the system will not work.

However, typically tunnel methods authenticate the server to the client
but depend on the inner method to authenticate the client to the server.

Let me give a concrete attack.  Consider an EAP server that takes the
channel binding data from the outer method if present otherwise the
inner method.

A client intends to use GPSK and includes channel binding data there.
An attacker acts as a man-in-the-middle, receives the GPSK lower layer
messages and replaces them with lower layer messages tunneling GPSK in
TTLS. So, the TTLS tunnel runs from the attacker to the EAP server,
while the inner GPSK runs from the client to the EAP server.  If this is
starting to look a lot like the standard set of EAP tunnel attacks,
you're absolutely right.  The attacker inserts channel binding data in
the outer tunnel and thus replaces the channel binding.

This is not a practical attack.  I'm not sure there are particularly
practical attacks in this space.  However, I think we have an obligation
to specify constraints such that the system is secure.  Here are
examples of constraints that would be sufficient.

* Cryptographic binding is used to prove that the outer tunnel party
  knows the inner tunnel key.  Note that proving that the inner tunnel
  party knows the outer key would not generally be sufficient mostly
  because a lot of the inner methods you might want won't ever support
  this.

* Never except the same equivalence class of EAP methods both inside an
  outside a tunnel.  That is, in a given configuration require that if
  GPSK is to be used it either always appears in a given tunnel for a
  specific user or never does.  I say equivalence class because it's
  possible that an attacker might be able to transform the messages of
  one method into another.  For example I'm not sure whether an attacker
  can turn one of the TLS-related methods into another.

* Assuming that adding channel binding information can never make a
  request that would fail succeed, take channel binding attributes from
  the inner method first.

--Sam

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 22 Jun 2010 13:34:54 +0700

Sam Hartman [mailto:[email-masked]] writes:

> >>>>> "Glen" == Glen Zorn <[email-masked]> writes:
> Hi.  I have read the later messages on this thread, but it sounded like
> you and Alan were talking past each other a bit, so I want to come back
> to where I think the disagreement is introduced.
> 
> 
>     Glen> Sam Hartman [mailto://[email-masked]] writes:
> 
>     >> Consider a corporation that has an internal network and that also
>     >> has agreements with WIFI hotspots to provide its employees
>     >> connectivity.  Policy requires that people use a different set of
>     >> firewall rules and VPN configuration when connecting at the WIFI
>     >> hotspots than when connecting to the home network.  Typically
>     >> clients determine which network is in use by the SSID.  They use
>     >> the same EAP credentials in both cases.
>     >>
>     >> You can imagine that the corporation would know the identities of
>     >> its own access points.  In particular, a combination of
>     >> configuration on the AAA servers and at the boundary firewall
>     >> could mean that the AAA servers know whether a given request for
>     >> access is coming from the corporate network or a WIFI hotspot.
>     >> Today, however, the corporate AAA infrastructure does not know
>     >> what the client thinks it is connecting to.  If the client
>     >> disclosed the SSID it sees then the corporation would be in a
>     >> position to enforce the security policy.
>     >>
>     Glen> Indeed it could, but all you really seem to be asking for is a
>     Glen> way for the corporation to be able to control the
>     Glen> configuration of the client.  As you point out, it is
>     Glen> reasonable to expect that the corporation knows the identity
>     Glen> of its own access points; why does it matter what the client
>     Glen> _thinks_ (for lack of a better word) that it is attached to?
>     Glen> I cannot see any purpose for the client sending the SSID of
>     Glen> the network to which it attached.  In fact, it seems that all
>     Glen> that is necessary is the ability to remotely modify the
>     Glen> configuration of a client; why is the job of EAP, again?
> 
> 
> 
> The client has two different policies both of which have been configured
> by the corporate infrastructure.
> 
> The first policy is a policy to be used when connected directly to the
> corporate network.  The second policy is a policy to be used when
> connected to more open networks.
> 
> The client knows both policies.  The client needs to choose which one to
> use.
> The client needs a procedure for connecting to the network such that on
> success:
> 
> 1) The client uses the corporate policy on the corporate network and the
> other policy on other networks
> 2) The client has an authenticated EAP and 802.11I association; the EAP
> association to the EAP server and the 802.11I association to the access
> point
> 3) No attacker can convince the client to use the corporate policy when
> connecting to other networks or the other policy when connecting to the
> corporate network without the cooperation of the corporate AAA
> infrastructure
> 
> So, somehow the client needs to discover which policy to use. We could
> use an insecure discovery mechanism and validate the results of that
> discovery with a secure protocol later. Alternatively we could use a
> secure discovery mechanism and bind the results of that mechanism to the
> rest of our protocol. As far as I can tell binding secure discovery to
> the later stages of the protocol is exactly as hard as validating
> insecure discovery, so I'll design a solution for insecure discovery.  I
> propose that the client discover which policy to use by looking at the
> SSIDs advertised by the APs. I understand SSIDs may not be unique; as a
> consequence our client will end up being unable to connect to a
> non-corporate network that happens to have chosen the same SSID as the
> corporate network. If you design a better discovery mechanism we can
> remove this defect; in practice if the corporate SSID is well-chosen
> this is not a significant problem.
> 
> So, based on the SSID, we have discovered what policy we will try to
> use. Since our discovery approach is entirely insecure, an attacker can
> give us the wrong policy to try.  If our overall approach is secure,
> then we must fail at a later step if that happens.
> 
> In this system, we've posited that the corporate AAA infrastructure
> knows whether a given AP is corporate or other. So, we want to take
> advantage of that information. We need to change the corporate AAA
> behavior to do that as it doesn't provide that service today.  We could:
> 
> 1) We can tell the corporate AAA infrastructure what policy we plan to
> use and have it validate that decision.
> 2) The corporate AAA infrastructure  can tell us what policy we should
> be using.

Or we could use the more direct & much simpler approach of allowing the
client to authenticate the network to which it is attached & use that data
to decide by itself.  This can be done today using EAP-TTLS.

> 
> The channel binding approach is option 1. We tell the corporate
> infrastructure what policy we're using as a channel-binding attribute in
> the EAP exchange. If we indicate we're using the corporate policy on an
> other network, then the corporate AAA infrastructure sends an
> access-reject. Otherwise if we're planning to use the other policy on
> the corporate network then the infrastructure sends an
> access-reject. Finally, if the policies match, then the infrastructure
> returns a result based on existing practice--if everything goes well, an
> access-accept.
> 
> So, in this design, we communicate the policy we wish to use to the
> corporate infrastructure so that our decision can be validated. No
> amount of configuration could allow the client to validate this decision
> on its own: it has no secure way to distinguish access points.
> 
> I've specifically constructed this example so that transitive roaming
> issues do not pop up.  

Note that transitive trust issues are irrelevant if EAP-TTLS is used.

> They were discussion in your thread with
> Alan. I'll get to that in the second of three messages I plan to write
> in response.
> 
> --Sam

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 22 Jun 2010 14:14:20 +0700

> terminate a relationship because of fraud, you want the data necessary

Indeed; however, there are lots of ways to collect that data that are both
secure and do not involve hacking up EAP.

> network: such a statement would simply be rejected by some proxy within

s/within/at: if said proxy is even one AAA hop inside the border an invalid
claim may be indistinguishable from a valid one.

> attributes that are claimed in the proxy request.

You can. but in this context it's difficult to see how an intermediate proxy
could filter on SSID (for example) w/o detailed knowledge of the topology of
both the originating and destination networks.

> 
> I'll take a specific example from Kerberos.  

I would be very careful making analogies between Kerberos & any IETF AAA
protocol: they work in wildly different ways, particularly WRT cross-realm
operation.  For example, it is possible to source-route messages and to
record (in a way that is _not_ tamper-proof) the route taken by a given
message in Diameter the same capability doesn't exist in RADIUS.  Most
proxies simply forward messages (hopefully) toward the ultimate destination
without regard for the path to be taken after the next hop.

> In Kerberos, it's important

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Jun 2010 08:01:35 -0400

>>>>> "Glen" == Glen Zorn <[email-masked]> writes:

    Glen> Or we could use the more direct & much simpler approach of
    Glen> allowing the client to authenticate the network to which it is
    Glen> attached & use that data to decide by itself.  This can be
    Glen> done today using EAP-TTLS.

How?
I'd appreciate an answer in approximately similar level of detail as I
have given you the answer  on the channel binding approach.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 22 Jun 2010 14:15:26 +0200

> Note that transitive trust issues are irrelevant if EAP-TTLS is used.

  I agree with Sam here.  I'd like to see more explanation behind this
assertion.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Jun 2010 10:01:02 -0400

>>>>> "Glen" == Glen Zorn <[email-masked]> writes:

the corporate network example from my first message as
    >> a case in point.  The corporation has two levels of trust:
    >> internal and everyone else. Internal entities may claim to be
    >> corporate access points. People who are part of "everyone else,"
    >> are not permitted to make this statement. The corporation need
    >> not worry about what happens if a roaming partner claimed in AAA
    >> attributes to be the corporation's network: such a statement
    >> would simply be rejected by some proxy within the corporate
    >> border.

    Glen> s/within/at: if said proxy is even one AAA hop inside the
    Glen> border an invalid claim may be indistinguishable from a valid
    Glen> one.

The key word there is may.  Depending on topology, configuration and
policy, it may be possible to distinguish things beyond the border.  I
agree the border is a logical place to make this distinction though.

    >> 
    >> More general, at each level in a proxy chain, you can consider
    >> whether the party you receive a message from is permitted to
    >> claim the attributes that are claimed in the proxy request.

    Glen> You can. but in this context it's difficult to see how an
    Glen> intermediate proxy could filter on SSID (for example) w/o
    Glen> detailed knowledge of the topology of both the originating and

I absolutely agree that the intermediate proxy needs sufficient
knowledge to perform the filtering.  Depending on the specific filter,
it is definitely the case that the proxy will need information about the
origin and destination organizations and networks.  That level of detail
is very often spelled out in business agreements for trading partners,
in the banking industry, and presumably in other industries I'm less
familiar with. I'm not aware of cases where AAA configuration was the
subject of these agreements, but I've also not been in a position where
I cared about the AAA infrastructure before.

But yes, for a lot of filters you need to understand the routing
topology well enough to understand whether a particular proxy should
legitimately be on the path between you and a given origin.  For RADIUS
at least, I do understand the difficulty in getting that information;
I'd rate it as higher than you'd probably want for most current network
access situations, but definitely not impossible.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 24 Jun 2010 14:35:53 +0700

Sam Hartman [mailto:[email-masked]] writes:

> The key word there is may.  

If that's the key word, then forget it ;-).  In actual fact, it is
impossible within either standard RADIUS or standard Diameter to securely
determine where a message came from beyond the node from which it was sent.
To be clear, if the filtering proxy is inside the corporate network, it will
be incapable of securely determining whether the message originated outside
that network or not.  I used the word "may" because somebody somewhere may
have devised a method for doing this; I make know claim of omniscience.
 
> Depending on topology, configuration and
> policy, it may be possible to distinguish things beyond the border.  

Policy & configuration cannot solve the problem, which is a protocol
deficiency.

> I agree the border is a logical place to make this distinction though.
> 
> 
>     >>

Nothing is impossible, but at the moment there is no way to do it and no
clear way to accomplish it.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 24 Jun 2010 15:58:33 +0700

> have given you the answer  on the channel binding approach.

I was hoping that someone with a higher level of expertise WRT eap-ttls than
mine would jump in here (Steve Hannah, for example) but I'll do my best.
Section 5 of RFC 5281 says:

5.  Architectural Model

   The network architectural model for EAP-TTLS usage and the type of
   security it provides is shown below.

   +----------+      +----------+      +----------+      +----------+
   |          |      |          |      |          |      |          |
   |  client  |<---->|  access  |<---->| TTLS AAA |<---->|  AAA/H   |
   |          |      |  point   |      |  server  |      |  server  |
   |          |      |          |      |          |      |          |
   +----------+      +----------+      +----------+      +----------+

   <---- secure password authentication tunnel --->

   <---- secure data tunnel ---->

   The entities depicted above are logical entities and may or may not
   correspond to separate network components.  For example, the TTLS
   server and AAA/H server might be a single entity; the access point
   and TTLS server might be a single entity; or, indeed, the functions
   of the access point, TTLS server and AAA/H server might be combined
   into a single physical device.  The above diagram illustrates the
   division of labor among entities in a general manner and shows how a
   distributed system might be constructed; however, actual systems
   might be realized more simply.

   Note also that one or more AAA proxy servers might be deployed
   between access point and TTLS server, or between TTLS server and
   AAA/H server.  Such proxies typically perform aggregation or are
   required for realm-based message routing.  However, such servers play
   no direct role in EAP-TTLS and are therefore not shown.

If certificate-based TLS authentication is used & the TTLS server is located
in the visited network (something that the client can check by matching the
identity advertised with a name in the cert), the task is accomplished (in
that the problem becomes one of policy, provisioning and implementation
rather than protocol design or standardization).

---

From: Alan DeKok <[email-masked]>
Date: Thu, 24 Jun 2010 11:29:00 +0200

> rather than protocol design or standardization).

  My understanding was that the TLS tunnel was used for at least two
purposes.  One was to perform TLS server validation, as you suggest
above.  Another was to provide privacy for authentication credentials.

  The proposal above satisfies the first purpose, but satisfies the
second only when the TTLS & home AAA server are co-located, or in the
same management domain.

  For roaming, the TTLS server is not in the same management domain as
the home AAA server.  The proposal above would require that the TTLS
server take the authentication credentials from inside of the TLS
tunnel, and proxy them over normal RADIUS, without the protection of a
TLS tunnel

  This proxying violates the privacy requirements.

  The only way I could see this method working is if the data inside of
the TLS tunnel was another TLS session.  The client could verify that
the outer session matched the local network, and that the inner session
matched the home network.

  Unless I'm missing something, that would require standards action, as
there is no document describing TLS inside of TTLS.  There is no
document describing how the client could perform the certificate checks
against the local network information, so that would require standards
action, too.

  And I'm not sure why this applies only to TTLS.  I see this as
applying equally well (or poorly) any other TLS-based EAP method.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 24 Jun 2010 17:40:45 +0700

>   This proxying violates the privacy requirements.

What privacy requirements are those?

> there is no document describing TLS inside of TTLS.  

EAP-TTLS provides for the transport of EAP inside the TLS tunnel.  

> There is no

Why?  I thought that we were talking about commercial entities here:
certainly roaming consortia can specify how they want to take care of
internal matters...

---

From: Alan DeKok <[email-masked]>
Date: Thu, 24 Jun 2010 13:02:34 +0200

> What privacy requirements are those?

  The requirement to keep authentication credentials private, which is
one of the reasons for choosing a TLS-based method in the first place.

> EAP-TTLS provides for the transport of EAP inside the TLS tunnel.  

  Is there a document describing that?  Will implementations be
interoperable without a document?  What security and privacy issues are
there with doing that?

> certainly roaming consortia can specify how they want to take care of

  Roaming was just one example.  Even with roaming, there are multiple
roaming consortia, for multiple purposes.  Standardizing a
cross-consortia method for channel bindings would appear to be useful to
the wider Internet Community, and well within the scope of the IETF.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 24 Jun 2010 18:38:28 +0700

> one of the reasons for choosing a TLS-based method in the first place.

Are you confused?  We're talking about being able to authenticate the
visited network, not tunnel method requirements...

> interoperable without a document?  What security and privacy issues are

RFC 5281.

> the wider Internet Community, and well within the scope of the IETF.

How does this affect the fact that the stated goal of making sure that the
network to which the client is attached is the one that was advertised?

---

From: Alan DeKok <[email-masked]>
Date: Thu, 24 Jun 2010 14:20:47 +0200

> visited network, not tunnel method requirements...

  Your proposal authenticates the visited network, at the cost of
exposing the users authentication credentials to the visited network,
and to everyone else in the proxy chain.  This fails the privacy
requirements of any TLS-based EAP method, and has nothing at all to do
with the tunnel method requirements.

>> interoperable without a document?  What security and privacy issues are

  i.e. EAP-TTLS, which is informational, not standards track.  And it
has little or no discussion on the dual authentication which would be
necessary for your proposal to work.

> network to which the client is attached is the one that was advertised?

  Channel bindings are proposed to solve that, and other issues.  The
proposal is to do this without exposing authentication credentials to
everyone.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 24 Jun 2010 13:59:53 -0400

>>>>> "Glen" == Glen Zorn <[email-masked]> writes:

    Glen> If certificate-based TLS authentication is used & the TTLS
    Glen> server is located in the visited network (something that the
    Glen> client can check by matching the identity advertised with a
    Glen> name in the cert), the task is accomplished (in that the
    Glen> problem becomes one of policy, provisioning and implementation
    Glen> rather than protocol design or standardization).

Glen, thanks for explaining this.  I now believe I understand what
you're proposing.

Like Alan, I'm concerned about the security and privacy implications of
have the TTLS server be in the visited network in a different
organization.

However we can do something similar.  We could have the home AAA server
use a different EAP server or at least different TLS certificate for the
corporate network than for other networks.  From the standpoint of the
client I think this is very similar to what you describe.  It has some
advantages, including that we don't need to ask visited networks to
change their configuration or deploy TTLS servers.

I agree that works for the case I proposed. However I do not prefer it
as a solution.

At this point , I think we understand each other's positions and have
clear disagreement.  We are not going to be able to change each other's
minds.  So, the WG will have to come to consensus on whether channel
binding has value.

For the record, here are the reasons I prefer channel binding to using
different certificates to distinguish properties of the network.

Channel binding scales better on dimensions that I care about. For each
set of attributes that a client wants to distinguish I need a separate
certificate with the TLS approach. With channel binding, the client
simply needs to give these attributes to the EAP server. Significantly
increasing the number of certificates is likely to complicate management
of the client and of the PKI within the organization. If an external CA
is used, this may involve a significant cost.

Using TLS certificates tends to require that all clients want to
distinguish the same attributes of the network. With channel binding,
two clients can send a different set of attributes for validation
against the channel binding information. The certificate approach seems
like it will be very complicated especially when an organization wishes
to change the set of attributes that clients wish to distinguish.

I think channel binding does less damage to the conceptual EAP model
than this TLS approach. Today in EAP, the peer authenticates to the
issuer of its credentials; given a credential, a peer typically knows
who the other party will be. Trust management between the peer and EAP
server is relatively simple in this model. However, if TLS certificates
represent networks rather than credential issuers, then the conceptual
parties in the security model change. I think that complicates trust;
the privacy issues Alan brings up are the most obvious example. In
contrast, I at least believe that channel binding fits within the
existing EAP model. Certainly, we've done a lot of analysis including
the EAP keying framework and the AAA key management requirements
assuming such a facility and this analysis does not appear to have shown
a disconnect between the EAP model and channel binding.

I'll note that channel binding appears very easy to add to TTLS.

However, there is one case where the of multiple TLS certificates may
provide a significant benefit over traditional channel binding. If there
is an entity trusted by the client that is significantly closer to the
NAS than the home EAP server, then having a TTLS tunnel to that entity
may provide a point that is in a better position to make statements
about the NAS. I'll note that this approach has significant power when
combined with channel binding. However it seems like there is a lot of
complexity involved and issues to work through. It seems like having
trust relationships with all these entities in the network will require
a fairly complex PKI or complex client management. It seems like this
approach is getting away from the AAA model, which at least as I
conceptualize it has a major goal of limiting the trust management of
the client. Figuring out when to route an EAP conversation through such
an endpoint seems kind of tricky; what set of clients is it done for? Do
clients request such routing? If so, how? If not, how is the
cross-organizational configuration managed? Still, I think this use case
is quite interesting and is something we should examine.

--Sam

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 24 Jun 2010 11:48:31 -0700 (PDT)

Hi Alan,

> with the tunnel method requirements.

  I may be missing something but the key shared by the client and the NAS
is going to be known by the proxies in that chain so what sort of problem
is being solved by applying these privacy requirements to proxies?

  There are man-in-the-middle attacks and dictionary attacks possible
by an attacker between the client and the NAS and these tunneled EAP
methods address that. But if you think that it's a problem for a proxy
between the TTLS server and the AAA server to see the client's
credentials then don't you think it's a (bigger) problem that this proxy
will have access to the client's key?

  Dan.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 24 Jun 2010 14:56:52 -0400

>>>>> "Dan" == Dan Harkins <[email-masked]> writes:

    Dan>   Hi Alan,

    Dan> On Thu, June 24, 2010 5:20 am, Alan DeKok wrote:
    >>>> The requirement to keep authentication credentials private,
    >>>> which is one of the reasons for choosing a TLS-based method in
    >>>> the first place.
    >>> 
    >>> Are you confused?  We're talking about being able to
    >>> authenticate the visited network, not tunnel method
    >>> requirements...
    >> 
    >> exposing the users authentication credentials to the visited
    >> network, and to everyone else in the proxy chain.  This fails the
    >> privacy requirements of any TLS-based EAP method, and has nothing
    >> at all to do with the tunnel method requirements.

    Dan>   I may be missing something but the key shared by the client
    Dan> and the NAS is going to be known by the proxies in that chain
    Dan> so what sort of problem is being solved by applying these
    Dan> privacy requirements to proxies?
The MSK is a relatively short-term key.  The credentials that proxies
may be able to attack are long-term credentials.
So, I'm with Alan: the long-term credentials are more important than the
    Dan> MSK.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 24 Jun 2010 13:36:54 -0700 (PDT)

Sam,

  The only type of credential that would have the issues you're
talking about is a long-term password used in PAP. Now I'm not
a big OPS guy but I do have quite a bit of experience in actual
deployments of 802.1X and EAP and I haven't seen them used anywhere.
If someone has a long-term password they're doing EAP-MSCHAPv2.
If someone's doing PAP they're using a token card or some type of
OTP. Are you worried about a AAA proxy hijacking a client's OTP
and impersonating it? To what effect? An fake billing? Can't this
proxy engage in fraud with the client's MSK as well? Are you worried
about a AAA proxy doing an off-line dictionary attack against MSCHAPv2?
I suggest you refrain from doing business with the company operating
it then because you have bigger issues.

  Just out of curiosity, though, how do you propose to prevent
a proxy from seeing an MS-CHAPv2 exchange or an OTP fly by? These
tunnel methods typically terminate in devices that are also AAA
clients, and that's because people want to do this sort of thing--
terminate the tunnel locally and then forward the client's credential
on to some central clearing house for a yea or nea. Do you want to
prohibit an "inner method" from terminating on a different entity
than the "outer (tunnel) method"?

  If the client's credential needs more protection than the MSK
then why are we bothering with the tunnel method work? If you have a
pre-shared key, code, phrase, or word use EAP-pwd; if you have a
certified public key use EAP-TLS. That protects the client's credential
and regardless of where it's terminated the MSK will be seen by
intermediate proxies but so what.

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 24 Jun 2010 22:55:11 +0200

> deployments of 802.1X and EAP and I haven't seen them used anywhere.

  TTLS is in wide-spread use in many environments.

> If someone has a long-term password they're doing EAP-MSCHAPv2.

  I disagree with such a blanket statement.

> OTP.

  See above.

> Are you worried about a AAA proxy hijacking a client's OTP

  It's bad security practice to expose information that doesn't need to
be exposed.

> a proxy from seeing an MS-CHAPv2 exchange or an OTP fly by?

  The tunnel methods currently in use terminate the TLS tunnel at the
home AAA server.  No proxy sees the MS-CHAPv3 or OTP exchange.

> These
> on to some central clearing house for a yea or nea.

  Can you describe a system in wide-spread use that does this?  My
experience has been that this practice is rare. It is generally done
only within the home AAA domain, in order to enable inter-operability
with AAA servers that don't do EAP.

> Do you want to

  I think the messages are clear.  Speculation as to additional intent
is not necessary.

> intermediate proxies but so what.

  I agree with Sam on this point.

  I'm also unsure about the benefit of using a TLS-based method without
using supplicant to home AAA TLS.  Existing WiFi networks *already* use
TLS for the web pages obtained over HTTPS.  They then use WISPr to post
the passwords.  This is semantically identical to the proposal to
terminate EAP-TLS locally, and proxy the inner tunnel data.

  The reason EAP channel bindings are being proposed is that many of the
people who've deployed "local TLS + password" login methods see it as
insufficient.  They pretty much have the solution proposed by Glen, and
they want something more.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 24 Jun 2010 15:06:38 -0700 (PDT)

>   I disagree with such a blanket statement.

  I disagree with disagreements that do not provide any justification
for disagreement.

  See above.

>   It's bad security practice to expose information that doesn't need to

  No, what's bad security practice is to expose a secret which allows
an attacker to completely void the security practices engaged in by the
client and NAS! Either a proxy is trusted (to see information that is
hidden from those who are not trusted) or it's not. You can't have it
both ways.

> home AAA server.  No proxy sees the MS-CHAPv3 or OTP exchange.

  I disagree with such blanket statements. I know of implementations
of EAP tunnel methods by such vendors as Cisco that do otherwise. The
freeware hostapd software does too. Evidence abounds to contradict
you blanket statement.

> with AAA servers that don't do EAP.

  Every wireless switch product I know of has a feature where the
tunnel is terminated on the switch and the "inner method" can go
elsewhere if so configured. Look at PEAP. It's standard in the most
prevalent laptop software around and what are it's "inner methods"?
Well there's EAP-MSCHAPv2 and EAP-TLS. In other words, it's another
EAP method. And the client is speaking EAP inside of EAP because that
allows the "inner method" to be terminated somewhere else.

  Notice how the tunnel method requirements document talks about "the
inner EAP method"? It's an EAP method, not just some credential exchange,
and being an EAP method it can be sent to another device. How do you
propose that "the inner EAP method" terminate at the same place as the
tunnel?

  Can you describe current deployments of tunnel methods that terminate
everything, EAP-TLS plus some client credential authentication, at the
home AAA server?

>   I think the messages are clear.  Speculation as to additional intent

  No, the message Sam communicated was not clear. He stated a problem
and the implication of "fixing" that "problem" is, itself, a problem.
I'm not speculating on anything. I'm asking a simple question. Since
you agree with Sam on this then why don't you answer it?

  Alan, do you want to prohibit an "inner method" from terminating on a
different entity than the "outer (tunnel) method"? If the answer is yes
then I have no further questions. If the answer is no then I'd like to
know how you intend on keeping the contents of that "inner method" away
from the prying eyes of these proxy attackers?

  Dan.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 24 Jun 2010 15:45:16 -0700

There are many deployments of Tunneled EAP methods (EAP-TTLS, EAP-FAST)
where a password is sent from the client to the Authentication server
within the protected tunnel.  Terminating the tunnel somewhere other
than the home server would be bad as it would disclose this long term
secret.  

Joe  

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dan
> Harkins
> Sent: Thursday, June 24, 2010 3:07 PM
> To: Alan DeKok
> Cc: [email-masked]; Sam Hartman
> Subject: Re: [Emu] Channel Binding Discussion at IETF 77: why bother
> 
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 25 Jun 2010 08:14:18 +0900

Why can't have another EAP tunnel terminated at home authentication
server inside EAP-TTLS tunnel terminated at the visited network to
protect password end-to-end (besides additional tunneling overhead, of
course)?

Yoshihiro Ohba

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 24 Jun 2010 16:24:35 -0700 (PDT)

Hi Joe,

  Why would someone go to the expense to implement EAP-TTLS or EAP-FAST
but not also do some hash-a-password-with-nonces method like GPSK or
MSCHAPv2 that proves to the client that the server knows the password?
The only reason I can see to do PAP inside EAP-TTLS or EAP-FAST is
when using a token card or other OTP. What other reason would
someone do this? It's like driving a horse-drawn carriage instead
of a car-- "why are you still using this failed technology?" (Apologies
to the Amish on this list).

  Dan.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 24 Jun 2010 16:34:57 -0700

One reason often discussed on this list is that the passwords are not
stored in clear text or some other format that can be used with these
protocols.  

> From: Dan Harkins [mailto:[email-masked]]
> Sent: Thursday, June 24, 2010 4:25 PM
> To: Joseph Salowey (jsalowey)
> Cc: Dan Harkins; Alan DeKok; [email-masked]; Sam Hartman
> Subject: RE: [Emu] Channel Binding Discussion at IETF 77: why bother
> 
> 
>   Hi Joe,
> 
> >> >   It's bad security practice to expose information that doesn't
need
> > to
> >>   Alan, do you want to prohibit an "inner method" from terminating
on
> > a

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 24 Jun 2010 17:26:04 -0700 (PDT)

Joe,

  I'm sorry I'm being so dense.

  What is the nature of this transformed password such that it
cannot be used in those protocols yet it's still a long-term
credential whose disclosure in PAP would be tragic? That doesn't
sound like a OTP or a token card since those aren't long-term
credentials, and it doesn't sound like the transform is some
one-way function because the output of those can be used in the
protocols described below. So I'm stumped? What is this thing?

  Dan.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 24 Jun 2010 18:18:41 -0700

This is way off topic for the channel binding discussion, and has been
discussed numerous times before.  Instead of taking the list deeper into
this discussion I suggest we take this off line.

> Sent: Thursday, June 24, 2010 5:26 PM
> >> >> From: [email-masked] [mailto:[email-masked]] On
Behalf
> > Of
> >> >> >> If someone's doing PAP they're using a token card or some
type
> > of
> >> >> an attacker to completely void the security practices engaged in
by
> >> > the
> >> >> client and NAS! Either a proxy is trusted (to see information
that
> > is
> >> >> hidden from those who are not trusted) or it's not. You can't
have
> > it
> >> >> >   The tunnel methods currently in use terminate the TLS tunnel
at
> >> > the
> >> >> of EAP tunnel methods by such vendors as Cisco that do
otherwise.
> > The
> >> >> > experience has been that this practice is rare. It is
generally
> > done
> >> >> propose that "the inner EAP method" terminate at the same place
as
> > the
> >> >> everything, EAP-TLS plus some client credential authentication,
at
> > the
> >> >> >   I think the messages are clear.  Speculation as to
additional
> >> > intent
> >> >> different entity than the "outer (tunnel) method"? If the answer
is
> >> > yes
> >> >> then I have no further questions. If the answer is no then I'd
like
> > to
> >> >> know how you intend on keeping the contents of that "inner
method"
> >> > away

---

From: Alan DeKok <[email-masked]>
Date: Fri, 25 Jun 2010 03:27:12 +0200

>   I disagree with disagreements that do not provide any justification

  By the same token, your original opinion lacks justification, too.

  My opinion is based on my experiences.  As you do not share those
experiences, I understand why they would be new information.  I don't
understand why you would discount them completely as being unjustified.

> hidden from those who are not trusted) or it's not. You can't have it

  I think it's a false dichotomy to label trust as binary.  A proxy may
not be trusted with long-term secrets, because abusing those long-term
secrets is easy.  It may be trusted with short-term secrets, because
those secrets are short-term, and abusing them is difficult.

> freeware hostapd software does too. Evidence abounds to contradict

  By "in use", I meant "in practice".  This should have been obvious
from the example I gave, which you deleted.

  In case you didn't know, I've written freeware which does exactly
that: terminate the TLS tunnel, and proxy the inner data.  This
capability has driven some of the experiences noted earlier.  And I
don't think hostapd has that capability, as it's a much more limited
RADIUS server.

> elsewhere if so configured.

  Where is that used?  Within an enterprise, or as part of a roaming
consortium?

  Enterprises use it.  They are terminating the TLS tunnel in the same
administrative domain as the home AAA server.  Which means no proxying.
 I don't know of any roaming consortium which uses that capability.

> Look at PEAP. It's standard in the most

  I fail to see how using EAP in the inner tunnel is what "allows" the
inner method to be terminated elsewhere.  TTLS with PAP can be
terminated elsewhere, too.

> inner EAP method"? It's an EAP method, not just some credential exchange,

  That is not what the requirements document says.  It refers to "inner
authentication methods", and has no requirement that it be EAP.  It
*does* have requirements on the inner method if and when it is EAP.

> and being an EAP method it can be sent to another device.

  Yes... as can any other inner authentication method.

> How do you

  Pretty much the same way that people are doing it now.

> everything, EAP-TLS plus some client credential authentication, at the

  Yes.  Eduroam.  Used by tens of thousands of people world-wide.

> from the prying eyes of these proxy attackers?

  The proposal to terminate TLS on the visited network *requires* that
the users credentials are exposed all the way down the proxy chain.

  The proposal to terminate TLS on the home network *permits* the home
system to do what it wants with the user credentials.

  If you can't see a difference between the two scenarios, then there is
nothing more to discuss.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 24 Jun 2010 20:39:03 -0700 (PDT)

Alan,

> the users credentials are exposed all the way down the proxy chain.

  Wrong, it "allows the user credentials to be exposed", depending on
the EAP method.

>   If you can't see a difference between the two scenarios, then there is

  I understand the difference (obviously a bit better than you do). And I
didn't ask you to list the differences. You said that the former "fails
the privacy requirements of any TLS-based EAP method." So I asked you a
simple question. Let me rephrase it for you in the hope you will answer
it: how do you propose to prevent this REQUIREMENT from not being met?

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 25 Jun 2010 08:34:24 +0200

>   Wrong, it "allows the user credentials to be exposed", depending on

  Hmm... it requires that any user credentials in the tunnel be exposed.

> it: how do you propose to prevent this REQUIREMENT from not being met?

  The requirements are that the home system gets to choose the privacy
requirements.  If they choose to terminate TLS in the visited network,
fine.  If they choose to terminate the TLS method themselves, and then
forward the user credentials elsewhere, fine.

  In that view, your question is irrelevant.

  The alternate view, and one I'm opposed to, is that a third-party
chooses the privacy requirements for the home system.  In that view,
your question is highly relevant.  Since it's not a view I hold, I
cannot answer your question in any meaningful way.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 25 Jun 2010 10:46:41 +0200

> MSCHAPv2 that proves to the client that the server knows the password?

  Legacy password databases.

> when using a token card or other OTP.

  For enterprises, this is a reasonable assumption.  For ISPs, it's not.

  Alan DeKok.