iQA/AwUBPIOR/DN1fXKoxmisEQIzEwCeJTz1HdajikwCyyZdmZRSP3AC5rkAnRq5
R6tYe21/znRpMA4JcQ2tVFIY
=Wx64
-----END PGP SIGNATURE-----
------_=_NextPart_001_01C1C390.DCA17400
Content-Type: text/html
RE: [eap] RE: Suggested work item for EAP WG Charter
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The point here is that there is only so much that can be done with
the RADIUS protocol, while still being able to call it RADIUS. If
changes to a protocol modify it's behavior completely (meaning more
than just adding new attributes), then the current deployment of
RADIUS servers is useless anyways, and an upgrade is required.
PatC
- -----Original Message-----
From: Walker, Jesse [mailto:jesse.walker@intel.com]
Sent: Monday, March 04, 2002 7:18 AM
To: Pat R. Calhoun; 'eap@frascone.com'
Subject: RE: [eap] RE: Suggested work item for EAP WG Charter
Pat,
Your suggestion to work this within the context of DIAMETER has great
merit. My only concern with it is that RADIUS vendors fully intend to
support 802.1X and 802.11, and 802.11 vendors fully intend to rely on
this support. This means that either RADIUS would need to be upgraded
to accommodate the needs of keying, or else the issue has to be
brought out into the open so that people would know not to try to
deploy products in this configuration, at least when their goal is
security.
- -- Jesse
- -----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com]
Sent: Saturday, March 02, 2002 2:22 PM
To: 'eap@frascone.com'
Subject: [eap] RE: Suggested work item for EAP WG Charter
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> The most critical issue still confronting IEEE 802.11 TGi is how to
> accomplish dynamic key distribution securely. TGi has done much
> good work on how to effect key distribution between the 802.11
> access point and station, but this architecture requires at least
> one key distribution from an 802.1X authentication server to the
> access point. Today this is done using RADIUS, based on ad hoc
> techniques. These techniques cannot securely distribute a key for
> its intended purpose. In particular, existing RADIUS techniques
> may be suitable for handing off a key between the authentication
> server and the access point, intended for communication between
> themselves alone, but as constituted today they are insecure for
> transferring a session key intended for use between the access
> point and the station. To become secure the key handoff has to be
> enhanced to incorporate additional cryptographic state that can be
> used to provide assurances to all three parties involved in the
> transaction. Examples of such state are the information
> communicated among the KDC and the communicating parties in the
> Needham-Schroeder and Otway-Rees protocols.
But the EAP WG is really not the right place to be working on AAA
protocols. In fact, I would urge you to take a look at the Diameter
protocol, currently being standardized by the AAA WG. The NASREQ
application document already describes how such session keys can be
transferred to the access point in a secure fashion (using CMS as the
cryptographic protocol).
> As of now IEEE 802.11 TGi has no legitimate forum for this
> discussion. IEEE 802.11 TGi cannot solve the backend key handoff
> methodology itself, because the communication among the backend
> components is outside its scope. A second plausible venue--IEEE
> 802.1 TGaa, chartered with fixing identified 802.1X problems--also
> lacks the necessary charter to tackle the backend. On the other
> hand, it is infeasible for TGi to finish the design of the
> handshake between the access point and the station without
> relating this handshake to the backend key distribution, which
> cannot be done until it is defined.
Right, and I would urge folks not to attempt to tackle this in the
IEEE SDO, since it is really a L3+ problem, and work is already in
progress... What we would really like is for folks to comment on the
draft which is about to go through another WG last call.
> My fear is that if we do not find a venue for this work, we will
> squander all the valuable work that IEEE 802.11 TGi has done to
> rectify WEP's deficiencies, and 802.11 security will remain no
> better than the tarball the 1999 version of the 802.11 standard
> has bequeathed us. The EAP WG seems a natural home for it. Please
> consider including this work in the EAP charter, and let me know if
> there is anything I can do to help achieve this goal.
I agree
PatC
- -----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use
<http://www.pgp.com>
iQA/AwUBPIFQkDN1fXKoxmisEQJjrACfWU6lDbDvnMJqWrkjehDs1sUFUz0AoIbk
KrLI6yBZv5W3diNoBGbfZ7rL
=n34F
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPIOR/DN1fXKoxmisEQIzEwCeJTz1HdajikwCyyZdmZRSP3AC5rkAnRq5
R6tYe21/znRpMA4JcQ2tVFIY
=Wx64
-----END PGP SIGNATURE-----
------_=_NextPart_001_01C1C390.DCA17400--
From jesse.walker@intel.com Mon Mar 4 18:20:59 2002
From: jesse.walker@intel.com (Walker, Jesse)
Date: Mon, 4 Mar 2002 10:20:59 -0800
Subject: [eap] Suggested work item for EAP WG Charter
Message-ID: <10C8636AE359D4119118009027AE9987120B833A@FMSMSX34>
Glen,
>> In particular, existing RADIUS
>> techniques may be suitable for handing off a key between the
>> authentication
>> server and the access point, intended for communication between
themselves
>> alone, but as constituted today they are insecure for
>> transferring a session
>> key intended for use between the access point and the station. To become
>> secure the key handoff has to be enhanced to incorporate additional
>> cryptographic state that can be used to provide assurances to all three
>> parties involved in the transaction.
>
>Please explain why you think that this is so, and if it is, why this
>communication is not coming from the chair of TGi. I ask this because I,
>for one, am unaware of any discussion within TGi taht even imply that this
>is a requirement. Given that the AS and AP trust each other (assumed), why
>is a reasonable cryptographic protocol (such as CMS or even IPSec) is
>insufficient to protect the transfer of a STA-AP session key from the AS to
>the AP?
There has been in fact ample discussion around exactly these points. There
is, for instance, the whole key handoff discussion, of which AS-AP handoff
is a special case. As a second example, there is the flap around the
Arbaugh-Mishra 802.1X paper, which echos many of our key handoff
discussions, and which we have also discussed.
But even if we had never discussed these points before, we would be forced
to if the issue were raised; if someone perceives holes in our security,
then these have to be addressed, and making an appeal that this wasn't ever
an issue before doesn't help.
I don't buy the assumed trust argument, because it is not specific enough to
offer any useful insight. Let me respond to it by asking why should we
assume the AS and the AP trust each other, and, more to the point, for what
purpose should they trust each other? I think the correct assumptions are
something like
a. The AS and the AP share a key used for key distribution, and that both
parties can be trusted to use this key for no other purpose, and to expose
it to no other parties;
b. The AS can be trusted to distribute a fresh key whenever it distributes a
key.
Why should we assume substantially more about the AP-AS relationship? Each
assumption represents a new point of attack if compromised, so we would do
well to think about eliminating as many assumptions as possible.
Protocols exist that would allow us to reduce the number of assumptions we
make by incorporating explicit verification in place of trust assumptions.
It is feasible to add protocol state allowing the AS to verify that the key
distribution request really did originate with a legitimate station and not
as the result of a rogue AP or a rogue station. It is feasible for both the
AS and the station to verify that the key distribution is live, even though
they can't verify it is fresh (that's why we have to make the second trust
assumption). It is feasible for both the AP and the station to verify that
the AS intended to distribute this particular key to this particular pair, i.e., that each is talking to the other intended recipient of
the key, and to no one else, and for the protocol to protect against either
the AP or the station cheating (except by exposing a key). The existing
method of throwing keys over the fence to the AP does not have any of these
guarantees built in, so we have to assume much more to use it. Each such
assumption may reasonable in a sufficiently constrained environment, but I
question whether together they are reasonable in a network as open as a
WLAN.
And I don't buy basing the security on mechanisms like IPsec. By definition,
IPsec provides bilateral security between the two parties sharing a security
association, and binds only the two together. A key distribution protocol of
the sort we are discussing is not a bilateral relationship. Key distribution
is a trilateral relationship among three parties--the AS, the AP, and the
station--and because of this will have to cryptographically bind the three
parties together somehow to be secure, i.e., to minimize points to attack.
You can replace IPsec by any other bilateral security protocol, and the same
argument obtains.
My position is that it would be prudent for us to look at adapting a key
distribution protocol that reduces our exposure by minimizing security
assumptions. I believe this because we are building systems that expose many
more attack points than in the past. Indeed, I think the burden of proof is
on the other foot: what leads us to think the special conditions and
circumstances and topologies that permitted security shortcuts in the past
are still applicable in the more fragile environments we are building today?
Why should the mechanisms that worked in more restricted environments still
be applicable unchanged when moved into new environments that, on the
surface at least, seem to violate many of the assumptions we made before?
>> Examples of such state are the
>> information communicated among the KDC and the communicating
>> parties in the
>> Needham-Schroeder and Otway-Rees protocols.
>>
>> As of now IEEE 802.11 TGi has no legitimate forum for this
>> discussion. IEEE
>> 802.11 TGi cannot solve the backend key handoff methodology
>> itself, because
>> the communication among the backend components is outside its scope.
>
>Yes, and it's not even clear that this is requiredA
We will simply have to agree to disagree on this point.
-- Jesse
From aboba@internaut.com Mon Mar 4 17:47:37 2002
From: aboba@internaut.com (Bernard Aboba)
Date: Mon, 4 Mar 2002 09:47:37 -0800 (PST)
Subject: [eap] Suggested work item for EAP WG Charter
In-Reply-To: <10C8636AE359D4119118009027AE9987120B833A@FMSMSX34>
Message-ID:
Since this discussion directly relates to a chartered work item of an
existing IETF WG (AAA), I am going to ask that discussion be moved to the
AAA WG mailing list. An issue has been filed against the NASREQ
specification relating to this, and mail on this thread has been forwarded
to the AAA WG list.
From jrv@interlinknetworks.com Mon Mar 4 23:28:22 2002
From: jrv@interlinknetworks.com (John Vollbrecht)
Date: Mon, 04 Mar 2002 18:28:22 -0500
Subject: [eap] EAP changes possibilities
Message-ID: <3C840316.6EE3DC13@interlinknetworks.com>
EAP – Issues and Suggestions for EAPng
The following is for discussion as part of the EAP BOF. I have included
suggestions for change to EAP and to best practices for Network Access
Devices that translate EAP messages from one carrier protocol to
another.
-----
EAP common use is in situations where a Client attaches to a Network
Access Device (NAD – also known as NAS, AP, Edge device, --) and
authenticates to an Authoriziation server (AS – e.g. RADIUS server,
Diameter Server, COPS PDP, ---).
Use in dial access with PPP and in wireless LANS with 802.1x is common,
and proposals for use with SIP, MobileIP, and even EAP over UDP are
proposed. Transport of EAP over RADIUS, Diameter, COPS, SIP, UDP is in
production or proposed.
The standard picture is something like the following, with different
names for different players depending on the application.
Client ---------------- NAD ------------------AS
1. Who’s talking to who
EAP is designed to be a Point to Point protocol. By this I mean that it
has no addressing capability, and an EAP packet sent from Client to NAD
(e.g. over PPP) is forwarded to an AS (e.g. in a RADIUS packet). The
NAD knows somehow which AS to forward the EAP message to, normally the
same place the access request is sent.
In practice, the NAD will initiate and send an EAP message to the Client
to get its identity. This is needed in order to determine where an
access request should be sent.
This could be considered a separate EAP exchange from the later exchange
between the Client and AS.
The sequence of exchanges is as follows.
Client ---------------- NAD ------------------ AS
<- [identity]->
<---------[authentication] ------------>
1.1 Suggestion for change in EAPng:
I would like to see EAPng have a way to indicate that an exchange is
local (between NAD and Client) or standard (between AS and Client). One
possibility would be to define an additional set of EAP Codes for
local. For example:
0 Request
1 Response
2 Success
3 Failure
101 Local Request
102 Local Response
103 Local Success
104 Local Failure
-----------------------------------------------------
2. What exchanges happen in an Access Control Dialog
a) Client /NAD
Initial Identity exchange
Final Success/Failure of method
b) Client /AS
EAP methods (may include key generation)
c) NAD /AS (not EAP)
Initial Authorization Request
Authorization result (may include Key transport from AS to
NAD)
2.1 Suggestions for change in RFC 2869 (and for inclusion in other best
practices for handling AP in NADs.)
a) Do not include EAP Identity response in initial Authorization request
from NAD to AS
b) Do not send success or failure from AS. Send Accept or Reject RADIUS
message (or equivalent). This message will also carry Key from AS to NAD
if necessary
c) NAD always creates Success or Failure EAP message locally, and sends
to Client..
---------------------------------------------------------
3. Mutual Authorization
A Client should be able to initiate an EAP exchange to the AS. With PPP
it is possible for either the client or the server or both to require
the other to authenticate itself. In 802.1x it is not clear (to me at
least) how the client can require the server to authenticate. A number
of mutual authentication methods have been published which make this
less of a problem. Still it seems reasonable to allow the client to
initiate an EAP method (in the simple case, just an Identity request for
example).
3.1 Suggestion
Allow the client to send an EAP request after receiving a “normal”
request from the AS. The reason for waiting till it receives a request
is to be sure that there is a path to the AS for it to use. The Request
from the Client to the AS MAY allow the Reply to be piggybacked with it
in the carrier protocol. This would mean that a multiple EAP messages
might be carried in a RADIUS packet. I am guessing the piggybacking
idea will be controversial, but I would like to consider it.
---------------------------------------------------------------
4. Sequential EAP methods
EAP provides a way for the AS and Client to authenticate each other and
possibly to do other authorization checks. It is possible for the
server to do a sequence of methods (e.g. Identity followed by MD5).
What is difficult is for the AS that it is ok if the Client is ok. This
is especially important if the Client is doing a parallel and
independent set of checking methods.
4.1 Ok with me if its ok with you method
To deal with this I suggest that a new method be developed in which the
response is an ACK or NAK, but which might be delayed while the other
end continues with additional methods.
-----------------------------------------------
I would lappreciate comments on these suggestions. The actual changes
to the protocol would be small, but I think they would both clarify
useage and create the possibility of using EAP at access time for doing
things like negotiating QoS requirements for the Client.
-- John
From DReeder@flarion.com Fri Mar 8 00:07:28 2002
From: DReeder@flarion.com (David Reeder)
Date: Thu, 7 Mar 2002 19:07:28 -0500
Subject: [eap] Notes on rfc2284bis-02
Message-ID: <8C92E23A3E87FB479988285F9E22BE4647D1CB@ftmail>
I am relatively new to this discussion, apologies if any of the
following issues have already been treated or solved. My sense is
EAP is a work in progress and that some of the following obseravtions
may be useful. Most are well-contained notes about the details in
the draft.
ISSUE #1 -- Request/Response Type namespace:
Advisable to introduce some growing room in the Type namespace
given at the top of Section 5 ("Initial EAP Request/Respose
Types"). Types 1-3 are EAP control messages, wherease Type 4 is
the beginning of the list of authentication types.
Clearly EAP is yet incomplete and is likely to grow (possibly in
state, operational details and header fields). Why not set the
first authentication type at some higher number (25? 50?). This
leaves room for new control types. Eg, new Types may be needed
for key management.
ISSUE #2 -- NAK lists ordered alternatives:
Would it be conveient for the NAK (Section 5.3) to return an
ordered list of authentication types, instead of just one? Thus
both the Peer and Authenticator have more choice as the list of
authentication types grows. The list might provide an indicator of
security/access policy -- eg, specify a list such as: #1 IKE, #2
OTP, #3 MD5-Challenge. The Authenticator could immediately
downgrade to #3 if it is too busy and SLA with the Peer allows it.
ISSUE #3 -- Multi-message authentication exchanges:
It is not clear how EAP will handle Request/Response Types which,
themselves, consist of multi-message exchanges. Eg, IKE requires
3-6 messages. Is Code "Request" always used for messages initiated
by the Authenticator, and Code "Response" for all messages from the
Peer? How does the identifier change (or not) during the exchange?
Assume that it does not change and instead rely on sequence numbers
within the given authentication protocol?
ISSUE #4 -- Peer plays active as well as passive role:
Seems like there should be a clear means for Peer to initate an
exchange with Authenticator, rather than having to wait for a
Request. This is most important if (eg) a mobile device wishes to
have mutual authentication with an access router even though they
share no other acceptable authentication method besides MD5-Challenge.
More sophisticated authentication methods (IKE, TLS) support mutual
authentication no matter who begins the exchange, so this may not
be a problem in those cases. Though if it is arbitrary who begins the
exchange for these methods, it could be convenient for the Peer to
begin the exchange once it detects (eg) an access router advertisement.
ISSUE #5 -- Division of labor with PANA WG:
There appears to be important overlap between the charters of the
PANA and proposed EAP WGs. (Not to mention other WGs such as
IPSRA.) This overlap may be removed by collapsing one group into
the other, or by clearly distinguishing the role of each.
Seems like WG roles might be distinguished very simply:
. PANA is concerned with the transport layer(s) of EAP;
. EAP is concerned with everything else, and is transport agnostic.
Following this guideline, PANA should defer any questions about
security (key management, replay protection, &c), protocol state
machines, retry mechanisms and robustness of the authentication
exchange to EAP. EAP should, in turn, defer any interactions
between itself and the layer at which it is transported to PANA.
Acting on such guidelines would significantly shrink the PANA
charter, and in turn, possibly indicate that Section 3
("Media-specific issues") be separated out of the BIS draft into a
separate document for further specification and maintenance by PANA.
david
..........................................................................
David Reeder 908/947-7075 804a 2990 2490 47c3 8ef1
23be 39ce d1f5 56c0 a5c5
From aboba@internaut.com Fri Mar 8 00:48:10 2002
From: aboba@internaut.com (Bernard Aboba)
Date: Thu, 7 Mar 2002 16:48:10 -0800 (PST)
Subject: [eap] Re: Notes on RFC 2284bis
In-Reply-To: <8C92E23A3E87FB479988285F9E22BE4647D1CB@ftmail>
Message-ID:
> EAP is a work in progress and that some of the following obseravtions
> may be useful.
Actually, RFC 2284 is an IETF Proposed Standard, and thus is not a "work
in progress". As a result, RFC 2284bis is about clarifying the
specification while remaining backwards-compatible with RFC 2284. So this
is not a "greenfield" effort.
> Why not set the
> first authentication type at some higher number (25? 50?).
Because changing existing authentication types would be incompatible with
RFC 2284, and existing Method Types allocated by IANA.
> Would it be conveient for the NAK (Section 5.3) to return an
> ordered list of authentication types, instead of just one?
This might be possible while retaining backward compatibility, as long as
existing implementations won't discard the NAK packet as a
result. This would imply that a peer sending a list of authentication
types in the NAK, instead of just one, might get back a type it didn't put
in the list, because the other implementation only read the first NAK type
and didn't go farther.
> It is not clear how EAP will handle Request/Response Types which,
> themselves have multiple roundtrips.
Existing EAP methods handle this today. See RFC 2716 for an example.
> Is Code "Request" always used for messages initiated
> by the Authenticator, and Code "Response" for all messages from the
> Peer?
Yes.
> How does the identifier change (or not) during the exchange?
We could use more detail on this, I think. Most implementations I have
seen increment the Identifier.
> Assume that it does not change and instead rely on sequence numbers
> within the given authentication protocol?
Some protocols do use "Parts" but I have so far not seen sequence numbers.
> Seems like there should be a clear means for Peer to initate an
> exchange with Authenticator, rather than having to wait for a
> Request.
EAP is a peer-to-peer protocol. So it's quite feasible for one party to
initiate to the other or vice versa. In other words, there's no reason
that a NAS couldn't be a peer, and a host couldn't be the authenticator.
> This is most important if (eg) a mobile device wishes to
> have mutual authentication with an access router even though they
> share no other acceptable authentication method besides MD5-Challenge.
Since EAP is peer to peer, it's quite feasible for each side to do an
MD5-Challenge authentication to the other (although you have to be wary of
reflection attacks).
> EAP is concerned with everything else, and is transport agnostic.
One of the goals of RFC 2284bis is to lay out the requirements that EAP
has on the lower layers, and make the protocol more media
independent. Assuming this can be achieved, then other WGs and
standards bodies can successfully adapt EAP for use with other media and
transports.
An example of some of the problems we have in this regard are the RFC 2284
references to "alternate indications" of success/failure. These are
problematic because not all lower layers provide these indications; also
the implementation surveys indicate that few if any implementations
actually take these indications into account. However, the lack of an ACK
for Success/Failure packets was built on the assumption that "alternate
indications" would be available. Thus the discussion about creating new
ACK'd EAP Types for Success and Failure.
> Following this guideline, PANA should defer any questions about
> security (key management, replay protection, &c), protocol state
> machines, retry mechanisms and robustness of the authentication
> exchange to EAP.
I think that makes sense. We already have enough trouble rationalizing
a potential EAP state machine with the 802.1X state machine. Thankfully,
Bill Arbaugh's group at University of Maryland has signed up to tackle
this. Creating yet another potentially incompatible state machine would
make their job that much harder.
> EAP should, in turn, defer any interactions
> between itself and the layer at which it is transported to PANA.
I suspect that PANA is not concerned about EAP transport over *all* lower
layers, just IP, correct?
> Acting on such guidelines would significantly shrink the PANA
> charter, and in turn, possibly indicate that Section 3
> ("Media-specific issues") be separated out of the BIS draft into a
> separate document for further specification and maintenance by PANA.
I'm not clear why PANA would be concerned with how EAP is transported over
PPP and IEEE 802. Can you explain?
From weiwang@interlinknetworks.com Mon Mar 11 06:15:21 2002
From: weiwang@interlinknetworks.com (Wei Wang)
Date: Mon, 11 Mar 2002 01:15:21 -0500
Subject: [eap] A suggestion for extensibility of EAP
Message-ID: <3C8C4B79.1060307@interlinknetworks.com>
I don't know if this has been suggested already. Also, I am new
to the list and haven't gone through the archived messages yet.
What I would like to suggest is to add one EAP type, which would
do the following:
1. Negotiate authentication methods for, potentially, mutual
and asymmetrical authentication.
2. Negotiate key generation algorithm(s), which may also be
asymmetrical, if needed.
There are examples of existing mutually authenticating EAP types
that generate encryption keys for use in WEP sessions. However,
for extensibility, it seems to make sense to allow such key
generation be separated from authentication.
Also, this should allow a much larger EAP type coding space for
adding new authentication types.
Regards,
--
Wei Wang mailto:weiwang@interlinknetworks.com
Interlink Networks, Inc. http://www.interlinknetworks.com
From paul@funk.com Wed Mar 13 07:18:17 2002
From: paul@funk.com (Paul Funk)
Date: Wed, 13 Mar 2002 02:18:17 -0500
Subject: [eap] latest EAP-TTLS draft
Message-ID: <4.1.20020313021539.02cd1690@mail.funk.com>
--=====================_-1960140844==_.ALT
Content-Type: text/plain; charset="us-ascii"
Unfortunately, I was late in submitting the most recent EAP-TTLS
draft, so it didn't make it to the drafts site in time for next week's
meeting.
If you're interested in reading it before the meeting, it can be found
at:
http://www.funk.com/NIdx/draft-ietf-pppext-eap-ttls-01.txt
Thanks,
Paul
Paul Funk
Funk Software, Inc.
617 497-6339
paul@funk.com
--=====================_-1960140844==_.ALT
Content-Type: text/html; charset="us-ascii"
Unfortunately, I was late in submitting the most recent EAP-TTLS
draft, so it didn't make it to the drafts site in time for next week's
meeting.
If you're interested in reading it before the meeting, it can be found
at:
http://www.funk.com/NIdx/draft-ietf-pppext-eap-ttls-01.txt
Thanks,
Paul
Paul Funk
Funk Software, Inc.
617 497-6339
paul@funk.com