Subject: Re: [eap] Comments on draft-ietf-eap-netsel-problem-06.txt

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 25 Apr 2007 08:11:30 -0700

Here is some text to resolve part of Joe's comments:

Add Section 3.5:

3.5  Security

   Network discovery and selection mechanisms may introduce
   new security vulnerabilities.  As noted in Section 2.3.1, network
   operators may consider the AAA routing table to be confidential
   information, and therefore may not wish to provide it to
   unauthenticated peers via the mechanism described in RFC 4284.
   While the peer could provide a list of the realms it supports, with
   the authenticator choosing one, this approach raises privacy
   concerns.  Since identity selection occurs prior to authentication,
   the peer's supported realms would be sent in cleartext, enabling
   an attacker to determine the realms for which a potential victim
   has credentials.  This risk can be mitigated by restricting peer
   disclosure.  For example, a peer may only disclose additional
   realms in situations where an initially selected identity has proved
   unusable.

   Since network selection occurs prior to authentication, it is typically
   not possible to secure mechanisms for network discovery or
   identity selection, although it may be possible to provide for
   secure confirmation after authentication is complete.  As an
   example, some parameters discovered during network discovery
   may be confirmable via EAP Channel Bindings;  others may be
   confirmed in a subsequent Secure Association Protocol
   handshake.

   However, there are situations in which advertised
   parameters may not be confirmable.  This could lead to
   "bidding down" vulnerabilities.  [RFC3748] Section 7.8 states:

     Within or associated with each authenticator, it is not anticipated
     that a particular named peer will support a choice of methods.  This
     would make the peer vulnerable to attacks that negotiate the least
     secure method from among a set.  Instead, for each named peer, there
     SHOULD be an indication of exactly one method used to authenticate
     that peer name.  If a peer needs to make use of different
     authentication methods under different circumstances, then distinct
     identities SHOULD be employed, each of which identifies exactly one
     authentication method.

In practice, where the authenticator operates in "pass-through" mode, the 
EAP method negotiation will occur between the EAP peer and server, and 
therefore the peer will need to associate a single EAP method with a given 
EAP server.  Where multiple AAA servers and corresponding identities may be 
reachable from the same selected network, the EAP peer may have difficulty 
determining which identity (and corresponding EAP method) should be used. 
Unlike network selection, which may be securely confirmed within a Secure 
Association Protocol handshake, identity selection hints provided within the 
EAP-Request/Identity are not secured.

As a result, where the identity selection mechanism described in RFC 4284 is 
used, the "hints"  provided could be used by an attacker to convince the 
victim to select an identity corresponding to an EAP method offering lesser 
security (e.g. EAP MD5-Challenge).  One way to mitigate this risk is for the 
peer to only utilize EAP methods satisfying the [RFC4017] security 
requirements, and for the peer to select the identity corresponding to the 
strongest authentication method where a choice is available.

Joe Salowey said:

I've taken a look at the draft and the one concern I have is that it
seems that security considerations are discussed rather lightly.  In
particular they are not discussed in the design considerations.

In the discussion of AAA routing it would be good to have more
discussion of the trust relationships required between AAA systems.
There is also little discussion of authenticating the network and/or
realm that is being accessed or determining that the network is
authorized to provide the services which it may claim to provide.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 25 Apr 2007 21:29:39 -0700

Hi Bernard,

This looks good for the security considerations.  In section 3.2 I think
there needs to be some discussion of authorization. Configuration of a
trust root is necessary, but not always sufficient to secure the AAA
exchange and path selection. 

Joe 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 8:12 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [eap] Comments on draft-ietf-eap-netsel-problem-06.txt
> 
> In practice, where the authenticator operates in 
> "pass-through" mode, the EAP method negotiation will occur 
> between the EAP peer and server, and therefore the peer will 
> need to associate a single EAP method with a given EAP 
> server.  Where multiple AAA servers and corresponding 
> identities may be reachable from the same selected network, 
> the EAP peer may have difficulty determining which identity 
> (and corresponding EAP method) should be used. 
> Unlike network selection, which may be securely confirmed 
> within a Secure Association Protocol handshake, identity 
> selection hints provided within the EAP-Request/Identity are 
> not secured.
> 
> As a result, where the identity selection mechanism described 
> in RFC 4284 is used, the "hints"  provided could be used by 
> an attacker to convince the victim to select an identity 
> corresponding to an EAP method offering lesser security (e.g. 
> EAP MD5-Challenge).  One way to mitigate this risk is for the 
> peer to only utilize EAP methods satisfying the [RFC4017] 
> security requirements, and for the peer to select the 
> identity corresponding to the strongest authentication method 
> where a choice is available.
> 
> Joe Salowey said:
> 
> I've taken a look at the draft and the one concern I have is 
> that it seems that security considerations are discussed 
> rather lightly.  In particular they are not discussed in the 
> design considerations.
> 
> In the discussion of AAA routing it would be good to have 
> more discussion of the trust relationships required between 
> AAA systems.
> There is also little discussion of authenticating the network 
> and/or realm that is being accessed or determining that the 
> network is authorized to provide the services which it may 
> claim to provide.
> 
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 25 Apr 2007 21:29:39 -0700

Hi Bernard,

Joe