The text of issue 404 is enclosed below.
Within tunneled methods, it appears possible for more than
one Peer-Id and
Server-Id to exist. For example, a tunneled method could
authenticate peer
and server machine identities using certificates, then
execute an inner EAP
method supporting mutual authentication which also exports a
Peer-Id and
possibly a Server-Id.
Where more than one Peer and Server identities are
authenticated, some care
may be required to understand the implied key scope.
Different EAP methods
may use different authenticated peer or server identities so
that there
should not be an expectation that the Peer-Id(s) will be
identical or that
the Server-Id(s) will be identical.
In split authentication scenarios the server terminating
Phase 1 of the
tunneled method may not be the same party terminating Phase
2. In this case
the Server-Id(s) would not be referring to the same party.
In some tunneled methods the MSK/EMSK is derived only from
the Phase 1
exchange, in which case only the Peer-Id/Server-Id from
Phase 1 is relevant
to the MSK/EMSK key scope. In other tunneled methods the
exported MSK/EMSK
may be derived from both Phase 1 and Phase 2 keys. However
in this case I
believe it is true that only the Phase 1 entities have
knowledge of the
combined keys, so that again only the Phase 1 Peer-Id and
Server-Id are
relevant to the key scope.
As a result, a question arises as to whether all the
Peer-Id(s) and
Server-Id(s) are relevant to defining the key scope, if more
than one
Peer-Id/Server-Id are exported. At first glance, it seems
that the
Peer-Id(s) are multiple names for the same entity, but that
the Server-Id(s)
may not be. If the goal is to define the key scope, then
perhaps only the
Phase 1 Peer-Id/Server-Id are relevant.
Comments welcome.
===========================
A strawman resolution of this issue is the following:
Change Peer-Id to Peer-Id(s) and Server-Id to Server-Id(s).
In Section 1.4, change the text on Peer-Id and Server-Id to
the following:
" EAP methods supporting key derivation and mutual
authentication
SHOULD export a method-specific EAP conversation
identifier known as
the Session-Id, as well as one or more peer identifiers
(Peer-Id(s)) and
MAY export
one or more method-specific server identifiers
(Server-Id(s)). EAP
methods MAY
also support the import and export of channel binding
parameters.
EAP method specifications developed after the publication
of this
document MUST define the Peer-Id, Server-Id and
Session-Id. The
combination of the Peer-Id(s) and Server-Id(s) uniquely
specifies the
endpoints of the EAP method exchange when they are
provided. For
existing EAP methods the Peer-Id, Server-Id, and
Session-Id are
defined in Appendix A.
Peer-Id
As described in [RFC3748] Section 7.3, the identity
provided in
the EAP-Response/Identity can be different from the
peer
identities authenticated by the EAP method. For
example, the
identity provided in the EAP-Response/Identity can be
a privacy
identifier as described in "The Network Access
Identifier"
[RFC4282] Section 2.3, or can be decorated as
described in
[RFC4282] Section 2.7. Where the EAP method
authenticates one or
more peer identities, those identities are exported by
the method
as the Peer-Id(s). It is possible for more than one
Peer-Id to be
exported by an EAP method. For example, in a
tunneling method,
more than one peer identity can be authenticated. Not
all EAP
methods provide a method-specific peer identity; where
this is not
defined, the Peer-Id is the null string.
Server-Id
Where the EAP method authenticates one or more server
identities,
those identities are exported by the method as the
Server-Id(s).
It is possible for more than one Server-Id to be
exported by an
EAP method, such as within a tunneling method. Not
all EAP
methods provide a server identity; where this is not
defined, the
Server-Id is the null string.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
---+
| |
^
| EAP Method |
|
| |
|
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ |
|
| | | | | |
|
| | EAP Method Key |<->| Long-Term
| | |
| | Derivation | | Credential | |
|
| | | | | |
|
| | | +-+-+-+-+-+-+-+ |
Local to |
| | | |
EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Method |
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ |
|
| | | TEK | |MSK, EMSK | |IV | |
|
| | |Derivation | |Derivation | |Derivation | |
|
| | | | | | |(Deprecated) | |
|
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ |
|
| | ^ | | |
|
| | | | | |
V
+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+
---+
| | | |
^
| Peer-Id(s), | | |
Exported |
| Server-Id(s), | channel | MSK (64+B) | IV (64B)
by |
| Session-Id | bindings | EMSK (64+B) |
(Optional) EAP |
| | & Result | |
Method |
V V V V
V
Figure 2: EAP Method Parameter Import/Export"
In Section 1.4.1, change the first paragraph to:
"Each key created within the EAP key management
framework has
a name (a unique identifier),
as well as a scope (the parties to whom the key is
available).
The scope of exported keying material and TEKs is defined by
the
authenticated
peer identities (Peer-Id(s)) and the authenticated server
identities
(Server-Id(s)), where available. Where an EAP method that
derives
keys does not provide a Server-Id,
the EAP peer will not know the identity of the EAP server
with which it
derived EAP keying material. Where an EAP method that
derives keys
does not provide a Peer-Id, the EAP server will not know the
identity
of the EAP peer with which it derived EAP keying
material."
[BA] Perhaps the above text needs some further clarification
with respect to
the Phase 1/Phase 2 issues described above.
-------------------------------------------------
Issue 404: Peer-Id & Server-Id in Tunneled Methods
Submitter name: Paul Funk
Submitter email address: pfunk juniper.net
Date Submitted: April 7, 2007
Reference: http://lists.frascone.com/pipermail/eap/msg04709.html
Document: KEYING-18
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
Review of the EAP-TTLSv0 specification has raised some
questions
about how the Peer-Id is determined for tunneled methods:
1. What if multiple identities are being authenticated?
EAP-TTLSv0 can handle both mutual authentication in phase I
(via certificates) as well as one or more inner methods.
Are multiple Peer-Ids returned in this case, or is there
only
one (or none)?
2. What if Phase I used only server authentication and the
inner method
doesn't export a Peer-Id (e.g. EAP-MD5). Does the tunneled
method return
the null Peer-Id in this case?
3. Do Peer-Ids have a type?
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
