The text of Issue 404 is enclosed below. This issue relates
to the usage of
the
Peer-Id and Server-Id within tunnel methods.
The purpose of the Peer-Id and Server-Id is to identify the
entities that
were
involved in the creation of EAP keying material. Within a
tunnel method the
EAP keying material could be derived solely from the outer
authentication
(as in EAP-TTLSv0), or it could be derived from a
combination of the outer
and inner exchanges.
Where the EAP keying material is derived solely from the
outer
exchange, the Peer-Id and Server-Id is determined based on
the
identities authenticated in the outer exchange. If the EAP
keying
material is derived from both the outer and inner exchanges,
then
the Peer-Id and Server-Id are determined based on the
identities
authenticated in both exchanges.
It is possible that the inner or outer exchange will not
export a
Peer-Id and/or Server-Id, or that a single exchange can
export
multiple Peer-Id(s) and Server-Id(s). Where the inner and
outer
exchanges export Peer-Id(s) and Server-Id(s), it is possible
that
the inner and outer identities differ in type and/or
contents. For example, the Server-Id from the outer
exchange
could be an RDN, while the Server-Id from the inner
exchange
could be an IP address or FQDN. The Peer-Id(s) and
Server-Id(s) from the inner and outer authentication
exchanges
are combined and exported together.
Where the outer exchange only provides server authentication
and
the inner exchange doesn't export a Peer-Id, the tunneled
method
will return the null Peer-Id, but will return one or more
Server-Id(s). Typically Peer-Id(s) will conform to the RFC
4282
syntax for the NAI, and Server-Id(s) will conform to the RFC
4282
syntax for the realm portion of the NAI; however, the
Server-Id
could also be an IP address.
The proposed resolution is as follows:
Change Peer-Id to Peer-Id(s) and Server-Id to Server-Id(s)
within the
document.
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 method-specific 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
Peer-Id(s)
and Server-Id(s), when provided, identify the entities
involved
in generating EAP keying material. For existing EAP methods
the
Peer-Id, Server-Id and Session-Id are defined in Appendix
A.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
---+
| |
^
| 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"
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. If an EAP method that generates keys
authenticates one or more method-specific 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, a peer certificate
can
contain more than one peer identity; in a tunnel method
peer identities could be authenticated both within an outer
and inner exchange and these identities could be different
in
type and contents. For example, an outer exchange could
provide
a Peer-Id in the form of an RDN, whereas an inner exchange
could identify the peer via its NAI or MAC address. Where
EAP keying material is determined solely from the outer
exchange,
only the outer Peer-Id(s) are relevant; where the EAP
keying
material is determined from both the inner and outer
exchanges,
then both the inner and outer Peer-Id(s) are relevant and
are
exported by the tunnel method. Not all EAP methods provide a
method-specific
peer identity; where this is not defined, the Peer-Id is the
null
string. Within methods that do not support key generation,
the
Peer-Id is always the null string.
Server-Id
If an EAP method that generates keys authenticates one or
more
method-specific 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. For example,
a
server certificate can contain more than one server
identity;
in a tunnel method server identities could be authenticated
both within an outer and inner exchange and these identities
could
be different in type and contents. For example, an outer
exchange
could provide a Server-Id in the form of an IP address,
whereas
an inner exchange could identify the server via its FQDN or
hostname.
Where EAP keying material is determined solely from the
outer exchange,
only the outer Server-Id(s) are relevant; where the EAP
keying
material is determined from both the inner and outer
exchanges,
then both the inner and outer Server-Id(s) are relevant and
are
exported by the tunnel method. Not all EAP methods provide a
server
identity;
where this is not defined, the Server-Id is the null
string.
Within methods that do not support key generation, the
Server-Id is
always the null string."
In Section 1.4.1, change the first four paragraphs 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 method-specific 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.
An EAP method that satisfies the [RFC4017] mandatory
security
requirements will typically provide a non-null Peer-Id;
however it
is possible for an EAP method to satisfy the [RFC4017]
mandatory
security requirements while providing a null Server-Id.
In an EAP method where EAP keying material is generated
solely based
on a TLS exchange involving server-only certificate
authentication,
the Peer-Id would be the null string and the Server-Id(s)
would be
determined from the server certificate. Even where
Peer-
Id(s)/Server-Id(s) are exported by an inner exchange, if
keying
material derived from the inner exchange is not
incorporated into EAP
keying material exported by the tunnel method, then the
inner
identities are not relevant for the purpose of
determining the tunnel
method's Peer-Id(s)/Server-Id(s). This is true even if
the tunnel
method proves that a single peer or server participated
in the inner
and outer authentications.
If a server identity is not claimed, the Server-Id is the
null
string. However, if a server identity is claimed and
authenticated,
then a Server-Id can be provided, even if the server only
proves
possession of a shared secret or password. For example,
a method
providing for exchange of method-specific peer and server
identities
can prove that both the peer and server possess a shared
secret or
password. In this case both a Peer-Id and Server-Id can
be provided,
even though the server identity was not confirmed as it
would be
where server certificate authentication is supported.
"
==================================================
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
|