Subject: RE: [eap] Fwd: I-D ACTION:draft-adrangi-eap-network-discovery-04.txt

From: "Bari, Farooq" <[email-masked]>
Date: Wed, 13 Oct 2004 09:38:01 -0700

Hi Bernard, Jari

There were three open issues listed for this draft. All of them have now
been addressed as follows.

271- addressed per Stephen Mccann email (10/6/2004)
269 - addressed per Jari's email (10/6/2004)
256 (editorials) -  addressed in this revision of the draft.

Can we now close these issues for the draft and move forward.

Best Regards

Farooq

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jari Arkko
Sent: Tuesday, October 12, 2004 9:30 PM
To: [email-masked]
Subject: [eap] Fwd: I-D
ACTION:draft-adrangi-eap-network-discovery-04.txt

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
> 	Title		: Mediating Network Discovery in the Extensible 
> 			  Authentication Protocol (EAP)
> 	Author(s)	: F. Adrangi, et al.
> 	Filename	: draft-adrangi-eap-network-discovery-04.txt
> 	Pages		: 11
> 	Date		: 2004-10-12
> 	
> This document defines a mechanism that allows an access network to
>    provide identity selection hints to an EAP client.  The purpose is
to
>    help the client in selecting the most appropriate identity and NAI
>    decoration to use.  This solution is especially useful in roaming
>    scenarios where the access network does not have a direct
>    relationship with the client's home network, but instead a
mediating
>    network, such as a roaming consortium or broker, is used.
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-
04.txt
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Oct 2004 12:21:15 +0300

> 271- addressed per Stephen Mccann email (10/6/2004)

Confirm.

> 269 - addressed per Jari's email (10/6/2004)

Confirm.

> 256 (editorials) -  addressed in this revision of the draft.

There's part of issue 256 that does not seem to be
addressed. Or maybe the text is somewhere.

> Can we now close these issues for the draft and move forward.

I'm still missing one part of issue 256. I'll send a separate
e-mail about that.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Oct 2004 12:48:41 +0300

This is the part of Bernard's issue that I don't see
addressed in the new draft. Hopefully I just missed
some text somewhere else than in the Security Considerations
section. If not, I have a text suggestion below which
you can add & resubmit.

> Section 4
> 
> "  Identity hint information is delivered inside an EAP Identity Request
>    before the user authenticates to the network, and before the network
>    is authenticated to the user.  This information can be modified by an
>    attacker.  Therefore, it MUST be considered an unauthenticated hint
>    that does not override any local policies at the peer."
> 
> I think you need to say a bit more about what an attacker could do with
> this and the potential counter-measures.  The main threat seems to be
> discovery of the potential peer identities. If the peer is using a weak
> EAP method for some identities, this might be used by an attacker to
> steal credentials for that identity.
> 
> So you might refer to specific local policies that cannot be overriden,
> such as requiring mutual authentication, strong keys, etc.  Also, the peer
> may choose to restrict the hints to which it will respond -- a given
> identity might be locked down to a particular SSID and not given out to
> another one, regardless of the hint.

Here's suggested new formulation for Section 4:

4.  Security considerations

    Identity hint information is delivered inside an EAP Identity Request
    before the user authenticates to the network, and before the network
    is authenticated to the user.  This information can be modified by an
    attacker.  Therefore, it MUST be considered an unauthenticated hint.

    Unauthenticated hints may result in peers inadvertantly revealing
    their identities, leading to a privacy vulnerability. More seriously,
    if a weak EAP method is associated with one of the peer's identities, this
    may lead to a bidding down attack or a successful attack against
    that identity. To guard against these vulnerabilities, peers may have
    local policies that can not be overriden. Such policies may indicate,
    for instance, that a particular identity is only used together with
    a specific link-layer network or device identity and not used on others,
    despite any hints that the peer may have received. Note that while
    such policies make attacks harder, popular link layers may not
    support authentication of such link layer information, at least
    not until EAP authentication has completed. As a result, these
    vulnerabilities may remain.

    In case the identity hint information is used to select a mediating
    network for NAI decoration, it should be noted that at least with
    some EAP methods, there is no way for the home network AAA server to
    verify that the mediating network used was actually the same one that
    the peer had requested.

--Jari