> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba hotmail.com]
> Sent: Saturday, May 06, 2006 7:42 PM
> To: eapfrascone.com
> Subject: [eap] Re: issue 367: Key Scope and EAP Server
Authorization
>
> I think I see the point, which is that a given
authenticator may be
> connected to
> more than one EAP server, and that all authenticators
in a single
> administrative
> domain may not share the same EAP server. Also, EAP
servers cannot
> necessarily
> be assumed to share key state among each other. If the
> selcted EAP method
> does not
> provide the Server-ID, then the peer cannot know the
scope of
> the keys it
> derives with the EAP server.
>
[Joe] I'm not sure that a formal server-ID is required or
sufficient. The peer has a set of credentials that it uses
to establish trust in a server. It needs to know what the
limits of that trust is. If the peer wants to resume some
state with an particular server then server-ID is very
useful, but I think that is a slightly different problem.
> This can create a number of issues, such as a peer
attempting
> (but failing)
> a
> fast reconnect because the server that the
authenticator is
> configured to
> communicate with is not the same one with which the
peer
> established the
> previous session.
>
[Joe] Or one EAP server/Authenticator can attempt to spoof
another.
> However, there are other situations in which the server
> identity is not
> material,
> such as handoff in an 11r Mobility Domain (MD), where
the STA
> only care
> whether
> a candidate AP is in the same MD, not whether the new
> authenticator is
> configured
> to talk to the same backend authentication server as
the
> current or initial
> AP.
>
[Joe] I'm not familiar with this scenario, is this based on
a context transfer from one AP to another? So in this case
you are putting your trust in one AP to only exchange data
with another valid AP?
> In practice, the peer determines whether an
authenticator is
> within the
> scope
> of authorization of the backend authentication server
by
> attempting to
> complete
> the SAP exchange with it. If the exchange succeeds, the
> authenticator is
> authorized; if not, it isn't.
[Joe] Implicit in this statement is that the peer pefromed
some authorization of the authentication server.
> It is possible for the peer to attempt a
> fast reconnect exchange with the wrong server; unless
the
> server were to
> include its identity in the EAP-Request there is no way
for
> the peer to
> determine what server it is talking to before the EAP
method
> conversation
> gets underway. Even if the authenticator were to
advertise
> the server(s)
> that it is configured to talk to, and even if those
servers
> were identified
> by their Server-IDs, it would not be possible for the
peer to
> know a-priori
> which server it was going to talk to, since the primary
> server can change
> due
> to changes in network or server availability.
>
[Joe] Sounds true
> Given this, I'm not sure how the peer can verify that
an
> authenticator is
> allowed to be authorized by an EAP server.
>
[Joe] This seems to me to be a rather serious system
problem, since all we know is the EAP server and our trust
in the authenticator is based on authorization from the EAP
server. If we can't verify this then I'm not sure why we
are worried about channel bindings. If you don't now the
scope of the EAP server that is establishing trust then you
don't know whether the parameters are valid or not.
> The proposed resolution is as follows:
>
> Change Section 2.2 to the following:
>
> "2.2 Peer, Authenticator and Server Architecture
>
> This specification does not impose constraints on the
> architecture of the
> EAP authenticator, peer or server. Any of the
authenticator
> architectures
> described
> in [RFC4118] can be used. As a result, lower layers
> need to identify EAP peers and authenticators
unambiguously, without
> incorporating implicit assumptions about
> peer and authenticator architectures.
>
> For example, it is possible for multiple base stations
> and a "controller" (e.g. WLAN switch) to
comprise a single EAP
> authenticator.
> In such a situation, the "base station
identity" is
> irrelevant to the EAP
> method conversation, except perhaps as an opaque blob
to be used in
> Channel Bindings. Many base stations can share the same
authenticator
> identity.
> It should be understood that an EAP authenticator or
peer:
>
> [a] may contain one or more physical or logical ports;
> [b] may advertise itself as one or more
"virtual"
> authenticators, peers or servers;
> [c] may utilize multiple CPUs;
> [d] may support clustering services for load balancing
or failover.
>
> Both the EAP peer and authenticator may have more than
one
> physical or
> logical
> port. A peer may simultaneously access the network via
multiple
> authenticators, or via multiple physical or logical
ports on a given
> authenticator.
> Similarly, an authenticator may offer network access to
> multiple peers,
> each via a separate physical or logical port.
> When a single physical
> authenticator advertises itself as multiple
> "virtual authenticators", it is possible
for a single physical port
> to belong to multiple "virtual
authenticators".
>
> An authenticator may be configured to communicate with
more than one
> backend authentication server, each of which is
configured to
> communicate with a subset of the authenticators.
> The situation is illustrated in Figure 3.
> +-+-+-+-+
> | 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"
>
> Add a new section 2.2.1 entitled "Server
Identification":
>
> "2.2.1 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 server that
> a peer communicates
> with may vary according to network and server
availability.
> 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.
>
> As a result, prior to initiation of the EAP
conversation, the
> peer may not
> be able to predict which
> EAP server it will be communicating with. 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. The
peer may
> not be able to
> determine
> the Server-Id prior to the start of the EAP method
> conversation, since the
> Server-Id is not included in the EAP-Request/Identity,
and may not be
> advertised by the authenticator during the discovery
phase."
>
>
------------------------------------------------------------
--
> -------------------
> Issue 367: Key Scope and EAP Server Authorization
> Submitter name: Joe Salowey
> Submitter email address: jsaloweycisco.com
> Date Submitted: May 3, 2006
> Reference: http://lists.frascone.com/pipermail/eap/msg04231.html
> Document: KEYING-12
> Comment type: 'T'echnical
> Priority: '1' Should fix
> Section: 2.2.1 and 3.2
> Rationale/Explanation of issue:
> Section 1.4.1 correctly defines the scope of the EAP
keying
> material as
> being defined by the EAP Peer and EAP server, however
this
> relationship
> is not carried out in other key scope discussions as
far as I
> can tell.
> In order for channel binding, key mixing etc. to work
the
> peer must make
> sure that the key is used not just within the
authorized parameters of
> the lower layer, but of the authorized scope of the EAP
> server as well.
>
> I'm not sure of all of all the places where this needs
to be
> addressed,
> but I think it needs to be addressed in section 2.2.1
perhaps
> by adding
>
> "[g] Verifying that the advertised scope is
within the scope that the
> EAP server is allowed to authorize"
>
> Section 3.2 should probably state somewhere that:
>
> "The peer should verify that the key scope
advertised by the
> authenticator is within the scope that is allowed to be
authorized by
> the EAP Server."
>
>
>
____________________________________________________________
_____
> 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
|
>[Joe] I'm not sure that a formal server-ID is required
or sufficient. The
>peer has a set of credentials that it uses to establish
trust in a server.
>It needs to know what the limits of that trust is. If
the peer wants to
>resume some state with an particular server then
server-ID is very useful,
>but I think that is a slightly different problem.
[Bernard] The NAI allows the peer to request authentication
within a given
realm. The assumption is that any EAP server in that realm
will have access
to the credentials necessary to authenticate the peer.
However, the peer
cannot necessarily assume that the EAP servers share a cache
of
method-specific keying material. This is where things get
tricky.
>[Joe] Or one EAP server/Authenticator can attempt to
spoof another.
If the EAP method doesn't support authentication of the
server claim of
identity, then even if the method supports mutual
authentication, the peer
is only verifying that the EAP server has access to the
credentials, it is
not authenticating the server itself. For example, in
EAP-TLS, TTLS, PEAP,
etc. the server identity can be validated by the peer; in
EAP-SIM and
EAP-AKA it cannot be. One question this brings up is
whether a method that
doesn't support server certificates can validate the server
identity.
>[Joe] I'm not familiar with this scenario, is this
based on a context
>transfer from one AP to another? So in this case you
are putting your
>trust in one AP to only exchange data with another valid
AP?
11r allows the authenticators derive cryptographically
independent keys
(PMK-R1s) from the MSK. So it is not context transfer,
which would mean
that all authenticators use the same key to derive TSKs. In
11r the trust
model is between a new authenticator and the
"initiall" authenticator.
Compromise of the "initial" authenticator leads
to compromise of all peer
sessions that originated at that authenticator. However, it
does not
necessarily compromise sessions which did not originate at
the compromised
authenticator, due to the crytographic separation built into
the key
hierarchy.
>[Joe] Implicit in this statement is that the peer
pefromed some
>authorization of the authentication server.
The peer can only do that if it authenticates the server,
right? For
example, in EAP-TLS or PEAP the peer can perform
authorization of the EAP
server.
> > Given this, I'm not sure how the peer can verify
that an
> > authenticator is allowed to be authorized by an
EAP server.
> >
>[Joe] This seems to me to be a rather serious system
problem, since all we
>know is the EAP server and our trust in the
authenticator is based on
>authorization from the EAP server. If we can't verify
this then I'm not
>sure why we are worried about channel bindings. If you
don't now the scope
>of the EAP server that is establishing trust then you
don't know whether
>the parameters are valid or not.
I think that the peer has to trust that the backend
authenticator server
will not send a key to an unauthorized authenticator. This
implies that
either the backend authentication server either checks that
the Request
attributes make sense (NAS-Identifier, Called-Station-Id,
etc.) or that the
local proxy does it if one is present.
You are correct that if the EAP server does not check the
authorization of
the authenticator, then Channel Bindings provide little
value; the
authenticator can provide the same mis-information to the
peer and backend
server, and it will be believed.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|