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

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 30 Apr 2007 08:22:59 -0700

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:[email-masked]] 
	Sent: Sunday, April 29, 2007 11:42 PM
	To: Joseph Salowey (jsalowey); Bernard Aboba; [email-masked]
	Cc: [email-masked]
	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:[email-masked]]
	Sent:   Wednesday, April 25, 2007 09:35 PM Pacific Standard Time
	To:     Bernard Aboba; [email-masked]
	Cc:     [email-masked]
	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:[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
	>
	> 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

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

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

---

From: "Bari, Farooq" <[email-masked]>
Date: Mon, 30 Apr 2007 09:43:05 -0700

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 
[email-masked] <mailto:[email-masked]>  
+1 425 580 5526 

From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Monday, April 30, 2007 8:23 AM
To: Bari, Farooq; Bernard Aboba; [email-masked]
Cc: [email-masked]
Subject: RE: [eap] Comments on draft-ietf-eap-netsel-problem-06.txt

Joe.

	Hi Joe

	BR
	
	Farooq

	 -----Original Message-----
	From:   Joseph Salowey (jsalowey) [mailto:[email-masked]]
	Sent:   Wednesday, April 25, 2007 09:35 PM Pacific Standard Time
	To:     Bernard Aboba; [email-masked]
	Cc:     [email-masked]
	Subject:        Re: [eap] Comments on
	
	Hi Bernard,

	Joe
	
network
confidential
4284.
supports, with
privacy
authentication,
enabling
victim
peer
additional
for
an
discovery