eap Mailing List: Proposed Resolution of Issue 404: Peer-Id & Server-Id in Tunnel Methods

[Bernard Aboba (bernard_aboba]

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 [at] 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?