Issue 300: Port
Submitter name: Yoshihiro Ohba
Submitter email address: mailto:aboba@internaut.com
Date first submitted: 5/4/2005
Reference: http://mail.frascone.net/pipermail/eap/2005-May/003391.html
Document: KEYING-06
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue
In draft-ietf-eap-keying-06.txt, the definition of "port" is not
clear. In fact, the draft talks about peer ports and authenticator
ports. On the other hand, there is a definition of "network access
port" in IEEE 802.1X specification, but I'm not sure the port in the
eap-keying draft is exactly the same as defined in 802.1X.
Also, can an "authenticator port" be physically separated from the
authenticator? I think they can be separated.
[Jari Arkko]
This does seem to be an issue. I'm not sure we can
define "port" well enough, given the variety of link layers
that use it in different ways.
I went through keying-07 and tried to see if we can avoid
this problem. Most of the text involving ports simply
reminds the reader that multiple physical or virtual ports
may be involved, and the implications to identification.
I don't think this part is problematic, but our definitions
(like in TSKs) should not rely on the term "port". A small
proposed change below.
> Transient Session Keys (TSKs)
>
> Session keys used to protect data exchanged between a port of the
> peer and a port of the authenticator after the EAP authentication
> has successfully completed. TSKs are appropriate for the lower
> layer ciphersuite negotiated between the ports of the EAP peer and
> authenticator. Examples of TSK derivation are provided in Appendix
> D.
s/between a port of the peer and a port of the authenticator/in a session
between the peer and the authenticator/
Proposed Resolution: Accept
Issue 301: TSKs
Submitter name: Yoshihiro Ohba
Submitter email address: mailto:aboba@internaut.com
Date first submitted: 5/4/2005
Reference: http://mail.frascone.net/pipermail/eap/2005-May/003392.html
Document: KEYING-06
Comment type: T
Priority: S
Section: 2.1
Rationale/Explanation of issue
In section 2.1:
"
Transient Session Keys (TSKs)
Session keys used to protect data exchanged between the peer and
the authenticator after the EAP authentication has successfully
completed. TSKs are appropriate for the lower layer ciphersuite
negotiated between the EAP peer and authenticator. Examples of TSK
derivation are provided in Appendix D.
"
I think that ports should be the consumers of the TSKs. The text may
be revised something like:
"
Transient Session Keys (TSKs)
Session keys used to protect data exchanged between a port of the peer and
a port of the authenticator after the EAP authentication has successfully
completed. TSKs are appropriate for the lower layer ciphersuite
negotiated between the ports of the EAP peer and authenticator.
Examples of TSK derivation are provided in Appendix D.
"Proposed Resolution: Accept
Issue 302: Clarifications on the "Domino Effect"
Submitter name: Julien Bournelle
Submitter email address: julien.bournelle@int-evry.fr
Date first submitted: 5/4/2005
Reference: http://mail.frascone.net/pipermail/eap/2005-May/003390.html
Document: KEYING-06
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue
In RFC4017, the Domino effect is described:
"Compromise of a single authenticator cannot compromise any other part
of the system, including session keys and long-term secrets."
Does this finally imply that the authenticator MUST not provide keys to
other entity ?
[Bernard Aboba]
Here is a quote from "AAA Key Management" (draft-housley-aaa-key-mgmt-01.txt):
Prevent the Domino effect
Compromise of a single authenticator MUST NOT compromise any
other part of the system, especially session keys and long-term
keys. There are many implications of this requirement;
however, two implication deserves highlighting. First, an
authenticator MUST NOT share any keying material with another
authenticator. Second, the scope of the authenticator needs to
be defined and understood by all parties that communicate with
it.The proposed resolution is to summarize the security requirements
from draft-housley-aaa-key-mgmt-01.txt in the key management document.
[Jari Arkko] I think we need to describe the basic principles instead.
Proposed Resolution: Discuss
Issue 303: Expert Review of EAP PAX
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: 4/17/2005
Reference: http://mail.frascone.net/pipermail/eap/2005-April/003274.html
Document: PAX-02
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue
This an expert review of EAP PAX, draft-clancy-eap-pax-02.txt,
based on RFC 3748 requirements and the review template
at http://www.drizzle.com/~aboba/EAP/template.txt
Note that an expert review is a not an analysis to find out
if the method is suitable for any specific purpose; we just
make sure that the method does not break EAP and that
its sufficiently well documented. Also, I didn't review
compliance to IEEE method requirements. (Any takers?)
Overall, the verdict is "pass", although a couple of editorial
clarifications might be useful. Inline:
> 1. Does the method document its security properties
> in sufficient manner, as required by Section 7.2
> of RFC 3748?
>
> 1a. Mechanism. Is the mechanism explained?
Yes. See Sections 2 and 3.
> 1b. Security claims. Are the claimed and not claimed
> properties listed?
Yes. See Section 4.3.
Note: The claim for "cryptographic binding" (RFC 3748, Section 7.2.1)
is not documented for PAX, as this claim is relevant for tunnel
methods only. But for completeness sake it would be desirable to
mention why its not being listed.
> 1c. Justifications for the claims? Is an explanation or
> reference provided to each of the claims?
Yes.
> 1d. Key strength. Is the key strength documented?
Yes.
> 1e. Description of key hierarchy. Is the key hierarchy
> documented?
Yes. See Section 2.3 and 2.1.
> [Optional, at least for now: does it conform to EAP
> keying framework?]
Yes. Note: the keying framework is still being worked
on.
> 1f. Indication of vulnerabilities. Are the known vulnerabilities
> documented?
Yes. See Sections 2.2 and 4.
> [Note: it seems unreasonable to require the documentation
> of unknown vulnerabilities :-) The "known" may of course be
> "known to reviewer" or "known to author" or "known to the
> community", but that appears to be best we can do.]
>
> 2. Compliance with EAP packet formats
>
> 2a. Does the method comply with the packet formats
> defined in Section 4 of RFC 3748?
Yes.
> 3. Compliance with EAP behaviour
>
> 3a. Does the method comply with Success/Failure usage
> as defined in Sections 2, 2.2, and 4.2?
Yes. (Editorial note: the document talks explicitly about
the conditions upon which an EAP Failure needs to be sent.
However, while it can be understood and implied, it doesn't
actually say that an EAP Success should be sent otherwise.)
> 3b. Does the method comply with sequence usage as defined
> in Section 2.1 of RFC 3748?
Yes. No sequences are used.
> 3c. Does the method comply with request/response processing
> rules as defined in Section 4.1 of RFC 3748?
Yes.
> 3d. Does the method comply with retransmission rules
> as defined in Section 4.3 of RFC 3748?
Yes.
> 3e. Does the method comply with the usage defined for
> Identity, as defined in Section 5.1 of RFC 3748?
Yes.
> 3f. Does the method comply with the usage defined for
> Notification, as defined in Section 5.2 of RFC 3748?
Yes. No Notifications are used.
> 3g. Does the method comply with the usage defined for
> Nak and Expanded-Nak as defined in Section 5.3 of RFC 3748?
Yes.
> 3h. Does the method comply with the MIC usage requirements
> from Sections 3.1, 7.5, and 7.8 of RFC 3748?
Yes. See Section 2.4, for instance.
Note: Regarding RFC 3748 Section 7.8 (optional) behaviour for
detecting bidding down attacks using Naks, EAP PAX does not do this.
Might be useful to note this.
> 4. Compliance with IANA requirements
>
> 4a. Does the method comply with EAP-based IANA requirements
> defined in Section 6 of RFC 3748? That is, if it requests
> the allocation of new numbers in the EAP namespace [not
> applicable if the numbers have already been allocated],
> is the type of the document and process appropriate for the
> desired action?
Yes.
> 4b. Does the method comply with other IANA requirements in
> the IETF standards track RFCs? For instance, does the
> method attempt to allocate TLS extensions (which would
> only be possible for standards track RFCs)?
Yes, the document complies with the IANA requirements,
as there are no other number spaces used than those in
EAP.
[Bernard Aboba]
It would be useful to have PAX document the key name and scope, as in
Appendix E in the Key Management framework.
[Charles Clancy]
Jari, thanks for your time and your review. I've put together -03 to
address your comments and updates some of the references. I will be
submitting it shortly. Meanwhile, a copy can be found here:
http://www.cs.umd.edu/~clancy/eap-pax/draft-clancy-eap-pax-03.txt
> [JA] Also, I didn't review compliance to IEEE method requirements.
> (Any takers?)
For anyone interested in this, it's outlined in the last paragraph of the
introduction.
> [JA] The claim for "cryptographic binding" (RFC 3748, Section 7.2.1)
> is not documented for PAX, as this claim is relevant for tunnel
> methods only. But for completeness sake it would be desirable to
> mention why its not being listed.
Ah... I have channel binding but not cryptographic binding. I've added it
to section 4.3.
> [JA] (Editorial note: the document talks explicitly about
> the conditions upon which an EAP Failure needs to be sent.
> However, while it can be understood and implied, it doesn't
> actually say that an EAP Success should be sent otherwise.)
I've added the following to section 2.4:
If PAX-ACK is received in response to a message fragment, the receiver
continues the protocol execution. If PAX-ACK is received in response
to PAX_STD-3 or PAX_SEC-5, then the server MUST send an EAP-Success
message. This indicates a successful execution of PAX.
> [JA] Regarding RFC 3748 Section 7.8 (optional) behaviour for
> detecting bidding down attacks using Naks, EAP PAX does not do this.
> Might be useful to note this.
I've added the following to section 4.3:
EAP is susceptible to an attack where an attacker uses NAKs to
convince an EAP client and server to use a less secure method, and can
be prevented using method-specific integrity protection on NAK
messages. Since EAP-PAX does not have suitable keys derived for this
integrity protection at the begining of a PAX conversation, this is
not included.
> [BA] It would be useful to have PAX document the key name and scope,
> as in Appendix E in the Key Management framework.
I've added the following to section 2.3:
The EAP Key Managment Framework [I-D.ietf-eap-keying] recommends
specification of key names and scope. The EAP-PAX Method-ID is the
MID value computed as described above. The EAP peer name is the CID
value exchanged in PAX_STD-2 and PAX_SEC-2. The EAP server name is
an empty string.
[ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]Proposed Resolution: Discuss
Issue 304: Review of EAP-IKEv2
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: 6/13/2005
Reference: http://mail.frascone.net/pipermail/eap/2005-June/003444.html
Document: EAP-IKEv2
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Having read draft-tschofenig-eap-ikev2-06, I believe this
document is not ready for expert review yet. It needs a
substantial amount of work to make it a decent EAP method
specification, and its compliance with RFC 3748 is best
assessed once it has matured a bit more.
Some comments (not as RFC3748 expert reviewer, but an
ordinary reviewer):
- The description of the protocol is very confusing reading.
In many cases, the document seems to pretend it is using IKEv2
as an EAP method, or profiling IKEv2, but it's not: This is a
new protocol that just happens to copy many aspects from IKEv2
(which is mainly a good idea, of course).
So talking about sending IKEv2 messages is plain wrong:
in almost all cases, the messages are not a valid IKEv2
messages. Even when the message formats look similar, the
semantics of the payloads and exchanges are not.
Sometimes this gets just plain silly: For instance, Section 4
says "In particularly the following messages and payloads
SHOULD not be sent Traffic Selector (TS) payloads...". So what
exactly would be the "valid reasons in particular circumstances"
(from RFC2119 definition of "SHOULD") to ignore this item,
and how should the other end process those payloads?
My suggestion for rewriting the draft would be as follows:
First, consider choosing a less confusing name for your
protocol. Then describe whatever message exchanges you have
in correct terms: you're describing EAP-IKEv2 messages
(not IKEv2 messages) that contain EAP-IKEv2 payloads (which
may copy the details from IKEv2 payloads, but the semantics
often change slightly... and then you don't have to say that
"traffic selector payloads must not be included", because
there's no such payload type in EAP-IKEv2). Finally, when
you have described what the EAP-IKEv2 messages and payloads
mean, you can say that the syntax is the same as for similarly
named IKEv2 payloads (so you get to reuse the work done for IKEv2).
- While copying the cryptographic aspects from IKEv2 is a good
idea, perhaps copying everything is not (e.g. the messages
for fast reconnect could be called something else than
a "CREATE_CHILD_SA exchange", since CHILD_SAs are not very
meaningful in this context)
- Since this document does not defined a tunneled EAP method,
I'd suggest deleting all mentions this feature of IKEv2
(or at least move the text talking about "if we supported
this feature, it would be done that way" to an Appendix).
- Section 6: "Currently five bits ... are defined": this
section defines the meaning of only three bits. Strangely
enough, two other bits are named ("S" and "F") but it
is not described why they're named, or what they mean.
- Section 6: "Each fragment sent must subsequently be
acknowledged": how?
- Section 8: length of EAP-IKEv2's MSK and EMSK is at least 64
octets: how do the parties decide how much longer than 64
octets? (or if it's exactly 64 octets, say so)
- Section 9: The part starting with "To avoid this..." sounds
fishy: what's the benefit of having two different options
in this situation?
- Section 10: What happens if the peer has forgotten the SA?
(figures 8 and 9 assume the peer still has the SA,
since it can send messages having "SK{..}")
- Section 11.4: since we have payloads whose contents are not
described in this document, we need a normative reference
to some document whey there are described. Otherwise,
an implementation can't process those contents in an
interoperable fashion...- Section 12 should include some text about identity privacy
(especially when doing fast reconnect or authenticating both
parties using shared secrets).
- Missing "IANA considerations" section.
Proposed Resolution: Discuss
Issue 305: Appendix Cleanup
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 7/18/2005
Reference:
Document: KEYING-07
Comment type: T
Priority: S
Section: Appendix A-D
Rationale/Explanation of issue:
Several of the Appendices could be pared back or combined.
Recommend combining Appendix B & C into a unified Appendix A.
Recommend combining Appendix A & D into a unified Appendix B.
Recommend renaming Appendix E & F to Appendix C & D.
Here is the new text for Appendices A & B:
Appendix A - EAP-TLS Key Hierarchy
EAP-TLS [RFC 2716] was documented prior to the development of EAP key
management terminology [RFC3748], and therefore does not explicitly
define the MSK and EMSK.
In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master
secret via a one-way function. This ensures that the TLS master
secret cannot be derived from the MSK, EMSK or IV unless the one-way
function (TLS PRF) is broken. Since the MSK is derived from the the
TLS master secret, if the TLS master secret is compromised then the
MSK is also compromised.
[RFC2716] specifies that the MSK is divided into two halves,
corresponding to the "Peer to Authenticator Encryption Key" (Enc-
RECV-Key, 32 octets, also known as the PMK) and "Authenticator to
Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the
Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key
attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send-
Key attribute.
The EMSK is also divided into two halves, corresponding to the "Peer
to Authenticator Authentication Key" (Auth-RECV-Key, 32 octets) and
"Authenticator to Peer Authentication Key" (Auth-SEND-Key, 32
octets). The IV is a 64 octet quantity that is a known value; octets
0-31 are known as the "Peer to Authenticator IV" or RECV-IV, and
Octets 32-63 are known as the "Authenticator to Peer IV", or SEND-IV.
The key derivation scheme MUST be interpreted as follows:
MSK = TLS-PRF-64(TMS, "client EAP encryption",
client.random || server.random)
EMSK = second 64 octets of:
TLS-PRF-128(TMS, "client EAP encryption",
client.random || server.random)
IV = TLS-PRF-64("", "client EAP encryption", client.random || server.random)
MSK(0,31) = Peer to Authenticator Encryption Key (Enc-RECV-Key)
(MS-MPPE-Recv-Key in [RFC2548]). Also known as the
PMK.
MSK(32,63) = Authenticator to Peer Encryption Key (Enc-SEND-Key)
(MS-MPPE-Send-Key in [RFC2548])
EMSK(0,31) = Peer to Authenticator Authentication Key (Auth-RECV-Key)
EMSK(32,63) = Authenticator to Peer Authentication Key (Auth-Send-Key)
IV(0,31) = Peer to Authenticator Initialization Vector (RECV-IV)
IV(32,63) = Authenticator to Peer Initialization vector (SEND-IV)
Where:
IV(W,Z) = Octets W through Z inclusive of the IV.
MSK(W,Z) = Octets W through Z inclusive of the MSK.
EMSK(W,Z) = Octets W through Z inclusive of the EMSK.
TMS = TLS master_secret
TLS-PRF-X = TLS PRF function defined in [RFC2246] computed to X octets
client.random = Nonce generated by the TLS client.
server.random = Nonce generated by the TLS server.
Figure A-1 illustrates the TEK key hierarchy for EAP-TLS [RFC2716],
which is based on the TLS key hierarchy described in [RFC2246]. The
TLS-negotiated ciphersuite is used to set up a protected channel for
use in protecting the EAP conversation, keyed by the derived TEKs.
The TEK derivation proceeds as follows:
master_secret = TLS-PRF-48(pre_master_secret, "master secret",
client.random || server.random)
TEK = TLS-PRF-X(master_secret, "key expansion",
server.random || client.random)
Where:
TLS-PRF-X = TLS pseudo-random function defined in [RFC2246],
computed to X octets.
| | pre_master_secret |
server| | | client
Random| V | Random
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+---->| master_secret |<------+
| | (TMS) | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key Block (TEKs) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| client | server | client | server | client | server
| MAC | MAC | write | write | IV | IV
| | | | | |
V V V V V V
Figure A-1 - TLS [RFC2246] Key Hierarchy
Appendix B - Example Transient Session Key (TSK) Derivation
To date, PPP and IEEE 802.11 ciphersuites are suitable for keying by
EAP. This Appendix describes the keying requirements of common PPP
and 802.11 ciphersuites.
PPP ciphersuites include DESEbis [RFC2419], 3DES [RFC2420], and MPPE
[RFC3078]. The DES algorithm is described in [FIPSDES], and DES
modes (such as CBC, used in [RFC2419] and DES-EDE3-CBC, used in
[RFC2420]) are described in [DESMODES]. For PPP DESEbis, a single
56-bit encryption key is required, used in both directions. For PPP
3DES, a 168-bit encryption key is needed, used in both directions. As
described in [RFC2419] for DESEbis and [RFC2420] for 3DES, the IV,
which is different in each direction, is "deduced from an explicit
64-bit nonce, which is exchanged in the clear during the [ECP]
negotiation phase." There is therefore no need for the IV to be
provided by EAP.
For MPPE, 40-bit, 56-bit or 128-bit encryption keys are required in
each direction, as described in [RFC3078]. No initialization vector
is required.
While these PPP ciphersuites provide encryption, they do not provide
per-packet authentication or integrity protection, so an
authentication key is not required in either direction.
Within [IEEE-802.11], Transient Session Keys (TSKs) are required both
for unicast traffic as well as for multicast traffic, and therefore
separate key hierarchies are required for unicast keys and multicast
keys. IEEE 802.11 ciphersuites include WEP-40, described in
[IEEE-802.11], which requires a 40-bit encryption key, the same in
either direction; and WEP-128, which requires a 104-bit encryption
key, the same in either direction. These ciphersuites also do not
support per-packet authentication and integrity protection. In
addition to these unicast keys, authentication and encryption keys
are required to wrap the multicast encryption key.
Recently, new ciphersuites have been proposed for use with IEEE
802.11 that provide per-packet authentication and integrity
protection as well as encryption [IEEE-802.11i]. These include TKIP,
which requires a single 128-bit encryption key and two 64-bit
authentication keys (one for each direction); and AES CCMP, which
requires a single 128-bit key (used in both directions) in order to
authenticate and encrypt data.
As with WEP, authentication and encryption keys are also required to
wrap the multicast encryption (and possibly, authentication) keys.
Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient
session key used to protect unicast traffic, is derived from the PMK
(octets 0-31 of the MSK), known in [RFC2716] as the Peer to
Authenticator Encryption Key. In [IEEE-802.11i], the PTK is derived
from the PMK via the following formula:
PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) ||
Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))
Where:
PMK = AAA-Key(0,31)
SA = Station MAC address (Calling-Station-Id)
AA = Access Point MAC address (Called-Station-Id)
ANonce = Access Point Nonce
SNonce = Station Nonce
EAPOL-PRF-X = Pseudo-Random Function based on HMAC-SHA1, generating
a PTK of size X octets.
TKIP uses X = 64, while CCMP, WRAP, and WEP use X = 48.
The EAPOL-Key Confirmation Key (KCK) is used to provide data origin
authenticity in the TSK derivation. It utilizes the first 128 bits
(bits 0-127) of the PTK. The EAPOL-Key Encryption Key (KEK) provides
confidentiality in the TSK derivation. It utilizes bits 128-255 of
the PTK. Bits 256-383 of the PTK are used by Temporal Key 1, and Bits
384-511 are used by Temporal Key 2. Usage of TK1 and TK2 is
ciphersuite specific. Details are available in [IEEE-802.11i]
Proposed Resolution: Discuss
Issue 306: Channel Bindings
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: 7/18/2005
Reference: http://mail.frascone.net/pipermail/eap/2005-July/003497.html
Document: KEYING-07
Comment type: T
Priority: S
Section: 1.3, 6.7
Rationale/Explanation of issue
I reviewed -07's text about channel bindings. Please find below
some suggested edits that take into account some of the discussion
about channel bindings in recent months.
>1.3 ...
>
> Channel Bindings
>
> Channel Bindings include lower layer parameters that are verified
> for consistency between the EAP peer and server. In order to
> avoid introducing media dependencies, EAP methods MUST treat
> Channel Bindings as opaque octets.
s/EAP methods MUST treat Channel Bindings as opaque octets/EAP methods
that transport Channel Bindings data MUST treat this data as opaque
octets/
> Typically the EAP method imports Channel Bindings from the lower layer on the peer, and
>
> transmits them securely to the EAP server, which exports them to
> the lower layer. However, transport may occur from EAP server to
> peer, or may be bi-directional. On the side of the exchange (peer
> or server) where Channel Bindings are verified, the lower layer
> passes the result of the verification (TRUE or FALSE) up to the
> EAP method.
>
>6.7. Channel binding
>
> It is possible for a compromised or poorly implemented EAP
> authenticator to communicate incorrect information to the EAP peer
> and/or server. This may enable an authenticator to impersonate
> another authenticator or communicate incorrect information via out-
> of-band mechanisms (such as via AAA or the lower layer protocol).
>
> Where EAP is used in pass-through mode, the EAP peer typically does
> not verify the identity of the pass-through authenticator, it only
> verifies that the pass-through authenticator is trusted by the EAP
> server. This creates a potential security vulnerability, described in
> [RFC3748] Section 7.15.
>
> [RFC3579] Section 4.3.7 describes how an EAP pass-through
> authenticator acting as a AAA client can be detected if it attempts
> to impersonate another authenticator (such by sending incorrect NAS-
> Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
> [RFC3162] attributes via the AAA protocol). However, it is possible
> for a pass-through authenticator acting as a AAA client to provide
> correct information to the AAA server while communicating misleading
> information to the EAP peer via a lower layer protocol.
>
> For example, it is possible for a compromised authenticator to
> utilize another authenticator's Called-Station-Id or NAS-Identifier
> in communicating with the EAP peer via a lower layer protocol, or for
> a pass-through authenticator acting as a AAA client to provide an
> incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA
> server via the AAA protocol.
>
> As noted in [RFC3748] Section 7.15, this vulnerability can be
> addressed by use of EAP methods that support a protected exchange of
> channel properties such as endpoint identifiers, including (but not
> limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
> [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
> [RFC2865], and NAS-IPv6-Address [RFC3162].
>
> Using such a protected exchange, it is possible to match the channel
> properties provided by the authenticator via out-of-band mechanisms
> against those exchanged within the EAP method. For example, see
> [ServiceIdent].
Add: It is also possible to achieve Channel Bindings without transporting
data over EAP. For example, see [draft-ohba-eap-aaakey-binding]. In this
approach the authenticator informs the EAP server about the Channel Binding
parameters over AAA, and the server calculates its AAA-Key based on
this parameter set, making it impossible for the peer and authenticator
to complete Secure Association Protocol if there was a mismatch in
the parameters.
The main difference between these approaches is that in the EAP-based
case an upgrade to an EAP method that supports Channel
Binding data transport is needed, impacting both the peer and the
server. In the AAA-based case the peer and the server are impacted
as well, but not at the EAP layer. However, a modification
of the authenticator is needed in the AAA-based case.
[Bernard Aboba] How about this?
"Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. For example,
see [ServiceIdent].
It is also possible to achieve Channel Bindings without transporting
data over EAP. For example, see [draft-ohba-eap-aaakey-binding]. In this
approach the authenticator informs the backend server about the Channel Binding
parameters using AAA, and the backend server calculates its AAA-Key based on
this parameter set, making it impossible for the peer and authenticator
to complete the Secure Association Protocol if there was a mismatch in
the parameters.
The main difference between these approaches is that Channel
Binding support within an EAP method may require upgrading or
changing the EAP method,
impacting both the peer and the
server. Where Channel Bindings are implemented
in AAA, the peer, authenticator and the backend server need to be
upgraded, but the EAP method need not be modified."
Proposed Resolution: Discuss
Issue 307: Rewrite of Security Requirements
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 3/31/2005
Reference:
Document: KEYING-07
Comment type: T
Priority: S
Section: 7
Rationale/Explanation of issue
Section 7 consists of requirements on EAP methods, AAA
protocols, Secure Association Protocols and Ciphersuites that is in no way
tied back to the security requirements and threat model. One is left to
wonder whether these "requirements" were developed out of thin air, or
whether there is any basis/justification for them.
The overall recommendation is to delete Section 7. Here are the details:
Section 7.1 appears to have been taken from [RFC3748] Section 7.10. It is
therefore redundant and can be deleted.
Section 7.2 relates not to requirements but rather to the security
vulnerabilities inherent in RADIUS and Diameter usage. It therefore
should be incorporated into Section 6, Security Considerations (See Issue
294). One this is done, this section can be deleted.
Section 2.3, 4, 7.3 all include requirements relating to the Secure
Association Protocol. The recommendation is to consolidate this material
into Section 4, while deleting Section 7.3, and replacing Section 2.3 with
the following:
"2.3. Secure Association Phase
The Secure Association phase (phase 2), if it occurs, begins after
the completion of EAP authentication (phase 1a) and key transport
(phase 1b).
Secure Association Protocols typically include the following
features:
[1] Generation of fresh unicast and multicast transient session keys.
[2] Integrity and replay protection. This ensures that the Secure
Association Protocol messages cannot be forged, modified or
replayed.
[3] Secure capabilities negotiation. This enables security-relevant
parameters such as cryptographic algorithms to be securely
negotiated.
[3] Key management and naming. This enables security associations to
be created and deleted, and for key state to be kept synchronized
between the peer and authenticator.
[4] Mutual proof of possession of EAP keying material between the peer
and authenticator. This enables the EAP peer and authenticator to
confirm authorization.
Aspects of the Secure Association Protocol are discussed in more
detail in Section 4."
Replace Section 4 with the following:
"4. Key Management
EAP as defined in [RFC3748] supports key derivation, but not key
management. While EAP methods may derive keying material, EAP does
provide for the management of exported or derived keys. For example,
EAP does not support negotiation of the key lifetime of exported or
derived keys, nor does it support rekey. Although EAP methods may
support "fast reconnect" as defined in [RFC3748] Section 7.2.1, rekey
of exported keys cannot occur without reauthentication. In order to
provide method independence, key management of exported or derived
keys SHOULD NOT be provided within EAP methods.
Since neither EAP nor EAP methods provide key management support, it
is RECOMMENDED that key management facilities be provided within the
Secure Association Protocol. This includes:
[a] Entity Naming. A basic feature of a Secure Association Protocol is
the explicit naming of the parties engaged in the exchange.
Explicit identification of the parties is critical, since without
this the parties engaged in the exchange are not identified and the
scope of the EAP keying parameters negotiated during the EAP
exchange is undefined. As shown in Figure 3, both the peer and NAS
may have more than one physical or virtual port. As a result, the
peer and authenticator SHOULD identify themselves in a manner that
is independent of their attached ports.
[b] Mutual proof of possession of EAP keying material. The Secure
Association Protocol MUST demonstrate possession of the keying
material transported between the backend authentication server and
authenticator (.e.g. AAA-Key), and show that both the peer and
authenticator have been authenticated and authorized. Since mutual
proof of possession is not the same as mutual authentication, the
peer cannot verify authenticator assertions (including the
authenticator identity) as a result of this exchange.
[c] Secure capabilities negotiation. In order to protect against
spoofing during the discovery phase, ensure selection of the "best"
ciphersuite, and protect against forging of negotiated security
parameters, the Secure Association Protocol MUST support secure
capabilities negotiation. This includes the secure negotiation of
usage modes, session parameters (such as security association
identifiers (SAIDs) and key lifetimes), ciphersuites and required
filters, including confirmation of security-relevant capabilities
discovered during phase 0. As part of secure capabilities
negotiation, the Secure Association Protocol MUST support integrity
and replay protection of all messages.
[d] Key naming and selection. Where key caching is supported, it may
be possible for the EAP peer and authenticator to share more than
one key of a given type. As a result, the Secure Association
Protocol MUST explicitly name the keys used in the proof of
possession exchange, so as to prevent confusion when more than one
set of keying material could potentially be used as the basis for
the exchange. Use of the key naming mechanism described in this
document is RECOMMENDED.
In order to support the correct processing of phase 2 security
associations, the Secure Association (phase 2) protocol MUST
support the naming of phase 2 security associations and associated
transient session keys, so that the correct set of transient
session keys can be identified for processing a given packet. The
phase 2 Secure Association Protocol also MUST support transient
session key activation and SHOULD support deletion, so that
establishment and re-establishment of transient session keys can be
synchronized between the parties.
[e] Generation of fresh transient session keys (TSKs). Where the lower
layer supports caching of exported EAP keying material, the EAP
peer lower layer may initiate a new session using keying material
that was derived in a previous session. Were the TSKs to be
derived from a portion of the exported EAP keying material, this
would result in reuse of the session keys which could expose the
underlying ciphersuite to attack.
As a result, in lower layers where caching of EAP keying material
is supported, the Secure Association Protocol phase is REQUIRED,
and MUST support the derivation of fresh unicast and multicast
TSKs, even when the keying material provided by the backend
authentication server is not fresh. This is typically supported
via the exchange of nonces or counters, which are then mixed with
the exported keying material in order to generate fresh unicast
(phase 2a) and possibly multicast (phase 2b) session keys. By not
using EAP keying material directly to protect data, the Secure
Association Protocol protects it against compromise.
[f] Key lifetime management. This includes explicit key lifetime
negotiation or seamless rekey. EAP does not support negotiation of
key lifetimes, nor does it support rekey without reauthentication.
As a result, the Secure Association Protocol may handle rekey and
determination of the key lifetime. Where key caching is supported,
secure negotiation of key lifetimes is RECOMMENDED. Lower layers
that support rekey, but not key caching, may not require key
lifetime negotiation. To take an example from IKE, the difference
between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were
negotiated. In IKEv2, each end of the SA is responsible for
enforcing its own lifetime policy on the SA and rekeying the SA
when necessary.
[g] Key resynchronization. It is possible for the peer or
authenticator to reboot or reclaim resources, clearing portions or
all of the key cache. Therefore, key lifetime negotiation cannot
guarantee that the key cache will remain synchronized, and the peer
may not be able to determine before attempting to use a key whether
it exists within the authenticator cache. It is therefore
RECOMMENDED for the Secure Association Protocol to provide a
mechanism for key state resynchronization. Since in this situation
one or more of the parties initially do not possess a key with
which to protect the resynchronization exchange, securing this
mechanism may be difficult.
[h] Key scope synchronization. Since the Discovery phase is handled
out-of-band, EAP does not provide a mechanism by which the peer can
determine the authenticator identity. As a result, where the
authenticator has multiple ports and key caching is supported, the
EAP peer may not be able to determine the scope of validity of the
exported EAP keying material. Similarly, where the EAP peer has
multiple ports, the authenticator may not be able to determine
whether a peer has authorization to use a particular key. To allow
key scope determination, the Secure Association Protocol SHOULD
provide a mechanism by which the peer can determine the scope of
the key cache on each authenticator, and by which the authenticator
can determine the scope of the key cache on a peer. This includes
negotiation of restrictions on key usage.
[i] Direct operation. Since the phase 2 Secure Association Protocol is
concerned with the establishment of security associations between
the EAP peer and authenticator, including the derivation of
transient session keys, only those parties have "a need to know"
the transient session keys. The Secure Association Protocol MUST
operate directly between the peer and authenticator, and MUST NOT
be passed-through to the backend authentication server, or include
additional parties.
[j] Bi-directional operation While some ciphersuites only require a
single set of transient session keys to protect traffic in both
directions, other ciphersuites require a unique set of transient
session keys in each direction. The phase 2 Secure Association
Protocol SHOULD provide for the derivation of unicast and multicast
keys in each direction, so as not to require two separate phase 2
exchanges in order to create a bi-directional phase 2 security
association."
Section 7.4 (Ciphersuite Requirements) can be incorporated into
Section 1.4.4 (Ciphersuite Independence):
"1.4.4. Ciphersuite Independence
Ciphersuite Independence is a consequence of the principles of Mode
Independence and Media Independence.
While EAP methods may negotiate the ciphersuite used in protection of
the EAP conversation, the ciphersuite used for the protection of the
data exchanged after EAP authentication has completed is negotiated
between the peer and authenticator within the lower layer, outside of
EAP.
For example, within PPP, the ciphersuite is negotiated within the
Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
authentication is completed. Within [IEEE-802.11i], the AP
ciphersuites are advertised in the Beacon and Probe Responses prior
to EAP authentication, and are securely verified during a 4-way
handshake exchange.
Since the ciphersuites used to protect data depend on the lower
layer, requiring EAP methods have knowledge of lower layer
ciphersuites would compromise the principle of Media Independence.
Since ciphersuite negotiation occurs in the lower layer, there is no
need for ciphersuite negotiation within EAP, and EAP methods generate
keying material that is ciphersuite-independent.
Algorithms for deriving TSKs MUST NOT depend on the EAP
method, although algorithms for TEK derivation MAY be specific
to the EAP method.
In order to allow a ciphersuite to be usable within the EAP keying
framework, a specification MUST be provided describing how TSKs
suitable for use with the ciphersuite are
derived from exported EAP keying parameters.
Advantages of ciphersuite-independence include:
Reduced update requirements
If EAP methods were to specify how to derive transient session keys
for each ciphersuite, they would need to be updated each time a new
ciphersuite is developed. In addition, backend authentication
servers might not be usable with all EAP-capable authenticators,
since the backend authentication server would also need to be
updated each time support for a new ciphersuite is added to the
authenticator.
Reduced EAP method complexity
Requiring each EAP method to include ciphersuite-specific code for
transient session key derivation would increase method complexity
and result in duplicated effort.
Simplified configuration
The ciphersuite is negotiated between the peer and authenticator
outside of EAP. Where the authenticator operates in "pass-through"
mode, the EAP server is not a party to this negotiation, nor is it
involved in the data flow between the EAP peer and authenticator.
As a result, the EAP server may not have knowledge of the
ciphersuites and negotiation policies implemented by the peer and
authenticator, or be aware of the ciphersuite negotiated between
them. For example, since ECP negotiation occurs after
authentication, when run over PPP, the EAP peer and server may not
anticipate the negotiated ciphersuite and therefore this
information cannot be provided to the EAP method."
The only remaining paragraph from Section 7.4 can be added to Section
2.5.1:
" TSKs MUST be cryptographically separate from each other. Similarly,
TEKs MUST be cryptographically separate from each other. In
addition, the TSKs MUST be cryptographically separate from the TEKs."In addition, consolidate Section 7.1.1 and 7.1.2 into Section 1.5, as
follows:
"1.5 EMSK Usage
The MSK and EMSK MUST be unique for each session.
The EMSK must be cryptographically independent of the MSK and TEKs, and
the EMSK MUST be secret and not known to someone observing the
EAP authentication exchange.
The EMSK MUST NOT be transported from the EAP server to another
party, and as a result the EMSK is not replicated between
the backend server and authenticator via the AAA protocol. Although the
EMSK is not replicated, it is possible to derive keys from the EMSK via a
one-way function, and for these derived keys to be replicated from the
backend server to the authenticator.
Where a backend server is present the EMSK will not be available on
the authenticator, and therefore in order for the principle of Mode
Independence to be satisfied, TSKs derived within the lower layer
MUST NOT depend directly on the EMSK. The EMSK MUST NOT be used
directly for cryptographic protection of data."
Proposed Resolution: Accept
Issue 308: Rewrite of Lower Layer Section
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 9/21/2005
Reference: http://mail.frascone.net/pipermail/eap/2005-September/003605.html
Document: KEYING-07
Comment type: T
Priority: S
Section: 2
Rationale/Explanation of issue
Here is a proposed rewrite of Section 2 of the EAP Key Management
Framework document to improve clarity and clarify issues relating to lower
layer key usage.
--------------------------------------------------------------------
2. Lower Layer Operation
2.1. Overview
Where EAP key derivation is supported, the conversation typically
takes place in three phases:
Phase 0: Discovery
Phase 1: Authentication
1a: EAP authentication
1b: AAA Key Transport (optional)
Phase 2: Secure Association Establishment
2a: Unicast Secure Association
2b: Multicast Secure Association (optional)
Of these phases, Phase 0, 1b and Phase 2 are handled by a lower
layer. In the discovery phase (phase 0), peers locate
authenticators and discover their capabilities. For example, a peer
may locate an authenticator providing access to a particular network,
or a peer may locate an authenticator behind a bridge with which it
desires to establish a Secure Association.
The authentication phase (phase 1) may begin once the peer and
authenticator discover each other. This phase always includes EAP
authentication (phase 1a). Where the chosen EAP method supports key
derivation, in phase 1a EAP keying material is derived on both the
peer and the EAP server. This keying material may be used for
multiple purposes, including protection of the EAP conversation and
subsequent data exchanges.
An additional step (phase 1b) is required in deployments which
include a backend authentication server, in order to transport keying
material from the backend authentication server to the authenticator.
In order to obey the principle of Mode Independence, where a backend
server is present AAA Key transport needs to replicate the exported
EAP keying material and/or derived keys required for derivation of
the TSKs. Since existing TSK derivation techniques depend solely on
the MSK, in existing AAA implementations, this is the only keying
material replicated in the AAA key transport phase 1b.
A Secure Association exchange (phase 2) then occurs between the peer
and authenticator in order to manage the creation and deletion of
unicast (phase 2a) and multicast (phase 2b) security associations
between the peer and authenticator. The conversation between the
parties is shown in Figure 3.
EAP peer Authenticator Auth. Server
-------- ------------- ------------
|<----------------------------->| |
| Discovery (phase 0) | |
|<----------------------------->|<----------------------------->|
| EAP auth (phase 1a) | AAA pass-through (optional) |
| | |
| |<----------------------------->|
| | AAA Key transport |
| | (optional; phase 1b) |
|<----------------------------->| |
| Unicast Secure association | |
| (phase 2a) | |
| | |
|<----------------------------->| |
| Multicast Secure association | |
| (optional; phase 2b) | |
| | |
Figure 3: Conversation Overview
2.2. Discovery Phase
In the discovery phase (phase 0), the EAP peer and authenticator
locate each other and discover each other's capabilities. Discovery
can occur manually or automatically, depending on the lower layer
over which EAP runs. Since authenticator discovery is handled
outside of EAP, there is no need to provide this functionality within
EAP.
For example, where EAP runs over PPP, the EAP peer might be
configured with a phone book providing phone numbers of
authenticators and associated capabilities such as supported rates,
authentication protocols or ciphersuites. In contrast, PPPoE
[RFC2516] provides support for a Discovery Stage to allow a peer to
identify the Ethernet MAC address of one or more authenticators and
establish a PPPoE SESSION_ID.
IEEE 802.11 [IEEE-802.11] also provides integrated discovery support
utilizing Beacon and/or Probe Request/Response frames, allowing the
peer (known as the station or STA) to determine the MAC address and
capabilities of one or more authenticators (known as Access Point or
APs).
2.3. Authentication Phase
Once the peer and authenticator discover each other, they exchange
EAP packets. Typically, the peer desires access to the network, and
the authenticators provide that access. In such a situation, access
to the network can be provided by any authenticator attaching to the
desired network, and the EAP peer is typically willing to send data
traffic through any authenticator that can demonstrate that it is
authorized to provide access to the desired network.
An EAP authenticator may handle the authentication locally, or it may
act as a pass-through to a backend authentication server. In the
latter case the EAP exchange occurs between the EAP peer and a
backend authenticator server, with the authenticator forwarding EAP
packets between the two. The entity which terminates EAP
authentication with the peer is known as the EAP server. Where pass-
through is supported, the backend authentication server functions as
the EAP server; where authentication occurs locally, the EAP server
is the authenticator. Where a backend authentication server is
present, at the successful completion of an authentication exchange,
EAP keying material is transported to the authenticator (phase 1b).
EAP may also be used when it is desired for two network devices (e.g.
two switches or routers) to authenticate each other, or where two
peers desire to authenticate each other and set up a secure
association suitable for protecting data traffic.
Some EAP methods exist which only support one-way authentication;
however, EAP methods deriving keys are required to support mutual
authentication. In either case, it can be assumed that the parties
do not utilize the link to exchange data traffic unless their
authentication requirements have been met. For example, a peer
completing mutual authentication with an EAP server will not send
data traffic over the link until the EAP server has authenticated
successfully to the peer, and a Secure Association has been
negotiated.
Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction. Both peers
may act as authenticators and authenticatees at the same time.
Successful completion of EAP authentication and key derivation by a
peer and EAP server does not necessarily imply that the peer is
committed to joining the network associated with an EAP server.
Rather, this commitment is implied by the creation of a security
association between the EAP peer and authenticator, as part of the
Secure Association Protocol (phase 2). As a result, EAP may be used
for "pre-authentication" in situations where it is necessary to pre-
establish EAP security associations in order to decrease handoff or
roaming latency.
2.4. Secure Association Phase
The Secure Association phase (phase 2), if it occurs, begins after
the completion of EAP authentication (phase 1a) and key transport
(phase 1b).
Secure Association Protocols typically include the following
features:
[1] Generation of fresh unicast and multicast transient session keys.
[2] Integrity and replay protection. This ensures that the Secure
Association Protocol messages cannot be forged, modified or
replayed.
[3] Secure capabilities negotiation. This enables security-relevant
parameters such as cryptographic algorithms to be securely
negotiated.
[4] Key naming. In order to avoid confusion in the case where an EAP
peer has more than one set of exported EAP parameters applicable to
establishment of a phase 2 security association with an
authenticator, the secure Association protocol needs to identify
the keying material for use in the Secure Association Protocol
exchange.
[5] Key management. This enables security associations to be created
and deleted, and for key state to be kept synchronized between the
peer and authenticator.
[6] Mutual proof of possession of EAP keying material between the peer
and authenticator. This enables the EAP peer and authenticator to
confirm authorization.
Aspects of the Secure Association Protocol are discussed in more
detail in Section 4.
2.5. Layering
In completion of EAP authentication, EAP methods on the peer and EAP
server export the Master Session Key (MSK), Extended Master Session
Key (EMSK), Initialization Vector (IV), Peer-ID, Server-ID, Session-
ID and Key-Lifetime. As illustrated in Figure 4, keying material and
parameters exported by EAP methods are passed down to the EAP peer or
authenticator layers, which passes them to the EAP layer. Keying
material and related parameters (including Channel Bindings) MUST NOT
be cached by the EAP peer or authenticator layers, or the EAP layer.
Based on the Method-ID exported by the EAP method, the EAP layer
forms the EAP Session-ID by concatenating the EAP Expanded Type with
the Method-ID. Together with the MSK, EMSK, IV, Peer-ID, Server-ID,
and Key-Lifetime, the EAP layer passes the Session-ID down to the
lower layer.
The Method-ID is exported by EAP methods rather than the Session-ID
so as to prevent EAP methods from writing into each other's Session-
ID space.
2.6. Key Usage
In order to preserve the security of keys derived within EAP methods,
lower layers other than AAA MUST NOT export keys passed down by EAP
methods. This implies that EAP keying material or parameters passed
down to a lower layer are for the exclusive use of that lower and
MUST NOT be used within another lower layer.
The exception to this rule is AAA. As illustrated in Figure 5, the
AAA client provides transported EAP keying material and parameters to
the EAP authenticator lower layer. In order to prevent the
compromise of transported EAP keying material and parameters, the AAA
client and EAP authenticator MUST be co-resident.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| EAP method |
| |
| MSK, EMSK, IV, Channel |
| Peer-ID, Server-ID, Bindings |
| Method-ID, |
| Key-Lifetime |
| |
| V ^ ^ |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| EAP ! Peer or Authenticator ! ! |
| ! layer ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| EAP ! layer ! ! |
| ! ! ! |
| ! Session-ID = ! ! |
| ! Expanded-Type || ! ! |
| ! Method-ID ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| Lower ! layer ! ! |
| ! ! ! |
| V V ^ |
| MSK, EMSK, IV, Channel Result |
| Peer-ID, Server-ID, Bindings |
| Session-ID, |
| Key-Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Flow of EAP parameters
Peer Pass-through Authenticator Authentication
Server
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
|EAP method | |EAP method |
| V | | V |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | |EAP | EAP | | | ! |
| ! | |Peer | Auth.| EAP Auth. | | ! |
|EAP ! peer| | | | | |EAP !Auth.|
| ! | | | | | | ! |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | | | | | ! |
|EAP !layer| | EAP layer| EAP layer | |EAP !layer|
| ! | | | | | ! |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | | | | | ! |
| ! | | +-----------+ | | ! |
| ! | | ! | ! | | ! |
|Lower!layer| | Lower!layer| AAA ^ /IP | | AAA ! /IP |
| ! | | ! | ! | | ! |
| V | | V | ! | | ! |
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
! !
! !
+---------<-------+
AAA Protocol
Figure 5: Flow of EAP Keying Material and Parameters
2.6.1. Caching
If explicitly permitted within the lower layer specification, lower
layers MAY cache exported EAP keying material and related parameters,
including Channel Bindings. So as to enable interoperability, new
EAP lower layer specifications MUST describe EAP key caching
behavior. The caching behavior of existing EAP lower layers is as
follows:
PPP PPP, defined in [RFC1661] does not support caching of EAP key
material or parameters. Therefore EAP keying material passed down
to the lower layer is assumed to be lost and cannot be recovered.
IKEv2
IKEv2, defined in [IKEv2] only uses EAP keying material for
authentication purposes and not key derivation. As a result, IKEv2
does not cache EAP keying material or parameters, nor does it
utilize the Key-Lifetime to determine the lifetime of IPsec SAs.
As result, once IKEv2 authentication completes it is assumed that
EAP keying material and parameters are discarded.
IEEE 802.11i
IEEE 802.11i enables caching of the MSK, but not the EMSK, IV,
Peer-ID, Server-ID, Session-ID, or Key-Lifetime. More details are
about the structure of the cache are available in [IEEE-802.11i].
IEEE 802.1X-2004
IEEE 802.1X, defined in [IEEE-802.1X] does not support caching of
EAP keying material or parameters.
AAA Existing AAA servers supporting RADIUS/EAP [RFC3579] or Diameter
EAP [RFC4207] do not support caching of EAP keying material or
parameters. Regardless of whether a given AAA implementation
supports caching, keying material transported by AAA MUST be
discarded by the AAA server once it is sent.
2.7. Lower Layer Naming
Within the lower layer, the EAP peer and authenticator typically
utilize lower layer names to identify each other and define the scope
of cached keying material. However EAP methods treat lower layer
peer and authenticator identities as opaque blobs and do not
interpret them. For example, EAP peers cannot compare the lower
layer authenticator identifier with the Server-ID provided by the EAP
method, since these two identifiers will not be the same where pass-
through authentication is implemented.
For the purpose of identifying the authenticator to the peer, it is
RECOMMENDED that the NAS-Identifier attribute be provided by the
authenticator to the peer, and that if AAA is enabled, that the
authenticator/AAA client include the NAS-Identifer attribute within
the Access-Request sent to the AAA server. In order to ensure
against forgery, it is RECOMMENDED that the peer and authenticator
securely verify the authenticator identity, such as via the Secure
Association Protocol.
For the purpose of identifying the peer to the authenticator, the EAP
Peer-ID provided within the EAP method is recommended. Where the
authenticator acts as a pass-through, the AAA server may include the
Peer-ID in an Access-Accept if requested to do so by the
authenticator/AAA client. Alternatively, the peer may provide the
authenticator with the Peer-ID via the lower layer, such as within
the Secure Association Protocol.
2.8. Lower Layer Key Hierarchy
Based on the EAP keying material and parameters provided to it, the
lower layer may derive two other types of keys:
[3] Keying material calculated from exported EAP keying material
[4] Session keys calculated or transported by the Secure Association
Protocol: TSKs.
In order to satisfy the principle of Mode Independence, a lower layer
MUST only base the derivation of sesson keys on exported EAP
parameters guaranteed to be present on the peer and authenticator.
This implies that the Transient Sesion Keys (TSKs), known only to the
peer and authenticator, may only depend on exported EAP parameters
replicated by AAA from the EAP server to the authenticator.
TSKs MUST be cryptographically separate from each other. Similarly,
TEKs MUST be cryptographically separate from each other. In
addition, the TSKs MUST be cryptographically separate from the TEKs.
In existing usage, the only exported EAP parameter that is replicated
by AAA as the result of a successful EAP authentication is the MSK.
In existing usage, the AAA-Key is always derived from the MSK and so
can be referred to using the MSK name. AAA-Key = MSK(0,63).
The exported EAP parameters replicated from the EAP server to the
peer have a scope defined by the EAP peer name (if securely provided
to the authenticator), and the authenticator name (if securely
provided to the peer).
In order to avoid confusion in the case where an EAP peer has more
than one set of exported EAP parameters applicable to establishment
of a phase 2 security association with an authenticator, the secure
Association protocol needs to identify the keying material for use in
the Secure Association Protocol exchange.
When the authenticator acts as an endpoint of the EAP conversation
rather than a pass-through, EAP methods are implemented on the
authenticator as well as the peer. If the EAP method negotiated
between the EAP peer and authenticator supports mutual authentication
and key derivation, the EAP Master Session Key (MSK) and Extended
Master Session Key (EMSK) are derived on the EAP peer and
authenticator and exported by the EAP method. In this case, the MSK
and EMSK are known only to the peer and authenticator and no other
parties. The TEKs and TSKs also reside solely on the peer and
authenticator. This is illustrated in Figure 7. As demonstrated in
[I-D.ietf-roamops-cert], in this case it is still possible to support
roaming between providers, using certificate-based authentication.
Where a backend authentication server is utilized, the situation is
illustrated in Figure 8. Here the authenticator acts as a pass-
through between the EAP peer and a backend authentication server. In
this model, the authenticator delegates the access control decision
to the backend authentication server, which acts as a Key
Distribution Center (KDC). In this case, the authenticator
encapsulates EAP packet with a AAA protocol such as RADIUS [RFC3579]
or Diameter [RFC4072], and forwards packets to and from the backend
authentication server, which acts as the EAP server. Since the
authenticator acts as a pass-through, EAP methods reside only on the
peer and EAP server As a result, the TEKs, MSK and EMSK are derived
on the peer and EAP server.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | Local to |
| | EAP |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | TEK | | MSK | |EMSK | |IV | | |
| |Derivation | |Derivation | |Derivation | |Derivation | | |
| +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | | ^
| MSK (64B) | EMSK (64B) | IV (64B) Exported|
| | | by |
| | | EAP |
| V V v
| ---+
| AAA-Key Transported |
| by AAA |
| Protocol |
V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| TSK Derivation | Lower layer |
| [AAA-Key Cache] | Specific |
| | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
Figure 6: Complete Key Hierarchy
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| |===============| |
| |EAP, TEK Deriv.|Authenti-|
| |<------------->| cator |
| | | |
| | Secure Assoc. | |
| peer |<------------->| (EAP |
| |===============| server) |
| | Link layer | |
| | (PPP,IEEE802) | |
| | | |
|MSK,EMSK | |MSK,EMSK |
| (TSKs) | | (TSKs) |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK | MSK, EMSK
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
| (TEKs) | | (TEKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
Figure 7: Relationship between EAP peer and authenticator (acting as
an EAP server), where no backend authentication server is present.
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| |===============| |========| |
| |EAP, TEK Deriv.| | | |
| |<-------------------------------->| backend |
| | | |AAA-Key/| |
| | Secure Assoc. | | Name | |
| peer |<------------->|Authenti-|<-------| auth |
| |===============| cator |========| server |
| | Link Layer | | AAA | (EAP |
| | (PPP,IEEE 802)| |Protocol| server) |
| | | | | |
|MSK,EMSK | | MSK | |MSK,EMSK |
| (TSKs) | | (TSKs) | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| MSK, EMSK | MSK, EMSK
| |
| |
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
| (TEKs) | | (TEKs) |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
Figure 8: Pass-through relationship between EAP peer, authenticator
and backend authentication server.[Joe Salowey]
I think in general this looks pretty good. I have some comments and
questions:
Section 2.3
- In paragraph 4 it states
"In either case, it can be assumed that the parties do not utilize the
link to exchange data traffic unless their authentication requirements
have been met."
Is there a reason why it is useful to assume this? I'm not sure that it
needs to be true (although I agree that it often is).
- in paragraph 6
It should also state that successful EAP authentication and key
derivation does not necessarily mean that the peer will be granted
access. There is typically authorization and resource allocation which
also must happen can could fail. This may be handled (or not handled)
differently by different lower layers.=20
Section 2.4=20
- is [3] related to capabilities in the discovery phase?
- What is meant by "more than one set of exported EAP parameters" in [4]
Section 2.5
- I thought we were deprecating IV, should we mention it here?
- Do we discuss key lifetime elsewhere in the document? I think it
needs more discussion and I'm not really crazy about exporting a value
called key lifetime from a mechanism, perhaps maximum-key-lifetime would
be better although I have reservations about that too since a key
lifetime may depend upon how it is used.
- Is methodID defined elsewhere? Is it a value exported by the EAP
method that uniquely identifies a particular execution of the EAP
method?
Section 2.6
- I am not sure that a lower layer MUST NOT export keys passed down by
EAP methods to other lower layers. It should at least be possible for a
lower layer to export keys derived from keys passed down by EAP methods
to other lower layers.
[Bernard Aboba]
The problem with sharing keys between media is that it
creates cascading vulnerabilities. If one media has a weak
ciphersuite that results in key compromise, then if keys are
shared between media, this could result in compromise of a
key used on another media with a strong ciphersuite.
At IETF 62, Sam Hartman brought up this point.
The one exception to this is AAA, which shares keying
material received by the AAA client with the EAP authenticator.
[Joe Salowey]
I agree that the same key should not be used for two different
purposes, however it should be possible for an implementation of a
"lower layer" to use a key to derive keying material to be used within
it's domain of applicability. These derived keys may actually be used
by different entities. Here is a possible revision to clarify this:
" In order to preserve separation of keying material and security
considerations fort lower layers separate,
lower layers MUST NOT export keys passed down by EAP methods outside
their domain of control. This implies that EAP keying material or
parameters passed down to a lower layer are for the exclusive use of
that lower and MUST NOT be used within another lower layer for a
different purpose."
[Bernard Aboba] This looks good.
[Joe Salowey]
- The EMSK MUST NOT be exported to a lower layer. AMSKs derived form
the EMSK may be exported.
[Bernard Aboba] The EAP method calculates the EMSK and exports it. Methods
do not calculate AMSKs. The EAP layer cannot know whether
the lower layer will calculate AMSKs or not. So the EAP
layer really has no choice but to pass the EMSK down to the
lower layer.
[Joe Salowey]
Perhaps methods should deal with derivation of AMSKs. I don't
think it is appropriate for the EMSK to be passed down to any lower
layer. I also don't think it is appropriate to call AAA a lower layer
as it is a bit confusing and a special case. I think between the
EAP-Server and EAP-Authenticator is a key distribution (or perhaps
parameter distribution) "layer" which controls the distribution (and
perhaps derivation) of keys. When there is AAA involved this
distribution layer uses the AAA protocol between the AAA server and AAA
client. When there is no AAA involved then the distribution layer is
local between the EAP implementation in the lower layer. The
distribution layer may help clarify the above exception to lower layers
and exported key material.
[Bernard Aboba]
RFC 3748 describes the export of the EMSK by EAP methods. Since the EAP
layer does not cache keys and needs to maintain lower layer independence,
when it obtains the EMSK from the method, it can't know that a given lower
requires an AMSK unless the lower layer specifically indicates that it needs
an AMSK and provides all the parameters to calculate it. Are you suggesting
that there is an interface between the lower layer and EAP layer, indicating
what keys are to be passed down to the lower layer?
One question is how such an interface would work within the EAP layering
model described in RFC 3748, Figure 2. One hypothesis is that the lower
layer on the EAP authenticator can indicate to the EAP layer what types of
keys it needs.
>I also don't think it is appropriate to call AAA a lower layer
>as it is a bit confusing and a special case.
RFC 3748 Figure 2 shows a picture of EAP with AAA/IP functioning as an EAP
lower layer. For the purposes of EAP key management, a AAA lower layer
interacts with the EAP layer the same as any other lower layer, no?
For example, doesn't AAA receive the same keys from the EAP layer as any
other lower layer? It might be able to do things that other lower layers
can't (like replicating keys between entities) but that is a separate issue.
>I think between the
>EAP-Server and EAP-Authenticator is a key distribution (or perhaps
>parameter distribution) "layer" which controls the distribution (and
>perhaps derivation) of keys.
AAA can handle the derivation of keys, just like any other lower layer.
Key transport is a special property of AAA, though.
If you look at figure 2 of RFC 3748, it shows the EAP authenticator, with
one interface having a conventional EAP lower layer, and the other interface
having a AAA lower layer, with EAP packets being routed between interfaces.
Presumably the AAA packet that carries EAP packets also carries the keys,
and one question that arises is whether the keys travel the same path that
the EAP packet does or not. If so, then the AAA-transported keying material
gets passed down into the lower layer the same way as locally generated keys
do. Since the EMSK is not replicated, this would imply that an AMSK needs
to be passed down to the lower layer, not the EMSK.
>When there is no AAA involved then the distribution layer is
>local between the EAP implementation in the lower layer.
The EAP layer sits on top of the lower layer, so I'm not sure where a
"distribution" layer would fit in.
[Bernard Aboba]
On the other hand, I think it makes sense to say that AAA
MUST NOT transport the EMSK, or that the EAP peer or
authenticator MUST NOT use the EMSK directly. It also makes
sense to say that existing lower layers (including AAA) do
not cache the EMSK.
[Joe Salowey] I agree with this.
Section 2.7
- I don't quite understand the goal of this section. It is called
naming, but the section talks about securely verifying names which is
somewhat different. What is this section trying to accomplish?
Section 2.8
- paragraph 8 - the last sentence " As demonstrated in
[I-D.ietf-roamops-cert], in this case it is still possible to support
roaming between providers, using certificate-based authentication."
seems out of context.
Proposed Resolution: Accept
Issue 309: Review
Submitter name: Maryline Maknavicius
Submitter email address: Maryline.Maknavicius@int-evry.fr
Date first submitted: 11/09/2005
Reference: http://lists.frascone.com/pipermail/eap/msg03755.html
Document: KEYING-08
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue
Please find hereafter few comments on draft-ietf-eap-keying-08.
1. IMHO the meaning of "lower layer" should be clarified and make consistent
through all the document.
For instance, figure 3 and section 2.3 consider lower layer as including AAA,
while figure 4 and associated explanations of section 2.2 consider AAA and lower
layers separately.
For instance, this does not help understanding section 2.4.1 :
"[a] The lower layer MAY specify additional restrictions on key usage,
such as limiting the use of EAP keying material and parameters on
the EAP peer to the port over which on the EAP conversation was
conducted."
where I guess lower layer does not correspond to AAA, but I may have
misunderstood.
To clarify, I think a definition of "lower layers" is needed in section 1.2.
2. In section 2.1, a typical conversation with phases is given with no details
on what applies for specific lower layer protocols like IKEv2, PPP, IEEE
802.11i...
However, in section 2.3 (caching), explanations are personalized to each lower
layer protocol, giving clues on how this framework should integrate in each
protocol.
I feel like a section (or an appendix) is missing on how this framework applies
to current lower layer protocols.
3. Other clarifications needed in section 3.2:
" As a result, while the lifetime of calculated keys can be less than
or equal that of the exported keys they are derived from, it cannot
be greater. For example, TSK re-key may occur prior to EAP re-
authentication."I do not understand how the last sentence ("TSK re-key may occur prior to EAP
re-authentication") illustrates that exported keys have greater/same lifetime
than derived keys. Maybe to be removed or better explained.
[Bernard Aboba]
The issue of the meaning of "lower layer" was also brought up in Issue 320.
Are those changes sufficient to clarify the issue?
Does the following change clarify the re-key issue?
In Section 3.2, change:
" As a result, while the lifetime of calculated keys can be less than
or equal that of the exported keys they are derived from, it cannot
be greater. For example, TSK re-key may occur prior to EAP re-
authentication."
To:
" As a result, while the lifetime of calculated keys can be less than
or equal that of the exported keys they are derived from, it cannot
be greater. For example, when EAP re-authentication occurs, TSK
re-key will also occur. However, this does not prohibit TSK re-key
from occurring prior to expiration of the lifetime of exported keys.
For example, TSK re-key may occur prior to EAP re-authentication."
Here is some additional material on the EAP conversation phases:
Add the following material to Section 2.1:
Existing EAP lower layers implement phase 0, 2a and 2b in different ways:
PPP PPP, defined in [RFC1661] does not support discovery, nor does
it include a Secure Association Protocol.
PPPOE PPPOE, defined in [RFC2516], includes support for a Discovery stage
(phase 0). In this step, the EAP peer sends a PPPoE Active Discovery
Initiation (PADI) packet to the broadcast address, indicating
the service it is requesting. The Access Concentrator replies
with a PPPOE Active Discovery Offer (PADO) packet containing
its name, the service name and an indication of the services
offered by the concentrator. The discovery phase is not secured.
PPPOE, like PPP, does not include a Secure Association Protocol.
IKEv2
IKEv2, defined in [RFC4306], handles the derivation of unicast security
associations (phase 2a), while the derivation of multicast security
associations (phase 2b) is handled in a separate group key management protocol,
as described in [RFC4046]. Several mechanisms have
been proposed for discovery of IPsec security gateways.
[RFC2230] discusses the use of KX Resource Records (RRs) for
IPsec gateway discovery. However, while KX RRs are
supported by many DNS server implementations, they have not yet been
widely deployed. Alternatively, DNS SRV [RFC2782] can be used for
this purpose. Where DNS is used for gateway location, DNS security
mechanisms such as DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and
Simple Secure Dynamic Update [RFC3007] are available.
IEEE 802.11i
IEEE 802.11, defined in [IEEE-802.11], handles discovery via the
Beacon and Probe Request/Response mechanisms. EAP authenticators
periodically announce their service names (SSIDs) as well as
capabilities using Beacon frames. Alternatively, EAP peers
can query for authenticators by sending a Probe Request to the
broadcast address. The 4-way handshake defined in [IEEE-802.11i]
enables the derivation of unicast (phase 2a) and multicast/broadcast
(phase 2b) secure associations. Note that since the group key
exchange transports a group key from the authenticator to the
peer, two 4-way handshakes may be required in order to support
peer-to-peer communications.
IEEE 802.1X-2004
IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support
discovery (phase 0), nor does it provide for derivation of unicast
or multicast secure associations.
IEEE 802.16e
IEEE 802.16e, defined in [IEEE-802.16e] {need text}
Proposed Resolution: Accept
Issue 310: Definitions
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: 11/07/2005
Reference: http://lists.frascone.com/pipermail/eap/msg03736.html
Document: KEYING-08
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue
o Terms AAA server, backend authentication server,
EAP server: EAP server is a different entity.
But it would be useful to use a single term for the
"backend authentication server"/AAA server. The
document already states that the terms are
used interchangeably. For backwards compatibility
reasons (e.g. RFC 3748) we should not delete the
terms, but use just one through the eap-keying
document.
o Definition of "export". Not sure if we need to add
anything here.
o AAA-Key. There has indeed been confusion. But
It seems that Bernard's new definition works:
AAA-Key
The
term "AAA-Key" is synonymous with MSK.
o Use of MSK as a basis for AMSKs. This appears to
not possible due to the use MSK for another purpose
already.
o Definition of PMK. We may need to say less here.
Suggested text:
Pairwise Master Key (PMK)
Lower layers use MSK in lower-layer dependent manner.
For instance, in [IEEE-802.11i] Octets 0-31 of the MSK
are known as the Pairwise Master Key (PMK). In
[IEEE-802.11i] the TKIP and AES CCMP ciphersuites derive
their Transient Session Keys (TSKs) solely from the PMK, whereas
the WEP ciphersuite as noted in [RFC3580], derives its TSKs from
both halves of the MSK. In [802.16e], the MSK is truncated to
40 octets for PMK and 20 octets for PMK2.
and delete PMK usage from
Appendix A.
o Definition of AMSKs here vs. in the extensions.
We have discussed this in other threads already.
I think we were leaning on defining them here,
but we can discuss this issue in the meeting today.
Proposed Resolution:
In Section 1.2, change the definition of PMK to the following:
Pairwise Master Key (PMK)
Lower layers use MSK in lower-layer dependent manner.
For instance, in [IEEE-802.11i] Octets 0-31 of the MSK
are known as the Pairwise Master Key (PMK). In
[IEEE-802.11i] the TKIP and AES CCMP ciphersuites derive
their Transient Session Keys (TSKs) solely from the PMK, whereas
the WEP ciphersuite as noted in [RFC3580], derives its TSKs from
both halves of the MSK. In [802.16e], the MSK is truncated to
40 octets for PMK and 20 octets for PMK2.
Change the term "AAA server" to "backend authentication server" throughout the document.
In Appendix A, change:
" [RFC2716] specifies that the MSK is divided into two halves,
corresponding to the "Peer to Authenticator Encryption Key" (Enc-
RECV-Key, 32 octets, also known as the PMK) and "Authenticator to
Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the
Enc-RECV-Key (the PMK) is transported in the MS-MPPE-Recv-Key
attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send-
Key attribute."
To:
" [RFC2716] specifies that the MSK is divided into two halves,
corresponding to the "Peer to Authenticator Encryption Key" (Enc-
RECV-Key, 32 octets) and "Authenticator to
Peer Encryption Key" (Enc-SEND-Key, 32 octets). In [RFC2548], the
Enc-RECV-Key is transported in the MS-MPPE-Recv-Key
attribute, and the Enc-SEND-Key is transported in the MS-MPPE-Send-
Key attribute."
Proposed Resolution: Accept
Issue 311: EAP and Authorization
Submitter name: Avi Lior
Submitter email address: avi@bridgewatersystems.com
Date first submitted: 11/03/2005
Reference: http://lists.frascone.com/pipermail/eap/msg03709.html
Document: KEYING-08
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue
In
draft-ietf-eap-keying-08.txt page 6:
"The EAP server
also
stores the peer's identity and/or other information
necessary to
decide whether access to some service should be
granted. The peer
stores information necessary to
choose which secret to use for which
service."
The issue i have is
that the above seems to indicate that the EAP-Server is somehow involved in
authorization.
This is *hopefully"
not true, and contradicts section 4.1 of the same draft.
Suggest
re-write:
"The EAP server also
stores the peer's identity and the
peer
stores information necessary to choose which secret to use
for which
service."
Note also that in
the following paragraph the sentence is repeated again:
"If authentication
is based on proof of possession of the private key
corresponding
to the public key contained within a certificate, the
parties
store the EAP method to be used and the trust anchors used to
validate the certificates. The EAP server also stores the
peer's
identity and/or other information necessary to decide
whether access
to some service should be granted. The peer
stores information
necessary to choose which certificate to use
for which service."
Suggested
re-write:
"If authentication is based on proof of possession
of the private key
corresponding to the public key contained
within a certificate, the
parties store the EAP method