eap Mailing List: Re: Issue 305: Appendix Cleanup

[Jari Arkko (jari.arkko]

Looks good to me. --Jari

Bernard Aboba wrote:

> > Ok for me. When integrating A & D to section 2, make
> > sure the text represents these as examples (not
> > normative).
> >    
>
> In working this through, I think it might be easier for now to combine A &
> D into a single Appendix B.  Here is a strawman:
>
> 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]
>
>
>
>