eap Mailing List: Re: Comments on draft-ietf-eap-netsel-problem-06.txt

[Bernard Aboba (bernard_aboba]

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.