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 to be
used and the trust anchors used to
validate the
certificates. The EAP server also stores the peer's
identity and the peer stores information
necessary to choose
which certificate to use for which service."
[Joe Salowey]
"The EAP server also stores the
peer's identity and/or other information
necessary to decide whether access
to some service should be granted. "
This sentence (appearing twice)
makes it sound like the EAP server is
going to decide whether to access to a
server should be granted. It
would be better to say something
like
"The EAP server also stores the peer's identity and/or other
information
associated with the identity. This information may be
provided with the
authenticated identity to the entity that determines
whether access to
the service that required EAP authentication should be
granted."
[BA] The proposed resolution is as
follows:
In Section 1.3, change:
" 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.
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."
To:
"The EAP server also stores the peer's identity as
well as other information
associated with it. This information may be used to
determine whether access
to some service should be granted. The
peer
stores information necessary to choose which secret to use for
which
service.
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 the peer stores information
necessary to choose
which certificate to use for which service."
Proposed Resolution: Accept
Issue 312: Editorial Review
Submitter name: Mats Naslund
Submitter email address: Mats.Naslund@ericsson.com
Date first submitted: November 30, 2005
Reference:
Document: Keying-08
Comment type: E
Priority: 1
Section: multiple
Rationale/Explanation of issue:
The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document
provides a framework for the generation, transport and usage of
MN: In what sense is _generation_ of key material really covered?
It explains how some methods have done, but does it really specify
a framework for key generation?
Transient Session Keys (TSKs)
Session keys used to protect data exchanged in a session between
the peer and 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
B.
MN: sorry, didn't find a single such example.
AAA-Key
A key derived by the peer and EAP server, used by the peer and
authenticator in the derivation of Transient Session Keys (TSKs).
Where a backend authentication server is present, the AAA-Key is
transported from the backend authentication server to the
authenticator. 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).
MN: Why not show a figure of the hierachy? In fact, what does it look like?
---> TEK
/
.../ ---> MSK = AAAk ----> TSK
\ \
\ \---> PMK --> TSK
\
\---> EMSK
[BA] The document doesn't really provide a framework for the generation of
EAP keying material (MSK/EMSK). At best it describes some requirements and
provides some examples.
The TSK generation examples are no longer in Appendix B; this is now
discussed in Section 2.3 (not sure this is the best place for that though).
The discussion might be expanded to talk a bit more about the security
properties of various schemes:
PPP: TSKs generated directly from MSK. Caching not supported,
since this could lead to TSK reuse. PFS only possible with
methods that support it.
IEEE 802.11i: TSKs generated from MSK via 4-way handshake. Caching
allowed since freshness is guaranteed. PFS not possible
where cached PMKs are used.
IKEv2: TSKs generated from IKEv2 exchange, EAP keying material
only used for authentication. No caching. PFS can be
negotiated.
IEEE 802.16e: TSKs generated by the authenticator. EAP keying material
used to encrypt, and integrity protect the transported
TSK. PFS not possible.
Figure 1 currently includes the TEKs, MSK, EMSK. In -07, Figure 5
included the AAA-Key and TSKs, though not the PMK. The problem
with that figure is that it was potentially misleading, since it
implied that the TSKs are always derived from the MSK. As noted
above, this is not necessarily the case.
Perhaps we can include MSK = AAA-Key in figure 1 and maybe add
a few words about the PMK, just to say that it represents a
portion of the MSK (the portion varies between different lower
layers).
[BA] The proposed resolution is as follows:
In the Abstract, change:
" The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document
provides a framework for the generation, transport and usage of
keying material generated by EAP authentication algorithms, known as
"methods". It also specifies the EAP key hierarchy."
To:
" The Extensible Authentication Protocol (EAP), defined in [RFC3748],
enables extensible network access authentication. This document
provides a framework for the transport and usage of
keying material generated by EAP authentication algorithms, known as
"methods". It also specifies the EAP key hierarchy."
In Section 1, change:
" This document provides a framework for the generation, transport and
usage of keying material generated by EAP authentication algorithms,
known as "methods". In EAP keying material is generated by EAP
methods. Part of this keying material may be used by EAP methods
themselves and part of this material may be exported. The exported
keying material may be transported by AAA protocols or transformed by
Secure Association Protocols into session keys which are used by
lower layer ciphersuites. This document describes each of these
elements and provides a system-level security analysis. It also
specifies the EAP key hierarchy."
To:
" This document provides a framework for the transport and
usage of keying material generated by EAP authentication algorithms,
known as "methods". In EAP, keying material is generated by EAP
methods. Part of this keying material may be used by EAP methods
themselves and part of this material may be exported. The exported
keying material may be transported by AAA protocols or used by
Secure Association Protocols in the generation or transport of session keys which are used by
lower layer ciphersuites. This document describes each of these
elements and provides a system-level security analysis. It also
specifies the EAP key hierarchy."
Proposed Resolution: Accept
Issue 313: Distributed
Authenticators
Submitter name: Mats Naslund
Submitter email
address: Mats.Naslund@ericsson.com
Date
Submitted: November 30, 2005
Reference:
Document: Keying-08
Comment
type: T
Priority: 1
Section: multiple
Rationale/Explanation of
issue:
Encryption Key" (Enc-SEND-Key) (reception is
defined from the point
of view of the
authenticator). Within [IEEE-802.11i] Octets 0-31
of the MSK (Enc-RECV-Key) 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.
MN: See comment a few lines down.
Transient EAP Keys (TEKs)
Session keys which are used to establish a protected
channel
between the EAP peer and server during the EAP
authentication
exchange. The TEKs are appropriate for use
with the ciphersuite
negotiated between EAP peer and
server for use in protecting the
EAP conversation.
The TEKs are stored locally by the EAP method
and are not
exported. Note that the ciphersuite used to set up the
protected channel between the EAP peer and server during
EAP
authentication is unrelated to the ciphersuite used
to subsequently
protect data sent between the EAP peer
and authenticator. An
example TEK key hierarchy is
described in Appendix A.
Transient Session Keys (TSKs)
Session keys used to protect data exchanged in a session
between
the peer and 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
B.
MN: Here I have some trouble... This seems to
mandate that protection
(on the network side) MUST be terminated in the
authenticator.
In WiMAX, the authenticator is in the AGW, but the session
protection
is in the BS.
I.e. it is not clear why both PMK and TSK
should be shared between the
same two entities... Doesn't one shared key
suufice?
TSKs are permitted to be accessed only by the EAP peer
and
authenticator. Since the TSKs can be determined from the
transported
MN: does this imply that the authenticator always needs to
be in the
"base station"? (since the base station will know TSKs)
[BA] The key framework document does not constrain the authenticator
implementation. For
example, any of the CAPWAP architectures can be used.
The EAP conversation is between the peer and server. These are the only
identities
that matter to the parties; the authenticator identity, if known
at all, is only treated
as an opaque blob for the purposes of Channel
bindings.
However, the SAP conversation is between the peer and the
authenticator. It is possible for
multiple base stations and a "controller"
(e.g. WLAN switch) to comprise a single authenticator.
Since an
authenticator may have many ports, the authenticator ID is distinct from any
port
identifier (e.g. BSSID).
Therefore from the point of view of the
EAP peer, the "base station identity"
(e.g. Called-Station-ID) is irrelevant
except as an opaque blob to be used in
Channel Bindings. All that matters is
the authenticator identity, because that
defines the scope of the EAP keying
material. Many base stations can share the
same authenticator identity.
Having said this, the scope of the Transient Session Keys is defined by
the SAP. Typically
a SAP will bind the TSKs to a particular port, so that the
session keys do *not* have
authenticator-wide scope -- they can only be used
on a particular port (e.g. layer 2
endpoint address). But this is not a
requirement; an authenticator can allow
TSKs to be reused on different ports
assuming that it can guarantee TSK freshness
(such as by keeping centralized
replay counter state). My understanding is that some
WLAN switches allow
multiple ports to use the same TSK with IEEE 802.11i.
Perhaps it would
be more clear to state:
Transient Session Keys (TSKs)
Session keys used to protect data exchanged after EAP
authentication
has successfully completed, using the ciphersuite negotiated
between the EAP peer and authenticator.
[BA] The proposed resolution is as follows:
In Section 1.2, change the definition of Transient Session Keys to the
following:
Transient Session Keys (TSKs)
Session keys used to
protect data exchanged after EAP authentication
has successfully completed,
using the ciphersuite negotiated
between the EAP peer and authenticator.
In Section 2.4.1, delete the following text:
" AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072]
provide
a mechanism for the identification of AAA clients; since
the EAP
authenticator and AAA client are always co-resident,
this mechanism
can be applied to the identification of EAP
authenticators.
RADIUS requires that an Access-Request
packet contain one or more of
the NAS-Identifier, NAS-IP-Address
and NAS-IPv6-Address attributes.
Since a NAS may have more than
one IP address associated with it, the
NAS-Identifier attribute
is RECOMMENDED for the unambiguous
identification of the EAP
authenticator.
From the point of view of the AAA server, EAP
keying material and
parameters are transported to the NAS
identified by the NAS-
Identifier attribute. Since the
NAS/ EAP authenticator MUST NOT
share EAP keying material or
parameters with another party, if the
EAP peer or AAA server
detects use of EAP keying material and
parameters outside the
scope defined by the NAS-Identifier, the
keying material MUST be
considered compromised."
Insert a new Section prior to Section 2.4.2, including the following
text:
2.4.2 Authenticator Architecture
"The EAP method conversation is between the EAP peer and server, as
identified by the Peer-ID and Server-ID. The authenticator identity,
if
considered at all by the EAP method, is treated as
an opaque blob for the
purposes of Channel bindings.
However, the Secure Association Protocol
conversation is between the
peer and the authenticator, and therefore the
authenticator and peer
identities are relevant to that exchange, and define
the scope of use of the
EAP keying material passed down to the lower layer.
Since an authenticator may have many ports,
the authenticator
identifier used within the Secure Association Protocol exchange
SHOULD be
distinct from any port identifier (e.g. MAC address). Similarly, where a
peer
may have multiple ports, and sharing of EAP keying material
and parameters
between peer ports of the same link type is allowed, the peer
identifier
used within the Secure Association Protocol exchange
SHOULD also be distinct
from any port identifier.
While EAP Keying Material passed down to the lower layer is
not
intrinsically bound to particular authenticator and peer ports,
Transient Session Keys MAY be bound to particular authenticator
and peer
ports by the Secure Association Protocol. However,
a lower layer MAY also
permit TSKs to be used on multiple peer
and/or authenticator ports,
providing that TSK freshness is
guaranteed (such as by keeping replay
counter state within
the authenticator).
This specification does not
impose constraints on the architecture of the
EAP authenticator or peer. Any
of the authenticator architectures described
in [RFC4118] can be used. For
example, it is possible for multiple base stations
and a "controller" (e.g.
WLAN switch) to comprise a single EAP authenticator.
In such a situation, the
"base station identity" is irrelevant to the EAP
method conversation, except
perhaps as an opaque blob to be used in
Channel Bindings. Many base stations
can share the same authenticator identity.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
a
mechanism for the identification of AAA clients; since the EAP
authenticator
and AAA client are always co-resident, this mechanism
is applicable to the
identification of EAP authenticators.
RADIUS [RFC2865] requires that an
Access-Request packet contain one or more of
the NAS-Identifier,
NAS-IP-Address and NAS-IPv6-Address attributes.
Since a NAS may have more
than one IP address, the
NAS-Identifier attribute is RECOMMENDED for the
unambiguous
identification of the EAP authenticator.
From the point of
view of the AAA server, EAP keying material and
parameters are transported to
the EAP authenticator identified
by the NAS-Identifier attribute. Since an
EAP authenticator MUST NOT
share EAP keying material or parameters with
another party, if the
EAP peer or AAA server detects use of EAP keying
material and
parameters outside the scope defined by the NAS-Identifier,
the
keying material MUST be considered compromised."
Add to the Informative References:
[RFC4118] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy
for
Control and Provisioning of Wireless Access Points (CAPWAP)",
RFC
4118, June 2005
Proposed Resolution: Accept
Issue 314: AAA-Key Confusion
Submitter
name: Mats Naslund
Submitter email address: Mats.Naslund@ericsson.com
Date
Submitted: November 30, 2005
Reference:
Document: Keying-08
Comment
type: T
Priority: 1
Section: multiple
Rationale/Explanation of
issue:
AAA-Key
A key derived by the peer and EAP
server, used by the peer and
authenticator in the
derivation of Transient Session Keys (TSKs).
Where a
backend authentication server is present, the AAA-Key is
transported from the backend authentication server to the
authenticator. 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).
MN: Isn't it the
case that we MUST
have AAAk = MSK for mode independence?? Why does it only
say
"in existing usage..."
The purpose of the PMK is a bit unclear
to me...
Within EAP, the primary function of the AAA protocol is
to maintain
the principle of Mode Independence, so that as far as the
EAP peer is
concerned, its conversation with the EAP authenticator,
and all
consequences of that conversation, are identical, regardless
of the
authenticator mode of operation.
MN: Doesn't this
imply that AAAk MUST be equal to MSK?
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 provide 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.
MN: again does this imply
that MSK = AAAk? How else get mode independence?
[BA] Since existing EAP lower layers only make use of the MSK, the MSK must
be transported from the server to
authenticator in order to provide for mode
independence. Currently it is not necessary to transport other keys,
since
existing lower layers don't use them. However, it does not necessarily
follow that only the MSK can be
transported.
So yes, the MSK must be
transported as a consequence of mode independence. And yes, AAA-Key = MSK, but
this
is a tautology, not a consequence of any principle.
I think it is more correct to say that "all keys which are required by the
lower layer need to be transported
from the server to the authenticator",
and leave the term "AAA-Key" out of it.
Proposed Resolution:
In Section 1.2, change:
"AAA-Key
A key derived by the peer and EAP
server, used by the peer and
authenticator in the
derivation of Transient Session Keys (TSKs).
Where a
backend authentication server is present, the AAA-Key
is
transported from the backend authentication
server to the
authenticator. 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)."
To:
"AAA-Key
The term "AAA-Key" is synonymous with MSK."
In Section 2.1, change:
" 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 provide 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. "
To:
" 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, all keying material which us required by the lower
layer needs to
be transported from the EAP server to the
authenticator.
Since existing TSK derivation techniques depend solely
on the
MSK, in existing implementations, this is the only keying
material replicated in the AAA key transport phase 1b. "
Proposed Resolution:
Accept
Issue 315: Ciphersuites and Key
Lengths
Submitter name: Mats Naslund
Submitter email address: http://by106fd.bay106.hotmail.msn.com/cgi-bin/compose?curmbox=00000000-0000-0000-0000-000000000001&a=e5cf394c12ca3d454cb958bf15cbafa33e1fc16d4eed72a137fecb3cf18e47f2&mailto=1&to=Mats.Naslund@ericsson.com&msg=1DB00FFA-A710-4EB4-BBC9-CBFEC426805C&start=0&len=4213&src=&type=x
Date Submitted: November 30, 2005
Reference:
Document: Keying-08
Comment type: T
Priority: 1
Section: 1.4.4
Rationale/Explanation
of issue:
Ciphersuite Independence is a consequence of the
principles of Mode
Independence and Media Independence.
MN: I
don't agree. Suppose that the MSK had been only 80 bits rather
than 64
bytes. We could then not have satsified security requirements
on 256-bit key
cipher suites. Now, the MSK's 64 bytes are so huge
that it is sufficient for
all "practical" cipher suites. But I still
claim it does not follow as a
consequence from Mode and Media independence
alone. There is an implict
assumption that enough "key entropy"
is available.
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.
MN: yes, to avoid
needing to know key requirements, the MSK
has been chosen to be "large
enough for all practical use"
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.
MN:...thanks to the fact that the MSK is so
large.
[BA] In RFC 3748, both the MSK and EMSK are required to be at least 64+
Octets
in length. So all exported keying material is large, not just the MSK.
Since the lower layer ciphersuites vary between media, if the EAP keying
material
were not large enough (or have enough entropy) to handle any
ciphersuite, then EAP keying
material would not be usable on all media, and
media independence would be compromised.
So I guess you can say that
Ciphersuite independence is a requirement for Media
Independence, and to
obtain ciphersuite independence, exported EAP keying material
needs to be
large (with sufficient key entropy).
I am not sure what mode
independence has to do with this, though. That seems orthogonal.
[BA] The proposed resolution is as follows:
Within Section 1.4.4 change:
" Ciphersuite Independence is a consequence of the principles of Mode
Independence and Media Independence."
To:
"Ciphersuite Independence is a requirement for Media Independence. Since lower
layer ciphersuites vary between media, media independence requires that
EAP keying material needs to be large enough (with sufficient entropy) to
handle any ciphersuite."
Proposed Resolution:
Accept
Issue 316: Counter Length
Submitter
name: Mats Naslund
Submitter email address: Mats.Naslund@ericsson.com
Reference:
Document: Keying-08
Comment type: T
Priority: 1
Section: 5.8
Rationale/Explanation of issue:
Lower Layer
The lower layer Secure Association Protocol MUST generate
a fresh
session key for each session, even if the keying
material and
parameters provided by EAP methods are
cached, or the peer or
authenticator lacks a high entropy
random number generator. A
RECOMMENDED method is
for the peer and authenticator to each
provide a nonce or
counter of at least 128 bits, used in session
key
derivation.
MN: If it is a counter, I don't see why it needs to be 128
bits...
Only a few bits will change anyway each time a new key is generated.
[BA] For a random nonce, large size makes sense so as to avoid replay.
For a counter, it need only be as large as the maximum number of TSK
rekeys to be supported.
For example, if only 256 rekeys were to be
supported, the counter could only be 8 bits, right?
The point is that this is a rekey counter, not a packet replay counter.
[BA] The proposed resolution is as follows:
In Section 5.8, change:
"Lower Layer
The lower layer Secure Association
Protocol MUST generate a fresh
session key for each
session, even if the keying material and
parameters
provided by EAP methods are cached, or the peer or
authenticator lacks a high entropy random number generator. A
RECOMMENDED method is for the peer and authenticator to
each
provide a nonce or counter of at least 128 bits,
used in session
key derivation. "
To:
"Lower Layer
The lower layer Secure Association Protocol MUST generate a
fresh
session key for each session, even if the keying material and
parameters provided by EAP methods are cached, or the peer or
authenticator lack a high entropy random number generator. A
RECOMMENDED
method is for the peer and authenticator to each
provide a nonce or counter
used in session key derivation.
If a nonce is used, it is RECOMMENDED that
it be at least 128 bits."
Proposed Resolution:
Accept
Issue 317: Key Separation
Submitter
name: Mats Naslund
Submitter email address: Mats.Naslund@ericsson.com
Date
Submitted: November 30, 2005
Reference:
Document: Keying-08
Comment
type: T
Priority: 1
Section: multiple
Rationale/Explanation of
issue:
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 layer
and MUST NOT be used within another lower
layer. This prevents
compromise of one lower layer from
compromising other applications
using EAP keying parameters.
MN: I guess this is "key separation"... But if this is a MUST
requirement,
why not here standardize a way to do it? I.e.
lower_layer_key = f(MSK, layer_ID).
In order
to provide method independence, key
management of exported or derived
keys SHOULD NOT be provided within
EAP methods.
MN: does this
exclude that EAP can provide key separation?
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:
MN: But if the MSK is always
sent to the SA protocol, it really does
not help if the SA protocol does
e.g. key separation. Compromise
of the "entity" hosting the SA protocol
would still compromise the
MSK. I guess I am asking: is there a "middle
layer" missing, between
EAP and the SA procotol that takes care of key
separation?
[a] Entity Naming. A basic feature of a Secure
Association Protocol is
the explicit naming of the
parties engaged in the exchange.
Without explicit
identification, 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 5, both the peer and authenticator may have more
than one physical or virtual port, and as a result SHOULD
identify
themselves in a manner that is independent of
their attached ports.
(snip)
[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.
MN: This part clarifies a lot. So, it seems there is a "layer"
missing...
It is said above that it is RECOMMENDED that the Secure
Association
Protocol (SAP) supports all of this. But what about interaction
between
different SAPs? I.e. should there be a layer below EAP, but above
SAP
that takes care of inter-access key separation? Or, where is this done?
Or is cross-SAP usage prohibited?
[BA] The document is describing what is done today, which is that the MSK is
passed down
to the lower layer.
One of the questions we have been
discussing is whether the EAP layer can provide for key
separation. One
problem is that the EAP layer does not have a mechanism by which it
can
negotiate the cryptographic algorithms with which to compute the
"separate keys".
EAP methods can negotiate ciphersuites, but this only
applies to the EAP conversation.
There is no way for an EAP method to
negotiate the f() used to compute the lower layer
keys. So if the EAP layer
specifies a KDF using a fixed algorithm (e.g. SHA-1) and
that algorithm is
compromised, there is no way to fix it. This seems short-sighted.
Lower
layers have a lot more flexibility -- and therefore if "crypto-agility"
is
required, then negotiation of f() needs to occur below EAP. Today there is
no
"middle layer" between EAP and the lower layer, so the only way this can
be
handled is in the lower layer.
In terms of operation, there is no
interaction between the SAPs. The EAP keying
material is used only by the
lower layer over which the EAP conversation
occurred.
[Mats]
Yes. I guess my basic comment boils down to: how should EAP key
mgmt
be done "tomorrow"? I.e. how do we provide things such as
key
separation, seamless inter access handover, etc. From what I
now
understand, it seems that EAP itself may not be a good place
to
specify this sort of more "advanced" things.
[BA]
That is a difficult question. Here are some (semi-random)
thoughts:
1. With the increasing emphasis on "crypto-agility" we
cannot utilize hard-coded algorithms; every cryptographic algorithm has to be
negotiable. Since within EAP methods ciphersuite negotiation is restricted to
what is necessary for the EAP method itself (not the data or subsequent lower
layer key derivation), EAP itself cannot provide the required
crypto-agility.
However lower layers can provide the required
agility. The implication seems to be that the algorithm used to generate AMSKs
from the EMSK needs to be negotiated in the lower layer, and therefore the AMSK
generation algorithm cannot be hard coded in the EAP layer. If AMSK generation
occurs in the EAP layer, this creates the prospect of continually having to
upgrade the EAP implementation every time a new lower layer defines a new KDF
for AMSK generation. This would seem to violate the principle of media
independence.
This problem does not exist if the EMSK is passed
down to the lower layer, which can then generate AMSKs itself. If a new lower
layer defines a different algorithm for AMSK generation, then only that lower
layer needs to change; the EAP implementation does not need to be
upgraded.
2. IEEE 802.11r has developed a "fast BSS transition"
scheme which depends only on the MSK. The scheme does appear to be compatible
with much of the "AAA Key Management" document, yet it does not require the use
of the EMSK. Here is how it works.
Something called the "PMK-R1"
is derived from the MSK. The PMK-R1s are cryptographically separate from each
other, and a different PMK-R1 is derived for each port. Note that within IEEE
802.11r only a single authenticator (known as the "Mobility Domain Controller")
obtains the MSK (PMK-R0), which is never shared with other authenticators. At
various points there has been discussion of deleting the MSK (PMK-R0) once the
PMK-R1s are derived from it, although that is not in the current
document.
From
what I can tell, IEEE 802.11r does provide many of the required
security properties, including key lifetime negotiation,
authenticator identification, TSK freshness, ciphersuite negotiation, etc. It is
true that compromise of the MSK will compromise the entire "mobility domain".
However, it is possible to configure the mobility domain so that it corresponds
to a single authenticator (e.g. a single WLAN switch).
Even
where the "mobility domain" corresponds to multiple authenticators, compromise
of any authenticator that is not also the Mobility Domain Controller does not
lead to cascading vulnerabilities. In other words, obtaining one PMK-R1 does not
help you obtain other PMK-R1s or the MSK. If the MSK were to be deleted after
PMK-R1 calculation, compromise of a Mobility Domain Controller after PMK-R1
distribution would not lead to compromise of other authenticators. Only
possession of the MSK would permit that.
There is still more
work to be done with IEEE 802.11r (Version 1.0 only issued recently), but it is
well worth reading. Any IETF participant can participate in the ballot process
as a non-voter. Here is a pointer to the document (ask for the archive password
if you don't already have it):
http://grouper.ieee.org/groups/802/11/private/Draft_Standards/11r/P802.11r-D1.0.pdf
There are also some basic issues with use of EAP to support application layer
security.
RFC 3748, Section 1.3 states:
EAP was designed for use in
network access authentication, where IP
layer connectivity may not be
available. Use of EAP for other
purposes, such as bulk data transport, is NOT
RECOMMENDED.
Given that use of EAP or application-layer authentication is
outside the applicability
of EAP, it would not be appropriate to modify the
EAP key hierarchy to be modified to
enable this.
[Bernard Aboba]
Here are the proposed changes:
Change "Method-ID" to "Session-ID" in
Figure 1.
Remove figures 3 and 4.
Rewrite Section 2.2 as
follows:
"2.2 Layering
On completion of EAP authentication, keying
material and
material and parameters exported by the EAP method are
provided
to the lower layer and AAA layer (if present). These include
the
Master Session Key (MSK), Extended Master Session Key (EMSK),
Peer-ID,
Server-ID, Session-ID and Key-Lifetime. The Initialization
Vector (IV) is
deprecated.
In order to preserve the security of keys derived within EAP
methods,
lower layers 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 layer and MUST NOT
be
used within another lower layer. This prevents compromise of one
lower
layer from compromising other applications using EAP
keying
parameters.
EAP keying material and parameters provided to a
lower layer MUST NOT
be transported to another entity. For example, EAP
keying material
and parameters passed down to the EAP peer lower layer MUST
NOT leave
the peer; EAP keying material and parameters passed down
or
transported to the EAP authenticator lower layer MUST NOT leave
the
authenticator.
On the EAP server, keying material requested by and
passed down to
the AAA layer may be replicated to the AAA layer on
the
authenticator. On the authenticator, the AAA layer provides
the
replicated keying material to the lower layer over which the
EAP
authentication conversation took place. This enables
"mode
independence" to be maintained.
The EMSK MUST NOT be provided to
an entity outside the EAP server or
peer, nor is it permitted to pass any
quantity to an entity outside
the EAP server or peer from which the EMSK
could be computed without
breaking some cryptographic assumption, such as
inverting a one-way
function. The EMSK MUST NOT be transported by the AAA
layer.
As noted in [RFC3748] Section 7.10:
The EMSK is reserved for
future use and MUST remain on the EAP
peer and EAP server where it is
derived; it MUST NOT be
transported to, or shared with, additional parties,
or used to
derive any other keys.
The EAP layer as well as the peer
and authenticator layers MUST NOT
modify or cache keying material or
parameters (including Channel
Bindings) passing in either direction between
the EAP method layer
and the lower layer or AAA layer."
Proposed Resolution:
Accept
Issue 318: Transient Session
Keys
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date Submitted:
November 30, 2005
Reference:
Document: Keying-08
Comment type:
T
Priority: S
Section: 2.3
Rationale/Explanation of issue:
There is no section of the document that talks directly about
generation
of transient session keys. Here is a suggested
rewrite of Section
2.3:
2.3 Transient Session Keys
Existing EAP lower layers handle
the caching of EAP keying
material and the generation of transient session
keys in
different ways:
PPP PPP, defined in [RFC1661] does not
support caching of EAP keying
material or parameters. PPP ciphersuites derive
their TSKs
directly from the MSK, as described in [RFC2716]. This method
is NOT RECOMMENDED, since were PPP to support caching, this
could result
in stale TSKs. As a result, once the PPP session
is terminated, EAP keying
material and parameters MUST be discarded.
Since caching of EAP keying
material is not permitted, within PPP
there is no way to handle TSK rekey
without EAP re-authentication.
Perfect Forward Secrecy (PFS) is only possible
within PPP if
the negotiated EAP method supports this.
IKEv2
IKEv2, defined in [IKEv2] only uses EAP keying material
for
authentication purposes and not key derivation. As a
result, the
keying material derived within IKEv2 is
independent of the EAP keying
material and rekey of IPsec
SAs can be handled without requiring EAP
re-authentiation.
Since generation of keying material is independent of EAP,
within IKEv2 it is possible to negotiate PFS, regardless of
the EAP
method that is used. IKEv2 does not cache EAP keying
material or parameters,
nor does it utilize the EAP Key-Lifetime
parameter 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, or Session-ID. More details are
about the
structure of the cache are available in [IEEE-802.11i].
In IEEE 802.11i, TSKs
are derived from the MSK using the
4-way handshake, which includes a nonce
exchange. This
guarantees TSK freshness even if the MSK is reused.
The
4-way handshake also enables TSK rekey without EAP
re-authentication.
PFS is only possible within IEEE 802.11i
if the negotiated EAP method
supports this.
IEEE 802.1X-2004
IEEE 802.1X-2004, defined in
[IEEE-802.1X-2004] does not support
caching of EAP keying material or
parameters. Therefore once EAP
authentication completes, it is assumed that
EAP keying material
and parameters are discarded.
IEEE 802.16e
IEEE
802.16e, defined in [IEEE-802.16e] supports caching of the
MSK, but not the
EMSK, IV, Peer-ID, Server-ID or Session-ID.
In IEEE 802.16e, TSKs are
generated by the authenticator without
any contribution by the peer. The TSKs
are encrypted, authenticated
and integrity protected using the MSK. As a
result, TSK rekey
is possible without EAP re-authentication. PFS is not
possible
even if the negotiated EAP method supports it.
AAA Existing AAA implementations supporting RADIUS/EAP [RFC3579] or
Diameter
EAP [RFC4072] do not support caching of EAP keying material
or
parameters. In existing AAA client, proxy and server
implementations, exported EAP
keying material (MSK, EMSK and IV) as well as
parameters and
derived keys are not cached and MUST be presumed lost after
the AAA
exchange completes.
In order to avoid key reuse, the AAA layer
MUST delete transported
keys once they are sent. The AAA layer MUST NOT
retain keys that
it has previously sent. For example, a AAA
layer
that has transported the MSK MUST delete it, and keys MUST
NOT be derived
from the MSK from that point forward."
Proposed Resolution:
Accept
Issue 319: Requirement on transport of EAP Keying
Material
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date Submitted:
December 1, 2005
Reference:
Document: Keying-08
Comment type:
T
Priority: 1
Section: 2.2
Rationale/Explanation of issue:
The document states
"In order to prevent the compromise
of
transported EAP keying material and parameters, the AAA
client and
EAP authenticator MUST be co-resident."
It
could be possible for the EAP authenticator to use another secure
protocol
other than a AAA protocol to transport EAP key material.
Requested
change:
"In order to prevent the compromise of
transported EAP keying
material and parameters they MUST be securely
transmitted from the entity
that hosts the EAP server to the entity that
hosts the EAP authenticator and
makes use of the key material."
[BA]
I think the issue here is similar to the one brought up in Issue
313. An EAP authenticator may be constructed in a variety of ways.
Whether the authenticator has multiple ports or a single port, involves
multiple CPUs or a single CPU, or even is constructed using lightweight APs and
a WLAN switch is not relevant to EAP.
For EAP purposes, an Authenticator
is an entity that identifies itself with a single authenticator identity, both
within the lower layer as well as in AAA. Neither the EAP peer nor the AAA
server care about the details of how the authenticator is constructed, and
neither should this document.
So when the document says that the
"Authenticator and AAA cilent are co-resident" it means that both the
Authenticator and AAA client share the same authenticator identity. This
is required, because if it were not true then Channel Bindings would fail to
verify. That's probably all we can or should say on this subject.
[Joe Salowey]
> For EAP purposes, an Authenticator is an entity that
> identifies itself with a single authenticator identity, both
> within the lower layer as well as in AAA. Neither the EAP
> peer nor the AAA server care about the details of how the
> authenticator is constructed, and neither should this document.
>
This makes sense. If we define an authenticator to span multiple
physical entities then I am OK with the current text. Perhaps we should
include this in the definition or point to sections of the document
where this is described. I'm thinking maybe we should pull the
description of the authenticator variations out of 2.4 into its own
section on EAP authenticator.
> So when the document says that the "Authenticator and AAA
> cilent are co-resident" it means that both the Authenticator
> and AAA client share the same authenticator identity. This
> is required, because if it were not true then Channel
> Bindings would fail to verify.
I'm not sure that this is true. I'm not sure that the
authenticator identity is necessarily the only choice for identifier.
The lower layer must define what the identifier is, define attributes in
AAA protocols need to carry the identifier and how to do comparisons of
the identifier. However this is a separate issue related to section
2.4.
[BA] The Proposed Resolution is as follows:
In Section 2.2, delete:
"In order to prevent the compromise of
transported EAP keying material and parameters, the AAA client and
EAP authenticator MUST be co-resident."
Proposed Resolution:
Accept
Issue 320: Use of term lower
layer
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date Submitted:
December 1, 2005
Reference:
Document: Keying-08
Comment type:
E
Priority: 1
Section: 2
Rationale/Explanation of issue:
The term lower layer is used inconsistently in the document.
Lower
layer should refer to the protocol between the EAP Peer and the
EAP
Authenticator. It is between these entities that the
security
association protocol is typically run. The MSK is transported
to the
lower layer.
AAA is not an EAP lower layer except in the
special case where the AAA
client and server are acting as the EAP Peer and
EAP Authenticator for
some reason (an example of this could was in
EUSM). Entities other than
the lower layer may obtain keys derived from
the EMSK.
Requested change:
Section 2.1
-----------
change
"Of these phases, Phase 0, 1b and Phase 2 are handled by a
lower layer."
To
"Of these phases, Phase 0, 1b and Phase 2 are
handled external to EAP.
Phases 0 and 2 are handled by the lower layer
protocol and phase 1b is
typically handled by a AAA protocol."
Section
2.2
------------
(remove references to IV)
---
Change
"The
EMSK MUST NOT be provided to the lower layer, nor is it permitted
to pass any
quantity to the lower layer from which the EMSK could be
computed without
breaking some cryptographic assumption, such as
inverting a one-way
function."
To
"The EMSK MUST NOT be provided to an entity outside
the EAP server or
peer, nor is it permitted to pass any quantity to an
entity outside the EAP
server or peer from which the EMSK could be computed
without breaking some cryptographic assumption, such as
inverting a one-way
function."
---
Change
"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. "
To
"In order to
preserve the security of keys derived within EAP methods,
lower layers
MUST NOT export keys passed down by
EAP
methods."
---
Change
"EAP keying material and
parameters provided to a lower layer other
than AAA MUST NOT be transported
to another entity."
To
"EAP keying material and parameters
provided to a lower layer MUST NOT
be transported to another
entity."
---
Change
"The exception to the "no sharing" rule is the
AAA layer. On EAP
server, keying material requested by and passed
down to the AAA layer
may be replicated to the AAA layer on the
authenticator. On the
authenticator, the AAA layer may
provide the replicated keying
material to the lower layer over which
the EAP authentication
conversation took place. This enables
"mode independence" to be
maintained. "
To
"The AAA
layer may transport keys that are exported from the EAP server.
On the EAP
server, keying material requested by and passed down to the AAA layer
may be
replicated to the AAA layer on the authenticator. On
the
authenticator, the AAA layer may provide the replicated
keying
material to the lower layer over which the EAP
authentication
conversation took place. This enables "mode
independence" to be maintained."
-----------
Section
2.3
-----------
Change
"The caching behavior of existing EAP lower
layers is as follows:"
To
"The caching behavior of existing EAP lower layers and AAA layers is
as
follows:"
[BA] The proposed resolution is to accept the above proposed changes, with
the following modifications:
Change
"The exception to the "no sharing" rule is the AAA layer.
On EAP
server, keying material requested by and passed down to the AAA
layer
may be replicated to the AAA layer on the
authenticator. On the
authenticator, the AAA layer may
provide the replicated keying
material to the lower layer over which
the EAP authentication
conversation took place. This enables
"mode independence" to be
maintained. "
To
"On the EAP
server, keying material requested by and passed down to the AAA layer
may be
replicated to the AAA layer on the authenticator. On
the
authenticator, the AAA layer may provide the replicated
keying
material to the lower layer over which the EAP
authentication
conversation took place. This enables "mode
independence" to be maintained.
However, the EMSK MUST NOT be transported by the AAA layer."
Change:
"Existing EAP lower layers handle the caching of EAP keying
material and
the generation of transient session keys in
different ways:"
To:
"Existing EAP lower layers and AAA handle the caching of EAP
keying
material and the generation of transient session keys in
different
ways:"
Change "Lower Layer" to "Lower Layer or AAA" in Figure 3.
Change the first two paragraphs of Section 2.2 to:
"As illustrated in Figure 3, on completion of EAP authentication,
EAP
methods export the Master Session Key (MSK), Extended Master
Session
Key (EMSK), Peer-ID, Server-ID, Session-ID and Key-Lifetime to
the
EAP peer or authenticator layers. The Initialization Vector (IV)
is
deprecated.
The EAP peer and authenticator layers MUST NOT modify
or cache keying
material or parameters (including Channel Bindings) passing
in either
direction between the EAP method layer and the EAP layer. The
EAP
layer also MUST NOT cache keying material or parameters
(including
Channel Bindings) passed to it, whether by the EAP
peer/authenticator
layer, the lower layer or the AAA layer."
Proposed Resolution:
Accept
Issue 321: IV
Submitter name: Joe
Salowey
Submitter email address: jsalowey@cisco.com
Date Submitted:
December 1, 2005
Reference:
Document: Keying-08
Comment type:
E
Priority: 1
Section: 1
Rationale/Explanation of issue:
Section 1.3
--
Since IV is being deprecated I think we should
reference it a little as
possible, suggestion is to remove references to IV
in this section. It
should be removed in figure 1.
Section 1.3.1
Should remove reference to IV
[BA] The Proposed Resolution is as follows:
Section 1.3:
In
Figure 1, add (Deprecated) to the IV Derivation box and
(Optional) to the IV
arrow.
Section 1.3.1
Change:
"MSK, EMSK and IV
Names"
To:
"MSK and EMSK names"
Proposed Resolution: Accept
Issue 322: Authenticator
Architecture
Submitter name: Joe Salowey
Submitter email address:
jsalowey@cisco.com
Date Submitted:
December 1, 2005
Reference:
Document: Keying-08
Comment type:
T
Priority: 1
Section: 2.4
Rationale/Explanation of issue:
There is a lot of discussion about authenticator architecture
which
probably should be pulled into a separate section on
authenticator
architecture.
Requested change:
Move the
description of authenticator architecture to its own section
[Bernard Aboba] I have reorganized Section 2.4 as follows:
How does this look?
"2.4. Authenticator Architecture
This specification does not impose
constraints on the architecture of
the EAP authenticator or peer. Any of the
authenticator
architectures described in [RFC4118] can be used. For example,
it is
possible for multiple base stations and a "controller" (e.g.
WLAN
switch) to comprise a single EAP authenticator. In such a
situation,
the "base station identity" is irrelevant to the EAP
method
conversation, except perhaps as an opaque blob to be used in
Channel
Bindings. Many base stations can share the same
authenticator
identity. As a result, lower layers need to identify EAP peers
and
authenticators unambiguously, without incorporating
implicit
assumptions about peer and authenticator architectures.
It
should be understood that an EAP authenticator or peer:
[a] may contain
one or more physical or logical ports;
[b] may advertise itself as one or
more "virtual"
authenticators or peers;
[c] may utilize multiple
CPUs;
[d] may support clustering services for load balancing or
failover.
Both the EAP peer and authenticator may have more than one
physical
or logical port. A peer may simultaneously access the network
via
multiple authenticators, or via multiple physical or logical ports
on
a given authenticator. Similarly, an authenticator may offer
network
access to multiple peers, each via a separate physical or
logical
port. When a single physical authenticator advertises itself
as
multiple "virtual authenticators", it is possible for a single
physical
port to belong to multiple "virtual authenticators". The
situation is
illustrated in Figure 5.
[Figure is unchanged]
Figure 5: Relationship between EAP peer,
authenticator and server
2.4.1. Authenticator
Identification
The EAP method conversation is between the EAP peer and
server, as
identified by the Peer-ID and Server-ID. The authenticator
identity,
if considered at all by the EAP method, is treated as an opaque
blob
for the purposes of Channel bindings. However, the Secure
Association
Protocol conversation is between the peer and the
authenticator, and
therefore the authenticator and peer identities
are relevant to that
exchange, and define the scope of use of the EAP
keying material passed down
to the lower layer.
Since an authenticator may have multiple ports, the
authenticator
identifiers used within the Secure Association Protocol
exchange
SHOULD be distinct from any port identifier (e.g. MAC
address).
Similarly, where a peer may have multiple ports, and sharing of
EAP
keying material and parameters between peer ports of the same
link
type is allowed, the peer identifier used within the
Secure
Association Protocol exchange SHOULD also be distinct from any
port
identifier.
Where the peer and authenticator identify themselves
within the lower
layer using a port identifier such as a link layer address,
this
creates a number of problems:
[1] It may not be obvious to the
peer which authenticator ports are
associated with which
authenticators.
[2] It may not be obvious to the authenticator which peer
ports are
associated with which peers.
[3] It may not be obvious to
the peer which "virtual authenticator" it
is communicating with.
[4]
It may not be obvious to the authenticator which "virtual peer" it
is
communicating with.
AAA protocols such as RADIUS [RFC3579] and Diameter
[RFC4072]
provide a mechanism for the identification of AAA clients;
since
the EAP authenticator and AAA client are always co-resident,
this
mechanism is applicable to the identification of
EAP
authenticators.
RADIUS [RFC2865] requires that an Access-Request
packet contain one
or more of the NAS-Identifier, NAS-IP-Address and
NAS-IPv6-Address
attributes. Since a NAS may have more than one IP address,
the
NAS-Identifier attribute is RECOMMENDED for the
unambiguous
identification of the EAP authenticator.
From the point of
view of the AAA server, EAP keying material and
parameters are transported to
the EAP authenticator identified by
the NAS-Identifier attribute. Since an
EAP authenticator MUST NOT
share EAP keying material or parameters with
another party, if the
EAP peer or AAA server detects use of EAP keying
material and
parameters outside the scope defined by the NAS-Identifier,
the
keying material MUST be considered compromised."
Proposed Resolution:
Accept
Issue 323: AAA Key Cache
Submitter
name: Yoshihiro Ohba
Submitter email address: mailto:yohba@tari.toshiba.com
Date
Submitted: December 6, 2005
Reference:
Document: Keying-08
Comment
type: T
Priority: 1
Section: 2.3
Rationale/Explanation of issue:
The following text in section 2.3 of eap-keying draft talks about
not
caching the keys at AAA layer, but mostly in terms of AAA servers.
I
think the text should be revised so that any AAA layer entity
including
AAA client and AAA proxy does not cache the keys. (Note: I
explicitly
mention that AAA proxy does not cache the keys as well.
This might be related
to the ongoing hokey discussion where KDC in the
visiting domain is going to
be introduced. Having said that, I think
that the KDC, which is
expected to cache the keys, should be defined
outside the AAA
layer.)
"AAA
Existing AAA servers supporting RADIUS/EAP [RFC3579] or Diameter
EAP
[RFC4072] do not support caching of EAP keying material or
parameters.
In existing AAA server implementations, exported EAP
keying material (MSK,
EMSK and IV) as well as parameters and
derived keys are not cached and MUST
be presumed lost after the AAA
exchange completes.
In order to avoid
key reuse, the AAA layer MUST delete transported
keys once they are
sent. The AAA layer MUST NOT retain keys that
it has previously sent to
the authenticator. For example, a AAA
layer that has transported the
MSK MUST delete it, and keys MUST
NOT be derived from the MSK from that point
forward."
Taking a close look at EAP pass-through authenticator, the
EAP
authenticator *layer* and the EAP *layer* on the
pass-through
authenticator do not cache the keys as well, according to the
the
following text in section 2.2 of eap-keying draft:
"The EAP peer
and authenticator layers MUST NOT modify or cache keying
material or
parameters (including Channel Bindings) passing in either
direction between
the EAP method layer and the EAP layer. The EAP
layer also MUST NOT
cache keying material or parameters (including
Channel Bindings) passed to it
by the EAP peer/authenticator layer or the lower layer."
[BA] The proposed resolution is as follows:
Change the text in Section 2.3 to the following:
"AAA
Existing AAA client, proxy and server implementations supporting RADIUS/EAP
[RFC3579] or Diameter
EAP [RFC4072] do not support caching of EAP keying
material or
parameters. In existing AAA client, proxy and server
implementations, exported EAP
keying material (MSK, EMSK and IV) as well as
parameters and
derived keys are not cached and MUST be presumed lost after
the AAA
exchange completes.
In order to avoid key reuse, the AAA layer
MUST delete transported
keys once they are sent. The AAA layer MUST NOT
retain keys that
it has previously sent. For example, a AAA
layer
that has transported the MSK MUST delete it, and keys MUST
NOT be derived
from the MSK from that point forward."
Proposed Resolution:
Accept
Issue 324: Typos
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
Typos:
- section 1.3:
s/known the Key-Lifetime/known as the Key-Lifetime
- section 2.3:
s/As result,/As a result
s/More details are/More details
- section 2.4.1:
s/packet contain/packet contains
s/AAA server and client/authenticator/AAA server and uthenticator's AAA client
- section 3.1:
s/have been and authorized/have been authorized
- section 3.4:
s/the Secure Association Protocol include/the Secure Association Protocol
includes
- section 5:
s/achieves it security/achieves its security
Proposed Resolution:
Accept
Issue 325: Channel Bindings
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date Submitted: December 1, 2005
Reference:
Document: Keying-08
Comment type: T
Priority: 1
Section: 1.3, 1.4
Rationale/Explanation of issue:
Section 1.3
There are two styles of channel bindings that may be supported by EAP
methods. The text in this section describes exportable channel bindings.
There is also the approach where the bindings are non exportable. In
this case the method does a binary comparison of the channel bindings or
hash of the channel bindings and fails if the result does not match. I
can see the possibility of a method supporting both styles. Should we
include both?
Section 1.4
Exportable channel binding are references in this section,
non-exportable ones are not. If we make changes to this affect above
then we should change it here as well.
[Bernard Aboba] Here is the proposed resolution:
In Section 3.1 change:
"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 that transport Channel
Binding 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."
To:
"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 that transport Channel Binding 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 or AAA 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 or AAA layer passes
the result of the verification (TRUE or FALSE) up to the
EAP method.
While the verification can be done either by the peer
or the server, typically only the server has the knowledge to
determine the correctness of the values, as opposed to merely
verifying their equality."
Proposed Resolution:
Accept
Issue 326: Identifiers
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date Submitted: December 1, 2005
Reference:
Document: Keying-08
Comment type: T
Priority: 1
Section: 1
Rationale/Explanation of issue:
" EAP methods also MAY export method-specific peer and server
identifiers (peer-ID and server-ID), a method-specific EAP
conversation identifier known as the Method-ID, and the lifetime of
the exported keys, known the Key-Lifetime. EAP methods MAY also
support the import and export of Channel Bindings. New EAP method
specifications MUST define the Peer-ID, Server-ID and Method-ID. The
combination of the Peer-ID and Server-ID uniquely specifies the
endpoints of the EAP method exchange."
It seems that additional data associated with the identity should be
exported to satisfy section 1.3. Suggestion is to add this and call
them identity attributes.
In this paragraph it states that the "Peer-ID and Server-ID uniquely
specifies the endpoints of the EAP method exchange", however further down it states
that these quantities may be null. This is contradictory. Suggested
modification to above text:
"The combination of the Peer-ID and Server-ID may uniquely specify the
endpoints of the EAP method exchange if the method supports unique IDs."
[Bernard Aboba]
How about the following:
"The combination of the Peer-ID and Server-ID may uniquely specify the
endpoints of the EAP method exchange when they are provided."
Proposed Resolution:
Accept
Issue 327: PANA and EAP Keying Framework
Submitter name: Yoshihro Ohba
Submitter email address: yohba@tari.toshiba.com
Date Submitted: January 9, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg03860.html
Document: Keying-08
Comment type: T
Priority: 1
Section: 2.3
Rationale/Explanation of issue:
It would be useful to add some
description on how PANA handle the caching of EAP keying material and
the generation of transient session keys.
Requested change:
Add the following description in Section 2.3:
"PANA
PANA [I-D.ietf-pana-pana] supports caching of the MSK, but not
the EMSK, IV, Session-ID, Peer-ID or Server-ID. In the PANA
model [I-D.ietf-pana-framework], TSKs are generated using a
Secure Association Protocol between the peer and and
authenticator port (which is referred to as an Enforcement
Point), where both link-layer specific key exchange protocols and
IKE can be used as the Secure Association Protocol depending on
whether link-layer ciphering or IPsec is used between the peer
and the authenticator port. The key scope and lifetime of the
TSKs are communicated from the authenticator to the peer. The
key scope is specified as a list of device identifiers of the
Enforcement Points. Depending on the Secure Association
Protocol in use, TSK rekey is possible without EAP
re-authentication."[Bernard Aboba]
TSKs
are generated using a Secure Association Protocol
Can
you elaborate on this? If the TSKs are generated via an IKE DH exchange, with
the MSK used only for authentication (as in IKEv2/EAP) then the TSKs are not
dependent on the MSK and PFS is possible, right?
between
the peer and and authenticator port
Not sure I
understand this. The SAP exchange is between the peer and authenticator, not
between specific ports. However, a result of the SAP exchange can be derivation
of TSKs which are bound to specific ports.
[Yoshi Obha]
Yes. When IKE is used as the SAP, the IKE PSK derived from MSK is
used only for peer entity authentication for IKE DH and thus PFS is
possible. On the other hand when IEEE 802.11i 4-way handshake is used
as the SAP, PFS is possible if the negotiated EAP method supports
this.
[Bernard Aboba]
The IEEE 802.11i standard does not support PANA, so how can this work?
A single "virtual AP" either allows "open" authentication, or it requires 802.11i, but it can't do both simultaneously.
Therefore PANA cannot be used for the initial authentication, since PANA traffic will be dropped by the AP prior to completion of 802.1X.
> I don't think 802.11i prohibits any IP traffic to pass throuth
> uncontrolled port before 4-way handshake. In fact, there is a
> description in section 5.4.2.2 of IEEE 802.11i 2004 specification:
[Walker, Jesse] This is not true. 802.1X frames are the only type of
data 802.11i allows to pass over the link prior to key confirmation. IP
traffic is not encapsulated with the 802.1X Ethertype, so is expressly
blocked.
You can find the answer reading 802.1X Clause 8. The
answer is no. All data traffic passes through the control port. The
uncontrolled port passes only frames of Ethertype 802.1X.
Point), where both link-layer specific key exchange protocols and
IKE can be used as the Secure Association Protocol depending on
whether link-layer ciphering or IPsec is used between the peer
and the authenticator port.
What is a "link-layer specific key exchange
protocol"? Are we talking about existing SAPs such as 802.11i 4-way handshake,
or something else?
The key scope and lifetime of the
TSKs are communicated from the authenticator to the peer.
How? IKE does not define explicit lifetimes, nor does
it care about key scope because it doesn't support caching.
The lifetime of PANA session is carried in PANA message. This
lifetime is the same as the authorization lifetime which is also same
as the lifetime of the MSK.
Since IKEv2 does not support caching of EAP keying
parameters, including the MSK, the PANA lifetime cannot be used; the MSK is
discarded by IKEv2 regardless of what is in the PANA lifetime.
Then, draft-ietf-pana-ipsec specifies
that when IKE is used as the SAP, the lifetime of the IKE SA is bound
to the lifetime of the MSK.
The IPsec SA lifetime is determined by IKE, not PANA.
Since IKE discards the MSK after it completes, there is no notion of an MSK
lifetime in IKE.
The key scope is specified as a list of device identifiers of the
Enforcement Points.
This doesn't make sense where IKE is used as the SAP
unless we are talking about MOBIKE (which can move SAs between
addresses).
[Bernard Aboba] The intent of Section 2.3 is to review use of EAP within documents that have already been published.
PANA is still under review, and it appears that there are a number of issues that still need to be ironed out. Therefore,
I'd suggest that we omit discussion of PANA in this document.
Proposed Resolution: Reject
Issue 328: Terminology
Submitter name:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date Submitted:
January 24, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg03935.html
Document:
NETSEL-03
Comment type: E
Priority: S
Section:
1
Rationale/Explanation of issue:
This document needs a terminology
section.In particular, the term "network selection" is not
defined, and appears to be used to refer to a number of fundamentally different
problems.In looking at usage in other standards bodies (such as
IEEE 802.11), the term has been used in a number of contexts, and at times it is
hard to tell what context the document is discussing. For
example:a. The term "Network Selection" has sometimes been used
to describe the problem of
choosing between interfaces. For example, one
interface may be CDMA, and another
may be 802.11; which interface should be
used for outgoing traffic? I would
propose that we call this "interface
selection".b. The term has also been used to describe the
problem of choosing between "points
of attachment". For example, there are
three APs out there, which one should my
802.11 interface choose? In this
context, the term "network" may actually refer
to a desire to avoid having to
change IP addresses by retaining attachment
to the same IP network or prefix.
Perhaps the term "handoff
candidate selection" might better describe this
problem?c. Sometimes the term appears to be used as a synonym
for
"identity selection". Note that RFC 4284 is entitled "Identity Selection
Hints
for EAP"; the document does not use the term "network selection"
except
in reference to external work, such as this problem statement
document. Given the confusion caused by conflicting usage of the term "network
selection" I would recommend that the authors consider adding a terminology
section in which this and other terms can be defined.
Proposed Resolution:
Discuss
Issue 329: Reference Update
Submitter
name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date Submitted:
January 24, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg03936.html
Document:
NETSEL-03
Comment type: E
Priority: S
Section:
Various
Rationale/Explanation of issue:
A number of the references in the draft have now been
updated. These include: [I-D.ietf-ipsec-ikev2] - now published as RFC 4306.
[I-D.adrangi-eap-network-discovery] - now published as RFC 4284.
[I-D.ietf-radext-rfc2486bis] - now published as RFC 4282.
[IEEE.802.11-1999] - now updated as [IEEE.802.11-2003].
[IEEE.8021x] - now updated as [IEEE.802.1X-2004]
Proposed Resolution:
Discuss
Issue 330: Editorial Comments
Submitter
name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date Submitted:
January 25, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg03943.html
Document:
NETSEL-03
Comment type: E
Priority: S
Section:
Various
Rationale/Explanation of issue:
on
the client side, different approches vary in how much they rely
on
Typo
|
|-------->| |---------> "isp1.com"
This does not conform to the IETF's policy of using only
example.com when giving examples of DNS names.
Several instances throughout the document, different
domain names.
[eronendimacs]
Reference name looks different from the others. Consider
using, e.g., [Eronen04].
Mishra,
A., "Improving the latnecy of the Probe Phase
Typo
tells
the network which mediting network it has decided to choose)
Typo (meditating network? :-)
Identity.
The Alternative NAI is quaranteed to be an unknown NAI
Typo
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
Refer to RFC 4282 instead.
[I-D.ietf-radext-rfc2486bis]
Aboba, B., "The Network Access Identifier",
draft-ietf-radext-rfc2486bis-01 (work in progress),
October 2004.
See above.
[I-D.adrangi-eap-network-discovery]
Adrangi, F., "Mediating Network Discovery in the
Extensible Authentication Protocol (EAP)",
draft-adrangi-eap-network-discovery-14 (work in progress),
August 2005.
Refer to RFC 4284 instead.
[I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress),
October 2004.
Refer to RFC 4309 instead.
[Pasi58] Eronen, P., "Network Selection Issues", presentation to
EAP WG at IETF 58, November 2003.
Use [Eronen03] or something similar instead, better
style.
[pri04]
Priest, J., "The State of Wireless London", July 2004.
Capitalize pri04, or maybe Priest04 for consistent
style...
and
another set from his company.
Rewrite this as "... set
from the user's employer".
Arkko
& Aboba, Eds. Expires April 26, 2006 [Page 3]
The
new editors need to be put here, too.
Proposed Resolution:
Accept
Issue 331: Introduction
Improvements
Submitter name: Jari Arkko
Submitter email address:
jari.arkko@piuha.net
Date
Submitted: January 25, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg03944.html
Document:
NETSEL-03
Comment type: E
Priority: S
Section:
1
Rationale/Explanation of issue:
o There is more than one available network attachment point, and the
different points may have different characteristics.
Add ", or even be from different
providers".
o The user has multiple sets of credentials. For instance, the user
could have one set of credentials from a public service provider
and another set from his company.
Ok.
o There is more than one way to provide roaming between the access
and home network, and service parameters or pricing differs
between them. For instance, the access network could have both a
direct relationship with the home network and an indirect
relationship through a roaming consortium.
o The roaming relationships between access and home networks are so
complicated that current AAA protocols can not route the requests
to the home network unaided, just based on the domain in the given
Network Access Identifier (NAI) [RFC2486] [I-D.ietf-radext-
rfc2486bis].
o Payload packets get routed or tunneled differently, based on which
particular roaming relationship variation is used. This may have
an impact on the available services or their pricing.
Suggest combining these under a roaming effect
item.
o Virtual Operators share the same infrastructure, such as wireless
access points.
Put this after the first bullet, or maybe as a part of the first
bullet.
Proposed Resolution:
Accept
Issue 332: Section 2
Improvements
Submitter name: Jari Arkko
Submitter email address:
jari.arkko@piuha.net
Date
Submitted: January 25, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg03945.html
Document:
NETSEL-03
Comment type: E
Priority: S
Section:
2
Rationale/Explanation of issue:
The Access Network Discovery problem has been extensively studied,
see for instance the results of the IETF Seamoby WG, IEEE
specifications on 802.11 wireless LAN beaconing and probing process,
studies (such as [Fixingapsel]) on the effectiveness of these
mechanisms, and so on.
Maybe you could start with a reference to 802.11 as well as
some other (e.g. GSM cellular), then continue with the Seamoby
things; the main body of the work has been imho in the link
layers.
2.1
Access Network Discovery
This section is very 802.11 focused. It might make sense
to mention other link layers, too. For instance, cellular
link layers typically employ very network-centric mechanisms
for directing clients to the most suitable attachment point.
While there
is Standards Track RFC specifying the interpretation of the field
beyond the NUL character, [I-D.adrangi-eap-network-discovery] is
widely expected to be used.
While there is NO Standards Track
RFC? Also, don't say anything about what usage expectations there
are. Just state that the spec exists.
For instance, the Redirect feature could be used to provide
a centralized routing function for AAA, without having to know all
home network names in all access networks.
There should be some truth-in-advertising disclaimer
here. We don't know how to set the security up for
that in practice, and even if we did, it might not match
business practices.
Proposed Resolution:
Accept
Issue 333: Review Scope
Submitter name:
Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date Submitted:
January 25, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg03946.html
Document:
NETSEL-03
Comment type: E
Priority: S
Section: Abstract,
2.4
Rationale/Explanation of issue:
The document may attempt to state too much. Suggest
narrowing the scope a little bit, not claiming this document
has a recommendation on what to do in this area -- just
the definition of problem, as well as some analysis of the
limitations of certain types of solutions.
Specifically, in the
abstract:
The document presents also some
existing mechanisms which help solve at least parts of the problem,
and gives some suggestions on how to proceed for the rest.
Maybe rewrite this as "The document also provides a discussion of the
limitations of certain classes of solutions, including some that have
been previously defined."
Section 4 discusses existing mechanisms which help solve at least
parts of the problem. Section 5 gives some suggestions on how to
proceed for the rest.
Same here.
2.4
Payload Routing
While interesting, I wonder if we should spend energy looking
at this sub-problem. Could just mention it at the beginning but
not discuss it further.
[Jari Arkko] Parts remaining from issue 333:
> Section 4 gives the conclusions
> and some suggestions on how to proceed for the rest.
This should be: "Section 4 presents our conclusions."
Editorial:
> discussion of the limitations of certain classes of solution,
s/solution/solutions/
> The solution ...
Multiple occurrences of this. I think the draft should
not assume that we have a single solution in this space.
Therefore, we should typically write "Solutions should
satisfy ... " as opposed to "The solution should satisfy ..."
Proposed Resolution:
Accept
Issue 334: Section 3
Improvements
Submitter name: Jari Arkko
Submitter email address:
jari.arkko@piuha.net
Date
Submitted: January 25, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg03947.html
Document:
NETSEL-03
Comment type: E
Priority: S
Section:
3
Rationale/Explanation of issue:
I believe Section 3 would be better cast as "issues" than
"constraints". The topics should be grouped under
subsection items and discussed in more depth. For instance,
there are a few items that relate to AAA protocol operations
(different protocols, both client and server initiated transactions,
etc). Another topic is efficiency constraints, including avoiding
unnecessary polling with multiple networks, packet size
issues etc. A third topic could be backwards compatibility
and deployment considerations.
It would also be useful if specific examples could be
presented, for instance, about the use of RFC 4284
mechanisms taken to extremes and what implications
that would have.
Material from current Sections 4 and 5 could in part be
moved here.
Proposed Resolution:
Accept
Issue 335: Section 4
Improvements
Submitter name: Jari Arkko
Submitter email address:
jari.arkko@piuha.net
Date
Submitted: January 25, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg03948.html
Document:
NETSEL-03
Comment type: E
Priority: S
Section:
4
Rationale/Explanation of issue:
Perhaps this section could be moved before 3, and
shortened by moving some of the discussion of the
limitations of the existing mechanisms to the issues
Section (currently Section 3, Design Constraints).
A number of (small) improvements to payload routing control are
currently in progress in the IETF RADEXT WG. These include better
filtering and redirection support [I-D.ietf-radext-ieee802]. RADEXT
Is it really still there? I think there was a discussion on the
filtering parts to be removed... check this.
WG is also working on an new revision of the NAI specification
[I-D.ietf-radext-rfc2486bis]. This revision clarifies the use of the
'!' syntax in a NAI to route requests via specified mediating
networks.
Old stuff.
4.3
3GPP
This only deals with the I-WLAN functionality of 3GPP
networks. It would be interesting to see a paragraph or
two about the cellular network selection mechanisms,
at least a statement about the principles on which
it operates.
Proposed Resolution:
Accept
Issue 336: Section 5
Improvements
Submitter name: Jari Arkko
Submitter email address:
jari.arkko@piuha.net
Date
Submitted: January 25, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg03949.html
Document:
NETSEL-03
Comment type: E
Priority: S
Section:
5
Rationale/Explanation of issue:
I would significantly shorten this Section and focus
mainly on concluding some of the main findings of
the problem definition and the dicussion on issues.
Some of the discussion should be moved to the issue
section.
An example of something to keep:
o Nevertheless, many of the problems discussed in this draft are
very hard when one considers them in an environment that requires
a potentially large number of networks, fast handoffs, and
automatic decisions.
An example of something to move to the issue
section: o "Phone-book" based approaches such as RFC 3017 appear attractive
due to their ability to provide sufficient information for
automatic selection decisions. However, there is no experience on
applying such approaches to wireless access. The number of WLAN
access points is significantly higher than the number of dial-in
POPs; the distributed nature of the access network has created a
more complicated business and roaming structure, and the expected
rate of change in the information is high. As noted in [pri04]
and [I-D.groeting-eap-netselection-results], a large fraction of
current WLAN access points operate on the default SSID, which may
make the use of the phone book approach hard.An example of
something to remove:
... the IETF should in any case initiate work that
enables support for channel bindings in methods. Preferably, popular
methods should be updated, ensuring compatibility with existing
deployments. The representation of link layer parameters within EAP
should utilize a common framework, to make it easier to define new
link layers and keep the selection of EAP methods independent of the
link layer. A number of proposals exist in this space, but none of
them have yet been adopted by the EAP WG as work items.
Proposed Resolution:
Accept
Issue 337: Removal of Appendix
A
Submitter name: Bernard Aboba
Submitter email address: mailto:jari.arkko@piuha.net
Date
Submitted: February 25, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg03993.html
Document:
KEYING-09
Comment type: E
Priority: 1
Section: Appendix
A
Rationale/Explanation of issue:
The material in Appendix A has now been included in RFC 2716bis. As a
result,
it is no longer needed in the EAP Keying Framework. It is recommended
that
this Appendix be deleted.
Proposed Resolution:
Accept
Issue 338: Key Scope
Submitter name:
Joe Salowey
Submitter email address: jsalowey@cisco.com
Date Submitted:
December 1, 2005
Reference:
Document: Keying-08
Comment type:
T
Priority: 1
Section: 2.4
Rationale/Explanation of issue:
The key scope section is a little hard to understand.
---
The key
scope recommendations should specify which key it refers to. I
believe
it refers to the AAA-key.
---
There could be some more generic text about
key scoping that describes
the requirements in the lower layer such
as:
- Identify what parameters in the lower layer define the key
scope
- In phase 0 communicate lower layer parameters that identify the
key
scope between Peer and Authenticator
- If channel bindings are
supported then include these parameters in the
channel bindings in phase
1a
- The peer can now use the key scope parameters to determine if it
has
correct keys for phase 2 lower layer protocol
interactions
Requested change:
Include in the key scoping
section introduction (2.4) something along
the lines of the following
text:
"Since authenticator architectures and deployment scenarios vary
the
usable scope of the keys derived by the peer and server and sent to
the
authenticator vary. By defining a key scope a lower layer can
take
advantage of key caches in the system to optimize lower
layer
interactions. In order to address key scoping the following needs
to be
specified by the lower layer:
- Identify what parameters in the
lower layer define the key scope
- In phase 0 communicate lower layer
parameters that identify the key
scope between Peer and Authenticator
- If
channel bindings are supported then include these parameters in the
channel
bindings in phase 1a
- The peer can now use the key scope parameters to
determine if it has
correct keys for phase 2 lower layer protocol
interactions"
The following sections describe key scoping with respect to
the AAA-Key
that is sent to the authenticator for lower layer
protection. It is
possible that a lower layer may define other keys and
key uses which
need to have scoping applied.
---
Make it
clear that remaining parts of sections 2.4.1 and 2.4.2 refer to
the AAA-Key.
[Bernard Aboba]
The proposed resolution is to move the key scope material out of
Section
2.4 into a new Section 2.5. How does this look?
2.5. Key
Scope
Where the EAP peer and authenticator cannot unambiguously
identify
each other they may not be able to determine the scope of
transported
EAP keying material. This is particularly problematic for
lower
layers where key caching is supported.
For example, if the EAP
peer cannot identify the EAP authenticator,
it will be unable to determine
whether transported EAP keying
material has been shared outside of its
authorized scope, and
therefore needs to be considered compromised. There is
also a
practical problem because the EAP peer will be unable to utilize
the
EAP authenticator key cache in an efficient way.
To avoid these
problems, it is recomended that lower layers:
[1] Specify the lower layer
parameters used to identify the
authenticator and peer;
[2]
Communicate the lower layer identities between the peer and
authenticator
within phase 0;
[3] Communicate the lower layer authenticator identity
between the
authenticator and backend server within the
NAS-Identifier
attribute;
[4] Include the lower layer identities
within channel bindings (if
supported) in phase 1a, ensuring that they are
communicated between
the EAP peer and server;
[5] Securely verify the
lower layer identities within phase 2a;
[6] Utilize the advertised lower
layer identities to enable the peer
and authenticator to verify that keys are
maintained within the
advertised scope;
Absent explicit specification
within the lower layer, after the
completion of phase 1b, EAP keying material
and parameters are
bound to the EAP peer and authenticator, but are not bound
to a
specific peer or authenticator port.
While EAP Keying Material
passed down to the lower layer is not
intrinsically bound to particular
authenticator and peer ports,
Transient Session Keys MAY be bound to
particular authenticator and
peer ports by the Secure Association Protocol.
However, a lower
layer MAY also permit TSKs to be used on multiple peer
and/or
authenticator ports, providing that TSK freshness is
guaranteed
(such as by keeping replay counter state within the
authenticator).
In order to further limit the key scope the following
measures are
suggested:
[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.
[b] The backend authentication server and authenticator
MAY implement
additional attributes in order to further restrict the scope of
EAP
keying material. For example, in 802.11, the backend
authentication
server may provide the authenticator with a list of
authorized Called or
Calling-Station-Ids and/or SSIDs for which EAP
keying material is
valid.
[c] Where the backend authentication server provides
attributes
restricting the key scope, it is RECOMMENDED that restrictions
be
securely communicated by the authenticator to the peer. This can
be
accomplished using the Secure Association Protocol, but also
can be
accomplished via the EAP method or the lower layer.
Proposed Resolution:
Accept
Issue 339: Use of Session-Timeout in
Pre-authentication
Submitter name: Bernard Aboba
Submitter email
address: aboba@internaut.com
Date Submitted: March 23, 2006
Reference:
Document: Keying-10
Comment type: T
Priority: S
Section:
3.4
Rationale/Explanation of issue:
During the HOAKEY BOF, Avi Lior
pointed out that overloading of
Session-Timeout for use in pre-authentication
could cause problems.
For example, it might be desirable to be able to
specify both the
pre-authentication timeout and the Session-Timeout values at
the
same time.
Section 3.4 of the keying document describes use of
the Session-Timeout
attribute to set the pre-authentication timeout. Rather
than
specifying this here, it would be best to leave this to a
future
document.
The proposed change is as follows:
In
Section 3.4, delete the following text:
"Where EAP is used
for
pre-authentication, the session may not start until some future
time, or may
never occur. Nevertheless, the Session-Timeout value
represents the time
after which transported EAP keying material,
and all keys calculated from it,
will have expired on the
authenticator. If the session subsequently starts,
re-
authentication will be initiated once the Session-Time has expired.
If
the session never started, or started and ended, by default keys
transported
by AAA and all keys calculated from them will be
expired by the authenticator
prior to the future time indicated by
Session-Timeout."
[Jari Arkko]
| |
|
I actually liked the old text since it was very clear: ALL
exported
keys expire at Session-Timeout time, no exceptions. This
seems
to make sense, still.
I do agree that it might make
sense to have additional lifetimes
specified for the preauth case, but
I see those as additional
constraints rather than something that
replaces Session-Timeout.
|
I think the issue is how to specify *both* the Session-Timeout and
the pre-auth timeout. If only Session-Timeout is included, the meaning is
clear -- all keys expire when Session-Timeout runs out. However, if a pre-auth
timeout attribute is included then the question is how to specify the maximum
lifetime of the session, as opposed to the key lifetime. I'd like to leave some
wiggle room for future documents.
How about this?
"Where EAP is
used for pre-authentication, the session may not start until some future
time, or may never occur. Nevertheless, the Session-Timeout value
represents the maximum time after which transported EAP keying material, and all
keys calculated from it, will have expired on the authenticator. If the
session subsequently starts, re-authentication will be initiated once the
Session-Time has expired. If the session never started, or started and ended, by
default keys transported by AAA and all keys calculated from them will be
expired by the authenticator prior to the future time indicated by
Session-Timeout. Note that in future additional attributes may be
specified to control the lifetime of cached keys; these attributes may modify
the meaning of the Session-Timeout attribute in specific circumstances."
Proposed Resolution:
Discuss
Issue 340: MD5 Attacks
Submitter name:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date Submitted:
March 23, 2006
Reference:
Document: Keying-10
Comment type:
E
Priority: S
Section: 3.7
Rationale/Explanation of issue:
The
security considerations section refers to somewhat ancient attacks
on MD5.
Since significantly more sophisticated attacks exist now,
the text needs to
be updated.
Proposed Change:
In Section 3.7, change:
" As
described in [RFC3579] Section 4.3, known problems exist in the
key wrap
specified in [RFC2548]. Where the same RADIUS shared secret
is used by a PAP
authenticator and an EAP authenticator, there is a
vulnerability to known
plaintext attack. Since RADIUS uses the
shared secret for multiple purposes,
including per-packet
authentication, attribute hiding, considerable
information is exposed
about the shared secret with each packet. This exposes
the shared
secret to dictionary attacks. MD5 is used both to compute the
RADIUS
Response Authenticator and the Message-Authenticator attribute,
and
some concerns exist relating to the security of this
hash
[MD5Attack]."
To:
" The key wrap specified in [RFC2548],
which is based on
an MD5-based stream cipher, has known problems, as
described in [RFC3579] Section 4.3.
RADIUS uses the shared secret for
multiple purposes, including
per-packet authentication and attribute hiding,
considerable
information is exposed about the shared secret with each
packet.
This exposes the shared secret to dictionary attacks. MD5 is
used both to compute the RADIUS Response Authenticator and the
Message-Authenticator attribute, and concerns exist relating
to the
security of this hash [MD5Collision]."
Replace [MD5Attack] with
[MD5Collision] throughout the document and in the
references:
[MD5Collision]
Klima, V., "Tunnels in Hash Functions: MD5
Collisions Within a Minute",
Cryptology ePrint Archive, March 2006,
http://eprint.iacr.org/2006/105.pdf
Proposed Resolution:
Accept
Issue 341: Editorial NITs
Submitter name:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date Submitted:
March 23, 2006
Reference:
Document: Keying-10
Comment type:
E
Priority: S
Section: 6,7, Appendix A
Rationale/Explanation of
issue:
Some NITs:
Appendix A does not include references to each of the EAP
methods that
are described. These should be added to Appendix A as well as
the
reference list.
Proposed Resolution:
Accept
Issue 342: More NITs
Submitter name:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date Submitted:
March 23, 2006
Reference:
Document: Keying-10
Comment type:
E
Priority: S
Section: 3, 3.5, 4
Rationale/Explanation of issue:
Section 3 is somewhat confusing.
Section 3.5 is poorly written.
Section 4 is not clear about what mechanisms are being referred to in the
last sentence.
Change Section 3 from:
"3. Key
Management
EAP as defined in [RFC3748] supports key
derivation, but not key
management. While EAP methods may
derive keying material, EAP does
not 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 re-key. Although EAP
methods may
support "fast reconnect" as defined in [RFC3748] Section
7.2.1,
re-key of exported keys cannot occur without re-
authentication. In order to provide method independence,
key
management of exported or derived keys SHOULD NOT be
provided within
EAP methods."
To:
"3. Key Management
EAP as defined in
[RFC3748] supports key derivation, but not key
management. While EAP methods
may derive keying material, EAP does
not provide for the management of
exported or derived keys. Although
EAP methods may support "fast reconnect"
as defined in [RFC3748]
Section 7.2.1, EAP does not support re-key of
exported keys without
re-authentication. Existing EAP methods do not export
the Key-
Lifetime parameter; in the interest of method independence,
key
management of exported or derived keys SHOULD NOT be provided
within
EAP methods."
Change Section 3.5 from:
"3.5. Key cache
synchronization
Issues arise when attempting to synchronize
the key cache on the peer
and authenticator. Lifetime
negotiation alone cannot guarantee key
cache
synchronization.
One problem is that the AAA protocol cannot
guarantee synchronization
of key lifetimes between the peer and
authenticator. Where the
Secure Association Protocol is
not run immediately after EAP
authentication, the exported and
calculated key lifetimes will not be
known by the peer during
the hiatus. Where EAP pre-authentication
occurs, this can
leave the peer uncertain whether a subsequent
attempt to use the
exported keys will prove successful.
However, even where the
Secure Association Protocol is run
immediately after EAP, it is
still possible for the authenticator to
reclaim resources if the
created key state is not immediately
utilized.
The lower layer may utilize Discovery mechanisms
to assist in this.
For example, the authenticator manages the
key cache by deleting the
oldest key first (LIFO), the relative
creation time of the last key
to be deleted could be advertised
with the Discovery phase, enabling
the peer to determine whether
a given key had been expired from the
authenticator key cache
prematurely."
To:
"3.5. Key cache synchronization
Issues
arise when attempting to synchronize the key cache on the peer
and
authenticator.
While the AAA protocol can enable the backend
authentication server
to provide guidance on the lifetime of transported EAP
keying
material to the authenticator, this does not address the problem
of
key lifetime synchronization between the peer and authenticator.
Where
the EAP method does not export the Key-Lifetime parameter, the
lifetime of
the EAP keying material may not be defined until
completion of the Secure
Association Protocol, if ever. This can
leave the peer uncertain how long the
authenticator will maintain EAP
keying material within the key
cache.
However, key lifetime negotiation alone cannot guarantee key
cache
synchronization. Even where the Secure Association Protocol is
run
immediately after EAP and determines the lifetime of EAP
keying
material, it is still possible for the authenticator to
reclaim
resources.
The lower layer may utilize the Discovery phase 0
to improve key
cache synchronization. For example, if the authenticator
manages the
key cache by deleting the oldest key first (LIFO), the
relative
creation time of the last key to be deleted could be
advertised
within the Discovery phase, enabling the peer to determine
whether
keying material had been prematurely expired from the
authenticator
key cache."
Change Section 4 from:
"4. Handoff
Vulnerabilities
With EAP, a number of mechanisms are be utilized in order
to reduce
the latency of handoff between authenticators. One such mechanism
is
EAP pre-authentication, in which EAP is utilized to pre-establish
EAP
keying material on an authenticator prior to arrival of the
peer.
Another such mechanism is key caching, in which an EAP peer can
re-
attach to an authenticator without having to re-authenticate
using
EAP. Yet another mechanism is context transfer, such as is
defined
in [IEEE-802.11F] (now deprecated) and [CTP]. These
mechanisms
introduce new security vulnerabilities, as discussed in the
sections
that follow."
To:
"4. Handoff
Vulnerabilities
With EAP, several mechanisms are available to reduce the
latency in
handoff between authenticators:
[1] EAP pre-authentication.
This utilizes EAP to pre-establish EAP
keying material on an authenticator
prior to arrival of the peer.
[2] Key caching. This mechanism enables an
EAP peer to re-attach to an
authenticator without requiring EAP
re-authentication.
[3] Context transfer, such as is defined in
[IEEE-802.11F] (now
deprecated) and [CTP].
The sections that follow
discuss the security vulnerabilities introduced
by the above
mechanisms.
Proposed Resolution: Accept
Issue 343: Sections 1, 2 and 5 Cleanup
Submitter
name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date
Submitted: March 27, 2006
Reference:
Document: Keying-10
Comment type:
E
Priority: S
Section: 1, 2, 5
Rationale/Explanation of issue:
The flow of Section 1 leaves something to be desired. It launches
right into the EAP key hierarchy without any overview, and the
security goals of EAP are not discussed until Section 5, which
seems somewhat out of place.
The proposed resolution is to move the first half of Section 2.1
(up to the examples) and the portion of Section 5
dealing with security goals to Section 1.3.
The examples in the second half of Section 2.1 will be moved
to section 1.3.1. Section 1.3 (EAP Key Hierarchy) becomes
Section 1.4; Section 1.4 (EAP Invariants) becomes Section 1.5.
Section 2.2 (Layering) becomes Section 2 (Lower Layer Operation);
Section 2.3 (Transient Session Keys) becomes Section 2.1, Section
2.4 (Authenticator Architecture) becomes Section 2.2; Section
2.5 (Key Scope) becomes section 2.3.
Section 5.1 will be incorporated in Section 5, rather than being
a separate section. Section 5.2 (Threat Model) becomes Section
5.1.
The following paragraphs in Section 5.6 relate to authenticator
and peer identification, a subject extensively discussed in Section 2.4:
" In order to enable key binding and authorization of all parties, it is
RECOMMENDED that the parties use a set of identities that are
consistent between the conversation phases. RADIUS [RFC2865] and
Diameter NASREQ [RFC4005] require that the NAS/EAP authenticator
identify itself by including one or more identification
attributes within an Access-Request packet (NAS-Identifier,
NAS-IP-Address, NAS-IPv6-Address).
Since the backend authentication server provides EAP keying material
for use by the EAP authenticator as identified by these attributes,
where an EAP authenticator may have multiple ports, it is RECOMMENDED
for the EAP authenticator to identify itself using NAS identification
attributes during the Secure Association Protocol exchange with the
EAP peer. This enables the EAP peer to determine whether EAP keying
material has been shared between EAP authenticators as well as to
confirm with the backend authentication server that an EAP
authenticator proving possession of EAP keying material during the
Secure Association Protocol was authorized to obtain it. Typically,
the NAS-Identifier attribute is most convenient for this purpose,
since a NAS/authenticator may have multiple IP addresses.
Similarly, the backend authentication server authorizes the EAP
authenticator to provide access to the EAP peer identified by the
Peer-ID, securely verified during the EAP authentication exchange.
In order to determine whether EAP keying material has been shared
between EAP peers, where the EAP peer has multiple ports it is
RECOMMENDED for the EAP peer to identify itself using the Peer-ID
during the Secure Association Protocol exchange with the EAP
authenticator."
To reduce redundancy, it is recommended that these paragraphs be
changed to the following:
"In order to enable key binding and authorization of all parties, it is
RECOMMENDED that the parties use a set of identities that are
consistent between the conversation phases.
Section 2.2 discusses identification issues that arise where the
EAP authenticator and peer may have multiple ports. Consistently
identifying the EAP authenticator enables the EAP peer to determine
whether EAP keying material has been shared between EAP authenticators
as well as to confirm with the backend authentication server that an EAP
authenticator proving possession of EAP keying material during the
Secure Association Protocol was authorized to obtain it.
Similarly, the backend authentication server authorizes the EAP
authenticator to provide access to the EAP peer identified by the
Peer-ID, securely verified during the EAP authentication exchange.
In order to determine whether EAP keying material has been shared
between EAP peers, where the EAP peer may have multiple ports it is
RECOMMENDED for the EAP peer to identify itself using the Peer-ID
during the Secure Association Protocol exchange with the EAP
authenticator."
In Section 5.8, the following sentence contradicts the
discussion in Section 2.1.
"TSKs are permitted to be accessed
only by the EAP peer and authenticator.
Since the TSKs can be determined from the transported EAP
keying material and the cleartext of the Secure Association
Protocol exchange, the backend authentication server will have
access to the TSKs"
Recommend that it be changed to:
"TSKs are permitted to be accessed
only by the EAP peer and authenticator (Section 1.3).
As discussed in Section 2.1, PPP and 802.11i derive the TSKs
from transported EAP keying material;
802.16e utilizes transported EAP keying material for TSK keywrap; IKEv2
utilizes transported EAP keying material only to authenticate the
derivation of TSKs. Possession of transported keying material enables the
backend authentication server to masquerade as the authenticator, and
in some cases to obtain the TSKs (PPP, 802.11i, 802.16e)"
Section 1.3 now reads as follows:
"1.3. 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 external to EAP.
Phases 0 and 2 are handled by the lower layer protocol and phase 1b
is typically handled by a AAA protocol.
In the discovery phase (phase 0), peers locate authenticators and
discover their capabilities. 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. Discovery can occur manually or automatically,
depending on the lower layer over which EAP runs.
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 1: Conversation Overview
The authentication phase (phase 1) may begin once the peer and
authenticator discover each other. This phase, if it occurs, 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.
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, all keying material which is required by the lower
layer needs to be transported from the EAP server to the
authenticator. Since existing TSK derivation techniques depend
solely on the MSK, in existing implementations, this is the only
keying material replicated in the AAA key transport phase 1b.
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). The Secure Association
exchange (phase 2) 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 1.
The goal of the EAP conversation is to derive fresh session keys
between the EAP peer and authenticator that are known only to those
parties, and for both the EAP peer and authenticator to demonstrate
that they are authorized to perform their roles either by each other
or by a trusted third party (the backend authentication server).
Authorization issues are discussed in Sections 5.8.
Completion of an EAP method exchange (Phase 1a) supporting key
derivation results in the derivation of EAP keying material (MSK,
EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID)
and server (identified by the Server-ID). Both the EAP peer and EAP
server know the exported keying material to be fresh. Disclosure
issues are discussed in Section 5.5; key freshness is discussed in
Sections 3.3, 3.4 and 5.7.
Completion of the AAA exchange (Phase 1b) results in the transport of
EAP keying material from the EAP server (identified by the Server-ID)
to the EAP authenticator (identified by the NAS-Identifier) without
disclosure to any other party. Both the EAP server and EAP
authenticator know this keying material to be fresh. Security
properties of AAA protocols are discussed in Sections 5.2-5.8, and
5.11.
Completion of the Secure Association Protocol (Phase 2) results in
the derivation of Transient Session Keys (TSKs) known only to the EAP
peer (identified by the Peer-ID) and authenticator (identified by the
NAS-Identifier). Both the EAP peer and authenticator know the TSKs
to be fresh. Security properties of Secure Association Protocols are
discussed in Section 3.1."
[Jari Arkko]
| |
|
Possession of transported keying material enables
the backend
authentication server to masquerade as the authenticator, and
in some
cases to obtain the TSKs (PPP, 802.11i, 802.16e)"
|
Actually, I don't believe this is true in IKEv2 since the
authenticator needs to prove possession of *both* the IKEv2 secret (e.g. DH key)
as well as the EAP MSK. So gaining possession of the MSK would not allow a
backend authentication server to masquerade as the authenticator. Suggest
this be rewritten as follows:
"Where demonstration of authorization
depends entirely on possession of transported EAP keying material (such as in
PPP, 802.11i and 802.16e), this enables the backend server to masquerade as the
authenticator, and possibly to obtain the TSKs"
Proposed Resolution:
Accept
Issue 344: Yet More NITs
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date Submitted: March 30, 2006
Reference:
Document: Keying-10
Comment type: E
Priority: 1
Section: Various
Rationale/Explanation of issue:
In Section
1.3Change:"Phase 2: Secure Association
Establishment"To:"Phase 2: Secure Association
Protocol"Change: " In order to obey the principle of Mode Independence, where a backend
server is present, all keying material which is required by the lower
layer needs to be transported from the EAP server to the
authenticator. Since existing TSK derivation techniques depend
solely on the MSK, in existing implementations, this is the only
keying material replicated in the AAA key transport phase 1b."
To: " In order to obey the principle of Mode Independence (see Section
1.6.1), where a backend server is present, all keying material which
is required by the lower layer needs to be transported from the EAP
server to the authenticator. Since existing TSK derivation and
transport techniques depend solely on the MSK, in existing
implementations, this is the only keying material replicated in the
AAA key transport phase 1b."In Section 1.3.1,
add: "A proof of the security of the IEEE 802.11i 4-way
handshake when used with EAP-TLS [RFC2716], is provided in [He]."
Move the following material from Section 1.3 to Section 1.5 and
change the text from:
" The goal of the EAP conversation is to derive fresh session keys
between the EAP peer and authenticator that are known only to those
parties, and for both the EAP peer and authenticator to demonstrate
that they are authorized to perform their roles either by each other
or by a trusted third party (the backend authentication server).
Authorization issues are discussed in Sections 5.8. Completion of an EAP method exchange (Phase 1a) supporting key
derivation results in the derivation of EAP keying material (MSK,
EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID)
and server (identified by the Server-ID). Both the EAP peer and EAP
server know the exported keying material to be fresh. Disclosure
issues are discussed in Section 5.5; key freshness is discussed in
Sections 3.3, 3.4 and 5.7.
Completion of the AAA exchange (Phase 1b) results in the transport of
EAP keying material from the EAP server (identified by the Server-ID)
to the EAP authenticator (identified by the NAS-Identifier) without
disclosure to any other party. Both the EAP server and EAP
authenticator know this keying material to be fresh. Security
properties of AAA protocols are discussed in Sections 5.2-5.8, and
5.11.
Completion of the Secure Association Protocol (Phase 2) results in
the derivation of Transient Session Keys (TSKs) known only to the EAP
peer (identified by the Peer-ID) and authenticator (identified by the
NAS-Identifier). Both the EAP peer and authenticator know the TSKs
to be fresh. Security properties of Secure Association Protocols are
discussed in Section 3.1."To: " The goal of the EAP conversation is to derive fresh session keys
between the EAP peer and authenticator that are known only to those
parties, and for both the EAP peer and authenticator to demonstrate
that they are authorized to perform their roles either by each other
or by a trusted third party (the backend authentication server).
Completion of an EAP method exchange (Phase 1a) supporting key
derivation results in the derivation of EAP keying material (MSK,
EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID)
and server (identified by the Server-ID). Both the EAP peer and EAP
server know the exported keying material to be fresh. Key freshness
is discussed in Sections 3.3, 3.4 and 5.7.
Completion of the AAA exchange (Phase 1b) results in the transport of
EAP keying material from the EAP server (identified by the Server-ID)
to the EAP authenticator (identified by the NAS-Identifier) without
disclosure to any other party. Both the EAP server and EAP
authenticator know this keying material to be fresh. Disclosure
issues are discussed in Section 5.6; security properties of AAA
protocols are discussed in Sections 5.2-5.8, and 5.11.
Completion of the Secure Association Protocol (Phase 2) results in
the derivation or transport of Transient Session Keys (TSKs) known
only to the EAP peer (identified by the Peer-ID) and authenticator
(identified by the NAS-Identifier). Both the EAP peer and
authenticator know the TSKs to be fresh. Both the EAP peer and
authenticator demonstrate that they are authorized to perform their
roles. Authorization issues are discussed in Section 5.8 and 5.9;
security properties of Secure Association Protocols are discussed in
Section 3.1."
In Section 1.6.1, change "in order to support" to
"to support"Change: "However, one of the advantages of EAP is
that it enables deployment of"To:"However,
when utilized in "pass-through" mode, EAP enables deployment
of"In Section 1.6.2, change: " over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and IEEE
802.11 wireless LANs [IEEE-802.11i]."
To:" over
PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and
wireless networks
such as 802.11 [IEEE-802.11i] and 802.16 [IEEE-802.16e]."In
Section 2.3:Change "Figure 5" to "Figure
3".Change:"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"To:"For example, a difference between IKEv1
and IKEv2 is that in IKEv1 SA lifetimes
were negotiated; in IKEv2, each end
of the SA is"Change:"EAP does not support
negotiation of key lifetimes, nor does it support re-key
without
re-authentication."To: "EAP does not support re-key without re-authentication and existing EAP
methods do not support key lifetime negotiation."
Change:
"[RFC3748], does not support the negotiation of lifetimes for exported
keying material such as the MSK, EMSK and IV."
To: "[RFC3748], does not itself support the negotiation of lifetimes for
exported keying material such as the MSK, EMSK and IV."
Change:"material
or keys derived from it is only utilized by a
single"To:"material or keys derived from it
are only utilized by a single"In Section
5.8:Change "a post-EAP handshake" to "a Secure Association
Protocol"In Section
5.11:Change: "Both the RADIUS and Diameter protocols are potentially vulnerable to
impersonation by a rogue authenticator.
While AAA protocols such as
RADIUS [RFC2865] or
Diameter [RFC3588] support mutual
authentication
between the authenticator (known as the AAA client) and
the
backend authentication server (known as the backend authentication
server),
the security mechanisms vary according to the AAA
protocol. In RADIUS, the shared secret
used for authentication is determined by the source address
of the RADIUS packet. As noted in [RFC3579] Section 4.3.7,
it is highly desirable that the source address be checked
against one or more NAS identification attributes so as to
detect and prevent impersonation attacks.
When RADIUS requests are
forwarded by a proxy,"To:"Both the RADIUS
[RFC2865] and Diameter [RFC3588] protocols are potentially vulnerable
to
impersonation by a rogue authenticator.
While both protocols
support
mutual authentication
between the authenticator (known as the AAA client)
and
the backend authentication server (known as the backend authentication
server),
the security mechanisms vary. In RADIUS, the shared secret
used for authentication is determined by the source address
of the RADIUS packet. As noted in [RFC3579] Section 4.3.7,
it is highly desirable that the source address be checked
against one or more NAS identification attributes so as to
detect and prevent impersonation attacks.
When RADIUS
Access-Requests are forwarded by a
proxy,"Change: "While [RFC3588] requires use of the Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A/AAAA and PTR
RRs to be properly configured. As a result, it appears that Diameter
is as vulnerable to this attack as RADIUS, if not more so. To address
this vulnerability, it is necessary to allow the backend
authentication server to communicate with the authenticator directly,
such as via the redirect functionality supported in [RFC3588]."
To: "While [RFC3588] requires use of the Route-Record AVP, this utilizes
FQDNs, so that impersonation detection requires DNS A, AAAA and PTR
Resource Records (RRs) to be properly configured. As a result, Diameter
is as vulnerable to this attack as RADIUS, if not more so. To address
this vulnerability, it is necessary to allow the backend
authentication server to communicate with the authenticator directly,
such as via the redirect functionality supported in [RFC3588]."
In
Section 5.12:Change:"[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
Called-Station-ID [RFC2865], 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 backend authentication
server while
communicating misleading information to the EAP peer via the
lower
layer. For example, a compromised authenticator can
utilize another authenticator's Called-Station-Id or NAS-Identifier
in communicating with the EAP peer via the lower layer, 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."
To:"As described in
the previous section, it is possible for a proxy
to detect a AAA client
attempting
to impersonate another authenticator (such by sending
incorrect
Called-Station-ID [RFC2865], 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 backend authentication
server while
communicating misleading information to the EAP peer via the
lower
layer. For example, a compromised authenticator can
utilize another authenticator's Called-Station-Id or NAS-Identifier
in communicating with the EAP peer via the lower layer. Also,
a pass-through authenticator acting as a AAA client can provide an
incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA
server via the AAA protocol."
In Section 7.2, add the following
reference:[He] He, C., Sundararajan, M., Datta, A. Derek, A.
and J. C. Mitchell,
"A Modular Correctness Proof of TLS and IEEE
802.11i",
ACM Conference on Computer and Communications Security (CCS '05),
November, 2005.
Proposed Resolution:
Accept
Issue 345: References to Group Key
Management
Submitter name: Laksminath Dondeti
Submitter email address:
dondeti@qualcomm.com
Date Submitted: April 3, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04177.html
Document:
Keying-10
Comment type: E
Priority: S
Section:
2.1
Rationale/Explanation of issue:
EAP Key management framework I-D
currently says in Page 14
"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]. "
The problem is
4046 describes MSEC's group key management framework and not a particular key
management protocol. MSEC has specified three key management protocols for group
key establishment and they are GDOI, GSAKMP and MIKEY and is working on a third
GKDP (this one is *similar* to IKEv2).
I'd also suggest using
the phrase "establishment of multicast SAs" instead of "derivation ..."
Requested change:
"while the establishment of multicast
security associations (phase 2b) may be handled by a group key management
protocol such as GDOI [RFC3547], GSAKMP [RFC-to-be-GSAKMP], MIKEY [RFC3830], or
GKDP [GKDP-work-in-progress]."
[Jari Arkko]
I agree with your complaint about the current text. But
I have a question
for you: do any of the protocols
that you list in the proposed text work with
EAP-based
authentication? If yes, then those can be listed. Otherwise
it
might be more appropriate to say "... while the establishment
of multicast
security associations (phase 2b) is not
supported for EAP-based
authentication", or words
to that effect.
[Bernard Aboba] How about this?
"IKEv2, defined in
[RFC4306], includes support for EAP and handles the establishment of unicast
security associations (phase 2a). However, the establishment of multicast
security associations (phase 2b) typically does not involve EAP and needs to be
handled by a group key management protocol such as GDOI [RFC3547], GSAKMP
[GSAKMP], MIKEY [RFC3830], or GKDP [GKDP]."
Proposed Resolution:
Accept
Issue 346: Reference Cleanup
Submitter
name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date
Submitted: April 3, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04178.html
Document:
Keying-10
Comment type: E
Priority: S
Section: 4, 7.1,
7.2
Rationale/Explanation of issue:
There are references included in
Section 7.1 and 7.2 that are not referenced anywhere in the
text.
The proposed resolution is as follows:
Delete
[RFC2434] as a Normative reference.
Correct the reference to
[I-D.ohba-eap-aaakey-binding] (typo).
Add references in the text to [RFC2409], [RFC2607],[8021XHandoff],
[IEEE-02-758], [IEEE-03-084].
Add a non-normative reference to
[I-D.irtf-aaaarch-handoff].
Change the text of Section 4
to:
"4. Handoff Vulnerabilities
With EAP, several mechanisms are available to reduce the latency in
handoff between authenticators:
[1] EAP pre-authentication. This utilizes EAP to pre-establish EAP
keying material on an authenticator prior to arrival of the peer.
Use of pre-authentication within IEEE 802.11 is described in
[8021XHandoff] and [IEEE-802.11i]. [2] Key caching. This mechanism enables an EAP peer to re-attach to an
authenticator without requiring EAP re-authentication. [3] Context transfer, such as is defined in [IEEE-802.11F] (now
deprecated) and [RFC4067]. Use of context transfer for handoff
latency improvement is described in [IEEE-02-758]. [4] Proactive key distribution, such as is described in [IEEE-02-758]
and [I-D.irtf-aaaarch-handoff]. The sections that follow discuss the security vulnerabilities
introduced by the above mechanisms."
Delete the following
references from Section 7.2 (Informative References):
[DESMODES] National Institute of Standards and Technology, "DES Modes
of Operation", FIPS PUB 81, December 1980, <http://
www.itl.nist.gov/fipspubs/fip81.htm>. [FIPSDES] National Institute of Standards and Technology, "Data
Encryption Standard", FIPS PUB 46, January 1977. [IEEE-03-155]
Aboba, B., "Fast Handoff Issues", IEEE 802.11 Working
Group, IEEE-03-155r0-I, http://www.ieee802.org/11/
Documents/DocumentHolder/3-155.zip, March 2003. [I-D.ietf-roamops-cert]
Aboba, B., "Certificate-Based Roaming", draft-ietf-roamops-
cert-02 (work in progress), April 1999. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol,
Version 2 (DESE-bis)", RFC 2419, September 1998.
[RFC2420] Kummert, H., "The PPP Triple-DES Encryption Protocol (3DESE)",
RFC 2420, September 1998.
[RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption
(MPPE) Protocol", RFC 3078, March 2001. [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point
Encryption (MPPE)", RFC 3079, March 2001. [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005.
Proposed Resolution:
Accept
Issue 347: Key Scope Cleanup
Submitter
name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date
Submitted: April 3, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04179.html
Document:
Keying-10
Comment type: E
Priority: S
Section: 2.2, 2.3, 3.1,
5.5
Rationale/Explanation of issue:
Material relating to Key Scope is
included in Sections 2.2, 2.3, 3.1, 5.5. The material appears
redundant.
The resolution is to delete Section 2.3, and split
the material between Section 2.2.1 and a new Section 3.2, and delete the
following material from Section 3.1 [h], since it is already gone over in
considerable depth in Section 2.2:
"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."
Section
2.2.1 now reads as follows:
"2.2.1. Authenticator
Identification
The EAP method conversation is between the EAP peer and server, as
identified by the Peer-ID and Server-ID. The authenticator identity,
if considered at all by the EAP method, is treated as an opaque blob
for the purposes of Channel bindings. However, the Secure
Association Protocol conversation is between the peer and the
authenticator, and therefore the authenticator and peer identities
are relevant to that exchange, and define the scope of use of the EAP
keying material passed down to the lower layer.
Where the EAP peer and authenticator cannot unambiguously identify
each other they may not be able to determine the scope of transported
EAP keying material. This is particularly problematic for lower
layers where key caching is supported.
For example, if the EAP peer cannot identify the EAP authenticator,
it will be unable to determine whether transported EAP keying
material has been shared outside of its authorized scope, and
therefore needs to be considered compromised. There is also a
practical problem because the EAP peer will be unable to utilize the
EAP authenticator key cache in an efficient way. Where the peer and
authenticator identify themselves within the lower layer using a port
identifier such as a link layer address, this creates a number of
problems:
[1] It may not be obvious to the peer which authenticator ports are
associated with which authenticators. [2] It may not be obvious to the authenticator which peer ports are
associated with which peers. [3] It may not be obvious to the peer which "virtual authenticator" it
is communicating with. [4] It may not be obvious to the authenticator which "virtual peer" it
is communicating with. Since an authenticator may have multiple ports, the authenticator
identifier used within the Secure Association Protocol exchange
SHOULD be distinct from any port identifier (e.g. MAC address).
Similarly, where a peer may have multiple ports, and sharing of EAP
keying material and parameters between peer ports of the same link
type is allowed, the peer identifier used within the Secure
Association Protocol exchange SHOULD also be distinct from any port
identifier. AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072]
provide a mechanism for the identification of AAA clients; since
the EAP authenticator and AAA client are always co-resident, this
mechanism is applicable to the identification of EAP
authenticators. RADIUS [RFC2865] requires that an Access-Request packet contain one
or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
attributes. Since a NAS may have more than one IP address, the
NAS-Identifier attribute is RECOMMENDED for the unambiguous
identification of the EAP authenticator. From the point of view of the AAA server, EAP keying material and
parameters are transported to the EAP authenticator identified by
the NAS-Identifier attribute. Since an EAP authenticator MUST NOT
share EAP keying material or parameters with another party, if the
EAP peer or AAA server detects use of EAP keying material and
parameters outside the scope defined by the NAS-Identifier, the
keying material MUST be considered compromised. In order to ensure that lower layer identifies are securely
verified by all parties, it is recommended that lower layers: [a] Specify the lower layer parameters used to identify the
authenticator and peer; [b] Communicate the lower layer identities between the peer and
authenticator within phase 0; [c] Communicate the lower layer authenticator identity between the
authenticator and backend server within the NAS-Identifier
attribute; [d] Include the lower layer identities within channel bindings (if
supported) in phase 1a, ensuring that they are communicated between
the EAP peer and server;
[e] Securely verify the lower layer
identities within phase 2a;
[f] Utilize the advertised lower layer identities to enable the peer
and authenticator to verify that keys are maintained within the
advertised scope;"
The newly inserted Section 3.2 reads as
follows:
"3.2. Key Scope
Absent explicit specification within the lower layer, after the
completion of phase 1b, EAP keying material and parameters are bound
to the EAP peer and authenticator, but are not bound to a specific
peer or authenticator port.
While EAP Keying Material passed down to the lower layer is not
intrinsically bound to particular authenticator and peer ports,
Transient Session Keys MAY be bound to particular authenticator and
peer ports by the Secure Association Protocol. However, a lower
layer MAY also permit TSKs to be used on multiple peer and/or
authenticator ports, providing that TSK freshness is guaranteed (such
as by keeping replay counter state within the authenticator).
In order to further limit the key scope the following measures are
suggested:
[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. [b] The backend authentication server and authenticator MAY implement
additional attributes in order to further restrict the scope of EAP
keying material. For example, in 802.11, the backend
authentication server may provide the authenticator with a list of
authorized Called or Calling-Station-Ids and/or SSIDs for which EAP
keying material is valid.
[c] Where the backend authentication server provides attributes
restricting the key scope, it is RECOMMENDED that restrictions be
securely communicated by the authenticator to the peer. This can
be accomplished using the Secure Association Protocol, but also
can be accomplished via the EAP method or the lower layer."
In Section 5.5, Change:
" In order to enable key binding and authorization of all parties, it
is RECOMMENDED that the parties use a set of identities that are
consistent between the conversation phases. RADIUS [RFC2865] and
Diameter NASREQ [RFC4005] require that the NAS/EAP authenticator
identify itself by including one or more identification attributes
within an Access-Request packet (NAS-Identifier, NAS-IP-Address, NAS-
IPv6-Address).
Since the backend authentication server provides EAP keying material
for use by the EAP authenticator as identified by these attributes,
where an EAP authenticator may have multiple ports, it is RECOMMENDED
for the EAP authenticator to identify itself using NAS identification
attributes during the Secure Association Protocol exchange with the
EAP peer. This enables the EAP peer to determine whether EAP keying
material has been shared between EAP authenticators as well as to
confirm with the backend authentication server that an EAP
authenticator proving possession of EAP keying material during the
Secure Association Protocol was authorized to obtain it. Typically,
the NAS-Identifier attribute is most convenient for this purpose,
since a NAS/authenticator may have multiple IP addresses.
Similarly, the backend authentication server authorizes the EAP
authenticator to provide access to the EAP peer identified by the
Peer-ID, securely verified during the EAP authentication exchange.
In order to determine whether EAP keying material has been shared
between EAP peers, where the EAP peer has multiple ports it is
RECOMMENDED for the EAP peer to identify itself using the Peer-ID
during the Secure Association Protocol exchange with the EAP
authenticator."
To:
" In order to enable key binding and authorization of all parties, it
is RECOMMENDED that the parties use a set of identities that are
consistent between the conversation phases. Consistently identifying
the EAP authenticator enables the EAP peer to determine whether EAP
keying material has been shared between EAP authenticators as well as
to confirm with the backend authentication server that an EAP
authenticator proving possession of EAP keying material during the
Secure Association Protocol was authorized to obtain it.
Identification issues are discussed in Section 2.2 and key scope
issues are discussed in Section 3.2."
Proposed Resolution:
Accept
Issue 348: Definition of Lower
Layer
Submitter name: Vidya Narayanan
Submitter email address:
vidyan@qualcomm.com
Date Submitted: April 6, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04184.html
Document:
Keying-11
Comment type: E
Priority: S
Section:
Rationale/Explanation of issue:
I just looked up RFC3748 and the EAP Keying Framework and realized
that
there isn't a definition for the term "lower layer". I would
recommend
adding a definition to the terminology section of the keying
framework
draft. Lower layer, to me means the layer over which EAP runs.
Between
the peer and the authenticator, this would be the layer that runs
the
secure association protocol to derive TSKs, while between
the
authenticator and the AS, this would be the AAA protocol carrying
EAP,
for instance.
[Bernard Aboba]
RFC 3748 Section 2.2 says:"Lower
layer. The lower layer is responsible for transmitting and
receiving
EAP frames between the peer and authenticator."
How would this do as a definition of Lower Layer?
[Glen Zorn]
How about "carrying" instead of "transmitting and receiving"?
[Bernard Aboba] Sounds good.
Proposed Resolution:
Accept
Issue 349: Yet More NITs
Submitter name:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date Submitted:
April 12, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04205.html
Document:
Keying-11
Comment type: E
Priority: S
Section:
Rationale/Explanation of issue:
Move from Section 5 to Section 1.2: "The terms "Cryptographic binding", "Cryptographic separation",
"Key strength" and "Mutual authentication" are
defined in [RFC3748] and are used with the same
meaning in this document."
In Section 1.2 change "frequently" to
"also frequently"Add the following definition of "Secure
Association Protocol": An exchange that occurs between the EAP peer and authenticator
in order to manage the creation and deletion of unicast and
multicast security associations.
In Section 2.1,
change: "directly from the MSK, as described in [RFC2716]. This method
is NOT RECOMMENDED, since were PPP to support caching, this
could result in stale TSKs. As a result, once the PPP session"
To: "directly from the MSK, as described in [RFC2716]. This method
is NOT RECOMMENDED, since if PPP were to support caching, this
could result in TSK reuse. As a result, once the PPP session"
In
Section 2.2, change: " This specification does not impose constraints on the architecture of
the EAP authenticator or peer. Any of the authenticator
architectures described in [RFC4118] can be used. For example, it is
possible for multiple base stations and a "controller" (e.g. WLAN
switch) to comprise a single EAP authenticator. In such a situation,
the "base station identity" is irrelevant to the EAP method
conversation, except perhaps as an opaque blob to be used in Channel
Bindings. Many base stations can share the same authenticator
identity. As a result, lower layers need to identify EAP peers and
authenticators unambiguously, without incorporating implicit
assumptions about peer and authenticator architectures."
To: " This specification does not impose constraints on the architecture of
the EAP authenticator or peer. Any of the authenticator
architectures described in [RFC4118] can be used. As a result, lower
layers need to identify EAP peers and authenticators unambiguously,
without incorporating implicit assumptions about peer and
authenticator architectures.
For example, it is possible for multiple base stations and a
"controller" (e.g. WLAN switch) to comprise a single EAP
authenticator. In such a situation, the "base station identity" is
irrelevant to the EAP method conversation, except perhaps as an
opaque blob to be used in Channel Bindings. Many base stations can
share the same authenticator identity."
In Section 2.2.1,
change: " The EAP method conversation is between the EAP peer and server, as
identified by the Peer-ID and Server-ID. The authenticator identity,
if considered at all by the EAP method, is treated as an opaque blob
for the purposes of Channel bindings. However, the Secure
Association Protocol conversation is between the peer and the
authenticator, and therefore the authenticator and peer identities
are relevant to that exchange, and define the scope of use of the EAP
keying material passed down to the lower layer."
To: " The EAP method conversation is between the EAP peer and server, as
identified by the Peer-ID and Server-ID. The authenticator identity,
if considered at all by the EAP method, is treated as an opaque blob
for the purposes of Channel Bindings (see Section 5.12). However,
the Secure Association Protocol conversation is between the peer and
the authenticator, and therefore the authenticator and peer
identities are relevant to that exchange, and define the scope of use
of the EAP keying material passed down to the lower layer."
There
is redundancy between Section 2.2.1 and Section 5.5, which says: " In order to enable key binding and authorization of all parties, it
is RECOMMENDED that the parties use a set of identities that are
consistent between the conversation phases."
In Section 2.2.1,
Change:"In order to ensure that lower layer identifies are
securely verified by all parties, it is recommended that lower
layers:"To:"In order to ensure that lower
layer identities are securely verified by all parties, it is RECOMMENDED that
the parties use a set of identities that are consistent between the conversation
phases.
This can be achieved by:"Delete the above paragraph
from Section 5.5.
In Section 2.2.2 change:"
"virtual authenticators", the EAP peer and authenticator may not be able
to
agree on the scope of the EAP keying material, creating
a security
vulnerability. For"To: " "virtual authenticators", a number of security
vulnerabilities may arise if the peer and authenticator
are not correctly identified. For "
Change:"Several
measures are recommended to address these
issues:"To:"in order to address these
issues:"In Section 3, change: "key derivation, but not key management. While EAP
methods may derive keying material, EAP
does not provide for the management of exported or derived keys."
To:"key
derivation, but does not provide for the management of exported or derived
keys."'In Section 3.1, delete: "As shown in Figure 3, both the peer and authenticator may have more
than one physical or virtual port, and as a result SHOULD identify
themselves in a manner that is independent of their attached ports."
This
is redundant because Section 2.2.1 already states: " Since an authenticator may have multiple ports, the authenticator
identifier used within the Secure Association Protocol exchange
SHOULD be distinct from any port identifier (e.g. MAC address).
Similarly, where a peer may have multiple ports, and sharing of EAP
keying material and parameters between peer ports of the same link
type is allowed, the peer identifier used within the Secure
Association Protocol exchange SHOULD also be distinct from any port
identifier."In Section 3.1 [b], add: "Identity verification is
discussed in Section 2.2.1."Change:"Use of the
key naming mechanism described in this document is
RECOMMENDED."to"Use of the key naming
mechanism described in Section 1.4.1 is RECOMMENDED."In Section
3.1 [g] Change:"Key
resynchronization."To:"Key state
resynchronization"In Section 3.1 [j], add:"See
[RFC3748] Section 2.4 for more discussion."In Section 3.4,
change:"re-key TEKs during a
conversation."To:"re-key TEKs during an EAP
conversation."There is redundancy between Section 3.5 and
Section 5.7, which states: " As described in [RFC3580] Section 3.17, When sent in an Access-
Accept along with a Termination-Action value of RADIUS-Request, the
Session-Timeout attribute specifies the maximum number of seconds
of service provided prior to re-authentication. [IEEE-802.11i]
also utilizes the Session-Timeout attribute to limit the maximum
time that EAP keying material may be cached."In Section 3.5,
change: " On the authenticator, where EAP is used for authentication, the
Session-Timeout value represents the maximum session time prior to
re-authentication, as described in [RFC3580]. Where EAP is used
for pre-authentication, the session may not start until some future
time, or may never occur. Nevertheless, the Session-Timeout value
represents the maximum time after which transported EAP keying
material, and all keys calculated from it, will have expired on the
authenticator. If the session subsequently starts, re-
authentication will be initiated once the Session-Time has expired.
If the session never started, or started and ended, by default keys
transported by AAA and all keys calculated from them will be
expired by the authenticator prior to the future time indicated by
Session-Timeout. Note that in future additional attributes may be
specified to control the lifetime of cached keys; these attributes
may modify the meaning of the Session-Timeout attribute in specific
circumstances."To: " On the authenticator, where EAP is used for authentication, the
Session-Timeout attribute represents the maximum session time prior
to re-authentication. As described in [RFC3580] Section 3.17, when
sent in an Access-Accept along with a Termination-Action value of
RADIUS-Request, the Session-Timeout attribute specifies the maximum
number of seconds of service provided prior to re-authentication. Where EAP is used for pre-authentication, the session may not start
until some future time, or may never occur. Nevertheless, the
Session-Timeout value represents the maximum time after which
transported EAP keying material, and all keys calculated from it,
will have expired on the authenticator. If the session
subsequently starts, re-authentication will be initiated once the
Session-Time has expired. If the session never started, or started
and ended, by default keys transported by AAA and all keys
calculated from them will be expired by the authenticator prior to
the future time indicated by Session-Timeout; this feature is
utilized by [IEEE-802.11i]. Note that in future additional
attributes may be specified to control the lifetime of cached keys;
these attributes may modify the meaning of the Session-Timeout
attribute in specific circumstances."Delete the above
paragraph from Section 5.7.Combine sections 5.1 and
5.In Section 5, Move [2] to [10] and renumber the other
threats.Add the following additional bullets:
[8] An
attacker may attempt a man-in-the-middle attack in order to gain access
to
the network.
[9] An attacker may launch a denial of service attack against
the EAP
peer, authenticator or backend authentication
server.In Section 5.11, change:"see
[I-D.arkko-eap-service-identity-auth]."To:"see
the discussion in Section 1.4 as well as
[I-D.arkko-eap-service-identity-auth]." Add the following non-normative reference:
[RFC4372]
Adrangi, F., Lior, A., Korhonen, J. and J. Loughney,
Chargeable User Identity", RFC 4372, January 2006.
Proposed Resolution:
Accept
Issue 350: Requirements Confusion
Submitter
name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date
Submitted: April 12, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04206.html
Document:
Keying-11
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
Lower layer identities are not securely verified in
phase 2a, they are just exchanged. Secure verification requires Channel
Bindings.In Section 2.2.1, change:"Securely
verify the lower layer identities within phase
2a;"To:"Supporting the integrity-protected
exchange of identities within phase 2a;"Section 3.1
states: "As part of secure capabilities
negotiation, the Secure Association Protocol MUST support integrity
and replay protection of all messages."
This contradicts Section
5.3, which states: " In order to prevent forgery of Secure Association Protocol frames,
per-frame authentication and integrity protection is RECOMMENDED on
all messages."
It is also redundant with Section 5.6, which
states: " In order to prevent replay of Secure Association Protocol frames,
replay protection is REQUIRED on all messages. [IEEE-802.11i]
supports replay protection on all messages within the 4-way
handshake."
Recommendation is to change: "As part of secure capabilities
negotiation, the Secure Association Protocol MUST support integrity
and replay protection of all messages."
To: "The Secure Association Protocol MUST
support integrity and replay protection of all capability
negotiation messages."
In Section 3.8 (Key Wrap), material is included that is more relevant to
Section 5.4 (Unauthorized Disclosure):
" Where an untrusted AAA intermediary is present (such as a RADIUS
proxy or a Diameter agent), and data object security is not used,
transported keying material may be recovered by an attacker in
control of the untrusted intermediary. Possession of transported
keying material enables decryption of data traffic sent between the
peer and a specific authenticator. However, as long as EAP keying
material or keys derived from it are only utilized by a single
authenticator, compromise of the transported keying material does not
enable an attacker to impersonate the peer to another authenticator.
Vulnerability to an untrusted AAA intermediary can be mitigated by
implementation of redirect functionality, as described in [RFC3588]
and [RFC4072]."
Recommendation is to delete this material from
Section 3.8 and insert the following text in
Section 5.4: " Within the AAA
protocol, the authorization attributes provide the information
binding the transported keying material to the appropriate context.
For example, transported keying material is destined for the EAP
authenticator identified by the NAS-Identifier attribute within the
request, and relates to the EAP peer identified by the Peer-ID, User-
Name [RFC2865] or CUI [RFC4372] attributes.
[RFC2607] Section 7 describes the security issues ocurring when the
authenticator and backend authentication server do not communicate
directly. Where an untrusted AAA intermediary is present (such as a
RADIUS proxy or a Diameter agent), and data object security is not
used, transported keying material may be recovered by an attacker in
control of the untrusted intermediary. As discussed in Section 2.1,
unless the TSKs are derived independently from EAP keying material
(as in IKEv2), possession of transported keying material enables
decryption of data traffic sent between the peer and a specific
authenticator. However, as long as EAP keying material or keys
derived from it are only utilized by a single authenticator,
compromise of the transported keying material does not enable an
attacker to impersonate the peer to another authenticator.
Vulnerability to an untrusted AAA intermediary can be mitigated by
implementation of redirect functionality, as described in [RFC3588]
and [RFC4072]."
Proposed Resolution:
Accept
Issue 351: Incomplete EAP Pre-authentication
Discussion
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date Submitted: April 21, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04212.html
Document:
Keying-12
Comment type: T
Priority: 1
Section:
4.1
Rationale/Explanation of issue:
It has been pointed out (in
draft-vidya-eap-keying-gap-analysis as well as discussion in the HOAKEY BOF)
that there are a number of issues raised by EAP pre-authentication. Section 4
includes EAP pre-authentication in a list of handoff techniques and claims that
"The sections that follow discuss the security vulnerabilities introduced by the
above mechanisms." However, Section 4 does not include a discussion of EAP
pre-authentication concerns.The proposed resolution is to add a
Section 4.1, with the following text:"4.1 EAP
Pre-authenticationEAP pre-authentication enables an EAP peer to
pre-establish EAP keying material with
an authenticator prior to attaching to
it. Where there is sufficient time to pre-establish
keying material prior to
changing the point of attachment, this may enable the peer to
remove EAP
authentication from the critical path for handoff, reducing
latency.EAP pre-authentication exchanges typically differ from
a normal EAP conversation only
with respect to the lower layer encapsulation.
For example, in [IEEE-802.11i], EAP
pre-authentication frames are
encapsulated within a distinct Ethertype, but otherwise
conform to the
encapsulation described in [IEEE-802.1X]. As a result, an
EAP
pre-authentication conversation that eventually results in establishment
of security
associations differs little from the model described in Section
1.3, other than the
potential introduction of a delay between Phase 1 and
Phase 2. However, since
a peer may complete EAP pre-authentication with an
authenticator without eventually
attaching to it, it is possible that Phase 2
will not occur.[RFC3580] describes only minor differences in
the AAA exchange occurring
as a result of EAP pre-authentication as compared
with an ordinary EAP authentication
exchange. For example, since in 802.11i
an Association exchange does
not occur prior to EAP pre-authentication, the
SSID is not yet
known. As a result, an Access-Request generated as
the
result of pre-authentication cannot include the SSID
within the
Called-Station-Id attribute as described in
[RFC3580] Section 3.20. Since a
peer may never
associate with an authenticator to which it
pre-authenticated,
an Accounting-Request signifying the start of service
may
never be sent, or may only be sent with a substantial delay
after the
completion of authentication.Since an EAP pre-authentication
exchange differs from an EAP authentication exchange
only in subtle ways, the
backend authentication server may not be aware of
whether it is engaging in a
pre-authentication exchange,
resulting in operational or security problems.
For example,
where the authenticator does not include the SSID within the
Called-Station-Id
attribute in ordinary requests, pre-authentication
requests
may appear indistinguishable. As a result, the
backend
authentication server may not be able to correctly calculate
the
simultaneous sessions in progress, either preventing
successful completion of
pre-authentication or enabling
the peer to engage in more simultaneous
sessions than
they are authorized for. In order to allow backend authentication servers to handle
pre-authentication requests more reliably, it is recommended
that EAP pre-authentication requests be explicitly identified
within AAA protocols. Also, in order to supress unnecessary
EAP pre-authentication exchanges, it is recommended that
authenticators unambiguously identify themselves as described
in Section 2.2.2, allowing the peer to determine whether it
has previously established EAP keying material with that
authenticator."
Proposed Resolution:
Accept
Issue 352: Channel Binding Issue
Submitter
name: Yoshihiro Ohba
Submitter email address: yohba@tari.toshiba.com
Date
Submitted: April 25, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04216.html
Document:
Keying-12
Comment type: T
Priority: 1
Section:
5.11
Rationale/Explanation of issue:
Reference [I-D.draft-ohba-eap-aaakey-binding] should be obsoleted by
its successor, i.e., [I-D.draft-ohba-eap-channel-binding] which
provides more generic, complete and extensible way of channel binding.
Note that pre-configuration of the parameter set on AS is an important
property to achieve Channel Binding in 3-party key management.
Change:
" It is also possible to achieve Channel Bindings without transporting
data over EAP. For example, see [I-D.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 transported keying material 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."
to:
" It is also possible to achieve Channel Bindings without
transporting data over EAP. For example, see
[I-D.draft-ohba-eap-channel-binding]. In this approach the backend
server calculates transported keying material based on the
parameter set pre-configured for the authenticator, making it
impossible for the peer and authenticator to complete the Secure
Association Protocol if there was a mismatch in the parameters."
[Bernard Aboba] In looking through the document, I believe it is best that
discussion of Channel Bindings be concentrated in Section 5.11.
The proposed resolution is as follows:
In Section 1.4, change the Channel Binding entry from:
"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 that transport
Channel Binding 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 or AAA 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 or AAA layer passes
the result of the verification (TRUE or FALSE) up to the EAP
method.
While the verification can be done either by the peer or the
server, typically only the server has the knowledge to determine
the correctness of the values, as opposed to merely verifying
their equality. See Section 5.11 for further discussion."
To:
"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 that transport
Channel Binding data MUST treat this data as opaque octets.
See Section 5.11 for further discussion."
Replace Section 5.11 with the following:
"5.11. 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).
Where EAP is used in pass-through mode, the EAP peer does not verify
the identity of the pass-through authenticator. Within the Secure
Association Protocol, the EAP peer and authenticator only demonstrate
mutual possession of the transported EAP keying material. This
creates a potential security vulnerability, described in [RFC3748]
Section 7.15.
As described in the previous section, it is possible for a proxy to
detect a AAA client attempting to impersonate another authenticator
(such by sending incorrect Called-Station-Id [RFC2865], 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 backend authentication server while
communicating misleading information to the EAP peer via the lower
layer.
For example, a compromised authenticator can utilize another
authenticator's Called-Station-Id or NAS-Identifier in communicating
with the EAP peer via the lower layer. Also, a pass-through
authenticator acting as a AAA client can provide an incorrect peer
Calling-Station-Id [RFC2865][RFC3580] to the backend authentication
server via the AAA protocol.
As noted in [RFC3748] Section 7.15, this vulnerability can be
addressed by 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. 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 or AAA 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 or AAA layer passes
the result of the verification (TRUE or FALSE) up to the EAP
method. While the verification can be done either by the peer or the
server, typically only the server has the knowledge to determine
the correctness of the values, as opposed to merely verifying
their equality. For further discussion, see
[I-D.arkko-eap-service-identity-auth].
It is also possible to achieve Channel Bindings without transporting
data over EAP. For example, see [I-D.draft-ohba-eap-channel-binding].
In this approach the EAP method includes Channel Bindings in the
calculation of exported EAP keying material, making it impossible for
the peer and authenticator to complete the Secure Association Protocol
if there is a mismatch in the Channel Bindings. However, this approach
can only be applied where EAP methods generating key material are used
along with lower layers that utilize the keying material. For example,
this mechanism would not enable verification of Channel Bindings on
wired IEEE 802 networks which do not support data frame protection."
[Yoshihiro Ohba]
The last sentence is correct when 802.1X is used as EAP transport over
wired IEEE 802 networks, but not correct when PANA is used where it is
still possible to enable verification of Channel Bindings with this
scheme by protected PANA-Bind exchange as I mentioned to Joe.
I would suggest revising the last two sentences something like:
"However, this approach can only be applied where EAP methods
generating key material are used
along with lower layers that utilize the keying material for data frame frame
protection. For example, this mechanism would not enable verification of Channel
Bindings on wired IEEE 802 networks using IEEE 802.1X."
[Bernard Aboba]
Here is the new paragraph:
"It is also possible to achieve Channel Bindings without transporting
data over EAP. For example, see [I-D.draft-ohba-eap-channel-binding].
In this approach the EAP method includes Channel Bindings in the
calculation of exported EAP keying material, making it impossible for
the peer and authenticator to complete the Secure Association Protocol
if there is a mismatch in the Channel Bindings.
However, this approach can only be applied where EAP methods
generating key material are used
along with lower layers that utilize the keying material for data frame frame
protection. For example, this mechanism would not enable verification of
Channel Bindings on wired IEEE 802 networks using IEEE 802.1X."
Is this what you intended?
[Yoshihiro Ohba]
Here is the intended text:
"It is also possible to achieve Channel Bindings without transporting
data over EAP. For example, see [I-D.draft-ohba-eap-channel-binding].
In this approach the EAP method includes Channel Bindings in the
calculation of exported EAP keying material, making it impossible for
the peer and authenticator to complete the Secure Association Protocol
if there is a mismatch in the Channel Bindings. However, this
approach can only be applied where EAP methods generating key material
are used along with lower layers that utilize the keying material.
For example, this mechanism would not enable verification of Channel
Bindings on wired IEEE 802 networks using IEEE 802.1X."
Proposed Resolution:
Accept
Issue 353: Definition of
Session-Id/Method-Id
Submitter name: Joe Salowey
Submitter email
address: jsalowey@cisco.com
Date first submitted: 4/30/2006
Reference: http://lists.frascone.com/pipermail/eap/msg04220.html
Document:
KEYING-12
Comment type: 'E'ditorial
Priority: '1' Should fix
Section:
1.2
Rationale/Explanation of issue:
It seems that EAP
Session-ID/Method-ID should be define here
Requested change:
Add
Definition for EAP Session-ID/Method-ID
[Bernard Aboba] Resolution is to add the following definition of Session-Id
and delete Method-Id:
"Session-Id
The EAP Session-Id uniquely identifies an EAP session between an EAP
peer
(as identified by the Peer-Id) and server (as identified by
the
Server-Id). The EAP Session-Id consists of the concatenation of
the
Expanded EAP Type Code (including the Type, Vendor-Id and
Vendor-Type
fields defined in [RFC3748] Section 5.7) and the
temporally
unique identifier obtained from the method. This unique identifier
is
typically constructed from nonces
or counters used within the EAP
method exchange. The
inclusion of the Expanded Type Code in the EAP
Session-Id ensures
that each EAP method has a distinct Session-Id space.
Since an EAP
session is not bound to a particular authenticator or specific
ports
on the peer and authenticator, the authenticator port or identity
are
not included in the Session-Id."
Proposed Resolution:
Accept
Issue 354: Method-Id and
Session-Id
Submitter name: Joe Salowey
Submitter email address:
jsalowey@cisco.com
Date first submitted: 4/30/2006
Reference: http://lists.frascone.com/pipermail/eap/msg04221.html
Document:
KEYING-12
Comment type: 'T'echnical
Priority: '1' Should fix
Section:
1.4
Rationale/Explanation of issue:
This document defines both session
and Method Id. It seems that it
would be sufficient and less confusing to
define only one called the
session Id.
Suggested
definition:
"Session-Id
The Session-Id uniquely identifies an EAP
session between an EAP peer
(as identified by the Peer-Id) and server (as
identified by the
Server-Id). The EAP Session-Id consists of the
concatenation of the
Expanded EAP Type Code (including the Type, Vendor-Id
and Vendor-Type
fields defined in [RFC3748] Section 5.7) and the
temporally
unique identifier obtained from the method. This unique identifier
is
typically constructed from nonces
or counters used within the EAP
method exchange. The
inclusion of the Expanded Type Code in the EAP
Session-Id ensures
that each EAP method has a distinct Session-Id space.
Since an EAP
session is not bound to a particular authenticator or specific
ports
on the peer and authenticator, the authenticator port or identity
are
not included in the Session-Id."
Replace references to method-ID
with Session-Id.
Proposed Resolution:
Accept
Issue 355: Data Associated with
Authentication
Submitter name: Joe Salowey
Submitter email address:
jsalowey@cisco.com
Date Submitted: April 30, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04222.html
Document:
KEYING-12
Comment type: 'E'ditorial
Priority: '1' Should fix
Section:
Section 1.4
Rationale/Explanation of issue:
Length description of problem
This section contains text that seem to indicate that an EAP method
has
access to certain data for authorization. While this may be true
in
some cases this is not generally true.
Suggested
revision:
"As illustrated in Figure 2, the EAP method key derivation has
at the
root the long term credential utilized by the selected EAP
method.
If authentication is based on a pre-shared key, the parties store
the
EAP method to be used and the pre-shared key. The EAP server
also
stores the peer's identity as well as additional information.
This
information is typically used outside of the EAP method to determine if
access to
some service should be granted. The peer stores information
necessary
to choose which secret to use for which service.
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 may also store
additional
information associated with the peer's identity and the peer
stores
information necessary to choose which certificate to use for which
service."
Proposed Resolution:
Accept
Issue 356: Ciphersuite
Independence
Submitter name: Joe Salowey
Submitter email address:
jsalowey@cisco.com
Date Submitted: April 30, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04223.html
Document:
KEYING-12
Comment type: 'E'ditorial
Priority: '2' May fix
Section:
1.6.4
Rationale/Explanation of issue:
Section 3.7 implies that there
is a system level coordination between
the strength of the keys exported by
the EAP method and the strength of
keys required by the lower layer.
This section should reference this and indicate that the coordination
is
done outside of EAP.
[Bernard Aboba] While the negotiation of the appropriate group size
occurs within EAP,
there is no coordination between the lower layer and EAP
methods
with respect to the required key strength.
The proposed
resolution is to replace the first paragraph of Section 3.7 with the
following:
"3.7. Key Strength
As noted in Section 2.1, EAP lower
layers determine TSKs in
different ways. Where EAP keying material is
utilized in
the derivation, encryption or authentication of TSKs, it
is
possible for EAP key generation to represent the weakest
link.
In
order to ensure that EAP methods produce keying
material of an appropriate
symmetric key strength,
it is RECOMMENDED that EAP methods utilizing public
key cryptography choose a public key that has a
cryptographic strength
providing the required level
of attack resistance. This is typically
provided by
configuring EAP methods, since there is
no coordination
between the lower layer and EAP method
with respect to minimum required
symmetric key strength."
[Joe Salowey] The text looks OK to me.
Proposed Resolution:
Accept
Issue 357: Channel Binding
Definition
Submitter name: Vidya Narayanan
Submitter email address:
vidyan@qualcomm.com
Date Submitted: May 1, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04227.html
Document:
KEYING-12
Comment type: 'T'echnical
Priority: '1' Should fix
Section:
1.2
Rationale/Explanation of issue:
The document defines channel binding
as a communication within an EAP method - this seems a bit restrictive,
given that channel binding information could be carried out-of-band as
well. The only requirement is that the information be integrity
protected between the peer and server.
Requested change:Change wording to:
"The communication of integrity-protected
channel properties such as endpoint identifiers which can be
compared to values communicated via out of band mechanisms (such as
via a AAA or lower layer protocol)."
[Jari Arkko] Here is a proposed definition:
"Channel Binding
A secure mechanism for ensuring that a chosen set of channel
properties (such as endpoint identifiers) are agreed upon by the EAP
peer, authenticator and server."
[Vidya]
The proposed text by Jari went through some revisions as I recall, based
on some discussions on the list. Here is the latest on that text I
pulled out from one of Jari's email, subsequent to the discussions:
"I'd be happy to restrict the definition to peer and server agreeing
that they have the same view of the channel properties claimed by the
authenticator.
(But part of the distinction may also be in the specific implementation
of the "agreement"; what we are looking for is that the values agree,
without specifying who sends the values and who verifies them.)"
Based on the above, how about the following definition?
"Channel Binding
A secure mechanism for ensuring that a chosen set of channel properties
(such as authenticator identifiers and properties) are agreed upon by
the EAP peer and server."
[Yoshihiro Ohba] After Jari's email, I created a thread "Channel Binding analysis" for
further discussion. I still believe three party agreement is
essential for Channel Binding. To me the two party agreement
mentioned above looks similar to issueing a Kerberos ticket that is
never verified by the consumers of the ticket.
[Bernard Aboba] The text mentions authenticator identifiers and properties, which presumably
were agreed upon by the authenticator that sent them (unless it's a forgery).
However, there are also properties which don't relate to the authenticator
itself (such as Calling-Station-Id) but are transmitted by the authenticator
(e.g. to the backend server). Are there any cases where a property to be verified
by Channel Bindings is *not* transmitted by the authenticator? Would the following work?
"A secure mechanism for ensuring that a subset of the parameters transmitted by the
authenticator (such as authenticator identifiers and properties) are agreed upon by
the EAP peer and server."
I'm not sure what the definition of a "channel property" is in this case.
One could argue for example that the Calling-Station-Id is not a property of the
channel -- but its verification is still considered part of Channel Bindings.
[Yoshihiro Ohba] Transmitted to whom? I think not all parameters do not need to be
transmitted to the server while all parameters need to be transmitted
to the peer. In fact, if the server has the pre-established knowledge
about the parameters, the only information that needs to be sent from
authenticator to the server is authenticator identity which can be
used as the primary database look-up key to find out other parameters
associated with the authenticator identity.
Also I don't understand why peer's lower layer parameter such as
Calling-Station-Id needs to be agreed by peer and server. What is the
actual threat without agreement?
[Bernard Aboba]
Transmitted to whom? I think not all parameters do not need to be
transmitted to the server while all parameters need to be transmitted
to the peer.
I was leaving it open. Some things might be
transmitted to the peer but not the server, or vice versa. For example, the
authenticator may send Calling-Station-Id to the AAA server, but it doesn't send
it to the peer (the peer includes that in the source
address).
In fact, if the server has the pre-established knowledge
about the parameters, the only information that needs to be sent from
authenticator to the server is authenticator identity which can be
used as the primary database look-up key to find out other parameters
associated with the authenticator identity.
How can the peer use channel binding parameters which
it never received? So the authenticator needed to send it to the peer at least,
no?
Also I don't understand why peer's lower layer parameter such as
Calling-Station-Id needs to be agreed by peer and server. What is the
actual threat without agreement?
The threat is that the authenticator could lie about
the Calling-Station-Id. The peer could then find out from the server that it got
different information.
[Yoshi Ohba]
How about:
"It is expected that the parameters are also agreed upon by the peer
and authenticator via the lower layer if the authenticator is the
valid entity that advertised the parameters."
[Bernard Aboba]
How about
this:"A secure mechanism for ensuring that a subset of the
parameters transmitted by the
authenticator (such as authenticator
identifiers and properties) are agreed upon by
the EAP peer and server. It is
expected that the parameters are also securely agreed
upon by the EAP peer
and authenticator via the lower layer if the authenticator
advertised the
parameters."
[Yoshihiro Ohba]
The text works for me.
Proposed Resolution:
Accept
Issue 358: AAA-Key
Submitter name: Vidya
Narayanan
Submitter email address: vidyan@qualcomm.com
Date Submitted: May
1, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04228.html
Document:
KEYING-12
Comment type: 'E'ditorial
Priority: '2' May fix
Section:
1.2
Rationale/Explanation of issue:
Given that the term AAA-Key is not used elsewhere in the document, it
would be good to add a sentence clarifying that the definition is
provided as a clarification to the terminology used in older documents
and that it is no longer used.
Requested change:
Add to AAA-Key definition:
"This term is no longer used to refer to the MSK in this document."[Bernard Aboba] How about this?
"AAA-Key
The term AAA-Key is synonymous with MSK. Since multiple keys may
be transported by AAA, the term is potentially confusing and is not
used in this document."
Proposed Resolution:
Accept
Issue 359: Typo
Submitter name: Vidya
Narayanan
Submitter email address: vidyan@qualcomm.com
Date Submitted: May
1, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04229.html
Document:
KEYING-12
Comment type: 'E'ditorial
Priority: 'S' Must fix
Section:
1.4
Rationale/Explanation of issue:
Typo in Server-Id paragraph
Requested change:
s/method-specific peer identity/method-specific server identity/
Proposed Resolution:
Accept
Issue 360: EMSK Transport
Submitter name:
Vidya Narayanan
Submitter email address: vidyan@qualcomm.com
Date
Submitted: May 1, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04230.html
Document:
KEYING-12
Comment type: 'T'echnical
Priority: '1' Should fix
Section:
2
Rationale/Explanation of issue:
The section says "The EMSK MUST NOT be transported by the AAA
layer."
Given that the EMSK usage is currently undefined, it is not clear if
it
will be the AAA layer that derives further keys from the EMSK. In
fact,
doing so will create disparate behavior at the peer and server,
since
the peer does not have a AAA layer. Although this topic is
pending
discussion, it seems restrictive to say MUST NOT here. It does
make
sense, however, to say that the EMSK MUST NOT be transported
to
additional parties.
Requested change:
Delete the sentence "The EMSK MUST NOT be transported
by the AAA layer".
[Joe Salowey]
After reading the text again I would be OK removing the specific text
about the AAA layer.
Proposed Resolution:
Accept
Issue 361: Child key expiry
Submitter name:
Vidya Narayanan
Submitter email address: vidyan@qualcomm.com
Date
Submitted: May 1, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04231.html
Document:
KEYING-12
Comment type: 'T'echnical
Priority: '2' May fix
Section:
3.3
Rationale/Explanation of issue:
This section states "When keying material exported by EAP methods
expires, all keying material derived from the exported keying material expires, including
the TSKs." This seems to indicate that the keys derived from the EMSK
will also be expired when the EMSK expires. It is not yet clear if this
would apply to all kinds of keys derived from the EMSK. There may be
classes of keys derived from the EMSK for which different lifetime
guidelines apply. So, it may be good to clarify that the EMSK usage
documents will specify the guidelines for EMSK-based child keys.
Requested change:
Change
"When keying material exported by EAP methods expires, all keying
material derived from the exported keying material expires, including
the TSKs."
to
"When keying material exported by EAP methods expires, all keying
material derived from the exported keying material expires, including
the TSKs. Note that different lifetime guidelines may be specified in
future specifications for EMSK-based child keys."[Bernard Aboba]
One of the unstated threat model assumptions is that any key can be compromised over a sufficient
period of time. This includes the exported keys (MSK, EMSK). So the question is: if the MSK or
EMSK are considered "stale" should the TSKs also be considered stale?
In a previous comment, it was noted that TSK derivation techniques differ, so that a TSK could
be compromised even if the MSK/EMSK was not. Similarly, in protocols such as IKEv2, it might be
possible to derive a TSK that would not be compromised even if the EMSK/MSK was compromised.
For example, consider a 4096-bit DH used for IKEv2 TSK generation while the EAP method uses a
512-bit DH. Since EAP keys are used in IKEv2 only for authentication, as long as IKEv2 does
not reuse the MSK after it becomes stale (which it doesn't, because IKEv2 does not support
caching), the TSK is not compromised.
Given this, I think the problem is with the words "including the TSKs." If the TSKs are not
derived from the MSK/EMSK, then I don't think they should be considered stale once the
MSK/EMSK is considered stale.
However, if a key is derived from the MSK/EMSK, then if the MSK/EMSK is compromised, then
presumably the derived key is compromised as well, even if it is derived via PRF, mixing with
nonces, etc. If the attacker has obtained the MSK/EMSK, then it can also obtain the derived keys.
[Laksminath Dondeti]
We hope no one is using a 512-bit DH in an EAP method, considering that EAP key derivation requirements
(lengthwise, i.e., 64 octets of MSK, 64 octets of EMSK etc.) are as demanding as IKEv2's are. But, sure,
the concern is valid. Some EAP methods use the PSK directly for key derivation whereas IKEv2 doesn't.
I am not sure we can safely say that no IKEv2 implementation will cache the EAP MSK as the PSK. After
all, the PSK is only used for entity authentication and not for key distribution, and therefore, can
be used for a decent amount of time without any issues. Recall also that an alternative might be
password based PSKs which may not always be as strong as those coming from an EAP method (assuming
one of the newer methods).
[Bernard Aboba]
In this particular case, we are talking about caching of EAP keying material within the IKEv2 lower
layer. Caching of EAP keying material within the PANA lower layer is a separate issue.
Perhaps we can say that RFC 4306 does not support key caching? It seems that an extension to IKEv2
would be required to support this, since otherwise the IKE initiator and responder couldn't
negotiate whether cached EAP keys are to be used, and if so, which ones.
[Laksminath Dondeti]
Given this, I think the problem is with the words "including the TSKs." If the TSKs are not
derived from the MSK/EMSK, then I don't think they should be considered stale once the MSK/EMSK
is considered stale.
However, if a key is derived from the MSK/EMSK, then if the MSK/EMSK is compromised, then presumably
the derived key is compromised as well, even if it is derived via PRF, mixing with nonces, etc. If the
attacker has obtained the MSK/EMSK, then it can also obtain the derived keys.
I think there are several notes here, I think you captured most, but here is a list:
Compromise:
1. If an MSK/EMSK is compromised, all derived keys are assumed to have been compromised, as
long as any nonces exchanged are in the clear or protected with the MSK/EMSK, or keys derived thereof.
2. MSK/EMSK compromise does not necessarily impact child key derivation iff the MSK/EMSK (or keys
derived thereof) only serve as entity authentication keys and are not used for key derivation. (Perhaps
the latter -- and are not used for key derivation -- is too restrictive).
[Bernard Aboba]
Are you suggesting that there might be situations in which EAP keys aren't used for key derivation,
but compromise might still be possible?
[Laksminath Dondeti]
No. I am asking if the MSK/EMSK figures into the key derivation, say only partially (say along with
DH), compromise of MSK/EMSK means compromise of derived keys. I was then saying perhaps that is
too restrictive, but I'd contend not, unless there is a strong case made for the alternative.
[Bernard Aboba]
OK. If the MSK/EMSK were mixed into the key derivation, then there might be some weakening of
the key derivation. How much depends on the algorithm.
[Laksminath Dondeti]
Lifetime:
Lifetime, as far as I understand, is set due to two considerations. Let's consider confidentiality.
As soon as a block of ciphertext is transmitted, we can assume that an adversary has started a
brute-force attack to guess the key. With the most powerful adversary's capabilities that we want
to protect against in mind, we make an estimate of how long it might take for the computation to
complete and can set a lifetime. The other consideration is that the amount of traffic encrypted
with a given key may provide hints to reduce the computation needed by the brute-force attack.
With those considerations in mind,
3. Keys that are used frequently, for instance, for traffic protection expire sooner. We might say
those MUST NOT used beyond the EMSK's lifetime. They may expire sooner than the EMSK, however.
[Bernard Aboba]
Right. And by the same logic, the MSK and EMSK might expire at different times. I'm not sure that
the key lifetime section takes that into account adequately.
[Laksminath Dondeti]
4. Keys used less frequently, say, for entity authentication need not expire with the EMSK. We might
allow, for instance, local policy to set the lifetime on such keys. That lifetime MAY be beyond EMSK's lifetime.
[Bernard Aboba]
This makes sense assuming that the entity authentication keys aren't themselves derived from the EMSK.
[Laksminath Dondeti]
Even if entity authentication keys are derived from the EMSK, the guideline applies, I think.
Suppose the EMSK supports derivation of a traffic key and a separate entity authentication key,
wouldn't it make sense to say that, all other things being equal, the traffic key will have a
shorter lifetime than the entity authentication key, based on key usage?
[Bernard Aboba]
Yes, it would make sense. I guess I'd distinguish between a key calculated from the EMSK (e.g. AMSK)
and a TSK. The AMSK formulas that have been suggested so far are static -- that is, they are based on
a key-label, but do not generate a fresh key every time they are invoked on the same EMSK, in the way
that some TSK derivations do (e.g. 802.11i 4-way handshake).
Unless there is an ability to generate fresh keys without an EAP re-authentication, then when the
derived keyexpires it is necessary to do an EAP re-authentication. With TSKs it may be possible to
do a re-key independent of EAP (e.g. 802.11i 4-way handshake).
[Laksminath Dondeti]
I think Vidya was referring to #4 with her last statement (not mind reading; that came up in our
previous discussions on the topic :-) ).
[Bernard Aboba]
I'd also like to make sure that issues 1-3 are addressed adequately in the text.
[Laksminath Dondeti]
After having thought about this some more, I think we should have some text on EMSK to child
key derivation in the EAP-keying document along the lines of the 4 items listed earlier.
This is inline with the text on TSKs in 3.1(e) and perhaps elsewhere in the document.
Speaking very loosely and at a high level, we say that MSK is sent to the Authenticator and
then TSKs are derived using various protocols and go on to talk about TSK properties.
Likewise, we are talking about EMSK "usage" in the EAP keying FW document. We say a bunch
of things, all of which I am ok with and that the EMSK MUST NOT be used to derive keys, which
I am not ok with. There are proposals to change that, so we might start revising that
statement to avoid having two RFCs in conflict with each other.
Once that is done, talking about derived key properties is ok.
Iff that is not done, sure I agree with you (if we MUST NOT derive keys, what's the point
in talking about the properties of the derived keys?). But, I contend that that rule needs to
be revised.
[Bernard Aboba] In looking at the discussion of this issue, and reviewing the text, it is not clear
how useful it is to have EAP methods export the Key-Lifetime parameter. Today no EAP
methods export this parameter, and the text in Section 1.4 suggests that this
is not very useful anyway:
Key-Lifetime
While EAP itself does not support key lifetime negotiation, it is
possible to specify methods that do. However, systems that rely
on such negotiation for exported keys would only function with
these methods. As a result, it is NOT RECOMMENDED to use this
approach as the sole way to determine key lifetimes.
Similarly, Section 3 states:
Existing EAP methods do not export the Key-Lifetime
parameter; in the interest of method independence, key management of
exported or derived keys SHOULD NOT be provided within EAP methods.
As a result, it may make sense to remove discussion of the Key-Lifetime parameter
from the document.
The proposed resolution is as follows:
In Section 1.4, delete:
" Key-Lifetime
While EAP itself does not support key lifetime negotiation, it is
possible to specify methods that do. However, systems that rely
on such negotiation for exported keys would only function with
these methods. As a result, it is NOT RECOMMENDED to use this
approach as the sole way to determine key lifetimes."
Also, delete the Key-Lifetime parameter from Figure 2.
In Section 3, change:
"Existing EAP methods do not export the Key-Lifetime
parameter; in the interest of method independence, key management of
exported or derived keys SHOULD NOT be provided within EAP methods."
To:
"Existing EAP methods do not manage the lifetime of exported EAP
keying material; in the interest of method independence, key management of
exported or derived keys SHOULD NOT be provided within EAP methods."
[Vidya] OK. The following text on section 3.5 looks good.
Change Section 3.5 to the following:
"3.5. Exported and Calculated Key Lifetimes
All EAP methods generating keys are required to generate the MSK and
EMSK, and may optionally generate the IV. However, EAP, defined in
[RFC3748], does not itself support the negotiation of lifetimes for
exported keying material such as the MSK, EMSK and IV.
Several mechanisms exist for managing key lifetimes:
[a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and
Diameter [RFC4072] support the Session-Timeout attribute. The
Session-Timeout attribute represents the maximum lifetime of the
exported keying material, and all keys depending on it, on the
authenticator. Since existing backend authentication servers do
not cache keys exported by EAP methods, or keys calculated from
exported keys, the value of the Session-Timeout attribute has no
bearing on the key lifetime within the backend authentication
server.
On the authenticator, where EAP is used for authentication the
Session-Timeout attribute represents the maximum session time prior
to re-authentication. As described in [RFC3580] Section 3.17, when
sent in an Access-Accept along with a Termination-Action value of
RADIUS-Request, the Session-Timeout attribute specifies the maximum
number of seconds of service provided prior to re-authentication.
Where EAP is used for pre-authentication, the session may not start
until some future time, or may never occur. Nevertheless, the
Session-Timeout value represents the maximum time after which
transported EAP keying material, and all keys dependent on it, will
have expired on the authenticator. If the session subsequently
starts, re-authentication will be initiated once the Session-Time
has expired. If the session never started, or started and ended, by
default keys transported by AAA and all keys dependent on them be
expired by the authenticator prior to the future time indicated by
Session-Timeout; this feature is utilized by [IEEE-802.11i]. Note
that in future additional attributes may be specified to control
the lifetime of cached keys; these attributes may modify the
meaning of the Session-Timeout attribute in specific circumstances.
Since the TSK lifetime is often determined by authenticator
resources, and the backend authentication server has no insight
into the TSK derivation process, by the principle of ciphersuite
independence, it is not appropriate for the backend authentication
server to manage any aspect of the TSK derivation process,
including the TSK lifetime.
[b] Lower layer mechanisms. While AAA attributes can communicate the
maximum exported key lifetime, this only serves to synchronize the
key lifetime between the backend authentication server and the
authenticator. Lower layer mechanisms such as the Secure
Association Protocol can then be used to enable the lifetime of
exported and calculated keys to be negotiated between the peer and
authenticator.
Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include support for TSK re-key. Where the TSK is taken
directly from the MSK, there is no need to manage the TSK lifetime
as a separate parameter, since the TSK lifetime and MSK lifetime
are identical.
[c] System defaults. Where the EAP method does not support the
negotiation of the exported key lifetime, and a key lifetime
negotiation mechanism is not provided by the lower lower, there may
be no way for the peer to learn the exported key lifetime. In this
case it is RECOMMENDED that the peer assume a default value of the
exported key lifetime; 8 hours is recommended. Similarly, the
lifetime of calculated keys can also be managed as a system
parameter on the authenticator.
[d] Method specific negotiation within EAP. While EAP itself does not
support lifetime negotiation, it would be possible to specify
methods that do. However, systems that rely on such negotiation
for exported keys would only function with these methods. As a
result, it is NOT RECOMMENDED to use this approach as the sole way
to determine key lifetimes."Change Section 3.3 to the following:
"3.3. Parent-Child Relationships When an EAP re-authentication takes place, new keying material is
derived and exported by the EAP method, which eventually results in
replacement of TSKs, regardless of the way they are derived (see
Section 2.1). While the maximum lifetime of TSKs or child keys can
be less than or equal to that of the MSK/EMSK, it cannot be greater.
This is true even where exported EAP keying material is only used for
entity authentication and is not used for key derivation (such as in
IKEv2), so that compromise of exported EAP keying material does not
imply compromise of the TSKs or child keys. However, where child
keys are derived from or are wrapped by EAP keying material,
compromise of the MSK/EMSK does imply compromise of the child keys.
Child keys that are used frequently (such as TSKs which are used for
traffic protection) can expire sooner than the exported EAP keying
material they are dependent on, so that it is advantageous to support
re-key of child keys prior to EAP re-authentication. Note that
deletion of the MSK/EMSK does not necessarily imply deletion of TSKs
or child keys.
Failure to mutually prove possession of exported EAP keying material
during the Secure Association Protocol exchange need not be grounds
for deletion of the keying material by both parties; rate-limiting
Secure Association Protocol exchanges could be used to prevent a
brute force attack."
[Vidya]
> This is true even where exported EAP keying material is only used for
> entity authentication and is not used for key derivation (such as in
> IKEv2), so that compromise of exported EAP keying material does not
> imply compromise of the TSKs or child keys. However, where child
> keys are derived from or are wrapped by EAP keying material,
> compromise of the MSK/EMSK does imply compromise of the child keys.
In the above, are you talking about an EMSK compromise after expiry
affecting any keys that may still be in use? If so, I'm wondering how
viable that is - basically, the point that I'm not clear on is this - if
the EMSK is used to derive any keys that are handed out to other
entities, depending on the purpose of the key, the EAP server may really
have no control over that lifetime.
But, if this is a concern, I'm okay with providing guidance for key
expiry in this manner.
[Yoshihro Ohba] If the EAP server has no control over the lifetime when EMSK is used
for a specific purpose, then it would be the time to think about
possibility to use a mechanism other than EAP for that purpose.
[Bernard Aboba]
In the above, are you talking about an EMSK compromise after expiry
affecting any keys that may still be in use?
If the EMSK expires and the session is still in
progress, presumably the result is an EAP re-authentication which results in new
child keys.
If so, I'm wondering how
viable that is - basically, the point that I'm not clear on is this - if
the EMSK is used to derive any keys that are handed out to other
entities, depending on the purpose of the key, the EAP server may really
have no control over that lifetime.
It can provide a maximum lifetime (Session-Timeout)
to the authenticator, requesting EAP re-authentication to occur when the maximum
lifetime expires.The distinction we're making here is between
maximum lifetime (controlled by Session-Timeout) and deletion. If the EMSK is
deleted on the peer or server, this doesn't cause child keys to be deleted.
However, expiry of the maximum lifetime does result in new child
keys.[Vidya] Ok. The revised text for section 3.3 then looks good.
Proposed Resolution:
Accept
Issue 362: Lower layer parameters and EMSK
text
Submitter name: Joe Salowey
Submitter email address:
jsalowey@cisco.com
Date Submitted: May 2, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04247.html
Document:
KEYING-12
Comment type: 'E'ditorial
Priority: '1' Should fix
Section:
2
Rationale/Explanation of issue:
1. Passing of parameters to lower layer. It seems that there may be
some parameters passed to lower layers that could be usable elsewhere.
For example the Session-ID might be usable. If the session-id is
included in parameters then I think the following may be to
restrictive:
"This
implies that EAP keying material or parameters passed down to a lower
layer are for the exclusive use of that lower layer and MUST NOT be
used within another lower layer"
Suggested change:
"This implies that EAP keying material passed down to a lower
layer are for the exclusive use of that lower layer and MUST NOT be
used within another lower layer."
If this change is accepted there are several other places in the section
where this should be changed.
2. EMSK text
The First paragraph still mentions exporting the EMSK to the lower layer
which seems to be problematic when considered with the rest of the text
of this section. I don't think the EMSK should be discussed in the
lower layer section.
My suggestion would be to remove references to the EMSK in this section
and move the paragraph discussing the EMSK to Section 1.4 EAP Key
hierarchy.
[Bernard Aboba] The proposed resolution is as follows:
Move the following text from Section 2 to Section 1.4:
"The EMSK MUST NOT be provided to an entity outside the EAP server or
peer, nor is it permitted to pass any quantity to an entity outside
the EAP server or peer from which the EMSK could be computed without
breaking some cryptographic assumption, such as inverting a one-way
function. As noted in [RFC3748] Section 7.10:
The EMSK is reserved for future use and MUST remain on the EAP
peer and EAP server where it is derived; it MUST NOT be
transported to, or shared with, additional parties, or used to
derive any other keys."
Change the last four paragraphs of Section 2 to the following:
" In order to preserve the security of keys derived within EAP methods,
lower layers MUST NOT export keys passed down by EAP methods. This
implies that EAP keying material passed down to a lower layer is for
the exclusive use of that lower layer and MUST NOT be used within
another lower layer. This prevents compromise of one lower layer
from compromising other applications using EAP keying parameters.
EAP keying material provided to a lower layer MUST NOT be transported
to another entity. For example, EAP keying material passed down to
the EAP peer lower layer MUST NOT leave the peer; EAP keying
material passed down or transported to the EAP authenticator lower
layer MUST NOT leave the authenticator.
On the EAP server, keying material and parameters requested by and
passed down to the AAA layer may be replicated to the AAA layer on
the authenticator. On the authenticator, the AAA layer provides the
replicated keying material and parameters to the lower layer over
which the EAP authentication conversation took place. This enables
"mode independence" to be maintained.
The EAP layer as well as the peer and authenticator layers MUST NOT
modify or cache keying material or parameters (including Channel
Bindings) passing in either direction between the EAP method layer
and the lower layer or AAA layer."
[Vidya]
> The EMSK is reserved for future use and MUST remain on the EAP
> peer and EAP server where it is derived; it MUST NOT be
> transported to, or shared with, additional parties, or used to
> derive any other keys."
>
Are we sticking to this rule that the EMSK MUST NOT be used to derive
any other keys? Given that there is agreement in general about potential
derivation of keys from the EMSK, what implications does this text have
to future documents specifying derived keys from the EMSK?
> On the EAP server, keying material and parameters requested
> by and passed down to the AAA layer may be replicated to the
> AAA layer on the authenticator.
I understand what the above is trying to say - however, this does
conflict with the fact that the EMSK MUST NOT be transported to the
authenticator (even though it may be passed down to the AAA layer on the
server). I wonder if some clarification is necessary to avoid confusion.
[Bernard Aboba] The quote is from [RFC3748] so it can be removed.
How about this?
"On the EAP server, keying material and parameters requested by and passed down
to the AAA layer may be replicated to the AAA layer on the authenticator
(with the exception of the EMSK). On the authenticator, the AAA layer provides the
replicated keying material and parameters to the lower layer over
which the EAP authentication conversation took place. This enables
"mode independence" to be maintained."
Proposed Resolution: Discuss
Issue 363: Section 2.2 Title
Submitter
name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date
Submitted: May 2, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04254.html
Document:
KEYING-12
Comment type: 'E'ditorial
Priority: '1' Should fix
Section:
2.2
Rationale/Explanation of issue:
This section discusses peer architecture as well as authenticator
architecture.
Suggest title:
"2.2. Authenticator and Peer Architecture"
[Bernard Aboba] The proposed Section titles are:
"2.2. Authenticator and Peer Architecture
2.2.1. Authenticator and Peer Identification"
Proposed Resolution:
Accept
Issue 364: AAA Key Caching
Submitter name:
Joe Salowey
Submitter email address: jsalowey@cisco.com
Date Submitted:
May 2, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04256.html
Document:
KEYING-12
Comment type: 'T'echnical
Priority: '2' May fix
Section:
2.1
Rationale/Explanation of issue:
The Current draft states that keys
may not be cached once transported. I
am wondering if this is too
restrictive. Perhaps keys will be cached
for session recovery and
availability purposes.
Suggested Text:
"In order to
avoid key reuse, the AAA layer SHOULD delete transported
keys once
they are sent. The AAA layer SHOULD NOT retain keys that
it has
previously sent. For example, a AAA layer that has
transported
the MSK SHOULD delete it. If the AAA layer does cache an MSK
then the use of TSKs derived from the MSK MUST prevent key reuse."
[Bernard Aboba]
The retention of transported keying material has important security
implications.
For example, NIST key management guidelines require that
keying material that is
no longer needed be deleted, so as to avoid potential
compromise.
When transported keying material is not deleted, it is
possible for the keying
material to be reused. Since some EAP lower layers
(such as PPP) generate
TSKs directly from the MSK, if transported keying
material were to be resent,
then TSK reuse can occur, which violates the EAP
security goals.
In practice there are few measures that the authenticator
can take to prevent
this. In theory the authenticator could attempt to
determine freshness by
caching Session-Ids and checking for repeats.
However, most authenticators will
not be able to do this. As a result, the
authenticator is typically defenseless
against a backend authentication
server that resends the same key in a different
AAA session.
Proposed Resolution:
Reject
Issue 365: Ambiguous Use of
Identifier
Submitter name: Joe Salowey
Submitter email address:
jsalowey@cisco.com
Date Submitted: May 2, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04268.html
Document:
KEYING-12
Comment type: 'T'echnical
Priority: '1' Should fix
Section:
2.2.1
Rationale/Explanation of issue:
Ambiguous use of "identifier":
It is not clear in this section what the identifier is and what it is
identifying.
Does this section mean to suggest that lower layer entities identify
themselves using NAS-ID instead of layer addresses? I'm not sure that
this is a good thing or even really possible. It seems that lower layer
entities will identify themselves based on something related to lower
layer addresses. It seems that if a lower layer implements key caching
then it needs an identifier to identify the scope of the cache. This
identifier can be the NAS-ID.
I'm not quite sure I understand this section, but I think it just needs
to be clearer about what identity is being talked about.
This section does not contain any description of how existing lower
layers deal with authenticator identity. Are such examples available?
[Bernard Aboba] The proposed resolution is to rewrite Section 2.2.1 as follows:
"2.2.1. Authenticator and Peer Identification
The EAP method conversation is between the EAP peer and server. The
authenticator identity, if considered at all by the EAP method, is
treated as an opaque blob for the purposes of Channel Bindings (see
Section 5.12). However, the authenticator identity is important in
two other exchanges - the AAA protocol exchange and the Secure
Association Protocol conversation.
The AAA conversation is between the EAP authenticator and the backend
authentication server. From the point of view of the backend
authentication server, EAP keying material and parameters are
transported to the EAP authenticator identified by the NAS-Identifier
attribute. Since an EAP authenticator MUST NOT share EAP keying
material or parameters with another party, if the EAP peer or backend
authentication server detects use of EAP keying material and
parameters outside the scope defined by the NAS-Identifier, the
keying material MUST be considered compromised.
The Secure Association Protocol conversation is between the peer and
the authenticator. For lower layers which support key caching it is
particularly important for the EAP peer, authenticator and backend
server to have a consistent view of the usage scope of the
transported EAP keying material. In order to enable this, it is
RECOMMENDED that the Secure Association Protocol explicitly
communicate the usage scope of the EAP keying material passed down to
the lower layer, rather than implicitly assuming that this is defined
by the authenticator and peer endpoint addresses.
Since an authenticator may have multiple ports, the scope of the
authenticator key cache may not be described by a single endpoint
address. Similarly, where a peer may have multiple ports and sharing
of EAP keying material and parameters between peer ports of the same
link type is allowed, the extent of the peer key cache cannot be
communicated by using a single endpoint address. Instead, it is
RECOMMENDED that the EAP peer and authenticator consistently identify
themselves utilizing explicit identifiers, rather than endpoint
addresses or port identifiers.
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
a mechanism for the identification of AAA clients; since the EAP
authenticator and AAA client are always co-resident, this mechanism
is applicable to the identification of EAP authenticators.
RADIUS [RFC2865] requires that an Access-Request packet contain one
or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
attributes. Since a NAS may have more than one IP address, the NAS-
Identifier attribute is RECOMMENDED for explicit identification of
the authenticator, both within the AAA protocol exchange and the
Secure Association Protocol conversation.
Problems which may arise where the peer and authenticator implicitly
identify themselves using endpoint addresses include the following:
[a] It may not be obvious to the peer which authenticator ports are
associated with which authenticators. The EAP peer will be unable
to determine whether EAP keying material has been shared outside
its authorized scope, and needs to be considered compromised. The
EAP peer may also be unable to utilize the authenticator key cache
in an efficient way.
[b] It may not be obvious to the authenticator which peer ports are
associated with which peers. As a result, the authenticator may
not be able to enable a peer to communicate with it utilizing
multiple peer ports.
[c] It may not be obvious to the peer which "virtual authenticator" it
is communicating with. For example, multiple "virtual
authenticators" may share a MAC address, but utilize different NAS-
Identifiers.
[d] It may not be obvious to the authenticator which "virtual peer" it
is communicating with. Multiple "virtual peers" may share a MAC
address, but utilize different Peer-Ids.
[e] It may not be possible for the EAP peer and server to verify the
authenticator identity via channel bindings.
For example, problems [a], [c] and [e] occur in [IEEE-802.11i], which
utilizes peer and authenticator MAC addresses within the 4-way
handshake. Problems [b] and [d] do not occur since [IEEE-802.11i]
only allows a peer to utilize a single port.
The following steps enable lower layer identities to be securely
verified by all parties:
[f] Specifying the lower layer parameters used to identify the
authenticator and peer. As noted earlier, endpoint or port
identifiers are not recommended for identification of the
authenticator or peer when it is possible for them to have multiple
ports.
[g] Communicating the lower layer identities between the peer and
authenticator within phase 0. This allows the peer and
authenticator to determine the key scope if a key cache is
utilized.
[h] Communicating the lower layer authenticator identity between the
authenticator and backend server within the NAS-Identifier
attribute.
[i] Including the lower layer identities within Channel Bindings (if
supported) in phase 1a, ensuring that they are communicated between
the EAP peer and server.
[j] Supporting the integrity-protected exchange of identities within
phase 2a.
[k] Utilizing the advertised lower layer identities to enable the peer
and authenticator to verify that keys are maintained within the
advertised scope."
[Joe Salowey] I agree that the scope of EMSK derived keys must be defined,
however the details of how they are scoped is undefined. How they are
distributed is undefined. This will likely be defined on an application
by application basis. NAS identifier will probably be appropriate for
some. Others may not use a AAA protocol for key distribution or have a
scope that is larger, smaller or unrelated to a NAS. I don't think this
document should put too many constraints on EMSK usage.
>if multiple authenticators with different
> NAS-Identifiers possess the same key, then that indicates
> that those keys have been compromised.
[Joe] This seems somewhat arbitrary to me. A peer could see multiple
AAA clients as the same authenticator entity if an attribute other than
the NAS-ID is used as the authenticator identity. It seems that we may
be overloading NAS identifier.
> An authenticator cannot retrieve a key from the server if it has no
> way of mapping the Server-Id to a server that it recognizes.
[Joe] It seems that this issue is somewhat out of scope of this document
since key caching in AAA is not currently defined.
The question still remains; If no-one is going to validate that
the NAS-Identifier actually is within scope of the authenticator then
why bother to use it channel bindings?
Proposed Resolution:
Discuss
Issue 366: Section 2.2.2
Submitter name:
Joe Salowey
Submitter email address: jsalowey@cisco.com
Date Submitted:
May 2, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04274.html
Document:
KEYING-12
Comment type: 'E'ditorial
Priority: '2' May fix
Section:
2.2.2
Rationale/Explanation of issue:
What is the specific vulnerability in this situation?
" For example, the peer may assume that the "virtual
authenticators" are distinct and do not share a key cache, whereas,
depending on the architecture of the physical authenticator, a shared
key cache may or may not be implemented."
Maybe it should describe the peer problems that arise when you have
different authenticators that provide different levels of services,
similar to the authenticator problems in the next paragraph?
I'm not sure how recommendation [i] is related to the example of the
corporate/guest problem in the second paragraph.
[Bernard Aboba]
Sharing a logical cache between virtual authenticators creates the potential for elevation
of privilege or unauthorized access. By authenticating to one virtual authenticator,
the peer can gain access to any virtual authenticator that it shares a key cache with.
I don't think that Section 2.2.2 says this very clearly, though.
With respect to offering different services on different authenticators, this is
discussed in Section 4, but I am not sure it is a "virtual authenticator" issue.
I think that there are two issues that have been intermingled in [i]. One is the
need for virtual authenticators to advertise their identities consistently between
AAA and the lower layer, or else channel bindings could fail.
Another issue is the need for virtual authenticators to identify them distinctly,
so that peers can tell them apart. For example, in 802.11r it would not be a good
idea for all the virtual authenticators to use the same R0KH-ID, since then the
peers might not be able to tell them apart. However, if they used different
R0KH-IDs, but the same NAS-Identifier attribute, now channel bindings will fail.
Suggested resolution is as follows:
Change:
" When a single physical authenticator advertises itself as multiple
"virtual authenticators", a number of security vulnerabilities may
arise. For example, the peer may assume that the "virtual
authenticators" are distinct and do not share a key cache, whereas,
depending on the architecture of the physical authenticator, a shared
key cache may or may not be implemented.
Where EAP keying material is shared between "virtual authenticators"
an attacker acting as a peer could authenticate with the "Guest"
"virtual authenticator" and derive EAP keying material. If the
virtual authenticators share a key cache, then the peer can utilize
the EAP keying material derived for the "Guest" network to obtain
access to the "Corporate Intranet" virtual authenticator.
In order to address these issues:"
To:
" When a single physical authenticator advertises itself as multiple
"virtual authenticators", if the virtual authenticators do not maintain
logically separate key caches, then by authenticating to one virtual
authenticator, the peer can gain access to the other virtual authenticators
sharing a key cache.
For example, where a physical authenticator implements "Guest" and
"Corporate Intranet" virtual authenticators, an attacker acting as a peer
could authenticate with the "Guest" "virtual authenticator" and derive
EAP keying material. If the "Guest" and "Corporate Intranet" virtual
authenticators share a key cache, then the peer can utilize
the EAP keying material derived for the "Guest" network to obtain
access to the "Corporate Intranet" network.
In order to address this vulnerability:"
replace:
"[i] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly to the backend authentication server, such as by
utilizing a distinct NAS-Identifier attribute. This enables the
backend authentication server to utilize a separate credential to
authenticate each "virtual authenticator", and for the peer and
backend authentication server to verify the authenticator identity
via Channel Bindings (see Section 5.11)."
with
"[i] It is RECOMMENDED that each "virtual authenticator" identify itself
consistently to the peer and to the backend authentication server,
so as to enable the peer to verify the authenticator identity via
Channel Bindings (see Section 5.11).
[j] It is RECOMMENDED that each "virtual authenticator" identify itself
distinctly, in order to enable the peer to tell them apart. For
example, this can be accomplished by utilizing a distinct
NAS-Identifier attribute or BSSID."
Proposed Resolution:
Accept
Issue 367: Key Scope and EAP Server
Authorization
Submitter name: Joe Salowey
Submitter email address:
jsalowey@cisco.com
Date Submitted: May 3, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04231.html
Document:
KEYING-12
Comment type: 'T'echnical
Priority: '1' Should fix
Section:
2.2.1 and 3.2
Rationale/Explanation of issue:
Section 1.4.1 correctly defines the scope of the EAP keying material as
being defined by the EAP Peer and EAP server, however this relationship
is not carried out in other key scope discussions as far as I can tell.
In order for channel binding, key mixing etc. to work the peer must make
sure that the key is used not just within the authorized parameters of
the lower layer, but of the authorized scope of the EAP server as well.
I'm not sure of all of all the places where this needs to be addressed,
but I think it needs to be addressed in section 2.2.1 perhaps by adding
"[g] Verifying that the advertised scope is within the scope that the
EAP server is allowed to authorize"
Section 3.2 should probably state somewhere that:
"The peer should verify that the key scope advertised by the
authenticator is within the scope that is allowed to be authorized by
the EAP Server."
[Bernard Aboba]
I think I see the point, which is that a given authenticator may be connected to
more than one EAP server, and that all authenticators in a single administrative
domain may not share the same EAP server. Also, EAP servers cannot necessarily
be assumed to share key state among each other. If the selcted EAP method does not
provide the Server-ID, then the peer cannot know the scope of the keys it
derives with the EAP server.
This can create a number of issues, such as a peer attempting (but failing) a
fast reconnect because the server that the authenticator is configured to
communicate with is not the same one with which the peer established the
previous session.
However, there are other situations in which the server identity is not material,
such as handoff in an 11r Mobility Domain (MD), where the STA only care whether
a candidate AP is in the same MD, not whether the new authenticator is configured
to talk to the same backend authentication server as the current or initial AP.
In practice, the peer determines whether an authenticator is within the scope
of authorization of the backend authentication server by attempting to complete
the SAP exchange with it. If the exchange succeeds, the authenticator is
authorized; if not, it isn't. It is possible for the peer to attempt a
fast reconnect exchange with the wrong server; unless the server were to
include its identity in the EAP-Request there is no way for the peer to
determine what server it is talking to before the EAP method conversation
gets underway. Even if the authenticator were to advertise the server(s)
that it is configured to talk to, and even if those servers were identified
by their Server-IDs, it would not be possible for the peer to know a-priori
which server it was going to talk to, since the primary server can change due
to changes in network or server availability.
Given this, I'm not sure how the peer can verify that an authenticator is
allowed to be authorized by an EAP server.
The proposed resolution is to change Section 2.2 to the following:
"2.2. Peer and Authenticator Architecture
This specification does not impose constraints on the architecture of
the EAP authenticator or peer. Any of the authenticator architectures
described in [RFC4118] can be used. As a result, lower layers need to
identify EAP peers and authenticators unambiguously, without
incorporating implicit assumptions about peer and authenticator
architectures.
For example, it is possible for multiple base stations and a
"controller" (e.g. WLAN switch) to comprise a single EAP
authenticator. In such a situation, the "base station identity" is
irrelevant to the EAP method conversation, except perhaps as an
opaque blob to be used in Channel Bindings. Many base stations can
share the same authenticator identity. It should be understood that
an EAP authenticator or peer:
[a] may contain one or more physical or logical ports;
[b] may advertise itself as one or more "virtual"
authenticators or peers;
[c] may utilize multiple CPUs;
[d] may support clustering services for load balancing or failover.
Both the EAP peer and authenticator may have more than one physical
or logical port. A peer may simultaneously access the network via
multiple authenticators, or via multiple physical or logical ports on
a given authenticator. Similarly, an authenticator may offer network
access to multiple peers, each via a separate physical or logical
port. When a single physical authenticator advertises itself as
multiple "virtual authenticators", it is possible for a single
physical port to belong to multiple "virtual authenticators".
An authenticator may be configured to communicate with more than one
EAP server, each of which is configured to communicate with a subset
of the authenticators. The situation is illustrated in Figure 3.
+-+-+-+-+
| EAP
| Peer |
+-+-+-+-+
| | | Peer Ports
/ | \
/ | \
/
| \
/ | \
/ | \
/
| \
/
| \
/ |
\
Authenticator
| | | | | | | |
| Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| |
| |
| |
| Auth1 | | Auth2 | | Auth3 |
| |
| |
| |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ |
\ |
\ |
\ |
\ |
\ |
EAP over AAA \ |
\ |
(optional) \ |
\ |
\ | \ |
\ | \ |
\ | \ |
+-+-+-+-+-+ +-+-+-+-+-+ Backend
| EAP | | EAP
| Authentication
| Server1 | | Server2 | Servers
+-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Relationship between EAP peer, authenticator and
server"
Also, add Section
2.3:
"2.3. Server
Identification
The EAP method conversation is between the EAP peer and
server, as
identified by the Peer-Id and Server-Id. As shown in Figure 3,
an
authenticator may be configured to communicate with multiple
EAP
servers; the EAP server that an authenticator communicates with
may
vary according to configuration and network and server
availability.
While the EAP peer can assume that all EAP servers within a
realm
have access to the credentials necessary to validate
an
authentication attempt, it cannot assume that all EAP servers
share
persistent state.
Authenticators may be configured with
different primary or secondary
EAP servers, in order to balance the load.
Also, the authenticator
can dynamically determine the EAP server to which
requests will be
sent; in event of a communication failure, the authenticator
may fail
over to another EAP server. For example, in Figure 3,
Authenticator2
may be initially configured with EAP server1 as its primary
backend
authentication server, and EAP server2 as the backup, but if
EAP
server1 becomes unavailable, EAP server2 may become the
primary
server.
In general, the EAP peer cannot direct an
authentication attempt to a
particular EAP server within a realm; this
decision is made solely by
the authenticator. Nor can it determine which EAP
server it will be
communicating with, prior to the start of the EAP
method
conversation. The Server-Id is not included in the
EAP-
Request/Identity, and since the authenticator determines the
EAP
server dynamically, it typically is not possible for the
authenticator
to advertise the Server-Id during the discovery phase.
EAP methods may or may
not export the Server-Id, and as a result, the
EAP peer may not even learn
which server it was conversing with after
the EAP conversation completes
successfully.
As a result, an EAP peer, on connecting to a new
authenticator or
reconnecting to the same authenticator, may find itself
communicating
with a different EAP server. Fast reconnect, defined in
[RFC3748]
Section 7.2, may fail if the EAP server that the peer
communicates
with is not the same one with which it initially established
a
security association. For example, an EAP peer attempting an
EAP-TLS
session resume may find that the new EAP-TLS server will not
have
access to the TLS Master Key identified by the TLS Session-Id,
and
therefore the session resumption attempt will fail,
requiring
completion of a full EAP-TLS exchange.
EAP methods that
support mutual authentication may not allow the EAP
peer to verify the EAP
server identity. For example, the EAP peer
may only verify that the EAP
server possesses a long-term secret; in
this case the EAP peer will only know
that an authenticator has been
authorized by an EAP server, but will not
confirm the identity of the
EAP server.
EAP methods that export the
Server-Id MUST verify the server
identity. As noted in Appendix A, existing
EAP methods exporting the
Server-Id determine this from the altSubjectName in
the server
certificate, and as a result, the peer determines the identity of
the
server (expressed as a Fully Qualified Domain Name (FQDN))
by
validating the server certificate.
Validating the EAP server
identity enables the EAP peer to decide
whether a specific EAP server is
authorized, and to determine whether
the EAP server is sharing keying
material outside the intended scope.
In some cases, such as where the
certificate extensions defined in
[RFC4334] are included in the server
certificate, it may even be
possible for the peer to verify some Channel
Binding parameters from
the server certificate. Where the EAP peer does not
verify the EAP
server identity, it is not possible for the peer to determine
whether
the EAP server has shared keying material outside its
authorized
scope.
It is possible for problems to arise in situations
where the EAP
server identifies itself differently to the EAP peer
and
authenticator. For example, the Server-Id exported by EAP methods
may
not be identical to the Fully Qualified Domain Name (FQDN) of the
backend
authentication server. Where certificate-based
authentication is used within
RADIUS or Diameter, the altSubjectName
used in the backend server certificate
may not be identical to the
Server-Id or backend server FQDN.
Where
the backend server FQDN differs from the altSubjectName in the
certificate,
the AAA client may not be able to successfully determine
whether it is
talking to the correct backend authentication server.
Where the Server-Id and
backend server FQDN differ, the combination
of the key scope (Peer-Id,
Server-Id) and EAP conversation identifier
(Session-Id) may not be sufficient
for the authenticator to determine
where the key resides. For example, the
authenticator may identify
backend servers by their IP address (as occurs in
RADIUS), or using a
Fully Qualified Domain Name (as in Diameter). If the
Server-Id does
not correspond to the IP address or FQDN of a known
backend
authentication server, then the authenticator will not know
which
backend authentication server possesses the key."
[Joe Salowey]
Hi Bernard,
I think the text below is good, but I
don't think it addresses the issue
I had in mind.
Consider the
case where each authenticator contains its own EAP Server.
If the peer wants
to ensure that it is connecting to the "correct"
authenticator it obviously
cannot just rely upon channel bindings since
the authenticator is in control
of the EAP server, it must be able to
authorize the EAP server as being able
to authorize the authenticator.
If we consider a remote EAP Server then this
EAP server will be
authorized to atuhorize as subset of authenticators.
In order for a
peer to verify that the authenticator in collusion with the
EAP server
is not lying about some parameter it must be able to authorize the
EAP
Server as being able to authorize the authenticator.
In some ways
this is a basic thing, but I don't think this is currently
covered elswhere
in the document. It may not belong in this section,
but I think it
belongs somewhere with the scoping discussion.
[Bernard Aboba]
How about the following:
Add the
following paragraphs to the end of Section 2.3 Server
Identification:
"EAP methods that support mutual authentication
enable the EAP peer to only connect to authenticators authenticated by a trusted
EAP server. However, mutual authentication may not result in verification of the
EAP server identity. For example, the EAP peer may only verify that the EAP
server possesses a long-term secret; in this case the EAP peer will only know
that an authenticator has been authorized by an EAP server, but will not know
which one.
EAP methods that export the Server-Id MUST verify the
server identity. This enables the EAP peer to decide whether a specific EAP
server is authorized or not, and determine whether the EAP server is sharing
keying material outside the intended scope. In some cases, such as where the
certificate extensions defined in [RFC4334] are included in the server
certificate, it may even be possible for the peer to verify some Channel Binding
parameters from the server certificate. Where the EAP peer does not verify the
EAP server identity, it is not possible for the peer to determine whether keying
material has been shared outside its authorized scope."
[Jari Arkko]
I am basically fine with this text, but it may be exaggarate
the value of
an identifier a little bit. If you assume that the correct server set has
given long-term secret material to some other servers, its not clear that
having the server provide an identifier helps in all cases. For instance,
the server may lie about its identifier.
Suggested edit: s/This enables the EAP peer to decide/This may help
the EAP peer to decide/
[Bernard Aboba] Here is the revised text of Section 2.3:
"2.3. Server Identification
The EAP method conversation is between the EAP peer and server, as
identified by the Peer-Id and Server-Id. As shown in Figure 3, an
authenticator may be configured to communicate with multiple EAP
servers; the EAP server that an authenticator communicates with may
vary according to configuration and network and server availability.
While the EAP peer can assume that all EAP servers within a realm
have access to the credentials necessary to validate an
authentication attempt, it cannot assume that all EAP servers share
persistent state.
Authenticators may be configured with different primary or secondary
EAP servers, in order to balance the load. Also, the authenticator
can dynamically determine the EAP server to which requests will be
sent; in event of a communication failure, the authenticator may fail
over to another EAP server. For example, in Figure 3, Authenticator2
may be initially configured with EAP server1 as its primary backend
authentication server, and EAP server2 as the backup, but if EAP
server1 becomes unavailable, EAP server2 may become the primary
server.
In general, the EAP peer cannot direct an authentication attempt to a
particular EAP server within a realm; this decision is made solely by
the authenticator. Nor can it determine which EAP server it will be
communicating with, prior to the start of the EAP method
conversation. The Server-Id is not included in the EAP-
Request/Identity, and since the authenticator determines the EAP
server dynamically, it typically is not possible for the
authenticator to advertise the Server-Id during the discovery phase.
EAP methods may or may not export the Server-Id, and as a result, the
EAP peer may not even learn which server it was conversing with after
the EAP conversation completes successfully.
As a result, an EAP peer, on connecting to a new authenticator or
reconnecting to the same authenticator, may find itself communicating
with a different EAP server. Fast reconnect, defined in [RFC3748]
Section 7.2, may fail if the EAP server that the peer communicates
with is not the same one with which it initially established a
security association. For example, an EAP peer attempting an EAP-TLS
session resume may find that the new EAP-TLS server will not have
access to the TLS Master Key identified by the TLS Session-Id, and
therefore the session resumption attempt will fail, requiring
completion of a full EAP-TLS exchange.
EAP methods that support mutual authentication may not allow the EAP
peer to verify the EAP server identity. For example, the EAP peer
may only verify that the EAP server possesses a long-term secret; in
this case the EAP peer will only know that an authenticator has been
authorized by an EAP server, but will not confirm the identity of the
EAP server.
EAP methods that export the Server-Id MUST verify the server
identity. As noted in Appendix A, existing EAP methods exporting the
Server-Id determine this from the altSubjectName in the server
certificate, and as a result, the peer determines the identity of the
server (expressed as a Fully Qualified Domain Name (FQDN)) by
validating the server certificate.
Validating the EAP server identity may help the EAP peer to decide
whether a specific EAP server is authorized, and to determine whether
the EAP server is sharing keying material outside the intended scope.
In some cases, such as where the certificate extensions defined in
[RFC4334] are included in the server certificate, it may even be
possible for the peer to verify some Channel Binding parameters from
the server certificate. Where the EAP peer does not verify the EAP
server identity, it is not possible for the peer to determine whether
the EAP server has shared keying material outside its authorized
scope.
It is possible for problems to arise in situations where the EAP
server identifies itself differently to the EAP peer and
authenticator. For example, the Server-Id exported by EAP methods
may not be identical to the Fully Qualified Domain Name (FQDN) of the
backend authentication server. Where certificate-based
authentication is used within RADIUS or Diameter, the altSubjectName
used in the backend server certificate may not be identical to the
Server-Id or backend server FQDN.
Where the backend server FQDN differs from the altSubjectName in the
certificate, the AAA client may not be able to successfully determine
whether it is talking to the correct backend authentication server.
Where the Server-Id and backend server FQDN differ, the combination
of the key scope (Peer-Id, Server-Id) and EAP conversation identifier
(Session-Id) may not be sufficient for the authenticator to determine
where the key resides. For example, the authenticator may identify
backend servers by their IP address (as occurs in RADIUS), or using a
Fully Qualified Domain Name (as in Diameter). If the Server-Id does
not correspond to the IP address or FQDN of a known backend
authentication server, then the authenticator will not know which
backend authentication server possesses the key."
Proposed Resolution:
Discuss
Issue 368: Threat Model
Assumptions
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date Submitted: May 4, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04231.html
Document:
KEYING-12
Comment type: 'T'echnical
Priority: '1' Should fix
Section:
5
Rationale/Explanation of issue:
The assumptions about the attacker are not discussed as part of the
threat
model.
Recommendation is to change the first three paragraphs of Section
5
to the following:
" The EAP threat model is described in [RFC3748]
Section 7.1. The
security properties of EAP methods (known as "security
claims") are
described in [RFC3748] Section 7.2.1. EAP method requirements
for
applications such as Wireless LAN authentication are described
in
[RFC4017]. The RADIUS threat model is described in [RFC3579]
Section
4.1, and responses to these threats are described in
[RFC3579]
Sections 4.2 and 4.3.
However, in addition to threats
against EAP and AAA, there are other
system level threats. In developing the
threat model, it is assumed
that:
All traffic is visible to the
attacker.
The attacker can alter, forge or replay messages.
The attacker
can reroute messages to another principal.
The attacker may be a principal or
an outsider.
The attacker can compromise any key that is sufficiently
old.
Threats arising from these assumptions include:"
Proposed Resolution:
Accept
Issue 369: Key-Lifetime Parameter
removal
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date Submitted: June 8, 2006
Reference:
http://lists.frascone.com/pipermail/eap/msg04395.html
Document:
KEYING-13
Comment type: 'T'echnical
Priority: S
Section:
Various
Rationale/Explanation of issue:
In looking at the discussion of this issue, and reviewing the text, it is not
clear
how useful it is to have EAP methods export the Key-Lifetime
parameter. Today no EAP
methods export this parameter, and the text in
Section 1.4 suggests that this
is not very useful
anyway:
Key-Lifetime
While EAP itself does not support key
lifetime negotiation, it is
possible to specify methods that do. However,
systems that rely
on such negotiation for exported keys would only function
with
these methods. As a result, it is NOT RECOMMENDED to use
this
approach as the sole way to determine key lifetimes.
Similarly,
Section 3 states:
Existing EAP methods do not export the
Key-Lifetime
parameter; in the interest of method independence, key
management of
exported or derived keys SHOULD NOT be provided within EAP
methods.
As a result, it may make sense to remove discussion of the
Key-Lifetime parameter
from the document.
The proposed resolution is
as follows:
In Section 1.4, delete:
" Key-Lifetime
While
EAP itself does not support key lifetime negotiation, it is
possible to
specify methods that do. However, systems that rely
on such negotiation for
exported keys would only function with
these methods. As a result, it is NOT
RECOMMENDED to use this
approach as the sole way to determine key
lifetimes."
Change:
"EAP methods also MAY export method-specific peer and server
identifiers
(Peer-Id and Server-Id), a method-specific EAP
conversation identifier known
as the Session-Id, and the lifetime of
the exported keys, known as the
Key-Lifetime. "
To:
"EAP methods also MAY export method-specific peer and server
identifiers
(Peer-Id and Server-Id) and a method-specific EAP
conversation identifier
known as the Session-Id. "
In Section 2, change:
" On completion of EAP authentication, keying material and
material and
parameters exported by the EAP method are provided
to the lower layer
and AAA layer (if present). These
include the Master Session Key
(MSK), Extended Master Session
Key (EMSK), Peer-Id, Server-Id,
Session-Id and
Key-Lifetime. The Initialization Vector (IV) is
deprecated."
To:
" On completion of EAP authentication, keying material and
material and
parameters exported by the EAP method are provided
to the lower layer
and AAA layer (if present). These
include the Master Session Key
(MSK), Extended Master Session
Key (EMSK), Peer-Id, Server-Id,
and Session-Id. The
Initialization Vector (IV) is
deprecated."
Delete the
Key-Lifetime parameter from Figure 2.
In Section 3, delete:
"Existing EAP methods do not export the
Key-Lifetime
parameter; in the interest of method independence, key
management of
exported or derived keys SHOULD NOT be provided within EAP
methods."
In Section 3.5, change:
"System defaults. Where the EAP method does not support
the
negotiation of the exported key lifetime, and a
key lifetime
negotiation mechanism is not provided
by the lower lower, there may
be no way for the peer
to learn the exported key lifetime. In this
case it is RECOMMENDED that the peer assume a default value of
the
exported key lifetime; 8 hours is
recommended. Similarly, the
lifetime of
calculated keys can also be managed as a system
parameter on the authenticator."
To:
"System defaults.
Where the EAP method does not support the negotiation
of
the lifetime of exported keys, and a key lifetime negotiation mechanism is
not provided
by the lower lower, there may be no way for the peer to
learn
the lifetime of exported keys. In this case
it is RECOMMENDED that
the peer assume a default
value; 8 hours is recommended.
Similarly, the
lifetime of calculated keys can also
be managed as a system parameter on the
authenticator."
Change:
"[d] Method specific negotiation within EAP. While EAP itself
does not
support lifetime negotiation, it would be
possible to specify
methods that do. However,
systems that rely on such negotiation
for exported
keys would only function with these methods. As
a
result, it is NOT RECOMMENDED to use this approach
as the sole way
to determine key lifetimes."
To:
"[d] Method specific negotiation within EAP. While EAP itself does
not
support lifetime negotiation, it would be possible to specify
methods
that do. However, systems that rely on such negotiation
for exported keys
would only function with these methods;
in the interest of method
independence, key management of
exported or derived keys SHOULD NOT be
provided within EAP methods."
In Section 3.6, change:
" Where the EAP method does not export the Key-Lifetime
parameter, the
lifetime of the EAP keying material may not be
defined until
completion of the Secure Association Protocol, if
ever. "
To:
"Where the EAP method does not negotiate the
lifetime of exported keys,
the lifetime of the EAP keying
material may not be defined until completion
of the
Secure Association Protocol, if ever."
Change Appendix A to the following:
"Appendix A - Exported Parameters in Existing Methods
This Appendix specifies Session-Id, Peer-Id and Server-Id
for
EAP methods that have been published prior to this
specification. Future EAP method specifications MUST include
a
definition of the Session-Id, Peer-Id, and Server-Id
(could be the
empty string).
EAP-Identity
The EAP-Identity method is
defined in [RC3748]. It does not
derive
keys, and therefore does not define the
Session-Id. The Peer-Id exported by the Identity method
is
determined by the octets included within
the EAP-
Response/Identity. The
Server-Id is the empty string (zero
length).
EAP-Notification
The EAP-Notification
method is defined in [RFC3748]. It does
not
derive keys and therefore does not define
the
Session-Id. The Peer-Id and
Server-Id are the empty string (zero
length).
EAP-GTC
The
EAP-GTC method is defined in [RFC3748]. It does not
derive
keys and therefore does not define the
Session-
Id. The Peer-Id and Server-Id
are the empty string.
EAP-OTP
The EAP-OTP method is defined in
[RFC3748]. It does not derive
keys and
therefore does not define the Session-
Id. The Peer-Id and Server-Id are the empty string.
EAP-TLS
EAP-TLS is defined in
[RFC2716]. The EAP-TLS Session-Id is the
concatenation of the Expanded EAP Type Code (including the
Type,
Vendor-Id and Vendor-Type fields defined
in [RFC3748] Section 5.7)
with the peer and
server nonces. The Peer-Id and Server-Id
are
the contents of the altSubjectName in the
peer and server
certificates.
EAP-AKA
EAP-AKA is
defined in [RFC4187]. The EAP-AKA Session-Id is
the
concatenation of the Expanded EAP Type
Code (including the Type,
Vendor-Id and
Vendor-Type fields defined in [RFC3748] Section
5.7)
with the contents of the RAND field from
the AT_RAND attribute,
followed by the
contents of the AUTN field in the AT_AUTN
attribute.
The Peer-Id is the contents of
the Identity field from the
AT_IDENTITY
attribute, using only the Actual Identity
Length
octets from the beginning,
however. Note that the contents are
used
as they are transmitted, regardless of whether
the
transmitted identity was a permanent,
pseudonym, or fast re-
authentication
identity. The Server-Id is an empty string.
EAP-SIM
EAP-SIM is defined in
[RFC4186]. The EAP-SIM Session-Id is the
concatenation of the Expanded EAP Type Code (including the
Type,
Vendor-Id and Vendor-Type fields defined
in [RFC3748] Section 5.7)
with the contents of
the RAND field from the AT_RAND attribute,
followed by the contents of the NONCE_MT field in the
AT_NONCE_MT
attribute.
The Peer-Id is the contents of
the Identity field from the
AT_IDENTITY
attribute, using only the Actual Identity
Length
octets from the beginning,
however. Note that the contents are
used
as they are transmitted, regardless of whether
the
transmitted identity was a permanent,
pseudonym, or fast re-
authentication
identity. The Server-Id is an empty string."
Proposed Resolution:
Accept
Issue 370: Key Management
Submitter name:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date Submitted:
June 23, 2006
Reference:
http://lists.frascone.com/pipermail/eap/msg04442.html
Document: KEYING-13
Comment type:
'T'echnical
Priority: 1
Section: 3
Rationale/Explanation of issue:
Section 3 does not clearly describe why EAP is not a key management
protocol.
The proposed resolution is to change Section 3
from:
"3. Key Management
EAP as defined in [RFC3748]
supports key derivation, but does not
provide for the management
of exported or derived keys. Although EAP
methods may
support "fast reconnect" as defined in [RFC3748] Section
7.2.1,
EAP does not support re-key of exported keys without re-
authentication."
to:
"3. Key Management
EAP as defined in [RFC3748] supports key derivation, but does
not
provide for the management of exported or derived
keys. Missing
functionality includes:
[a]
Re-key. EAP does not support re-key of exported keys without
re-
authentication, although EAP methods may support
"fast reconnect"
as defined in [RFC3748] Section
7.2.1.
[b] Key delete/install semantics. EAP does not
synchronize
installation or deletion of keying
material on the EAP peer and
authenticator.
[c] Lifetime negotiation. EAP does not support
lifetime negotiation for
exported keys, and existing
EAP methods also do not support key
lifetime
negotiation.
[d] Cryptographic algorithm negotiation. EAP methods
only negotiate
cryptographic algorithms for their
own use, not for the underlying
lower
layers.
[e] Guaranteed TSK freshness. Without a post-EAP
handshake, TSKs can
be reused if EAP keying material
is cached.
These deficiencies are typically addressed via a
post-EAP handshake
known as the Secure Association
Protocol."
[Jari Arkko] Looks good to me.
Proposed Resolution:
Discuss
Issue 371: Session-Id Calculation
Submitter name:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date Submitted:
June 24, 2006
Reference:
http://lists.frascone.com/pipermail/eap/msg04452.html
Document: KEYING-13
Comment type:
'T'echnical
Priority: S
Section: 1.2, 1.4, Appendix A
Rationale/Explanation of issue:
For methods allocated with the standard EAP space (TLS, AKA, SIM) Appendix A
states that the Session-Id is constructed as follows:
"Session-Id is the concatenation of the Expanded EAP Type Code (including
the Type, Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7)
with
the..."
Since these methods have no Vendor-Id or Vendor-Type fields, are these
fields included or not?
My recommendation is to replace the text as follows:
"Session-Id is the concatenation of the EAP Type Code (<insert here>) with
the..."
[M. Vanderveen] That sounds fine.
[BA] The Proposed Resolution is as follows:
Here is the revised text of Section 1.2, 1.4 and Appendix A:
New Section 1.2 definition:
"Session-Id
The EAP Session-Id uniquely identifies an EAP session between an
EAP peer (as identified by the Peer-Id) and server (as identified
by the Server-Id). For more information, see Section 1.4."
Section 1.4:
" Session-Id
The Session-Id uniquely identifies an EAP session between an EAP
peer (as identified by the Peer-Id) and server (as identified by
the Server-Id). Where the EAP Type Code is less than 255, the EAP
Session-Id consists of the concatenation of the EAP Type Code and
a temporally unique identifier obtained from the method. Where
expanded EAP Type Codes are used, the EAP Session-Id consists of
the Expanded Type Code (including the Type, Vendor-Id and Vendor-
Type fields defined in [RFC3748] Section 5.7) concatenated with a
temporally unique identifier obtained from the method. This
unique identifier is typically constructed from nonces or
counters used within the EAP method exchange. The inclusion of
the Type Code in the EAP Session-Id ensures that each EAP method
has a distinct Session-Id space. Since an EAP session is not
bound to a particular authenticator or specific ports on the peer
and authenticator, the authenticator port or identity are not
included in the Session-Id."
Appendix A text for EAP-TLS, AKA, and SIM:
" EAP-TLS
EAP-TLS is defined in [RFC2716]. The EAP-TLS Session-Id is the
concatenation of the EAP Type Code (0x0D) with the peer and server
nonces. The Peer-Id and Server-Id are the contents of the
altSubjectName in the peer and server certificates.
EAP-AKA
EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the
concatenation of the EAP Type Code (0x17) with the contents of the
RAND field from the AT_RAND attribute, followed by the contents of
the AUTN field in the AT_AUTN attribute.
The Peer-Id is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether the
transmitted identity was a permanent, pseudonym, or fast re-
authentication identity. The Server-Id is an empty string.
EAP-SIM
EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the
concatenation of the EAP Type Code (0x12) with the contents of the
RAND field from the AT_RAND attribute, followed by the contents of
the NONCE_MT field in the AT_NONCE_MT attribute.
The Peer-Id is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length
octets from the beginning, however. Note that the contents are
used as they are transmitted, regardless of whether the
transmitted identity was a permanent, pseudonym, or fast re-
authentication identity. The Server-Id is an empty string."
Proposed Resolution:
Discuss
Issue 372: Key-Lifetime
Submitter name:
Alper Yegin
Submitter email address: alper.yegin@yegin.org
Date Submitted:
July 19, 2006
Reference:
http://lists.frascone.com/pipermail/eap/msg04464.html
Document: KEYING-14
Comment type:
'T'echnical
Priority: S
Section: 3.5
Rationale/Explanation of issue:
3.5. Exported and Calculated Key Lifetimes
All EAP methods generating keys are required to generate the MSK and
EMSK, and may optionally generate the IV. However, EAP, defined in
[RFC3748], does not itself support the negotiation of lifetimes for
exported keying material such as the MSK, EMSK and IV.
Several mechanisms exist for managing key lifetimes:
[a] AAA attributes. AAA protocols such as RADIUS [RFC2865] and
Diameter [RFC4072] support the Session-Timeout attribute. The
Session-Timeout attribute represents the maximum lifetime of the
exported keying material, and all keys depending on it, on the
authenticator. Since existing backend authentication servers do
not cache keys exported by EAP methods, or keys calculated from
exported keys, the value of the Session-Timeout attribute has no
bearing on the key lifetime within the backend authentication
server.
On the authenticator, where EAP is used for authentication the
Session-Timeout attribute represents the maximum session time prior
to re-authentication. As described in [RFC3580] Section 3.17, when
sent in an Access-Accept along with a Termination-Action value of
RADIUS-Request, the Session-Timeout attribute specifies the maximum
number of seconds of service provided prior to re-authentication.
Where EAP is used for pre-authentication, the session may not start
until some future time, or may never occur. Nevertheless, the
Session-Timeout value represents the maximum time after which
transported EAP keying material, and all keys dependent on it, will
have expired on the authenticator. If the session subsequently
starts, re-authentication will be initiated once the Session-Time
has expired. If the session never started, or started and ended, by
default keys transported by AAA and all keys dependent on them be
expired by the authenticator prior to the future time indicated by
Session-Timeout; this feature is utilized by [IEEE-802.11i]. Note
that in future additional attributes may be specified to control
the lifetime of cached keys; these attributes may modify the
meaning of the Session-Timeout attribute in specific circumstances.
Since the TSK lifetime is often determined by authenticator
resources, and the backend authentication server has no insight
into the TSK derivation process, by the principle of ciphersuite
independence, it is not appropriate for the backend authentication
server to manage any aspect of the TSK derivation process,
including the TSK lifetime.
Alper: We shall not present this (a) as if it is a complete mechanism that
can manage key lifetimes on all relevant parties (peer, authenticator,
authentication server). This only provides the MSK lifetime to the
authenticator. Only when coupled with how peer learns the key lifetime for
MSK and EMSK we'd have a complete solution.
Alper: I think what I'm suggesting is to enumerate these alternatives, such
that (a) appears under "how authenticator dynamically learns the MSK
lifetime."
[b] Lower layer mechanisms. While AAA attributes can communicate the
maximum exported key lifetime, this only serves to synchronize the
key lifetime between the backend authentication server and the
authenticator. Lower layer mechanisms such as the Secure
Association Protocol can then be used to enable the lifetime of
exported and calculated keys to be negotiated between the peer and
authenticator.
Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include support for TSK re-key. Where the TSK is taken
directly from the MSK, there is no need to manage the TSK lifetime
as a separate parameter, since the TSK lifetime and MSK lifetime
are identical.
Alper: Secure Association Protocol is a "consumer" of MSK. For that, I don't
expect it to set the any attributes of the MSK it is "using." Doing
otherwise is a hack, IMHO. I recommend we remove the current text from this
option.
Alper: But, we shall retain the option. IMO, the technically correct way of
doing this is not via the "secure association" protocol, but via the "eap
transport". The lifetime learned from the authentication server via AAA
protocols can be conveyed to the EAP peer via such protocols. If people
agree, I can propose text.
[c] System defaults. Where the EAP method does not support the
negotiation of the lifetime of exported keys, and a key lifetime
negotiation mechanism is not provided by the lower lower, there may
be no way for the peer to learn the lifetime of exported keys. In
this case it is RECOMMENDED that the peer assume a default value; 8
hours is recommended. Similarly, the lifetime of calculated keys
can also be managed as a system parameter on the authenticator.
[d] Method specific negotiation within EAP. While EAP itself does not
support lifetime negotiation, it would be possible to specify
methods that do. However, systems that rely on such negotiation
for exported keys would only function with these methods. In the
interest of method independence, key management of exported or
derived keys SHOULD NOT be provided within EAP methods.
Alper: again, this is all about how peer and authentication server agrees on
the MSK and EMSK lifetimes. It does not help the authenticator. We shall
categorize this mechanism as such.
Alper: Besides, what is the interaction between the lifetimes known and
delivered by the EAP methods and the AAA protocols? My understanding is, EAP
methods may export lifetimes, and the AAA protocol has the last say whether
the lifetime should be same as reported by the EAP method, or something
less. This is all about the "authorization" aspect.
[Bernard Aboba]
Alper: We shall not present this (a) as if it is a complete mechanism that
can manage key lifetimes on all relevant parties (peer, authenticator,
authentication server). This only provides the MSK lifetime to the
authenticator. Only when coupled with how peer learns the key lifetime for
MSK and EMSK we'd have a complete solution.
Right.
Alper: I think what I'm suggesting is to enumerate these alternatives, such
that (a) appears under "how authenticator dynamically learns the MSK
lifetime."
This makes sense.
Alper: Secure Association Protocol is a "consumer" of MSK. For that, I
don't
expect it to set the any attributes of the MSK it is "using." Doing
otherwise is a hack, IMHO. I recommend we remove the current text from this
option.
In practice the SAP handles this in a number of cases, including IKEv2, 802.16e,
and 11r. So I don't think we can leave it out.
Alper: But, we shall retain the option. IMO, the technically correct way of
doing this is not via the "secure association" protocol, but via the "eap
transport". The lifetime learned from the authentication server via AAA
protocols can be conveyed to the EAP peer via such protocols. If people
agree, I can propose text.
We should probably describe this as another option.
[d] Method specific negotiation within EAP. While EAP itself does not
support lifetime negotiation, it would be possible to specify
methods that do. However, systems that rely on such negotiation
for exported keys would only function with these methods. In the
interest of method independence, key management of exported or
derived keys SHOULD NOT be provided within EAP methods.
Alper: again, this is all about how peer and authentication server
agrees on
the MSK and EMSK lifetimes. It does not help the authenticator. We shall
categorize this mechanism as such.
Yes. In fact, it might create problems if *both* the method and SAP/transport
are trying to negotiate the lifetime. Do you have text to suggest?
Alper: Besides, what is the interaction between the lifetimes known and
delivered by the EAP methods and the AAA protocols? My understanding is, EAP
methods may export lifetimes, and the AAA protocol has the last say whether
the lifetime should be same as reported by the EAP method, or something
less. This is all about the "authorization" aspect.
Right. Another potential conflict.[Alper Yegin]
> In practice the SAP handles this in a number of cases, including IKEv2,
> 802.16e, and 11r. So I don't think we can leave it out.
I don't think we want to recommend that method. For that, not even
mentioning is the best thing, IMHO. If we really want to capture those
examples, I'd say they should go with a "NOT RECOMMENDED" qualifier in the
document.
[Bernard Aboba] Here is a revised proposal for both Sections 3.5 and 3.6:
"3.5. Exported and Calculated Key Lifetimes
The following mechanisms are available for communicating the lifetime
of exported and calculated keying material between the EAP peer,
server and authenticator:
AAA protocols (backend server and authenticator)
Lower layer mechanisms (authenticator and peer)
EAP method-specific negotiation (peer and server)
Where the EAP method does not support the negotiation of the lifetime
of exported keys, and a key lifetime negotiation mechanism is not
provided by the lower lower, there may be no way for the peer to
learn the lifetime of exported and calculated keys. This can leave
the peer uncertain how long the authenticator will maintain EAP
keying material within the key cache. In this case the lifetime of
exported keys can be managed as a system parameter on the peer and
authenticator; a default lifetime of 8 hours is RECOMMENDED.
3.5.1. AAA Protocols
AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be
used to communicate the maximum exported key lifetime from the
backend authentication server to the authenticator.
The Session-Timeout attribue is defined for RADIUS in [RFC2865] and
for Diameter in [RFC4005]. Where EAP is used for authentication,
[RFC3580] Section 3.17 indicates that a Session-Timeout attribute
sent in an Access-Accept along with a Termination-Action value of
RADIUS-Request specifies the maximum number of seconds of service
provided prior to re-authentication.
However, there is also a need to be able to specify the maximum
lifetime of cached keying material. Where EAP pre-authentication is
supported, cached keys can be pre-established on the authenticator
prior to session start, and will remain there until they expire. EAP
lower layers supporting caching of exported keying material may also
persist that material after the end of a session, enabling the peer
to subsequently resume communication utilizing the cached keying
material. In these situations it may be desirable for the backend
authentication server to specify the maximum lifetime of cached
keying material.
To accomplish this, [IEEE-802.11i] overloaded the Session-Timeout
attribute, assuming that it represents the maximum time after which
transported EAP keying material will expire on the authenticator,
regardless of whether transported keying material is cached.
An IEEE 802.11 authenticator receiving keying material is expected to
initialize a timer to the Session-Timeout value, and once the timer
expires, the exported keying material expires. Whether this results
in session termination or re-authentication is controlled by the
value of the Termination-Action attribute. Where re-authentication
occurs the exported keying material is replaced, and with it, new
calculated keys are put in place. Where session termination occurs,
exported and calculated keying material is deleted.
Overloading the Session-Timeout attribute is problematic in
situations where it is necessary to control the maximum session time
and key lifetime independently. For example, it might be desirable
to limit the lifetime of cached keys to 5 minutes while permitting a
user once authenticated to remain connected for up to an hour without
re-authenticating. As a result, in the future additional attributes
may be specified to control the lifetime of cached keys; these
attributes may modify the meaning of the Session-Timeout attribute in
specific circumstances.
Since the TSK lifetime is often determined by authenticator
resources, and the backend authentication server has no insight into
the TSK derivation process, by the principle of ciphersuite
independence, it is not appropriate for the backend authentication
server to manage any aspect of the TSK derivation process, including
the TSK lifetime.
3.5.2. Lower Layer Mechanisms
Lower layer mechanisms can be used to enable the lifetime of exported
and calculated keys to be negotiated between the peer and
authenticator. This can be accomplished either using the Secure
Association Protocol or within the lower layer transport.
Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include support for TSK re-key. Where the TSK is taken
directly from the MSK, there is no need to manage the TSK lifetime as
a separate parameter, since the TSK lifetime and MSK lifetime are
identical.
3.5.3. EAP Method-Specific Negotiation
All EAP methods generating keys are required to generate the MSK and
EMSK, and may optionally generate the IV. However, EAP, defined in
[RFC3748], does not itself support the negotiation of lifetimes for
exported keying material such as the MSK, EMSK and IV.
While EAP itself does not support lifetime negotiation, it would be
possible to specify methods that do. However, systems that rely on
such negotiation for exported keys would only function with these
methods. Also, there is no guarantee that the lifetime negotiated
within the EAP method would be compatible with backend authentication
server policy. In the interest of method independence and
compatibility with backend server implemenations, key management of
exported or derived keys SHOULD NOT be provided within EAP methods.
3.6. Key cache synchronization
Key lifetime negotiation alone cannot guarantee key cache
synchronization. Even where a lower layer exchange is run
immediately after EAP in order to determine the lifetime of EAP
keying material, it is still possible for the authenticator to
reclaim resources.
The lower layer may utilize the Discovery phase 0 to improve key
cache synchronization. For example, if the authenticator manages the
key cache by deleting the oldest key first (LIFO), the relative
creation time of the last key to be deleted could be advertised
within the Discovery phase, enabling the peer to determine whether
keying material had been prematurely expired from the authenticator
key cache."
[Michaela Vanderveen]
About section 3.6, the authenticator "reclaim[ing]
resources" is a bit unclear.
Also, deleting the older key first does not read to me as the same as a
LIFO queue, as the last key to be added is the newest one, and that's
not the one that it is thrown out first.
[Bernard Aboba]
How about this?
"3.6. Key cache Synchronization
Key lifetime negotiation alone cannot guarantee key cache
synchronization. Even where a lower layer exchange is run
immediately after EAP in order to determine the lifetime of EAP
keying material, it is still possible for the authenticator to
purge all or part of the key cache prematurely (e.g. due to reboot or
need to reclaim memory).
The lower layer may utilize the Discovery phase 0 to improve key
cache synchronization. For example, if the authenticator manages the
key cache by deleting the oldest key first, the relative
creation time of the last key to be deleted could be advertised
within the Discovery phase, enabling the peer to determine whether
keying material had been prematurely expired from the authenticator
key cache."
[Michaela Vanderveen]
Sounds very clear now. Thanks.
[Bernard Aboba] Here is the entire proposed resolution:
Replace Section 3.5 and 3.6 with the following:
"3.5. Exported and Calculated Key Lifetimes
The following mechanisms are available for communicating the lifetime
of exported and calculated keying material between the EAP peer,
server and authenticator:
AAA protocols (backend server and authenticator)
Lower layer mechanisms (authenticator and peer)
EAP method-specific negotiation (peer and server)
Where the EAP method does not support the negotiation of the lifetime
of exported keys, and a key lifetime negotiation mechanism is not
provided by the lower lower, there may be no way for the peer to
learn the lifetime of exported and calculated keys. This can leave
the peer uncertain how long the authenticator will maintain EAP
keying material within the key cache. In this case the lifetime of
exported keys can be managed as a system parameter on the peer and
authenticator; a default lifetime of 8 hours is RECOMMENDED.
3.5.1. AAA Protocols
AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be
used to communicate the maximum exported key lifetime from the
backend authentication server to the authenticator.
The Session-Timeout attribue is defined for RADIUS in [RFC2865] and
for Diameter in [RFC4005]. Where EAP is used for authentication,
[RFC3580] Section 3.17 indicates that a Session-Timeout attribute
sent in an Access-Accept along with a Termination-Action value of
RADIUS-Request specifies the maximum number of seconds of service
provided prior to re-authentication.
However, there is also a need to be able to specify the maximum
lifetime of cached keying material. Where EAP pre-authentication is
supported, cached keys can be pre-established on the authenticator
prior to session start, and will remain there until they expire. EAP
lower layers supporting caching of exported keying material may also
persist that material after the end of a session, enabling the peer
to subsequently resume communication utilizing the cached keying
material. In these situations it may be desirable for the backend
authentication server to specify the maximum lifetime of cached
keying material.
To accomplish this, [IEEE-802.11i] overloaded the Session-Timeout
attribute, assuming that it represents the maximum time after which
transported EAP keying material will expire on the authenticator,
regardless of whether transported keying material is cached.
An IEEE 802.11 authenticator receiving keying material is expected to
initialize a timer to the Session-Timeout value, and once the timer
expires, the exported keying material expires. Whether this results
in session termination or re-authentication is controlled by the
value of the Termination-Action attribute. Where re-authentication
occurs the exported keying material is replaced, and with it, new
calculated keys are put in place. Where session termination occurs,
exported and calculated keying material is deleted.
Overloading the Session-Timeout attribute is problematic in
situations where it is necessary to control the maximum session time
and key lifetime independently. For example, it might be desirable
to limit the lifetime of cached keys to 5 minutes while permitting a
user once authenticated to remain connected for up to an hour without
re-authenticating. As a result, in the future additional attributes
may be specified to control the lifetime of cached keys; these
attributes may modify the meaning of the Session-Timeout attribute in
specific circumstances.
Since the TSK lifetime is often determined by authenticator
resources, and the backend authentication server has no insight into
the TSK derivation process, by the principle of ciphersuite
independence, it is not appropriate for the backend authentication
server to manage any aspect of the TSK derivation process, including
the TSK lifetime.
3.5.2. Lower Layer Mechanisms
Lower layer mechanisms can be used to enable the lifetime of exported
and calculated keys to be negotiated between the peer and
authenticator. This can be accomplished either using the Secure
Association Protocol or within the lower layer transport.
Where TSKs are established as the result of a Secure Association
Protocol exchange, it is RECOMMENDED that the Secure Association
Protocol include support for TSK re-key. Where the TSK is taken
directly from the MSK, there is no need to manage the TSK lifetime as
a separate parameter, since the TSK lifetime and MSK lifetime are
identical.
3.5.3. EAP Method-Specific Negotiation
All EAP methods generating keys are required to generate the MSK and
EMSK, and may optionally generate the IV. However, EAP, defined in
[RFC3748], does not itself support the negotiation of lifetimes for
exported keying material such as the MSK, EMSK and IV.
While EAP itself does not support lifetime negotiation, it would be
possible to specify methods that do. However, systems that rely on
such negotiation for exported keys would only function with these
methods. Also, there is no guarantee that the lifetime negotiated
within the EAP method would be compatible with backend authentication
server policy. In the interest of method independence and
compatibility with backend server implemenations, key management of
exported or derived keys SHOULD NOT be provided within EAP methods.
3.6. Key cache Synchronization
Key lifetime negotiation alone cannot guarantee key cache
synchronization. Even where a lower layer exchange is run
immediately after EAP in order to determine the lifetime of EAP
keying material, it is still possible for the authenticator to
purge all or part of the key cache prematurely (e.g. due to reboot or
need to reclaim memory).
The lower layer may utilize the Discovery phase 0 to improve key
cache synchronization. For example, if the authenticator manages the
key cache by deleting the oldest key first, the relative
creation time of the last key to be deleted could be advertised
within the Discovery phase, enabling the peer to determine whether
keying material had been prematurely expired from the authenticator
key cache."
Proposed Resolution:
Accept
Issue 373: Organization of Section 4
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date Submitted:
August 2, 2006
Reference:
http://lists.frascone.com/pipermail/eap/msg04476.html
Document: KEYING-14
Comment type:
'T'echnical
Priority: S
Section: 4
Rationale/Explanation of issue:
Section 4 states the following:
" With EAP, several mechanisms are available to reduce the latency in
handoff between authenticators:
[a] EAP pre-authentication. This utilizes EAP to pre-establish EAP
keying material on an authenticator prior to arrival of
the peer.
Use of pre-authentication within IEEE 802.11 is
described in
[8021XHandoff] and [IEEE-802.11i].
[b] Key caching. This mechanism enables an EAP peer to re-attach to
an
authenticator without requiring EAP re-authentication.
[c] Context transfer, such as is defined in [IEEE-802.11F] (now
deprecated) and [RFC4067]. Use of context
transfer for handoff
latency improvement is described in [IEEE-02-758].
[d] Proactive key distribution, such as is described in
[IEEE-02-758][IEEE-03-084] and [I-D.irtf-aaaarch-handoff].
The sections that follow discuss the security vulnerabilities
introduced by the above mechanisms."
However, while Section 4.1 does talk about Pre-authentication,
it is not made explicit how Sections 4.2 and 4.3 relate to the
security of Key Caching, Context Transfer or Proactive Key
distribution.
For example, issues of authorization and correctness do not
apply to mechanisms which utilize AAA to distribute authorizations.
Therefore Section 4.2 and 4.3 do not seem to relate to the
Pre-authentication or Proactive Key Distribution mechanisms,
only to Key Caching and Context Transfer.
[Bernard Aboba]
The proposed resolution is to replace Section 4 with
the following text:
"4. Handoff Vulnerabilities
Several mechanisms have been proposed for reducing handoff latency
within networks utilizing EAP. These include:
EAP pre-authentication
In EAP pre-authentication, an EAP peer pre-establishes EAP keying
material with an authenticator prior to arrival. EAP pre-
authentication only affects the timing of EAP authentication, but
does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
exchanges; Discovery (phase 0) and Secure Association Protocol
(phase 2) exchanges occur as described in Section 1.3. As a
result, the primary benefit is to enable EAP authentication to be
removed from the handoff critical path, thereby reducing latency.
Use of EAP pre-authentication within IEEE 802.11 is described in
[8021XPreAuth] and [IEEE-802.11i].
Proactive key distribution
In proactive key distribution, derived keying material and
authorizations are transported from the backend authentication
server to a candidate authenticator in advance of a handoff. As a
result, EAP (phase 1a) is not required, but the Discovery (phase
0), and Secure Association Protocol exchanges (phase 2) are still
necessary. Within the AAA exchange (phase 1b), authorization and
key distribution functions are typically supported, but not
authentication. Proactive key distribution is described in
[MishraPro], [IEEE-03-084] and [I-D.irtf-aaaarch-handoff].
Key caching
Caching of EAP keying material enables an EAP peer to re-attach to
an authenticator without requiring EAP (phase 1a) or AAA (phase 1b)
exchanges. However, Discovery (phase 0) and Secure Association
Protocol (phase 2) exchanges are still required. Use of key
caching within IEEE 802.11 is described in [IEEE-802.11i].
Context transfer
In context transfer schemes, keying material and authorizations are
transferred between a previous authenticator and a new
authenticator. This can occur in response to a handoff request by
the EAP peer, or in advance, as in proactive key distribution. As
a result, EAP (phase 1a) is eliminated, but not the Discovery
(phase 0) or Secure Association Protocol exchanges (phase 2). If a
secure channel can be established between the new and previous
authenticator without assistance from the backend authentication
server, then the AAA exchange (phase 1b) can be eliminated;
otherwise, it is still required, although it may be shortened.
Context transfer protocols are described in [IEEE-802.11F] (now
deprecated) and "Context Transfer Protocol (CXTP)" [RFC4067].
"Fast Authentication Methods for Handovers between IEEE 802.11
Wireless LANs" [Bargh] analyzes fast handoff techniques, including
context transfer mechanisms.
Token distribution
In token distribution schemes the EAP peer is provided with a
credential, subsequently enabling it to authenticate with one or
more additional authenticators. During the subsequent
authentications, EAP (phase 1a) is eliminated or shortened; the
Discovery (phase 0) and Secure Association Protocol exchanges
(phase 2) still occur, although the latter may be shortened. If
the token includes authorizations and can be validated by an
authenticator without assistance from the backend authentication
server, then the AAA exchange (phase 1b) can be eliminated;
otherwise it is still required, although it may be shortened.
Token-based schemes are described in [Token] and [I-D.friedman-ike-
short-term-certs].
The sections that follow discuss the security vulnerabilities
introduced by the above schemes.
4.1. EAP Pre-authentication
EAP pre-authentication differs from a normal EAP conversation
primarily with respect to the lower layer encapsulation. For
example, in [IEEE-802.11i], EAP pre-authentication frames utilize a
distinct Ethertype, but otherwise conform to the encapsulation
described in [IEEE-802.1X]. As a result, an EAP pre-authentication
conversation differs little from the model described in Section 1.3,
other than the introduction of a delay between phase 1 and phase 2.
EAP pre-authentication relies on lower layer mechanisms for discovery
of candidate authenticators. Where discovery can provide information
on candidate authenticators outside the immediate listening range,
and the peer can determine whether it already possesses valid keying
material with candidate authenticators, the peer can avoid
unnecessary EAP pre-authentications and can establish keying material
well in advance, regardless of the coverage overlap between
authenticators. However, if the peer can only discover candidate
authenticators within listening range and cannot determine whether it
can reuse existing key material, then peer may not be able to
complete EAP pre-authentication prior to connectivity loss or may
pre-authenticate multiple times with the same authenticator,
increasing backend authentication server load.
Since a peer may complete EAP pre-authentication with an
authenticator without eventually attaching to it, phase 2 may never
occur. As a result, an Accounting-Request signifying the start of
service may never be sent, or may only be sent with a substantial
delay after the completion of authentication.
As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA
exchange resulting from EAP pre-authentication differs little from an
ordinary exchange described in "RADIUS Support for EAP" [RFC3579].
For example, since in IEEE 802.11i an Association exchange does not
occur prior to EAP pre-authentication, the SSID is not known by the
authenticator at authentication time, so that an Access-Request
cannot include the SSID within the Called-Station-Id attribute as
described in [RFC3580] Section 3.20.
Since only the absence of an SSID in the Called-Station-Id attribute
distinguishes an EAP pre-authentication attempt, if the authenticator
does not always include the SSID for a normal EAP authentication
attempt, the backend authentication server may not be able to
determine whether a session constitutes an EAP pre-authentication
attempt, potentially resulting in authorization or accounting
problems. Where the number of simultaneous sessions is limited, the
backend authentication server may refuse to authorize a valid EAP
pre-authentication attempt or may enable the peer to engage in more
simultaneous sessions than they are authorized for. Where EAP pre-
authentication occurs with an authenticator which the peer never
attaches to, the backend accounting server may not be able to
determine whether the absence of an Accounting-Request was due to
packet loss or a session that never started.
In order to enable pre-authentication requests to be handled more
reliably, it is RECOMMENDED that AAA protocols explicitly identify
EAP pre-authentication. In order to suppress unnecessary EAP pre-
authentication exchanges, it is RECOMMENDED that authenticators
unambiguously identify themselves as described in Section 2.2.1.
4.2. Proactive Key Distribution
In proactive key distribution schemes, the backend authentication
server transports keying material and authorizations to an
authenticator in advance of the arrival of the peer. The
authenticators selected to receive the transported key material are
selected based on past patterns of peer movement between
authenticators known as the "neighbor graph". Since proactive key
distribution schemes typically only demonstrate proof of possession
of transported keying material between the EAP peer and
authenticator, the backend authentication server may not be provided
with proof that the peer successfully authenticated to an
authenticator. To compute the "neighbor graph" the backend
authentication server therefore may need to rely on a stream of
accounting messages without a corresponding set of authentication
exchanges.
In order to prevent compromise of one authenticator from resulting in
compromise of other authenticators, cryptographic separation needs
to be maintained between the keying material transported to each
authenticator. However, even where cryptographic separation is
maintained, an attacker compromising an authenticator may still
disrupt the operation of other authenticators. Since proactive key
distribution schemes typically only demonstrate proof of possession
of transported keying material between the EAP peer and
authenticator, the backend authentication server is typically not
provided with proof that the peer actually connected to an
authenticator. To compute the "neighbor graph" it therefore may be
necessary to rely on a stream of accounting messages without a
corresponding set of authentication exchanges to verify against.
As noted in [RFC3579] Section 4.3.7, in the absence of spoofing
detection within the AAA infrastructure, it is possible for EAP
authenticators to impersonate each other. By forging NAS
identification attributes within accounting messages, an attacker
compromising one authenticator could corrupt the neighbor graph,
tricking the backend authentication server into transporting keying
material to arbitrary authenticators. While this would not enable
recovery of EAP keying material without breaking fundamental
cryptographic assumptions, it could enable fraudulent charges or
allow an attacker to disrupt service by increasing load on the
backend authentication server or thrashing the authenticator key
cache.
Since proactive key distribution requires the distribution of derived
keying material to candidate authenticators, the effectiveness of
this scheme depends on the ability of backend authentication server
to anticipate the movement of the EAP peer. As described in [Mishra-
Pro], knowledge of the "neighbor graph" can be established via static
configuration or analysis of accounting messages. Since proactive
key distribution relies on backend authentication server knowledge of
the "neighbor graph" it is most applicable to intra-domain handoff
scenarios. However, in inter-domain handoff where there may be many
authenticators, the "neighbor graph" may not be readily derived on
the backend authentication server, since peers may frequently connect
to authenticators that have not previously been encountered.
Since proactive key distribution schemes typically require
introduction of server-initiated messages as described in [RFC3576]
and [I-D.irtf-aaaarch-handoff], security issues described in
[RFC3576] Section 5 are applicable, including authorization (Section
5.1) and replay detection (Section 5.4) problems.
4.3. AAA Bypass
Fast handoff techniques which enable elimination of the AAA exchange
(phase 1b) differ fundamentally from typical network access scenarios
(dial-up, wired LAN, etc.) which include user authentication as well
as authorization for the offered service. Where the AAA exchange
(phase 1b) is omitted, authorizations and keying material are not
provided by the backend authentication server, and as a result they
need to be supplied by other means. This section describes some of
the implications.
4.3.1. Key Transport
Where transported keying material is not supplied by the backend
authentication server, it needs to be provided by another party
authorized to access that keying material. As noted in Section 1.5,
only the EAP peer, authenticator and server are authorized to possess
transported EAP keying material. Since EAP peers do not trust each
other, if the backend authentication server does not supply
transported keying material to a new authenticator, it can only be
provided by a previous authenticator.
As noted in Section 1.5, the goal of the EAP conversation is to
derive session keys known only to the peer and the authenticator. If
EAP keying material is replicated between a previous authenticator
and a new authenticator, then the previous authenticator may
potentially know the session keys used between the peer and new
authenticator. Also, the new authenticator may potentially know the
session keys used between the peer and the previous authenticator.
If a one-way function is used to derive the keying material to be
transported to the new authenticator, then the new authenticator is
not longer able to know previous session keys without breaking a
fundamental cryptographic assumption.
4.3.2. Authorization
As a part of the authentication process, the backend authentication
server determines the user's authorization profile and transmits the
authorizations to the authenticator along with the transported EAP
key material. Typically, the profile is determined based on the user
identity, but a certificate presented by the user may also provide
authorization information.
The backend authentication server is responsible for making a user
authorization decision, which requires answering the following
questions:
[a] Is this a legitimate user of this network?
[b] Is the user allowed to access this network?
[c] Is the user permitted to access this network on this day and at
this time?
[d] Is the user within the concurrent session limit?
[e] Are there any fraud, credit limit, or other concerns indicating
that access should be denied?
[f] If access is to be granted, what are the service parameters
(mandatory tunneling, bandwidth, filters, and so on) to be
provisioned for the user?
While the authorization decision is in principle simple, the
distributed decision making process may add complexity. Where
brokers or proxies are involved, all of the AAA entities in the chain
from the authenticator to the home backend authentication server are
involved in the decision. For example, a broker can deny access even
if the home backend authentication server would allow it, or a proxy
can add authorizations (e.g., bandwidth limits).
Decisions can be based on static policy definitions and profiles as
well as dynamic state (e.g. time of day or concurrent session
limits). In addition to the Accept/Reject decisions made by AAA
entities, service parameters or constraints may be communicated to
the authenticator.
The criteria for Accept/Reject decisions or the reasons for choosing
particular authorizations are typically not communicated to the
authenticator, only the final result. As a result, the authenticator
has no way to know what the decision was based on. Was a set of
authorization parameters sent because this service is always provided
to the user, or was the decision based on the time of day and the
capabilities of the authenticator?
4.3.3. Correctness
When the AAA exchange (phase 1b) is bypassed, several challenges
arise in ensuring correct authorization:
[a] Theft of service. Bypassing the AAA exchange (phase 1b) should not
enable a user to extend their network access or gain access to
services they are not entitled to.
[b] Consideration of network-wide state. Handoff techniques should not
render the backend authentication server incapable of keeping track
of network-wide state. For example, a backend authentication
server may need to keep track of simultaneous user sessions.
[c] Elevation of privilege. Backend authentication servers often
perform conditional evaluation, in which the authorizations
returned in an Access-Accept message are contingent on the
authenticator or on dynamic state such as the time of day. In this
situation, bypassing the AAA exchange could enable unauthorized
access unless the restrictions are explicitly encoded within the
authorizations provided by the backend authentication server.
A handoff mechanism that provides proper authorization is said to be
"correct". One condition for correctness is as follows:
For a handoff to be "correct" it MUST establish on the new
authenticator the same authorizations as would have been created
had the new authenticator completed a AAA conversation with the
backend authentication server.
A properly designed handoff scheme will only succeed if it is
"correct" in this way. If a successful handoff would establish
"incorrect" authorizations, it is preferable for it to fail. Where
the supported services differ between authenticators, a handoff that
bypasses the backend authentication server is likely to fail.
[RFC2865] section 1.1 states:
A authenticator that does not implement a given service MUST NOT
implement the RADIUS attributes for that service. For example, a
authenticator that is unable to offer ARAP service MUST NOT
implement the RADIUS attributes for ARAP. A authenticator MUST
treat a RADIUS access-accept authorizing an unavailable service as
an access-reject instead.
This behavior applies to attributes that are known, but not
implemented. For attributes that are unknown, [RFC2865] Section 5
states:
A RADIUS server MAY ignore Attributes with an unknown Type. A
RADIUS client MAY ignore Attributes with an unknown Type.
In order to perform a correct handoff, if a new authenticator is
provided with RADIUS authorizations for a known but unavailable
service, then it MUST process these authorizations the same way it
would handle a RADIUS Access-Accept requesting an unavailable
service; this MUST cause the handoff to fail. However, if a new
authenticator is provided with authorizations including unknown
attributes, then these attributes MAY be ignored. The definition of
a "known but unsupported service" MUST encompass requests for
unavailable security services. This includes vendor-specific
attributes related to security, such as those described in [RFC2548].
Although it may seem somewhat counter-intuitive, failure is indeed
the "correct" result where a known but unsupported service is
requested.
Presumably a correctly configured backend authentication server would
not request that an authenticator provide a service that it does not
implement. This implies that if the new authenticator were to
complete a AAA conversation, it would be likely to receive different
service instructions. Failure of the handoff is the desired result
since it will cause the new authenticator to go back to the backend
server in order to receive the appropriate service definition.
Handoff mechanisms which bypass the backend authentication server are
most likely to be successful when employed in a homogeneous
deployment within a single administrative domain. In a heterogeneous
deployment, the backend authentication server may return different
authorizations depending on the authenticator making the request, in
order to make sure that the requested service is consistent with the
authenticator capabilities. Where a backend authentication server
would send different authorizations to the new authenticator than
were sent to a previous authenticator, transferring authorizations
between the previous authenticator and the new authenticator will
result in incorrect authorization.
Virtual LAN (VLAN) support is defined in [IEEE-802.1Q]; RADIUS
support for dynamic VLANs is described in [RFC3580] and [RFC4675].
If some authenticators support dynamic VLANs while others do not,
then attributes present in the Access-Request (such as the NAS-Port-
Type, NAS-IP-Address, NAS-IPv6-Address and NAS-Identifier) could be
examined by the backend authentication server to determine when VLAN
attributes will be returned, and if so, which ones. However, if the
backend authenticator is bypassed, then a handoff occurring between
authenticators supporting different VLAN capabilities could result in
a user obtaining access to an unauthorized VLAN (e.g. a user with
access to a guest VLAN being given unrestricted access to the
network).
Similarly, a handoff between an authenticator providing
confidentiality and another that does not should fail, since if the
handoff were successful, the user would be moved from a secure to an
insecure channel without permission from the backend authentication
server."
Proposed Resolution: Accept
Issue 374: NITs
Submitter name: M. Vanderveen
Submitter email address: mvandrvn@yahoo.com
Date Submitted: July 18, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04463.html
Document: NETSEL-04
Comment type: Editorial
Priority: S
Section: Various
Rationale/Explanation of issue:
The draft is a good summary of the network selection problem.
I wonder if there is a plan to update this document after the various SDOs
make some progress in this area. Overall it looks good to go.
Some editorials:
- Page 4: "The selection is dependent upon for example the
authentication credentials for the user / device and the roaming
agreements." If there are no other factors that selection is
dependent on
(besides that mentioned in the sentence immediately following this one),
then
remove the "for example".
- Page 4: "The selection will be dependent upon for
example the support for an access technology by the device and
availability of such access technology based networks."
Same comment as above.
- Page 15: "APs must support 802.1X pre-authentication (optional
in IEEE 802.11i) ". The year of this standard should be specified,
just like it is earlier in that sentence. What is meant here is
probably IEEE 802.11i-2004.
- Page 20: "solutions for problem of network selection" -- insert "the"
before "problem".
-Page 20: "more than one points" -- replace "points" with "point"
[Jari Arkko] Everything is addressed except this:
- Page 15: "APs must support 802.1X pre-authentication (optional
in IEEE 802.11i) ". The year of this standard should be specified,
just like it is earlier in that sentence. What is meant here is
probably IEEE 802.11i-2004.
- Page 20: "solutions for problem of network selection" -- insert "the"
before "problem".
-Page 20: "more than one points" -- replace "points" with "point"
Proposed Resolution: Accept
Issue 375: Comments
Submitter name: Yoshihiro Ohba
Submitter email address: yohba@tari.toshiba.com
Date Submitted: July 20, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04465.html
Document: NETSEL-04
Comment type: Editorial
Priority: S
Section: 3.1
Rationale/Explanation of issue:
One minor comment on Section 3.1:
" The PANA protocol [17] has a mechanism to advertise and select "ISPs"
through the exchange of the ISP-Information AVP in its initial
exchange."
" The use of
other network identifiers than domain names is also possible, for
instance the PANA protocol uses an a free form string and an SMI
Network Management Private Enterprise Code [17], or Mobile Network
Codes embedded in NAIs as specified in 3GPP."
The description is true for the current version of PANA specification.
However, the latest discussion in the PANA WG will make the network
selection functionality be specified in a separate document other than
specifying it in the PANA base specification.
[Jari Arkko]
But latest PANA document (ietf-pana-pana) no longer has
ISP-Information or NAP-Information, so I think further
developments have changed the situation again. Here's the edit:
Remove text:
The PANA protocol [I-D.ietf-pana-pana] has a mechanism to advertise
and select "ISPs" through the exchange of the ISP-Information AVP in
its initial exchange.
Change text
The use of other network identifiers
than domain names is also possible, for instance the PANA protocol
uses an a free form string and an SMI Network Management Private
Enterprise Code [I-D.ietf-pana-pana], or Mobile Network Codes
embedded in NAIs as specified in 3GPP.
=>
The use of other network identifiers
than domain names is also possible.
And remove the reference too.
Proposed Resolution: Accept
Issue 376: Overall Comments
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date Submitted: August 8, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04477.html
Document: NETSEL-04
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
Organizational Issues
This document has some organizational issues. Section 1 describes when
the realm selection problem becomes relevant but since the problem is
defined in Section 2, the reader is left without an understanding of how
the problem manifests itself in those situations. To provide some
context, I think that some text is needed in Section 1 for each of the
first two bullets, describing the issues that can occur. The third bullet
does include discussion of issues.
In order to parallel the problems listed in Section 2, I was expecting a
section on "Payload routing" as well as one on "realm capability
discovery". Instead, I found found Sections 2.4 and 2.5 which do not seem
to correspond to one of the listed problems. I think Section 2.5 does
relate to the "capability discovery" problem so that perhaps it should be
renamed. I am not clear why Section 2.4 belongs where it is; I'd suggest
it be moved out of Section 2.
Section 2.3.1 seems to end just as it got started. This section seems to
be going somewhere important so I think it needs to be fleshed out. For
example, it could talk about how "default" versus "default free" proxies
in AAA routing.
Section 3 interrupts the flow of the document, and so I think it might be
best moved to an Appendix.
Section 4 is actually quite important, since one of the goals of this
effort was to address architectural problems with existing solutions.
However, this section does not talk much about scalability issues.
Terminology
The abstract refers to the "realm discovery and selection problem", as
do sections 1 and 2. However, the title of the document is still "Network
Discovery and Selection Problem". Also Section 3 uses other terms such as
"access network discovery", "network discovery process", "network
selection", without defining them. If you are going to use these terms
later on, I think that either new definitions are needed in Section 1.1,
or the terminology should be harmonized with the existing definitions.
Currently the terms "Access Technology Selection" and "Bearer Selection"
do not appear to be referenced outside Section 1.1.
References
Two reference styles are used. Most of the time the straight number style
is used (e.g. [34]). However, in Section 3.3, the author name is also
given (e.g. "Ahmavaara, Haverinen and Pichna [34]"). I would suggest
using a consistent style. Personally, I am not very fond of the number
style of referencing, particularly when RFCs are being referenced.
[Bernard Aboba] More detail on the proposed issues and resolutions are given below:
Here are more details on the issues and proposed changes:
Abstract
The so called network discovery and selection problem affects network
access, particularly in the presence of multiple available wireless
accesses and roaming. This problem has been the subject of
discussions in various standards bodies. This document summarizes
the discussion held about this problem in the Extensible
Authentication Protocol (EAP) working group at the IETF. The problem
is defined and divided into subproblems, and some constraints for
possible solutions are outlined. The document also provides a
discussion of the limitations of certain classes of solution,
including some that have been previously defined.
Suggest changing to:
When multiple access network are available, roaming
users may have difficulty in selecting which network
to connect to, and how to authenticate with that network.
This document defines the network discovery and
selection problem, dividing it into multiple sub-problems.
Some constraints on potential solutions are outlined, and
the limitations of several solutions (including existing ones)
are discussed.
1. Introduction
The network discovery and selection problem affects network access
and wireless access networks in particular. Aspects of the problem
will appear when any of the following conditions are true:
[BA] Suggest changing to:
When multiple access network are available, roaming
users may have difficulty in selecting which network
to connect to, and how to authenticate with that network.
The problem arises when any of the following conditions are
true:
[BA] The next few paragraphs state conditions under which the problem
can occur, but don't clearly state what bad things will happen in
each circumstance:
o There is more than one available network attachment point, and the
different attachment points may have different characteristics or
belong to different operators. In the case of virtual operators,
access network infrastructure including e.g. the access points can
be shared by multiple operators. In order to choose between the
network attachment points, it may be helpful to determine which
realms are supported and the capabilities access network
supporting those realms. Otherwise, the mobile station might
frequently roam into networks that are not able to satisfy the
roaming connectivity needs or provide services the mobile station
(and the subscriber) are seeking for. This would of course lower
the general quality of offered services.
o The user has multiple sets of credentials. For instance, the user
could have one set of credentials from a public service provider
and set from the user's employer. In this case it may be helpful
to provide additional information to enable the correct credential
set to be determined. Otherwise, it could happen that for example
a network access authentication repeatedly fails because of
incorrectly selected and offered set of credentials.
o There is more than one way to provide roaming between the visited
realm used for access and user's home realm, and service
parameters or pricing differs between them. For instance, the
visited access realm could have both a direct relationship with
the home realm and an indirect relationship through a roaming
consortium. In some scenarios, current AAA protocols may not be
able to route the requests to the home realm unaided, just based
on the domain in the given Network Access Identifier (NAI)
[RFC4282]. In addition, payload packets can get routed or
tunneled differently, based on the roaming relationship path in
use. This may have an impact on the available services or their
pricing.
[BA] Suggest changing to:
o More than one network attachment point is available, and the
attachment points differ in capability or belong to different
operators. In this case, a roaming user may have difficulty
determining which attachment points offering the desired services
it can successfully authenticate to. In order to choose between
multiple attachment points, it can be helpful to determine which
realms are supported and the capabilities that the networks support
o The user has multiple sets of credentials. In this case, the
user may not be able to determine which credentials to use with
which attachment point, or even whether any credentials it
possesses will allow it to authenticate successfully. This
can result in multiple unsuccessful authentication attempts
for each attachment point, wasting valuable time and resulting
in user frustration. For example, the user
could have one set of credentials from a public service provider
and set from an employer. In order to choose between multiple
attachment points, it can be helpful to provide additional
information to enable the correct credentials to be determined.
o There are multiple potential roaming paths between the visited
realm and the user's home realm, and service parameters or
pricing differs between them. In this case, the access network
may not be able to determine the roaming path that best matches
the user's preferences. This can lead to the user being
charged more than necessary, or not obtaining the desired
services. For example, the visited access realm could have
both a direct relationship with the home realm and an indirect
relationship through a roaming consortium. Current AAA protocols
may not be able to route the access request to the home AAA sever
purely based on the realm within the Network Access Identifier (NAI)
[RFC4282]. In addition, payload packets can be routed or
tunneled differently, based on the roaming relationship path.
This may have an impact on the available services or their
pricing.
[BA] The next paragraph could be cleaned up a bit:
In Section 2 the network discovery and selection problem is defined
and divided into subproblems, and some design issues for possible
solutions are outlined in Section 3. Section 4 gives the conclusions
and some suggestions on how to proceed for the rest. Appendix A
discusses existing mechanisms which help solve at least parts of the
problem. The terms "network" and "realm" have sometimes been used
interchangeably within the context of selection and discovery. It
should be noted that a realm can be reachable from more than one
access network types and selection of a realm may not imply certain
network capabilities.
Suggest changing to:
In Section 2 the network discovery and selection problem is defined
and divided into subproblems, and some potential solution constraints
are outlined in Section 3. Section 4 provides conclusions
and suggestions for future work. Appendix A
discusses existing solutions to portions of the problem.
[BA] The following sentences belong in the terminology section:
The terms "network" and "realm" have sometimes been used
interchangeably within the context of selection and discovery. It
should be noted that a realm can be reachable from more than one
access network types and selection of a realm may not imply certain
network capabilities.
Section 1.1
Decorated NAI
A NAI specifying a source route. See RFC4282 [RFC4282] Section
2.7 for more information.
[BA] "RFC4282" -> "RFC 4282"
Realm
Realm portion of an NAI [RFC4282].
[BA] Change to "The realm portion of..."
Network Selection
This refers to selection of an operator/ISP in order to access the
network. The process of network selection can occur either at the
beginning of a new session or during a handoff in case the user is
mobile. The selection is dependent upon for example the selection
of realm for the operator, authentication credentials for the
user/device and the roaming agreements. The realm Selection can
in turn also depend upon Access Technology Selection and/or Bearer
Selection.
[BA] I don't understand how network selection can occur at the beginning
of a session -- doesn't it need to occur before the session begins?
Also, I don't understand how network selection can occur during an L2
handoff. The "realm" of an operator doesn't make sense -- isn't a
realm is a characteristic of the home AAA server? Suggest rewriting to:
Selection of an operator/ISP for network access. Network Selection
occurs prior to network access authentication.
Network Discovery
This refers to a mechanisms that a node uses to discover available
networks prior the realm selection takes place. The discovery
process may be passive or active from a node point of view.
Typically the discovery mechanism varies depending on the access
technology. It is also possible that there are multiple discovery
mechanisms within one access technology depending on the network
deployment.
[BA] Suggest rewriting to:
The mechanism used to discover available networks. The discovery
mechanism may be passive or active, and depends on the access
technology. In passive network discovery, the node listens for
network announcements; in active network discovery the node
solicits network announcements. It is possible for an access
technology to utilize both passive and active network discovery
mechanisms.
Realm Selection
This refers to selection of the realm of the operator/ISP used to
access the network.
[BA] This doesn't make sense to me -- the realm is a characteristic of
the home AAA server. Suggest rewriting to:
The selection of the realm (and corresponding NAI) used to access the
network.
Network Access Server
The Network Access Server (NAS) is the device that clients connect
to in order to get access to the network. In PPTP terminology,
this is referred to as the PPTP Access Concentrator (PAC), and in
L2TP terminology, it is referred to as the L2TP Access
Concentrator (LAC). In IEEE 802.11, it is referred to as an
Access Point.
[BA] I would change to:
Network Access Server
The device that peers connect to in order to obtain access to the
network. In PPTP terminology,
this is referred to as the PPTP Access Concentrator (PAC), and in
L2TP terminology, it is referred to as the L2TP Access
Concentrator (LAC). In IEEE 802.11, it is referred to as an
Access Point.
Section 2
This problem spans multiple protocol layers and has been the subject
of discussions in IETF, 3GPP, and IEEE. This document summarizes the
discussion held about this problem in the Extensible Authentication
Protocol working group at IETF. There are a set of somewhat
orthogonal problems being discussed under the rubric of "network
discovery and selection".
[BA] Suggest changing to:
The network discovery and selection problem can be broken down into
multiple sub-problems. These include:
o The problem of "discovery of points of attachment". This is the
problem of discovering points of attachment available in the
vicinity, and the capabilities associated with these points of
attachment.
o The problem of "Identifier selection". This is the problem of
selecting which identity (and credentials) to use to authenticate
in a given point of attachment to the network.
o The problem of "AAA routing" which involves figuring out how to
route the authentication conversation originating from the
selected identity back to the home realm.
o The problem of "Payload routing" which involves figuring how the
payload packets are routed, where more advanced mechanisms than
destination-based routing is needed. However, while being an
interesting problem, this document does not attempt to do any
analysis or suggestions on it.
[BA] Suggest changing to:
o Discovery of points of attachment. This involves the discovery
of points of attachment in the vicinity, as well as their
capabilities.
o Identifier selection. This involves selection of the
NAI (and credentials) used to authenticate to the selected
ponit of attachment.
o AAA routing. This involves routing of the AAA
conversation back to the home AAA server, based on the realm
of the selected NAI.
o Payload routing. This involves the routing of data packets, in
the situation wh ere mechanisms more advanced than destination-based
routing are required. While this problem is interesting, it is not
discussed further in this document.
o The problem of "network capability discovery". This is the
problem of discovering the capabilities of a particular
destination network. For example, it may be important to know
whether a given network supports enrollment, what the charges are,
etc.
[BA] I'm not sure what "network capability discovery" means. Is this
about discovery the capabilities of the access network, or of the
home realm? On the assumption that this is about the home realm,
I suggest that the text be changed to the following:
o Realm capability discovery. This involves discovering the
capabilities of a home AAA server, such as whether the
home AAA server supports enrollment.
2.1. Discovery of the Point of Attachment to the Network
"The discovery of points of attachment" problem has been extensively
studied, see for instance the IEEE specifications on 802.11 wireless
LAN beaconing and probing process, studies (such as [Fixingapsel]) on
the effectiveness of these mechanisms, specifications on GSM network
discovery, results of the IETF Seamoby WG, and so on.
Traditionally, the problem of discovering available point of
attachment has been handled as a part of the link layer attachment
procedures, or through out-of-band mechanisms.
[BA] The above two paragraphs could be combined and tightened up. See
suggests below.
RFC 2194 [RFC2194] describes the pre-provisioning of dialup roaming
clients, which typically included a list of potential phone numbers,
updated by the provider(s) with which the client had a contractual
relationship. RFC 3017 [RFC3017] describes the IETF Proposed
Standard for the Roaming Access XML DTD. This covers not only the
attributes of the Points of Presence (POPs) and Internet Service
Providers (ISPs), but also hints on the appropriate NAI to be used
with a particular POP. The RFC supports dial-in and X.25 access, but
has extensible address and media type fields.
In IEEE 802.11 WLANs, the Beacon/Probe Request/Response mechanism
provides a way for Stations to discover Access Points (APs), as well
as the capabilities of those APs. Among the Information Elements
(IEs) included within the Beacon and Probe Response is the SSID, a
non-unique identifier of the network to which an Access Point is
attached. By combining network identification along with
capabilities discovery, the Beacon/Probe facility provides the
information required for both network discovery and roaming decisions
within a single mechanism.
[BA] The Beacon/Probe Request provides the SSID, as well as the capabilities
of individual APs. It does not provide for discovery of network wide
capabilities, per se. For example, the capabilities of all APs advertising
an SSID need not be identical. So while this mechanism might enable discovery
of a network, it does not enable discovery of the capabilities of that
network, only the discovery of the capabilities of selected APs within that
network.
As noted in [Velayos], the IEEE 802.11 Beacon mechanism does not
scale well; with a Beacon interval of 100ms, and 10 APs in the
vicinity, approximately 32 percent of an 802.11b AP's capacity is
used for beacon transmission. In addition, since Beacon/Probe
Response frames are sent by each AP over the wireless medium,
stations can only discover APs within range, which implies
substantial coverage overlap for roaming to occur without
interruption.
A number of enhancements have been proposed to the Beacon/Probe
Response mechanism in order to improve scalability and roaming
performance. These include allowing APs to announce capabilities of
neighbor APs as well as their own, as proposed in IEEE 802.11k
[IEEE.802.11k].
Typically scalability enhancement mechanisms attempt to get around
Beacon/Probe Response restrictions by sending advertisements at the
higher layers which are enabled once the station has associated with
an AP and gained IP connectivity. Since these mechanisms run over
IP, they can utilize IP facilities such as fragmentation, which the
link layer mechanisms may not always be able to do. For instance, in
IEEE 802.11, Beacon frames cannot use fragmentation because they are
multicast frames, and multicast frames are not acknowledged in
802.11.
Another issue with the Beacon/Probe Request/Response mechanism is
that it is either insecure or its security can be assured only after
already attaching to this particular network.
When considering access systems such as 802.11 WLANs networks it is
important to take into account different deployment options. For
example, a WLAN deployment may include a number of VLANs in order to
separate UAM (Universal Access Method) and 802.1X [IEEE.8021X] users
or users accessing network from different geographical/organizational
locations. It is also possible that a larger network spans multiple
ESSes and prefixes. It is also possible that users authenticating to
different realms are able to do so via the same SSID.
[BA] This paragraph needs to tie the various options back to the different
sub-problems.
Suggest rewriting to:
Traditionally, discovery of points of attachment has been handled
by link layer or out-of-band mechanisms. For example, the
IEEE 802.11 specification [IEEE-802.11] provides support for both
passive (Beacon) and active (Probe Request/Response) discovery
mechanisms; [Fixingapsell] studied the effectiveness of these
mechanisms. The GSM specifications [GSM] also provide for
discovery of points of attachment, as does the CARD [RFC4066]
protocol developed by the IETF SEAMOBY WG.
RFC 2194 [RFC2194] describes the pre-provisioning of dialup roaming
clients, which typically included a list of potential phone numbers,
updated by the provider(s) with which the client had a contractual
relationship. RFC 3017 [RFC3017] describes the IETF Proposed
Standard for the Roaming Access XML DTD. This covers not only the
attributes of the Points of Presence (POPs) and Internet Service
Provi