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