|
List Info
Thread: Proposed Resolution to Issue 365: Ambiguous Use ofIdentifier
|
|
| Proposed Resolution to Issue 365:
Ambiguous Use ofIdentifier |
|
2006-06-09 17:35:34 |
Hi Bernard,
I think this looks better with respect to identifier
terminology.
Additional comments and questions in line below:
> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba hotmail.com]
> Sent: Sunday, June 04, 2006 5:48 PM
> To: bernard_abobahotmail.com; eapfrascone.com
> Subject: Re: [eap] Proposed Resolution to Issue 365:
> Ambiguous Use ofIdentifier
>
> Looking over the proposed resolution, I think we can
make it
> moreclear that
> we are not talking about replacing endpoint addresses
with
> names. How about
> this?
>
> "2.2.2. Authenticator and Peer Identification
>
> The EAP method conversation is between the EAP peer and
server. The
> authenticator identity, if considered at all by the EAP
method, is
> treated as an opaque blob for the purposes of Channel
Bindings (see
> Section 5.12). However, the authenticator identity is
important in
> two other exchanges - the AAA protocol exchange and the
Secure
> Association Protocol conversation.
>
> The AAA conversation is between the EAP authenticator
and the backend
> authentication server. From the point of view of the
backend
> authentication server, EAP keying material and
parameters are
> transported to the EAP authenticator identified by the
NAS-Identifier
> attribute. Since an EAP authenticator MUST NOT share
EAP keying
> material or parameters with another party, if the EAP
peer or backend
> authentication server detects use of EAP keying
material and
> parameters outside the scope defined by the
NAS-Identifier, the
> keying material MUST be considered compromised.
>
[Joe] The section should clarify that the keying material
refers to keys
derived from the EAP MSK that are transmitted to the
authenticator.
Is it possible for an authenticator to be distributed across
several
devices? If so then the NAS identifiers may not be the best
choice in
these cases. Also what should be used in the Security
association
protocol if there is no AAA client (collocated
authenticator)?
> The Secure Association Protocol conversation is between
the peer and
> the authenticator. For lower layers which support key
caching it
> is particularly important for the EAP peer,
authenticator and backend
> server to have a consistent view of the usage scope of
the transported
> EAP keying material. In order to enable this, it is
RECOMMENDED
> that the Secure Association Protocol explicitly
communicate the
> usage scope of the EAP keying material passed down to
the lower
> layer, rather than implicitly assuming that this is
defined by
> the authenticator and peer endpoint addresses.
>
> Since an authenticator may have multiple ports, the
scope of the
> authenticator key cache may not be described by a
single endpoint
> address. Similarly, where a peer may have multiple
ports and
> sharing of EAP keying material and parameters between
peer ports
> of the same link type is allowed, the extent of the
peer key cache
> cannot be communicated by using a single endpoint
address.
> Instead, it is RECOMMENDED that the EAP peer,
authenticator and server
> consistently identify themselves utilizing explicit
identifiers that
> SHOULD be distinct from endpoint addresses or port
identifiers
> (e.g. IP or MAC addresses).
>
> AAA protocols such as RADIUS [RFC3579] and Diameter
[RFC4072] provide
> a mechanism for the identification of AAA clients;
since the EAP
> authenticator and AAA client are always co-resident,
this mechanism
> is applicable to the identification of EAP
authenticators.
>
> RADIUS [RFC2865] requires that an Access-Request packet
contain one
> or more of the NAS-Identifier, NAS-IP-Address and
NAS-IPv6-Address
> attributes. Since a NAS may have more than one IP
address, the
> NAS-Identifier attribute is RECOMMENDED for explicit
identification
> of the authenticator, both within the AAA protocol
exchange and
> the Secure Association Protocol conversation.
>
> It is possible for problems to arise in situations
where the
> backend server identifies itself differently to the EAP
peer
> and authenticator (e.g. where the Server-Id and backend
authentication
> server identity differ).
[Joe] It would seem that currently they almost always differ
since the
back end server is identified by the IP address to the
authenticator and
by the EAP method to the peer. What problems are you
referring to?
> Problems which may arise where the peer and
> authenticator implicitly identify themselves using
endpoint addresses
> include the following:
>
> [a] It may not be obvious to the peer which
authenticator ports are
> associated with which authenticators. The EAP peer
will be unable
> to determine whether EAP keying material has been
shared outside
> its authorized scope, and needs to be considered
compromised. The
> EAP peer may also be unable to utilize the
authenticator key cache
> in an efficient way.
>
> [b] It may not be obvious to the authenticator which
peer ports are
> associated with which peers. As a result, the
authenticator may
> not be able to enable a peer to communicate with it
utilizing
> multiple peer ports.
>
> [c] It may not be obvious to the peer which
"virtual authenticator" it
> is communicating with. For example, multiple
"virtual
> authenticators" may share a MAC address, but
utilize different
> NAS-Identifiers.
>
> [d] It may not be obvious to the authenticator which
"virtual peer" it
> is communicating with. Multiple "virtual
peers" may share a MAC
> address, but utilize different Peer-Ids.
>
> [e] It may not be possible for the EAP peer and server
to verify the
> authenticator identity via channel bindings.
>
> For example, problems [a], [c] and [e] occur in
[IEEE-802.11i], which
> utilizes peer and authenticator MAC addresses within
the 4-way
> handshake. Problems [b] and [d] do not occur since
[IEEE-802.11i]
> only allows a peer to utilize a single port.
>
> The following steps enable lower layer identities to be
securely
> verified by all parties:
>
[Joe] What does lower layer identities mean in this case?
Does this
mean peer, authenticator and port identities?
> [a] Specifying the lower layer parameters used to
identify the
> authenticator and peer;
>
> [b] Communicating the lower layer identities between
the peer and
> authenticator within phase 0;
>
> [c] Communicating the lower layer authenticator
identity between the
> authenticator and backend server within the
NAS-Identifier
> attribute;
>
[Joe] Is this necessary or desirable? If the AAA server
does not
already what the NAS-ID associated with the NAS, is it OK
for the NAS to
assert this? If the NAS can assert whatever it wants why
are we
bothering to do channel bindings?
> [d] Including the lower layer identities within Channel
Bindings (if
> supported) in phase 1a, ensuring that they are
communicated between
> the EAP peer and server;
>
> [e] Supporting the integrity-protected exchange of
identities within
> phase 2a;
>
> [f] Utilizing the advertised lower layer identities to
enable the peer
> and authenticator to verify that keys are maintained
within the
> advertised scope;"
>
>
>
____________________________________________________________
_____
> 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
|
|
| Proposed Resolution to Issue 365:
Ambiguous Use ofIdentifier |
|
2006-06-12 03:32:13 |
> > The AAA conversation is between the EAP
authenticator and the backend
> > authentication server. From the point of view of
the backend
> > authentication server, EAP keying material and
parameters are
> > transported to the EAP authenticator identified by
the NAS-Identifier
> > attribute. Since an EAP authenticator MUST NOT
share EAP keying
> > material or parameters with another party, if the
EAP peer or backend
> > authentication server detects use of EAP keying
material and
> > parameters outside the scope defined by the
NAS-Identifier, the
> > keying material MUST be considered compromised.
> >
>
>[Joe] The section should clarify that the keying
material refers to keys
>derived from the EAP MSK that are transmitted to the
authenticator.
Why are the considerations different for EMSK derived keys?
The AAA server
still has to know who the keys are being sent to, or they
can't be delivered
(e.g. a proxy could be in the path). The NAS-Identifier
attribute tells the
AAA server who that destination is.
>Is it possible for an authenticator to be distributed
across several
>devices? If so then the NAS identifiers may not be the
best choice in
>these cases. Also what should be used in the Security
association
>protocol if there is no AAA client (collocated
authenticator)?
The authenticator can only be distributed if the peer and
server see it as a
single entity, so that there is no indication that the
keying material has
been shared outside of the legal scope, which is defined by
the
NAS-Identifier. If the keys are passed among entities that
are identified
as distinct authenticators, then the peer and server will
detect that the
keys have been compromised.
For example, it's ok for an authenticator's ports to be
identified by
distinct MAC addresses or IP addresses. Since an
authenticator can have
multiple ports. use of a different port authenticator
doesn't imply a
different authenticator. But if multiple authenticators
with different
NAS-Identifiers possess the same key, then that indicates
that those keys
have been compromised.
> > It is possible for problems to arise in situations
where the
> > backend server identifies itself differently to
the EAP peer
> > and authenticator (e.g. where the Server-Id and
backend authentication
> > server identity differ).
>
>[Joe] It would seem that currently they almost always
differ since the
>back end server is identified by the IP address to the
authenticator and
>by the EAP method to the peer. What problems are you
referring to?
The issue arises in situations where an entity needs to
retrieve a key from
the AAA server. Since all AAA servers can't be assumed to
share a key
cache, the specific server on which the key resides needs to
be identified.
A peer cannot ask an authenticator to retrieve a key unless
it can provide
both the Key Name and the server from which it needs to be
retrieved. In
effect, the Peer-Id and Server-Id need to be part of the Key
Name.
However, an authenticator cannot retrieve a key from the
server if it has no
way of mapping the Server-Id to a server that it recognizes.
In Diameter, server can be identified by name, since
Diameter supports
DNS-based service location as well as certificate
authentication
(altSubjectName). So if the Server-Id is an FQDN, then the
Diameter client
can reach that server.
In RADIUS servers are identified only by IP address. So
presumably a RADIUS
server would need to resolve the Server-Id FQDN to an IP
address to figure
out which server to make the key request to. If the
Server-Id and AAA
server FQDN are different then the message may not be
deliverable.
This issue is not purely academic -- it will come up in the
EAPEXT BOF at
IETF 66.
> > The following steps enable lower layer identities
to be securely
> > verified by all parties:
> >
>[Joe] What does lower layer identities mean in this
case? Does this
>mean peer, authenticator and port identities?
I assume that we're talking about peer and authenticator
identities.
Comments below.
> > [a] Specifying the lower layer parameters used to
identify the
> > authenticator and peer;
It is possible to uniquely identify an authenticator in
multiple ways. For
example, a MAC address could be used, as long as it was
associated with the
entire authenticator and not just a port of it.
> > [b] Communicating the lower layer identities
between the peer and
> > authenticator within phase 0;
If this is not done, then the peer may not know the
authenticator scope.
> > [c] Communicating the lower layer authenticator
identity between the
> > authenticator and backend server within the
NAS-Identifier
> > attribute;
So whatever authenticator identity is chosen to be sent to
the peer also
needs to be sent to the backend server.
>[Joe] Is this necessary or desirable? If the AAA server
does not
>already what the NAS-ID associated with the NAS, is it
OK for the NAS to
>assert this? If the NAS can assert whatever it wants
why are we
>bothering to do channel bindings?
RADIUS REQUIRES the NAS to identify itself, using
NAS-Identifier,
NAS-IPv6-Address or NAS-IPv4-Address. However, if the NAS
has more than
one IP address, NAS-Identifier makes the most sense,
regardless of any EAP
considerations. If there is a proxy present, then the
proxy needs to
validate the NAS-Identifier; by the time it gets to the AAA
server, it is
not possible to validate it.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
|
| Proposed Resolution to Issue 365:
Ambiguous UseofIdentifier |
|
2006-06-12 04:35:05 |
To improve the clarity of the sections on Authenticator,
Peer and Server
Identification, I've done some rewriting. How about this?
"2.2.1. Authenticator and Peer Identification
The EAP method conversation is between the EAP peer and
server. The
authenticator identity, if considered at all by the EAP
method, is
treated as an opaque blob for the purposes of Channel
Bindings (see
Section 5.12). However, the authenticator identity is
important in
two other exchanges - the AAA protocol exchange and the
Secure
Association Protocol conversation.
The AAA conversation is between the EAP authenticator and
the backend
authentication server. From the point of view of the
backend
authentication server, EAP keying material and parameters
are
transported to the EAP authenticator identified by the
NAS-Identifier
attribute. Since an EAP authenticator MUST NOT share EAP
keying
material or parameters with another party, if the EAP
peer or backend
authentication server detects use of EAP keying material
and
parameters outside the scope defined by the
NAS-Identifier, the
keying material MUST be considered compromised.
+-+-+-+-+
| EAP |
| Peer |
+-+-+-+-+
| | | Peer Ports
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
Authenticator
| | | | | | | | | Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | |
| Auth1 | | Auth2 | | Auth3 |
| | | | | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | \ |
\ | \ |
\ | \ |
EAP over AAA \ | \ |
(optional) \ | \ |
\ | \ |
\ | \ |
\ | \ |
+-+-+-+-+-+ +-+-+-+-+-+
Backend
| EAP | | EAP |
Authentication
| Server1 | | Server2 |
Servers
+-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Relationship between EAP peer, authenticator
and server
The Secure Association Protocol conversation is between
the peer and
the authenticator. For lower layers which support key
caching it is
particularly important for the EAP peer, authenticator
and backend
server to have a consistent view of the usage scope of
the
transported EAP keying material. In order to enable
this, it is
RECOMMENDED that the Secure Association Protocol
explicitly
communicate the usage scope of the EAP keying material
passed down to
the lower layer, rather than implicitly assuming that
this is defined
by the authenticator and peer endpoint addresses.
Since an authenticator may have multiple ports, the scope
of the
authenticator key cache may not be described by a single
endpoint
address. Similarly, where a peer may have multiple ports
and sharing
of EAP keying material and parameters between peer ports
of the same
link type is allowed, the extent of the peer key cache
cannot be
communicated by using a single endpoint address.
Instead, it is
RECOMMENDED that the EAP peer and authenticator
consistently identify
themselves utilizing explicit identifiers, rather than
endpoint
addresses or port identifiers.
AAA protocols such as RADIUS [RFC3579] and Diameter
[RFC4072] provide
a mechanism for the identification of AAA clients; since
the EAP
authenticator and AAA client are always co-resident, this
mechanism
is applicable to the identification of EAP
authenticators.
RADIUS [RFC2865] requires that an Access-Request packet
contain one
or more of the NAS-Identifier, NAS-IP-Address and
NAS-IPv6-Address
attributes. Since a NAS may have more than one IP
address, the NAS-
Identifier attribute is RECOMMENDED for explicit
identification of
the authenticator, both within the AAA protocol exchange
and the
Secure Association Protocol conversation.
Problems which may arise where the peer and authenticator
implicitly
identify themselves using endpoint addresses include the
following:
[a] It may not be obvious to the peer which authenticator
ports are
associated with which authenticators. The EAP peer
will be unable
to determine whether EAP keying material has been
shared outside
its authorized scope, and needs to be considered
compromised. The
EAP peer may also be unable to utilize the
authenticator key cache
in an efficient way.
[b] It may not be obvious to the authenticator which peer
ports are
associated with which peers. As a result, the
authenticator may
not be able to enable a peer to communicate with it
utilizing
multiple peer ports.
[c] It may not be obvious to the peer which "virtual
authenticator" it
is communicating with. For example, multiple
"virtual
authenticators" may share a MAC address, but
utilize different NAS-
Identifiers.
[d] It may not be obvious to the authenticator which
"virtual peer" it
is communicating with. Multiple "virtual
peers" may share a MAC
address, but utilize different Peer-Ids.
[e] It may not be possible for the EAP peer and server to
verify the
authenticator identity via channel bindings.
For example, problems [a], [c] and [e] occur in
[IEEE-802.11i], which
utilizes peer and authenticator MAC addresses within the
4-way
handshake. Problems [b] and [d] do not occur since
[IEEE-802.11i]
only allows a peer to utilize a single port.
The following steps enable lower layer identities to be
securely
verified by all parties:
[f] Specifying the lower layer parameters used to identify
the
authenticator and peer. As noted earlier, endpoint or
port
identifiers are not recommended for identification of
the
authenticator or peer when it is possible for them to
have multiple
ports.
[g] Communicating the lower layer identities between the
peer and
authenticator within phase 0. This allows the peer and
authenticator to determine the key scope if a key cache
is
utilized.
[h] Communicating the lower layer authenticator identity
between the
authenticator and backend server within the
NAS-Identifier
attribute.
[i] Including the lower layer identities within Channel
Bindings (if
supported) in phase 1a, ensuring that they are
communicated between
the EAP peer and server.
[j] Supporting the integrity-protected exchange of
identities within
phase 2a.
[k] Utilizing the advertised lower layer identities to
enable the peer
and authenticator to verify that keys are maintained
within the
advertised scope.
2.2.2. Virtual Authenticators
When a single physical authenticator advertises itself as
multiple
"virtual authenticators", if the virtual
authenticators do not
maintain logically separate key caches, then by
authenticating to
one virtual authenticator, the peer can gain access to
the other
virtual authenticators sharing a key cache.
For example, where a physical authenticator implements
"Guest" and
"Corporate Intranet" virtual authenticators,
an attacker acting as a
peer could authenticate with the "Guest"
"virtual authenticator" and
derive EAP keying material. If the "Guest"
and "Corporate Intranet"
virtual authenticators share a key cache, then the peer
can utilize
the EAP keying material derived for the
"Guest" network to obtain
access to the "Corporate Intranet" network.
In order to address this vulnerability:
[a] Authenticators are REQUIRED to cache associated
authorizations
along with EAP keying material and parameters and to
apply
authorizations consistently. This ensures that an
attacker cannot
obtain elevated privileges even where the key cache is
shared
between "virtual authenticators".
[b] It is RECOMMENDED that physical authenticators maintain
separate
key caches for each "virtual
authenticator".
[c] It is RECOMMENDED that each "virtual
authenticator" identify itself
consistently to the peer and to the backend
authentication server,
so as to enable the peer to verify the authenticator
identity via
Channel Bindings (see Section 5.11).
[d] It is RECOMMENDED that each "virtual
authenticator" identify itself
distinctly, in order to enable the peer and backend
server to tell
them apart. For example, this can be accomplished by
utilizing a
distinct NAS-Identifier attribute or BSSID.
2.3. Server Identification
The EAP method conversation is between the EAP peer and
server, as
identified by the Peer-Id and Server-Id. As shown in
Figure 3, an
authenticator may be configured to communicate with
multiple EAP
servers; the EAP server that an authenticator
communicates with may
vary according to configuration and network and server
availability.
While the EAP peer can assume that all EAP servers within
a realm
have access to the credentials necessary to validate an
authentication attempt, it cannot assume that all EAP
servers share
persistent state.
Authenticators may be configured with different primary
or secondary
EAP servers, in order to balance the load. Also, the
authenticator
can dynamically determine the EAP server to which
requests will be
sent; in event of a communication failure, the
authenticator may fail
over to another EAP server. For example, in Figure 3,
Authenticator2
may be initially configured with EAP server1 as its
primary backend
authentication server, and EAP server2 as the backup, but
if EAP
server1 becomes unavailable, EAP server2 may become the
primary
server.
In general, the EAP peer cannot direct an authentication
attempt to a
particular EAP server within a realm; this decision is
made solely by
the authenticator. Nor can it determine which EAP server
it will be
communicating with, prior to the start of the EAP method
conversation. The Server-Id is not included in the EAP-
Request/Identity, and since the authenticator determines
the EAP
server dynamically, it typically is not possible for the
authenticator to advertise the Server-Id during the
discovery phase.
EAP methods may or may not export the Server-Id, and as a
result, the
EAP peer may not even learn which server it was
conversing with after
the EAP conversation completes successfully.
As a result, an EAP peer, on connecting to a new
authenticator or
reconnecting to the same authenticator, may find itself
communicating
with a different EAP server. Fast reconnect, defined in
[RFC3748]
Section 7.2, may fail if the EAP server that the peer
communicates
with is not the same one with which it initially
established a
security association. For example, an EAP peer
attempting an EAP-TLS
session resume may find that the new EAP-TLS server will
not have
access to the TLS Master Key identified by the TLS
Session-Id, and
therefore the session resumption attempt will fail,
requiring
completion of a full EAP-TLS exchange.
EAP methods that support mutual authentication may not
allow the EAP
peer to verify the EAP server identity. For example, the
EAP peer
may only verify that the EAP server possesses a long-term
secret; in
this case the EAP peer will only know that an
authenticator has been
authorized by an EAP server, but will not confirm the
identity of the
EAP server.
EAP methods that export the Server-Id MUST verify the
server
identity. As noted in Appendix A, existing EAP methods
exporting the
Server-Id determine this from the altSubjectName in the
server
certificate, and as a result, the peer determines the
identity of the
server (expressed as a Fully Qualified Domain Name
(FQDN)) by
validating the server certificate.
Validating the EAP server identity enables the EAP peer
to decide
whether a specific EAP server is authorized, and to
determine whether
the EAP server is sharing keying material outside the
intended scope.
In some cases, such as where the certificate extensions
defined in
[RFC4334] are included in the server certificate, it may
even be
possible for the peer to verify some Channel Binding
parameters from
the server certificate. Where the EAP peer does not
verify the EAP
server identity, it is not possible for the peer to
determine whether
the EAP server has shared keying material outside its
authorized
scope.
It is possible for problems to arise in situations where
the EAP
server identifies itself differently to the EAP peer and
authenticator. For example, the Server-Id exported by
EAP methods
may not be identical to the Fully Qualified Domain Name
(FQDN) of the
backend authentication server. Where certificate-based
authentication is used within RADIUS or Diameter, the
altSubjectName
used in the backend server certificate may not be
identical to the
Server-Id or backend server FQDN.
Where the backend server FQDN differs from the
altSubjectName in the
certificate, the AAA client may not be able to
successfully determine
whether it is talking to the correct backend
authentication server.
Where the Server-Id and backend server FQDN differ, the
combination
of the key scope (Peer-Id, Server-Id) and EAP
conversation identifier
(Session-Id) may not be sufficient for the authenticator
to determine
where the key resides. For example, the authenticator
may identify
backend servers by their IP address (as occurs in
RADIUS), or using a
Fully Qualified Domain Name (as in Diameter). If the
Server-Id does
not correspond to the IP address or FQDN of a known
backend
authentication server, then the authenticator will not
know which
backend authentication server possesses the key."
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
|
[1-3]
|
|