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

[Joseph Salowey (jsalowey) (jsalowey]

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

Sorry, the section should be 2.3.   Just because you have a trusted root certificate and can authenticate the identity of a AAA server does not mean that the AAA server should be authorized to be part of the AAA chain.   The same goes for source routing, just because a client specifies a particular path it should be allowed. 

 

Joe.

---

From: Bari, Farooq [mailto:FB5431 [at] att.com]
Sent: Sunday, April 29, 2007 11:42 PM
To: Joseph Salowey (jsalowey); Bernard Aboba; eap [at] frascone.com
Cc: jouni.korhonen [at] teliasonera.com
Subject: Re: [eap] Comments on draft-ietf-eap-netsel-problem-06.txt

Hi Joe

I did not understand your comment within the context of section 3.2 which is on backward compatibility. Can you expand on your comment or propose some wording so that we are able to better understand it.

BR

Farooq


Sent by GoodLink (www.good.com)


 -----Original Message-----
From:   Joseph Salowey (jsalowey) [mailto:jsalowey [at] cisco.com]
Sent:   Wednesday, April 25, 2007 09:35 PM Pacific Standard Time
To:     Bernard Aboba; eap [at] frascone.com
Cc:     jouni.korhonen [at] teliasonera.com
Subject:        Re: [eap] Comments on draft-ietf-eap-netsel-problem-06.txt

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
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

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