[Top] [All Lists]

Re: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)

2008-03-13 21:48:04
On 3/13/2008 8:49 PM, Jari Arkko wrote:

For what it is worth, this ex-EAP co-chair also thinks that
the use of EAP keys for applications is a very bad idea.

For a number of reasons. Take this from someone who has actually tried
to do this in the distant past and has realized that it was a bad idea.

But first let me clarify that I'm not criticizing HOKEY for EAP keys in
any way; HOKEY is a fine application for EAP keys. The document that
started this thread can be fixed by better IANA and applicability
sections. I've also changed the subject to reflect the new topic.

Back to the reasons for why application keying based on EAP is a bad
idea. First, there is an applicability statement in RFC 3748 which
discourages the use of EAP for other applications than network access.
We've generally treated this liberally and included things like VPN
access (IKEv2) and mobility services in this as well.

Use of EAP keys in other contexts than the network access itself
presents a number of problems. The primary problem is that while EAP
runs on many, many interfaces and products, the number of networks where
is still relatively small, or at least its nowhere near ubiquitous. This
presents a problem for applications that require EAP-based keys. This
hotel network supports web logins, not EAP so does that mean I would be
unable to use the EAP-based applications? And from the point of view of
an application provider, why would I want to exclude the 99.9% of
current Internet users that are not behind an EAP-based network interface?

Let us consider the opposite situation.  Let us say the hotel network 
uses EAP for authentication and the hotel front desk gives the IETF 
folks a scratch card with credentials.  We then use the credentials for 
authentication using 802.1X-EAP (example only).  The hotel or an 
associated third party also offers some services/applications and wants 
to provide them for free for the IETF folks.  However the hotel does not 
want to share the credentials with the third party server.  Sure, the 
hotel may not make this facility of key management for all application 
providers out there and this mechanism is not useful for general purpose 
application access.  Why would we force the hotel to provide multiple 
sets of credentials for each additional service/application that they 
want to provide?

Perhaps your argument is to use IKEv2-EAP in that case.  Sure, we can 
use that.  But, why not use the optimization when it is available?  Why 
force IKEv2 again?  Please see below for additional notes.

The conclusion from this is that application keying should be arranged
independently of network access. Note that in some cases you can use the
same credentials to access a particular application, even if you are not
reusing keys from the network access phase. For instance, IKEv2 and its
EAP capability has been used in some mobility designs. But this is an
independent run of EAP, nothing to do with the network access EAP run
(if there even was one).

This is an interesting distinction and I would really like to understand 
the logic behind the restriction.

Using key material derived from the EMSK, derived after network access 
authentication using an EAP method for applications is not ok.

However using the MSK from an EAP method run over IKEv2 for applications 
is ok.

Are you saying that a fresh verification of possession of long term 
credentials is necessary for application access?

Or does this have to do with some access technologies not choosing to 
adopt our protocol, EAP and us trying to optimize for those situations? 
  If the latter, why wouldn't we add features to our protocols and 
increase adoption of our protocols?  Or, perhaps we are suggesting that 
other people should not be using EAP and build their own mechanisms.

Please clarify.

Finally, many of the things that you want to do are impossible if you
tie your applications to network access keys. For instance, if you are
mobile you would ideally want to move from one access network to
another. What if one of these access networks does not support EAP for
network access. E.g., Wimax -> 3G? What would this do to your ability to
use an application?

 From what I know Wimax and 3GPP2 use EAP.  3GPP does not.  We should 
optimize for access networks that use our protocols.  When the user does 
roam to a non-EAP capable network, we force them to use IKEv2-EAP and 
they bear the cost of IKEv2 and an EAP method run.



IETF mailing list

IETF mailing list

<Prev in Thread] Current Thread [Next in Thread>