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

[Joseph Salowey (jsalowey) (jsalowey]

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:bernard_aboba [at] hotmail.com] 
> Sent: Wednesday, April 25, 2007 8:12 AM
> To: eap [at] frascone.com
> Cc: jouni.korhonen [at] teliasonera.com
> Subject: Re: [eap] Comments on draft-ietf-eap-netsel-problem-06.txt
> 
> 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
>