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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



See inline....

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@xxxxxxxxx]
> Sent: Thursday, March 13, 2008 11:50 PM
> To: Avi Lior
> Cc: Bernard Aboba; ietf@xxxxxxxx
> Subject: EAP applicability (Was: Re: IETF Last Call on Walled
> Garden Standard for the Internet)
>
> Avi,
>
> >> 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.
> >>
> >
> > Why?
> >
>
> 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.

Okay.  So some applications are okay.  I agree we need to provide guidelines as to the shortcomings.  Let SDOs then decide what is and what is not appropriate for them to do.

The point is that the term 'applications' is rather broad.  There are many types of applications. I may agree that using EMSK to protect all applications may be a problem.  But in certain situations it could solve problems 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?
>
> 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).
>
> 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?
>
> Jari
>
>
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]