|
List Info
Thread: Re: Comments on draft-ietf-eap-netsel-problem-06.txt
|
|
| Re: Comments on
draft-ietf-eap-netsel-problem-06.txt |
 
United States |
2007-04-30 10:22:59 |
|
| 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.
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) [cisco.com">mailto:jsalowey cisco.com]
Sent:
Wednesday, April 25, 2007 09:35 PM Pacific Standard
Time
To: Bernard Aboba;
eapfrascone.com
Cc: ;
jouni.korhonenteliasonera.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 [hotmail.com">mailto:bernard_abobahotmail.com]
>
Sent: Wednesday, April 25, 2007 8:12 AM
> To: eapfrascone.com
>
Cc: jouni.korhonenteliasonera.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 | |