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

[Bari, Farooq (FB5431]

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

Hi Joe,

 

In section 2.3.3 we do have the following text

 

   In addition, there are few mechanisms available to audit whether the

   requested source route is honored by the AAA infrastructure.  For

   example, an access network could advertise a realm route to

   costsless.example.com, while instead routing the access-request

   through costsmore.example.com.  While the decorated NAI would be made

   available to the home AAA server in the EAP-Response/Identity, the

   home AAA server might have a difficult time verifying that the source

   route requested in the decorated NAI was actually honored by the AAA

   infrastructure.  Similarly, it could be difficult to determine

   whether QoS or other routing requests were actually provided as

   requested.  To some extent, this problem may be addressed as part of

   the business arrangements between roaming partners, which may provide

   minimum service level guarantees.

   Given the potential issues with source routing, conventional AAA

   routing mechanisms are to be preferred wherever possible.  Where an

   error is encountered, such as an attempt to authenticate to an

   unreachable realm, "realm hints" can be provided as described

   [RFC4284].  However, this approach has severe scalability

   limitations, as outlined in Appendix A.1.

 

Does it not cover the issue you are referring to? If not, can you suiggest proposed any additions to the text.

BR,

Farooq Bari
farooq.bari [at] att.com
+1 425 580 5526
 

---

From: Joseph Salowey (jsalowey) [mailto:jsalowey [at] cisco.com]
Sent: Monday, April 30, 2007 8:23 AM
To: Bari, Farooq; Bernard Aboba; eap [at] frascone.com
Cc: jouni.korhonen [at] teliasonera.com
Subject: 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