Network Working Group M. Vanderveen Request for Comments
Contents
1. 0 1 2 3 01 258 4 5 6 17 8090 1 2 3 4 56 7 08 90 102 3 4 5 61 48 9 00 Code Identifier Length Type EAP SAKE Version 2 Session ID Subtype 2 AT_SPI_S Length SPI S AT_IV Length Initialization Vector AT_ENCR_DATA Length Encrypted Data AT_MSK_LIFE Length MSK Lifetime AT_MIC_S Length 18 MIC_S The semantics of the fields is described below Code 1 for Request Identifier A random number Length The length of the entire Vanderveen Soliman See 1 EAP packet Informationa in octets 1 Page 30 RFC 4763 EAP SAK November 2006 E Type EAP SAKI E Version 2 Session ID A number matching all other EAP messages in this EAP session Subtype 2 for SAKE Confirm AT_SPI_S The value field of this attribute contains the Server chosen ciphersuite SPI_S parameter The AT_SPI_S attribute is optional in the EAP Request SAKE Confirm AT_IV This attribute is optional to use in this message The valu field of this attribute contains the Initialization Vector that is used with the encrypted data following AT_ENCR_DATA This attribute is optional to use in this message Th ncrypted data if present2. such as derivation of application with other parties Informat Level 3 contains session keys such as Transient EAP Keys TEK Master Session Key MSK and Extended MSK EMSK TEKs are keys for use local to the EAP method only They are derived from the SMS A and the nonces using the EAP SAKE KDF They are partitioned into a 16 byte TEK Auth used to compute the MICs and a 16 byte TEK Cipher used to encrypt selected attributes Since the SMS is fresh so are the derived TEKs Root Secret A Root Secret B pre shared secret pre shared secret V V SAKE Master Secret lt RAND_S gt SAKE Master Secret SMS A l SMS B lt RAND_P gt V V Transient EAP Keys lt H gt Session Keys TEK Auth TEK Cipher lt gt MSK EMSK Figure 6 Key Hierarchy for the EAP SAKE Method On another branch of level 3 of the key hierarchy are the MSK and EMSK each mandated to be 64 bytes long They are derived from the SMS B and the nonces using the EAP SAKE KDF Again since the SMS is fresh so are the derived MSK EMSK The MSK is meant to be exported and relayed to other parties The EMSK is reserved for future use specific keys and is not shared ional Page 14 REC 4763 EAP SAK E November 2006 T The EAP SAKE key material is summarized in the table below
3. Key Size Scope Lifetime Use bytes Root Secret A 16 Peer Server Device Derive TEK Root Secret B 16 Peer Server Devic Derive MSK EMSK TEK Auth 16 Peer Server MSK Life Compute MICs TEK Cipher 16 Peer Server MSK Life Encrypt attribute MSK 64 Peer Server MSK Life Derive keys for Authenticator lower layer use EMSK 64 Peer Server MSK Life Reserved A key name format is not provided in this version Since this version of EAP SAKE does not support fast re authentication the lifetime of the TEKs is to extend only until the next EAP mutual authentication The MSK lifetime dictates when the next mutual authentication is to take place The Server MAY convey the MSK lifetime to the Peer in the AT_MSK_LIFE attribute Note that EAP SAKE does not support key lifetime negotiation The EAP SAKE Method Id is the contents of the RAND_S field from the AT_RAND_S attribute followed by the contents of the RAND_P field in the AT_RAND_P attribute 3 2 6 Key Derivation 3 2 6 1 Key Derivation Function For the rest of this document KDF X denotes the EAP SAKE Key Derivation Function whose output is X bytes This function is the pseudo random function of IEEE802 111 T The function takes three strings of bytes of arbitrary lengths a Key a Label and a Msg and outputs a string Out of length X bytes as follows Out KDF X Key Label
4. 5 Upon receipt of a EAP Response SAKE Auth Reject message th Server sends an EAP Failure message back to the Peer Vanderveen amp Soliman Informational Page 10 November 2006 E RFC 4763 EAP SAK 3 2 3 Identity Management It may be advisable to assign a temporary identifier TempID to a Peer when user anonymity is desired The TempID is delivered to the Peer in the EAP Request SAKE Confirm message The TempID follows the format of any NAI NAI and is generated by the EAP Server that engages in the EAP SAKE authentication task with the Peer EAP servers SHOULD be configurable with TempID spaces that can be distinguished from the permanent identity space For instance a specific realm could be assigned for TempIDs e g tmp example biz A TempID is not assigned an explicit lifetime The TempID is valid until the Server requests the permanent identifier or the Peer triggers the start of a new EAP session by sending in its permanent identifier A Peer MUST be able to trigger an EAP session at any time using its permanent identifier A new TempID assigned during a successful EAP session MUST replace the existing TempID for future transactions between the Peer and the Server Note that the delivery of a TempID does not imply that the Server considers the Peer authenticated the Server still has to check the MIC in the EAP Response SAKE Confirm messag
5. n server and 3 2 Protocol Operation EAP SAKE uses four messages consisting of two EAP request respons exchanges The EAP Success and EAP Failure messages shown in the figures are not part of the EAP SAKE method As a convention method attributes are named AT_XX where XX is the name of the parameter the attribute value is set to 3 2 1 Successful Exchange A successful EAP SAKE authentication exchange is depicted in Figure 1 The following steps take place Peer Server EAP Request SAKE Challenge AT_RAND_S AT_SERVERID 1 lt EAP Response SAKE Challenge AT_RAND_P AT_PEERID AT_SPI_P AT_MIC_P 2 gt EAP Request SAKE Confirm AT_SPI_S AT_ENCR_DATA AT_MIC_S 3 lt EAP Response SAKE Confirm AT_MIC_P 4 gt EAP Success J lt Figure 1 EAP SAKE Authentication Procedure with ciphersuite negotiation 1 The EAP server sends the first message of the EAP SAKE exchange This message is an EAP Request message of type SAKE and subtype Challenge The EAP Request SAKE Challenge message contains the attributes AT_RAND_S whose value is a nonce freshly generated Vanderveen Soliman I nformational Page 5 RFC 4763 EAP SAK E November 2006 by the Server and AT_SERVERID which carries an identifier of the Server a fully qualified domain name such as the r
6. Normal EAP SAKE authentication follows Figure 5 Server Is Given a TempID as Peer Identity Server Requires a PermID 1 The Peer or the Authenticator on behalf of the Peer sends an EAP Request message of type Identity and includes the TempID 2 The Server requires a PermID instead so it sends an EAP Request message of type SAKE and subtype Identity with attributes AT_PERM_ID_REQ and AT_SERVERID E 3 The Peer sends an EAP Response message of type SAKE and subtype Identity containing the attribute AT_PEERID carrying the Peer PermID 3 2 5 Key Hierarchy EAP SAKE uses a thr level key hierarchy Level 1 contains the pre shared secret called Root Secret This is a 32 byte high entropy string partitioned into the Root Secret A part 16 bytes and the Root Secret B part 16 bytes Vanderveen amp Soliman Informational Page 13 RFC 4763 Vanderveen Soliman EAP S Level 2 contains the key derivatio AK E November 2006 Ey E n key called the SAKE Master Secret SMS SMS A is derived from th Server nonces using the EAP SAKE K Similarly for SMS B The SMS is k and is not made known to other par Ey E Root Secret A key and the Peer and ey Derivation Function KDF and nown only to the Peer and Server ties
7. Di November 2006 E separate from the corresponding keys derived in the previous exchange Therefore compromise of MSK or EMSK on one exchange does not compromise the MSK and EMSK of previous or subsequent exchanges between a Peer and a Server 13 Identity Protection As seen from Section 3 2 3 the Server may assign a temporary NAI to a Peer in order to achieve user anonymity This identifier may be used by the Peer the next time it engages in an EAP SAKE authentication phase with the Server The TempID is protected by sending it encrypted within an AT_ENCR_DATA attribute and signed by the Server with a MIC Thus an eavesdropper cannot link the original PermID that the Peer first sends e g on power up to any subsequent TempID values sent in the clear to the Server The Server and Peer MAY be configured such that only TempID identities ar xchanged after one initial EAP SAKE phase that uses the Peer permanent identity In this case in order to achieve maximum identity protection the TempID SHOULD be stored in non volatile memory in the Peer and Server Thus compliance with this document does not preclude or mandate Peer identity protection across the lifetime of the Peer 14 Channel Binding The Server identifier and Peer identifier MAY be sent in the SAKE Challenge messages However since there is no established authentication key at the time of the first message
8. Length The total number of octets in the attribute including Type and Length Value Attribute specific Vanderveen amp Soliman Informational Page 23 RFC 4763 EAP SAKI November 2006 E The following attribute types are allocated Attr Name Length bytes Skippable Description AT_RAND_S 18 No Server Nonce RAND_S AT_RAND_P 18 No Peer Nonce RAND_P AT_MIC_S 10 No Server MIC AT_MIC_P 10 No Peer MIC AT_SERVERID variable No Server FODN AT_PEERID variable No Peer NAI tmp perm AT_SPI_S variable No Server chosen SPI SPI_S AT_SPI_P variable No Peer SPI list SPI_P AT_ANY_ID_REQ 4 No Requires any Peer Id tmp perm AT_PERM_ID_REQ 4 No Requires Peer s permanent Id NAI AT_ENCR_DATA Variable Yes Contains encrypted attributes AT_IV Variable Yes IV for encrypted attributes AT_PADDING 2 to 18 Yes Padding for encrypted attributes AT_NEXT_TMPID variable Yes TempID for next EAP SAKE phase AT_MSK_LIFE 6 Yes MSK Lifetime in seconds Vanderveen Soliman Informational Page 24 RFC 4763 EAP SAKE November 2006 3 3 3 Use of AT_ENCR_DATA Attribute An exa
9. The AT_PEERID attribute MUST be present in EAP Response SAKE Identity T 3 3 11 Other EAP Messages Formats The format of the EAP Request Identity and EAP Response Identity packets is described in EAP The user ID e g NAI SHOULD be present in this packet The format of the EAP Success and EAP Failure packet is also shown in EAP 4 IANA Considerations IANA allocated a new EAP Type for EAP SAKE EAP SAKE messages include an 8 bit Subtype field The Subtype is a new numbering space for which IANA administration is required The following subtypes are specified in this memo SAKB Challenges od tne4 d ie wlan eek 1 SAKE Cont Drm stile cate eit id 2 SAKE Auth Rejelt ooo o ooo 3 SARE TOA SOE TE 4 The Subtype specific data is composed of attributes which have an 8 bit type number Attributes numbered within the range 0 through 127 are called non skippable attributes and attributes within the range of 128 through 255 are called skippable attributes The EAP SAKE attribute type number is a new numbering space for which IANA administration is required The following attribute types are specified ATA RAND Gu E E NS 1 AT RAND P ecg scares aged it o a i a rar 2 AT MTC SA a oi e Gap ate ie e Neha e ees arte 3 AT MIC Pa sui ar a A E A A is a 4 ATOSERVERID ican la aaa a dia das a ee 5 AT PEER Di
10. E Subtype 2 for SAKE Confirm AT_MIC_P The value field of this attribute contains the Peer s MIC_P parameter The AT_MIC_P attribute MUST be present in the EAP Response SAKE Confirm AT_PADDING The value field is set to zero Added to achieve 32 bit alignment of the EAP SAKE packet 3 3 8 EAP Response SAKE Auth Reject Format The format of the EAP Response SAKE Auth Reject packet is shown below 0 1 2 3 OO de 2 B34 O26 7 8 90 11 2 34 976 PB OY Oe 1 2 3 44 5068 9 01 Code Identifier Length Type EAP SAKI E Version 2 Session ID Subtype 3 The semantics of the fields is described below Code 2 for Response Identifier A number that MUST match the Identifier field from the corresponding Request Length The length of the entire EAP packet in octets Type EAP SAKI E Vanderveen amp Soliman Informational Page 33 RFC 4763 Version 2 Session ID A number matching all other Subtype 3 for SAKE Auth Reject The format of the EAP SAK EAP messages in this November E EAP session EAP Request SAKE Identity Format EAP Request SAKE Identity is shown below o Ls 2374 SE SH Be 9 a TEZ 3 605 8 9 5 D253 A52
11. may contain an attribute AT_NEXT_TMPID containing the NAI the Peer should use in the next EAP authentication AT_MSK_LIFE This attribute is optional to use in this message The valu field of this attribute contains the MSK Lifetime in seconds AT_MIC_S The value field of this attribute contains the Server MIC_S parameter The AT_MIC_S attribute MUST be present in the EAP Request SAKE Confirm Vanderveen amp Soliman Informational Page 31 RFC 4763 EAP SAKI E November 2006 3 3 7 EAP Response SAKE Confirm Format The format of the EAP Response SAKE Confirm packet is shown below 0 1 2 3 0 1 2538 4 5 6 17 80920 1 2 3 4 5 36 708 9 00 102 3 4 5 61 48 9 00 Code Identifier Length Type EAP SAKE Version 2 Session ID Subtype 2 AT_MIC_P Length 18 MIC_P AT_PADDING Length 2 The semantics of the fields is described below Code 2 for Response Identifier A number that MUST match corresponding Request Length The length of the entire Type EAP SAKI E Version 2 Session ID the Identifier field from the EAP packet in octets A number matching all other EAP messages in this EAP session Vanderveen amp Soliman Informational Page 32 RFC 4763 EAP SAK November 2006
12. Msg Vanderveen amp Soliman Informational Page 15 RFC 4763 EAP SAKE November 2006 The KDF is a keyed hash function with key Key and operating on input Label Msg The convention followed herein is that concatenation is denoted by FLOOR denotes the floor function and X y denotes bytes x through y The label is an ASCII character string It is included in the exact form it is given without a length byte or trailing null character Below Length denotes a single unsigned octet with values between 0 and 255 bytes The following functions are defined s HMAC SHA1 H SHA1 Key Label Msg Length HMAC SHA1 Key Label Y Msg Length where Y 0x00 KDF 16 Key Label Msg KDF Key Label Msg 16 KDF 32 Key Label Msg KDF Key Label Msg 32 KDF 128 Key Label Msg KDF Key Label Msg 128 KDF Key Label Msg Length R ss mul string for i 0 to FLOOR Length 20 1 do R R H SHAl Key Label Msg i return R O Length 1 3 2 6 2 Transient EAP Keys Derivation The Peer and Server derive the SMS and then the TEK as follows SMS A KDF 16 Root Secret A SAKE Master Secret A RAND _P RAND_S EK KDF 32 SMS A Transient EAP Key RAND_S RAND_P TEK Auth TEK 0 15 EK Cipher TEK 16 31 3 2 6 3 Extended Master Session Key Derivation The
13. Peer and the Server derive the MSK EMSK as follows SMS B KDF 16 Root Secret B SAKE Master Secret B RAND_P RAND_S Session Key Block KDF 128 SMS B Master Session Key RAND_S RAND_P MSK Session Key Block 0 63 EMSK Session Key Block 64 127 The derivation above affords the required cryptographic separation between the MSK and EMSK That is knowledge of the EMSK does not immediately lead to knowledge of the MSK nor does knowledge of the M Vand SK immediately lead to knowledge of the EMSK erveen Soliman Informational Page 16 RFC 4763 EAP SAK E November 2006 3 2 7 Ciphersuite Negotiation A ciphersuite is identified by a numeric value called the Security Parameter Index SPI The SPI is used here in the EAP SAKE method in order to negotiate a ciphersuite between the Peer and the Server for EAP data protection only Obviously this ciphersuite can only be used late in the EAP conversation after it has been agreed upon by both the Peer and the Server The EAP method may or may not need to use this ciphersuite since attribute encryption is optional For example if the temporary identifier needs to be delivered to the Peer and needs to be encrypted then the negotiated ciphersuite will be used for this task If there are no attributes that need encryption as they are passed to the Peer then this ciphersuite is never used As with most
14. attribute contains the Server nonce RAND_S parameter The RAND_S attribute MUST be present in EAP Request SAKE Challenge AT_SERVERID The value field of this attribute contains the Server identifier e g a non null terminated string The AT_SERVERID attribute SHOULD be present in EAP Request SAKE Challenge Vanderveen amp Soliman Informational Page 27 RFC 4763 November 2006 E EAP SAK 3 3 5 EAP Response SAKE Challenge Format The format of the EAP Response SAKE Challenge packet is shown below 0 1 2 3 vT 4 5 O TT n0 1 234 5767 BG 0 TT 3 A 5 671 8 9 01 Code Identifier Length Type EAP SAKE Version 2 Session ID Subtype 1 AT_RAND_P Length 18 RAND_P AT_PEERID Length Peer NAI AT_SPI_P Length SPIP AT_MIC_P Length 18 MIC_P Code 2 for Response Identifier The semantics of the fields is described below A number that MUST match the Identifier field from the corresponding Request Length The length of the entire EAP packet in octets Vanderveen Soliman Informational Page 28 RFC 4763 EAP SAK November 2006 E Type EAP
15. i e in any message starting wit EAP Request SAKE Confirm message using algorithms corresponding to the e The attributes M AT_SPI_S attribut h the Server s The attributes MUST be encrypted SPI value specified by the UST be encrypted using the TEK Cipher key whose derivation is specified in Section 3 2 6 2 If an IV is required by the encryptio n algorithm then the sender of the AT_IV attribute MUST NOT reuse the IV value from previous EAP 2 SAKE packets The sender MUST choose a new value for each AT_IV attribute The sender SHOULD use a good random number generator to generate the initialization vector see RFC4086 for guidelines Vanderveen amp Soliman Informational Page 19 P SAKE November 2006 RFC 4763 E gt The value field of the AT_ENCR_DATA attribute consists of bytes encrypted using the ciphersuite specified in the AT_SPI_S attribute The encryption key is the TEK Cipher and the plaintext consists of one or more concatenated EAP SAKE attributes The default encryption algorithm as described in Section 3 2 8 3 requires the length of the plaintext to be a multiple of 16 bytes The sender MAY need to include the AT_PADDING attribute as the last attribute within the value field of the AT_ENCR_DATA attribute The length of the padding is chosen so that the length of the value field of the AT_ENCR_DATA attribute becomes a multiple of 16 bytes Th
16. 6 0189 1 Code Identifier Length Type EAP SAKE Version 2 Session ID Subtype 4 AT_PERM_ID_REO Length 4 Reserved AT_ANY_ID_REQ Length 4 Reserved AT_SERVERID Length Server ID The semantics of the fields is Code 1 for Request Identifier A random number Length The length of the entire Vanderveen amp Soliman See EAP Informational described below EAP packet in octets 2006 Page 34 RFC 4763 EAP SAK E November 2006 Type EAP SAKI E Version 2 Session ID A number matching all other EAP messages in this EAP session Subtype 4 for SAKE Identity AT_PERM_ID_REQ CJ The AT_PERM_ID_REQ attribute is optional to be included in cases where the Server requires the Peer to give its permanent j dentifier i e PermID The AT_PERM_ID_REO MUST NOT be included if the AT_ANY_ID_REQ attribute is included The value field only contains two reserved bytes which are set to zero on sending and ignored on reception AT_ANY_ID_REQ The AT_ANY_ID_REQ attribute is optional to be included in cases where the Server requires the Peer to send any identifier e g PermID TempID The AT_ANY_ID_REQ MUST NOT be included if AT_PERM_ID_REQ is included The value field only contains two reserved bytes which are set to zero on sending and ignored on reception One o
17. E EAP Request SAKE Confirm message the Peer The Server Server did Peer then compares th If they match the Peer considers th received MIC_S with the MIC_S it computed Server authenticated and it sends an EAP Respons Confirm integrity check messag with the attribute AT_MIC_P containing a message computed in the same manner as before of type SAKE and subtype 5 After a successful EAP SAKE exchange the Server concludes the EAP conversation by sending an EAP Success message to the Peer All EAP SAKE messages contain a Session ID which is chosen by the Server sent in the first message and replicated in subsequent messages until an EAP Success or EAP Failure is sent Upon receipt of an EAP SAKE message both Peer and Server MUST check the format of the message to ensure that it is well formed and contains a valid Session ID Note that the Session ID is introduced mainly for replay protection purposes as a Server In most Cases the Session ID and the it helps uniquely identify a session between a Peer and there is a one to one relationship between Peer Server pair method are summarized in the s preferenc Server chosen ciphersuite FODN The parameters used by the EAP SAKE table below Name Length bytes Description RAND_P 16 Peer nonce RAND_S 16 Server nonce MIC_P 16 Peer MIC MIC
18. E Challenge message and any messages sent thereafter Vanderveen amp Soliman Informational Page 17 RFC 4763 EAP SAK E November 2006 3 2 8 1 The AT_MIC_S and AT_MIC_P Attributes The AT_MIC_S and AT_MIC_P attributes are used for EAP SAKE message integrity The AT_MIC_S attribute MUST be included in all EAP SAKE packets that the Server sends whenever key material TEK has been derived That is the AT_MIC_S attribute MUST be included in the EAP Request SAKE Confirm message The AT_MIC_S MUST NOT be included in EAP Request SAKE Challenge messages or EAP Request SAKE Identity messages The AT_MIC_P attribute MUST be included in all EAP SAKE packets the Peer sends whenever key material TEK has been derived That is the AT_MIC_P attribute MUST be included in the EAP Response SAKE Challenge and EAP Response SAKE Confirm messages The AT_MIC_P attribute MUST NOT be included in the EAP Response SAKE Auth Reject message since the Peer has not confirmed that it has the same TEK as the Server Messages that do not meet the conditions specified above MUST be silently discarded upon reception The value field of the AT_MIC_S and AT_MIC_P attributes contain a message integrity check MIC The MIC is calculated over th ntir EAP packet prepended with the Server nonce and identifier and the Peer nonce and ide
19. IF ANY HE INTERNET SOCIETY THE IETE RUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES XPRESS OR IMPLIED INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT HE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY MPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR URPOSE T T UHH Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available nor does it represent that it has made any independent effort to identify any such rights Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on line IPR repository at http www ietf org ipr The IETF invites any interested party to bring to its attention a
20. Network Working Group M Vanderveen Request for Comments 4763 H Soliman Category Informational Qualcomm Flarion Technologies November 2006 Extensible Authentication Protocol Method for Shared secret Authentication and Key Establishment EAP SAK E lt Status of This Memo This memo provides information for the Internet community It does not specify an Internet standard of any kind Distribution of this memo is unlimited Copyright Notice Copyright C The IETF Trust 2006 H ESG Note This RFC is not a candidate for any level of Internet Standard The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security congestion control or inappropriate interaction with deployed protocols The RFC Editor has chosen to publish this document at its discretion Readers of this document should exercise caution in evaluating its value for implementation and deployment See RFC 3932 for more information Abstract This document specifies an Extensible Authentication Protocol EAP mechanism for Shared secret Authentication and Key Establishment SAKE This RFC is published as documentation for the IANA assignment of an EAP Type for a vendor s EAP method per RFC 3748 The specification has passed Designated Expert review for this IANA assignment Vand
21. Response SAKE Challenge message th Server uses both nonces RAND_S and RAND_P along with the Root Secret A key to compute the SMS and TEK in exactly the same way the Peer did Following that the Server computes the Peer s MIC_P in exactly the same way the Peer did The Server then compares the computed MIC_P with the MIC_P it received from the Peer If they match the Server considers the Peer authenticated If encryption is needed the Server selects the strongest ciphersuite from the Peer s ciphersuite list SPI_P or a suitable ciphersuite if the Peer did not include the AT_SPI_P attribute The Server sends an EAP Request message of type SAKE nd subtype Confirm containing the attributes AT_SPI_S arrying the ciphersuite chosen by the Server AT_ENCR_DATA ontaining encrypted data and AT_MIC_S carrying a message ntegrity check The AT_SPI_S and AT_ENCR_DATA are OPTIONAL ttributes included if confidentiality and or user identity nonymity is desired Other OPTIONAL attributes that MAY be ncluded are AT_NEXT_TMPID and AT_MSK_LIFE As before the IC_S value is computed using both nonces RAND_S and RAND_P and he entire EAP packet using the key TEK Auth TZEAPA wD Vanderveen amp Soliman Informational Page 6 REC 4763 4 If the Peer receives th indicating successful authentication by th computes the MIC_S in the same manner as the EAP SAK November 2006
22. SAK E November 2006 KEYWORDS Bradner S Key words for use in RFCs to Indicate Requirement Levels BCP 14 RFC 2119 March 1997 sHA1 National Institute of Standards and Technology U S Department of Commerce Federal Information Processing Standard FIPS Publication 180 1 Secure Hash Standard April 1995 8 2 Informative References NAI Aboba B Beadles M Arkko J Network Access Identifier RFC 4282 RFC4086 Eastlake D 3rd Schiller J y and P Eronen The December 2005 and S Crocker Randomness Requirements for Security BCP 106 RFC 4086 June 2005 Authors Addresses Michaela Vanderveen Qualcomm Flarion Technologies 135 Rte 202 206 South Bedminster NJ 07921 USA EMail mvandervn yahoo com Hesham Soliman Qualcomm Flarion Technologies 135 Rte 202 206 South Bedminster NJ 07921 USA EMail solimanhs gmail com Vanderveen Soliman Informational Page 45 RFC 4763 EAP SAK E November 2006 Full Copyright Statement Copyright C The IETF Trust 2006 This document is subject to the rights licenses and restrictions contained in BCP 78 and at www rfc editor org copyright html and except as set forth therein the authors retain all their rights This document and the information contained herein are provided on an AS IS basis and THE CONTRIBUTOR HE ORGANIZATION HE SHE REPRESENTS OR IS SPONSORED BY
23. SAKI E Version 2 Session ID A number matching all other EAP messages in this EAP session Subtype 1 for SAKE Challenge AT_RAND_P The value field of this attribute contains the Peer nonce RAND_P parameter The AT_RAND_P attribute MUST be present in the EAP Response SAKE Challenge AT PEERID he value field of this attribute contains the NAI of the Peer he Peer identity follows the same Network Access Identifier format that is used in EAP Response Identity i e including the NAI realm portion The identity is the permanent identity or a temporary identity The identity does not include any terminating null characters The AT_PEERID attribute is optional in the EAP Response SAKE Challenge T AT SPIP The value field of this attribute contains the Peer s ciphersuite list SPI_P parameter The AT_SPI_P attribute is optional in the EAP Response SAKE Challenge AT_MIC_P The value field of this attribute contains the Peer MIC_P parameter The AT_MIC_P attribute MUST be present in the EAP Response SAKE Challenge Vanderveen amp Soliman Informational Page 29 RFC 4763 3 The format of the EAP Request SAK EA E P Request SAK EAP SAK E E Confirm Format November 2006 E Confirm packet is shown below
24. _S 16 Server MIC SPP variable Peer ciphersuit SPI_S variable PEERID variable Peer identifier SERVERID variable Server identifier 3 2 2 Authentication Failure If the Authenticator receives an the Authenticator MUST terminate immediately The Server considers the Peer to of the two received MIC_P values Vanderveen amp Soliman Informational EAP Failure message from the Server the connection with the Peer have failed authentication if either does not match the computed MIC_P Page 7 RFC 4763 EAP SAK E November 2006 The Server SHOULD deny authorization for a Peer that does not advertise any of the ciphersuites that are considered acceptabl e g by local system policy and send an EAP Failure message In case of authentication failure the Server MUST send an EAP Failure message to the Peer as in Figure 2 1 take place The following steps Peer Server EAP Request SAKE Challenge AT_RAND_S AT_SERVERID 1 lt EAP Response SAKE Challenge AT_RAND_P AT_PEERID AT_SPI_P AT_MIC_P 2 gt Server finds MIC_P invalid l EAP Failure 3 lt l Figure 2 EAP SAKE Authentication Procedure Peer Fails Authentication 1 As in step 1 of Figure 1 2 As in step 2 of Figure 1 3 Upon receipt of the EAP Response SAKE Challenge messag y ER Server uses both nonces RAND_S and RAND_P along wit
25. arski for his helpful comments 8 References 8 1 Normative References AES CBC HMAC IANA H 7j T E802 11i National Institute of Standards and Technology Federal Information Processing Standards FIPS Publication 197 Advanced Encryption Standard AES November 2001 http csrc nist gov publications fips fips197 fips 197 pdf National Institute of Standards and Technology NIST Special Publication 800 38A Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 http csrc nist gov publications drafts Draft NIST_SP800 38D_Public_Comment pdf Aboba B Blunk L Vollbrecht J Carlson J and H Levkowetz Extensible Authentication Protocol EAP RFC 3748 June 2004 Krawczyk H Bellare M and R Canetti HMAC Keyed Hashing for Message Authentication RFC 2104 February 1997 Narten T and H Alvestrand Guidelines for Writing an IANA Considerations Section in RFCs BCP 26 RFC 2434 October 1998 T TEEE Standard for Information Technology Telecommunications and Information Exchange between Systems LAN MAN Specific Requirements Part 11 Wireless Medium Access Control MAC and physical layer PHY specifications Amendment 6 Medium Access Control MAC Security Enhancements June 2004 Vanderveen Soliman Informational Page 44 RFC 4763 EAP
26. cation if the received and the computed MIC_S values do not match In this case the Peer MUST send to the Server an EAP Response message of type SAKE and subtype Auth Reject indicating an authentication failure In this case the Server MUST send an EAP Failure message to the Peer as in Figure 3 The following steps take place Vanderveen amp Soliman Informational Page 9 RFC 4763 EAP SAK E November 2006 Peer Server EAP Request SAKE Challenge AT_RAND_S AT_SERVERID EAP Response SAKE Challenge AT_RAND_P AT_PEERID AT_SPI_P AT_MIC_P T EAP Request SAKE Confirm AT_SPI_S AT_ENCR_DATA AT_MIC_S Peer finds MIC_S invalid EAP Response SAKE Auth Reject EAP Failure Figure 3 EAP SAKE Authentication Procedure Server Fails Authentication 1 As in step 1 of Figure 1 2 As in step 2 of Figure 1 3 As in step 3 of Figure 1 4 The Peer receives a EAP Request SAKE Confirm message indicating successful authentication by the Server The Peer computes the MIC_S in the same manner as the Server did The Peer then compares the received MIC_S with the MIC_S it computed Since they do not match the Peer considers the Server to have failed authentication In this case the Peer responds with an EAP Response message of type SAKE and subtype Auth Reject indicating authentication failure
27. e AT_PADDING attribute SHOULD NOT be included if the total length of other attributes present within the AT_ENCR_DATA attribute is a multiple of 16 bytes The length of the AT_PADDING attribute includes the Attribute Type and Attribute Length fields The actual pad bytes in the value field are set to zero 0x00 on sending The recipient of the message MUST verify that the pad bytes are zero after decryption and MUST silently discard the message otherwis The MIC computed on the entire EAP message Can be used to obviate the need for special integrity protection or message authentication of the encrypted attributes An example of the AT_ENCR_DATA attribute is shown in Section 3 3 3 3 2 8 3 Security Parameter Index SPI Considerations An SPI value is a variable length string identifying at least an encryption algorithm and possibly a security association EAP SAKE does not mandate the format of the SPI it only mandates that the default encryption algorithm be supported if encryption is supported That is if an implementation compliant with this document supports encryption then it MUST support the AES CBC cipher The default encryption algorithm AES CBC involves the AES block cipher AES in the Cipher Block Chaining CBC mode of operation CBC The Peer in the EAP SAKE method can send up to four SPI values in its SPI_P field Because the lengt
28. e In case the EAP phase ends with an EAP Failure message then the Server and the Peer MUST consider the TempID that was just delivered as invalid Hence the Peer MUST NOT use this TempID the next time it tries to authenticate with the Server 3 2 4 Obtaining Peer Identity The types of identities that a Peer may possess are permanent and temporary identities referred to as PermID and TempID respectively A PermID can be an NAI associated with the Root Secret and is long lived A TempID is an identifier generated through the EAP method and that the Peer can use to identify itself during subsequent EAP sessions with the Server The purpose of the TempID is to allow for user anonymity support The use of TempIDs is optional in the EAP SAKE method The Server MAY request the Peer ID via the EAP Request SAKE Identity message as shown in Figure 4 This case may happen if for example the Server wishes to initiate an EAP SAKE session for a Peer it does not have a subscriber identifier for The following steps take place Vanderveen amp Soliman Informational Page 11 REC 4763 EAP SAKE November 2006 Peer Server Server wishes to initiate an EAP SAKE session EAP Request SAKE Identity AT_ANY_ID_REQ AT_SERVERID 1 lt EAP Response SAKE Identity AT_PEERID 2 g
29. ealm of the user NAI NAI The AT_SERVERID attribute is OPTIONAL but SHOULD be included in this message The purpose of the AT_SERVERID is to aid the Peer in selecting the correct security association i e Root Secret PEERID and SERVERID to use during this EAP phase T BI 2 The Peer responds by sending an EAP Response message of type SAK and subtype Challenge he EAP Response SAKE Challenge message contains the attributes AT_RAND_P which carries a nonce freshly generated by the Peer AT_PEERID which carries a Peer identifier AT_SPI_P which carries a list of one or more ciphersuites supported by the Peer and AT_MIC_P containing a message integrity check The AT_SPI_P and AT_PEERID attributes are OPTIONAL The AT_PEERID attribute SHOULD be included in order to cover the case of multi homed hosts A supported ciphersuite is represented by a value local to the EAP SAKE method or Security Parameter Index s section 3 2 8 3 The Peer uses both nonces along with the Root Secret A key to derive a SAKE Master Secret SMS and Temporary EAP Keys TEKs which also include the TEK Auth and TEK Cipher keys The MIC_P value is computed based on both nonces RAND_S and RAND_P and the entire EAP packet using the key TEK Auth see Section 3 2 6 T T 3 Upon receipt of the EAP
30. eplay protected authenticated the Server by sending the EAP Request SAKE Confirm message The Peer indicates that it has successfully EAP Response SAKE Confirm message which is al 11 The Master Session Key not lead to informatio is infeasible to calculate t EMSK TEKs the MSK or the Ze Within each EAP SAKE The keying material Cryptographic Separation of TEKs used to protect and the cryptographically separate session Keys EAP SAKE packets n about any other keys Session Independence EAP SAKE Both the Server and the Peer S 1 e nonces for the random MSK and number from a previous session does use a freshly generated random number implies that the EMSK derived within this session are cryptographically TEK Auth TEK Cipher Extended Master Session Key are Information about any of these keys does which is integrity and so integrity and replay protected the We also note that it he Root Secret from any or all of the fresh keying material is generated xported by this method from two independent sessions is cryptographically separat EAP SAKE exchange Vanderveen Soliman Informational as explained below HOULD generate fresh random numbers If either entity re uses a then the fact that the other EKs Page 41 RFC 4763 EAP SAK Die 5
31. erveen amp Soliman Informational Page 1 RFC 4763 EAP SAKE November 2006 Table of Contents Tae IAEESGALCELOA aia E ad A A A AA BATES Stee de et 3 Ze LSO LO ii ds Revere OS E a te amp arenes cone 3 32 PEOUOCOl DESCETPELON A Ad ds a eS A ates MEE 4 3 1 Overview and Motivation of EAP SAKE o ooooooooooooooooo 4 3220 BLOBOCOL OPeral TOA A A A tens io 5 Sada SUCCESS CUL Exchange a 2 E e EE ee NSS 5 S222 AUCHENEECAELON Fallera e inet a ce EEE vi 3203 Identity Management srete suits Gated abs gates URES SOs Ses 11 342 4 Obtaining Peer Identity vess revises uie eles woe Boe a es 11 Zro KEY HESLAE GAY NN 1 3 3525 Oe KEY DETAL TION ir ares marte 15 Sade la Ciphersuite Negotiation meses ais epa 17 3 2 8 Message Integrity and Encryption 17 Saz La gMent at CON dt ts dere whe Ra daa a de ab 4 ac 21 Sa O ETO CASOS aria E oe eee aia a ea 21 3 3 Message Formats A A ee A Stee ae debe ene eee ee 22 3 3 21 Message Format Summary dida g hee wei eee AG de 22 82 3020 Abtribute Format raid send tices da ia deta aca de 23 3 3 33 Use of ATSENCR DATA AEETIDUES das wets dg eels edad ses 25 3 3 4 EAP Request SAKE Challenge Format oooooooo oo 26 3 3 5 EAP Response SAKE Challenge Format oooooooo oo 28 3 3 6 EAP Request SAKE Confirm Format oo ooooo eee eee ees 30 3 3 7 EAP Response SAKE Confirm Forma
32. ey Claims seser eel Be eee eee eee AA e rege Re oe whe bw dts a AA 43 Vanderveen amp Soliman Informational Page 2 REC 4763 7 Acknowledgements 8 References 8 1 Normative References 8 2 Informative References I Introduction Th Extensibl methods 802 11i docum based docum EAP m Dos Term In this document of the specification words SHOULD NOT to b ab Kerberos EAP SAKE I T E802 11i Public Key Authentication Protocol provides a standard mechanism for support of multiple authenticatio EAP is also used within IEEE E framework EAP SAKI E EAP EAP supports several authentication schemes One Time Passwords ent defines an authentication scheme supports mutual authentication and session key derivation TL o on a static pr hod per REC 3748 inology shared secret data entation for the IANA assignment of an et Expert review for this IANA assignment T The specification MUST MUST NO RECOMMEND ED In addition to t he terms used in MUST OPT REQUIRED MAY and interpreted as described in BCP 14 EAP this the following terms and abbreviations MIC SMS NAI Message Integrity Check SAKE Master Secret Network Access Identifier Vanderveen amp Soliman Informational 802 networks t
33. f EAP SAKE messages received with invalid MIC fields In these updating the Root Secret securely SHOULD be 5 3 Mutual Authentication SAKE Confirm messages The EAP Request SAKE Server nonce RAND_S the EAP Response SAKE C Peer nonce RAND_P along with the Peer MIC EAP Request SAKE Confirm contains the Server MIC_S and MIC_P are computed using both no cases a procedure for in place Mutual authentication is accomplished via the SAKE Challenge and Challenge contains the hallenge contains the MIC_P and the MIC MIC_S Both MICs nces RAND_S and RAND _P and are keyed by the TEK a shared secret d Secret The Server considers the Peer authe computes matches the one that the Peer sends considers the Server authenticated if the MI the one that the Server sends The way the involves a keyed one way hash function whic rived from the Root nticated if the MIC_P it Similarly the Peer C_S it computes matches MICs are computed h makes it computationally hard for an attacker to produce the correct MIC without knowledge of the shared secret 5 4 Integrity Protection Integrity protection of EAP SAKE messages is use of the Message Integrity Checks MIC w message as soon as a common shared secret TI any message after the EAP Request SAKE Chal accomplished through the hich are present in every EK is available i e enge An adversa
34. f the AT_PERM_ID_REQ and AT_ANY_ID_REQ MUST be included AT_SERVERID The value field of this attribute contains the identifier realm of the Server The AT_SERVERID attribute is optional but RECOMMENDED to include in the EAP Request SAKE Identity Vanderveen amp Soliman Informational Page 35 RFC 4763 LITO The format of the 0 EAP SAK E EAP Response SAKE Identity Format EAP Response SAKE Identity 1 2 November is shown below 3 O 123 459 67 8 9 0123 45 678 903 2345 6 7 8 9 0 1 2006 Code Identifier Length Type EAP SAKE Version 2 Session ID Subtype 4 AT_PEERID Length Peer NAI The semantics of the fields is described below Code 2 for Response Identifier A number that MUST match corresponding Request the Identifier field from the Length The length of the entire EAP packet Type EAP SAKI E Version 2 Session ID A number matching all other EAP messages in this EAP session Subtype 4 for SAKE Identity Vanderveen Soliman Informational Page 36 November 2006 E RFC 4763 EAP SAK ATP T ERID P qd he value field of this attribute contains the NAI of the Peer
35. gth field is two octets and indicates the number of octets in an EAP message including the Code Identifier Length Type and Data fields Type To be assigned Version The EAP SAKE method as described herein is version 2 Session ID The Session ID is a 1 byte random number that MUST be freshly generated by the Server that must match all EAP messages in a particular EAP conversation Vanderveen amp Soliman Informational Page 22 November 2006 E RFC 4763 EAP SAK Subtype EAP SAKE subtype SAKE Challenge SAKE Confirm SAKE Auth Reject and SAKE Identity All messages of type EAP SAKE that are not of these subtypes MUST silently discarded Message Name Subtype Value decimal SAKE Challenge 1 SAKE Confirm 2 SAKE Auth Reject 3 SAKE Identity 4 3 3 2 Attribute Format The EAP SAKE attributes that are part of the EAP SAKE packet follow the Type Length Value format with l1 byte Type 1 byte Length and variable length Value up to 255 bytes The Length field is in octets and includes the length of the Type and Length fields The EAP SAKE attribute format is as follows 0 1 2 3 Od 235 4 3 6 7 08 09 001 203 Ao 8976 7 58 90 1 2 34 5611 B 9 Oh A Type Length Value Type 1l byte unsigned integer s Table below
36. h of the AT_SPI_P and AT_SPI_S attributes must each be a multiple of 2 bytes the sender pads the value field with zero bytes when necessary the AT_PADDING attribute is not used here For example the value field of the AT_SPI_S contains one byte with the chosen SPI followed by one byte of zeros Vanderveen amp Soliman Informational Page 20 RFC 4763 2 9 Fragme Ey E The EAP SAK do not get excess the limit of the network are 362 1 0 Error Cases lformed message EAP SAKE packe ilently discard messages to the o missing ma type of message Non matchi packet wit ng Sess h a Ses previous packet in this sessio this packet session Peer Authorization Failure authorized for services In that Case stolen Unexpected before the SAK successfully aut EAP Response SAK ndatory attribute EAP Success E Challenge and SAK silently discard any EAP SAK E ntation method does not require fragmentation ively long That is maximum transmission u s As a general rule if a Peer t that contains an error this packet not change state ther party Exampl an attribute that is and unrecognized subtypes or att the implementation S and not send any es of such errors include a November 2006 as the messages EAP packets are well within nit of other layers The only variable fields are those carrying NAl
37. h the Root Secret A key to compute the SMS and TEK in exactly the same way the Peer did Following that the Server computes the in exactly the same way the Peer did The Server then the computed MIC_P with the MIC_P it received from the Since they do not match the Server considers the Peer failed authentication and sends an EAP Failure message the Peer Vanderveen Soliman Informational Peer s MIC compares Peer to have back to Page 8 RFC 4763 EAP SAK E November 2006 If the AT_SPI_S attribute does not contain one of the SPI values that the Peer listed in the previous message or if the Peer did not include an AT_SPI_P attribute yet does not accept the ciphersuite th Server has chosen then the Peer SHOULD silently discard this message Alternatively the Peer MAY send a SAKE Auth Reject messag back to the Server in response to this message the Server MUST send an EAP Failure message to the Peer The AT_SPI_S attribute MUST be included if encryption is to be used The Server knows whether or not encryption is to be used as it is usually the Server that needs to protect some data intended for the Peer e g temporary ID group keys etc If the Peer receives an AT_SPI_S attribute yet there is no AT_ENCR_DATA attribute the Peer SHOULD process the message and skip the AT_SPI_S attribute The Peer considers the Server to have failed authenti
38. hrough the IEEE EAP Type for a ve November 2006 described in EAP D including smart cards S and others This alled the EAP SAKE hed as ndor s has passed Designated his RFC is publis several words are used to signify the requirements These words are often capitalized r The key MUST NOT SHOULD IONAL in this document KEYWORDS r document frequently uses Page 3 RFC 4763 EAP SAK E November 2006 3 Protocol Description E 3 1 Overview and Motivation of EAP SAK The EAP SAKE authentication protocol is a native EAP authentication method That is a stand alone version of EAP SAKE outside of EAP is not defined EAP SAKE is designed to enable mutual authentication based on pre shared keys and well known public cryptographic algorithms This method is ideal for subscription based public access networks e g cellular networks EAP SAKE assumes a long term or pre shared secret known only to the Peer and the Server This pre shared secret is called the Root Secret The Root Secret consists of a 16 byte part Root Secret A and 16 byte part Root Secret B The Root Secret A secret is reserved for use local to the EAP SAKE method i e to mutually authenticate the EAP Peer and EAP Server The Root Secret B secret is used to derive other quantities such as the Master Se
39. imis 32 byt of keyed hash functions e g KDF Thus assuming tically that th ffective key strength of the Root Secret is s th ffective key strengths of the derived keys is at most th ff ctive key strength of the Root Secret quantities they are derived from EMSK at most 16 bytes MSK at most 16 bytes 6 Securi This se la c ty Claims ction provides the security claims as required by EAP Mechanism EAP SAKE is a challenge response authentication and key establishment mechanism based on a symmetric pre shared secret Security claims EAP SAKE provides Mutual authentication Section 5 3 Integrity protection Section 5 4 Replay protection Section 5 5 Confidentiality optional Section 5 6 and Section 5 13 Key derivation Section 5 7 Dictionary attack protection Section 5 8 Protected result indication of successful authentication from Server and from Peer Section 5 10 Session independence Section 5 12 Key strength EAP SAKE supports key derivation with 256 bit ffective key strength Section 5 7 d Description of key hierarchy see Section 3 2 5 Vanderveen amp Soliman Informational Page 43 RFC 4763 EAP SAKI November 2006 E e Indication of vulnerabilities EAP Make does not provide Fast reconnect Fragmentation Channel binding Cryptographic binding 7 Acknowledgements Thanks to R Dyn
40. mple of the AT_ENCR_DATA attribute as used in the EAP Request SAKE Confirm message is shown below 0 1 2 3 QL 23 4 5 6 7 8 9 0 1 2 345 06 78901 23 45 06 7 8 9 0 1 AT_IV Length 18 Initialization Vector AT_ENCR_DATA Length AT_NEXT_TMPID Length in je hr Peer TempID hy p t je t 4 jad AT_MIC_S Length 10 MIC_S AT_PADDING Length Vanderveen amp Soliman Informational Page 25 RFC 4763 EAP SAK E November 2006 3 3 4 EAP Request SAKE Challenge Format The format of the EAP Request SAKE Challenge packet is shown below 0 1 2 3 T2 A S607 89 0 1 23 4 56 7 8 9 00 1 23 4 D 6 78 9 01 Code Identifier Length Type EAP SAKE Version 2 Session ID Subtype 1 AT_RAND_S Length 18 RAND_S AT_ SERVERID Length Server ID The semantics of the fields is described below Code 1 for Request Identifier A random number See EAP Length The length of the entire EAP packet in octets Type EAP SAKI E Version 2 Vanderveen amp Soliman Informational Page 26 November 2006 E RFC 4763 EAP SAK Session ID A random number chosen by the server to identify this EAP Session Subtype 1 for SAKE Challenge AT_RAND_S The value field of this
41. ntifier The value field of the MIC attribute is set to zero when calculating the MIC Including the Server and Peer nonces and identifiers aids in detecting replay and man in the middl attacks The Peer computes its MIC as follows MIC_P KDF 16 TEK Auth Peer MIC RAND_S RAND_P PEERID 0x00 SERVERID 0x00 lt EAP packet gt while the Server computes its MIC as MIC_S KDF 16 TEK Auth Server MIC RAND_P RAND_S SERVERID 0x00 PEERID 0x00 lt EAP packet gt Here lt EAP packet gt denotes th ntire EAP packet used as a string of bytes the MIC value field set to zero 0x00 denotes a single octet value used to delimit SERVERID and PEERID The PEERID and SERVERID respectively are the ones carried in the corresponding attributes in the SAKE Challenge messages Vanderveen amp Soliman Informational Page 18 RFC 4763 In case the SAKE Challenge exchange was preceded by an Attribute then t MUST be set to th If the AT_SERVERI message or the SA used in the compu AT_PEERID was not included in the SAK was no EAP Respon SAKE Challenge m EAP SAKI E November 2006 EAP Request SAKE Identity message containing the AT_SERVERID he SERVERID value in the MIC_P and MIC_S computation e value of thi
42. ny copyrights patents or patent applications or other proprietary rights that may cover technology that may be required to implement this standard Please address the information to the IETF at letf iprtietf org Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society Vanderveen amp Soliman Informational Page 46
43. other methods employing ciphersuite negotiation the following exchange is employed the Peer sends an ordered list of one or more supported ciphersuites starting with the most preferred one in a field SPI_P The Server then sends back the one ciphersuit chosen in a field SPI_S The Server SHOULD choose the strongest ciphersuite supported by both of them Gl Ciphersuite negotiation for data protection is achieved via SAK Signaling as follows In the EAP Response SAKE Challenge the Peer sends a list of supported ciphersuites SPI_P and protects that with a MIC In the EAP Request SAKE Confirm the Server sends one selected ciphersuite SPI_S and signs that with a MIC Finally the Peer confirms the selected ciphersuite and readiness to use it ina signed EAP Response SAKE Confirm message The negotiation is secure because of the Message Integrity Checks that cover th ntire EAP message 3 2 8 Message Integrity and Encryption This section specifies the EAP SAKE attributes used for message integrity and attribute encryption AT_MIC_S AT_MIC_P AT_IV AT_ENCR_DATA and AT_PADDING Only the AT_MIC_S and AT_MIC_P are mandatory to use during the EAP SAKE exchange Because the TEKs necessary for protection of the attributes and for message authentication are derived using the nonces RAND_S and RAND_P the AT_MIC_S and AT_MIC_P attributes can only be used in the EAP Response SAK
44. r replay protected This makes it possible for an attacker to spoof such messages Note that EAP Response SAKE Auth Reject cannot be protected with a MIC since an authentication failure indicates that the Server and Peer do not agree on a common key Most importantly an attacker cannot cause a Peer to accept an EAP Success packet as indication that the Server considers the mutual authentication to have been achieved This is because a Peer does not accept EAP Success packets before it has authenticated the Server or after it has considered the Server to have failed authentication 5 2 Root Secret Considerations If the Root Secret is known to any party other than the Server and Peer then the mutual authentication and key establishment using EAP SAKE is compromised EAP SAKE does not address how the Root Secret is generated or distributed to the Server and Peer It is RECOMMENDED that the entropy of the Root Secret be maximized The Root Secret SHOULD be machine generated Vanderveen amp Soliman Informational Page 38 RFC 4763 EAP SAK E If the Root Secret is derived from a low ent such as a human selected password then the is subject to on line and off line dictionar identify whether such a password has been co November 2006 ropy guessable quantity EAP SAKE key derivation y attacks To help mpromised implementations SHOULD keep a log of the number o
45. ropy of all these keys is at most the strength of the Root Secret The entropy of the MSK and of the EMSK assuming that the Server and Peer 128 bit nonces are generated using good random number generators is at most 256 bits Vanderveen amp Soliman Informational Page 40 RFC 4763 Jy 5 5 Ds 5 8 Dictionary Attacks Dictionary attacks are not feasible to mount on the because passwords are not used machine generated problems 9 Man in the Middl E EAP SAK Instead Resistance to man in t integrity protection t Integrity Check field extent of this resista MIC itself Man in th EAP method within a tu 10 Result Indication EAP SAKE result indications integrity protection Protection the Root Secret is This does not necessarily pose provisioning November 2006 EAP SAKE method Attacks he middle attacks is provided through the hat each EAP message carries i e Messag as soon as a common key for this EAP session has been derived through mutual authentication As before the nce is commensurate with the strength of the middle attacks associated with the use of any nneling or sequencing protocol are beyond the scope of this document provides result indication protection in that it provides and replay protection The Server indicates that it has successfully authenticated the Peer by sending the r
46. ry cannot modify any of the MIC protected messa recipient to encounter a MIC failure Thee protection is commensurate with the security derive the MIC the length and entropy of th the KDF and the length of the MIC 5 5 Replay Protection The first message of most session establishm EAP SAKE is subject to replay A replayed EAP Request SAKE Challenge message results i EAP Response SAKE Challenge message back wh was computed using the attacker s chosen non risk to the compromise of the TEK Auth key cannot proceed successfully as the Peer will invalid Vanderveen amp Soliman Informational ges without causing the xtent of the integrity of the KDF used to shared secret used by ent protocols such as n the Peer sending an ich contains a MIC that ce This poses a minimal and this EAP Session find the Server s MIC Page 39 RFC 4763 EAP SAKI November 2006 E Replay protection is achieved via the RAND_S and RAND_P values together with the Session ID field which are included in the calculation of the MIC present in each packet subsequent to the EAP SAKE Challenge request packet The Session ID MUST be generated anew by the Server for each EAP session Session Ids also aid in identification of possible multiple EAP sessions between a Peer and a Server Within the same session messages can be replayed by an attacker but the sta
47. s limited by their length field to 256 bytes link which or Server receives HOULD EAP not allowed in this ributes F ion Id If a sion Id field Peer or Server rec not matching the S n such as when the termina that entity SHOULD sile not applicable for the first message of an ives an EAP SAK ession Id from the ntly discard EAP SAKE ay ry It may be possible that a Peer is not the Server SHOULD send an MUST NOT send an E Confirm rounds EAP Success packets before t A Server 1 device is reported EAP Failure message EAP Success messag The Peer MUST Peer has h henticated the Server via the E Confirm packet The Peer and Server SHOULD log all error cases Vanderveen Soliman Informational Page 21 RFC 4763 EAP SAK E November 2006 3 3 Message Formats 3 3 1 Message Format Summary A summary of the EAP packet format EAP is shown below for convenience The fields are transmitted from left to right 0 1 2 3 OLA A O 89 Odd BG T 18 9 00 11 23 AT 6 Teg 0r 1 Code Identifier Length Type EAP SAKE Version 2 Session ID Subtype Code 1 Request 2 Response Identifier The identifier field is one octet and aids in matching responses with requests Length The Len
48. s attribute D was not KE Identity message included in either the SAKE Challenge then the value of the SERVERID tation of MIC_P and MIC_S MUST be empty If the E Challenge message and there se SAKE Identity message preceding the The Server and Pe ssages then the value of the PEERID used in the computation of MIC_P and MIC_S MUST be empty er identity are incl luded in the computation of the signed responses so that the Peer and Server can verify each other s identities and the possession of a common secret the TEK Auth However since th e AT_SERVI the Server EAP SAKE does 3 2 8 2 The AT_IV The AT_IV and AT_ encrypted informa field of AT_IV co required by the e AT_ENCR_ DATA tion betw ntains an ncryption ERID is not explicitly signed with a MIC by not claim channel binding and AT_PADDING Attributes ENCR_DATA attributes can be used to transmit n the Server and the Peer The value initialization vector IV if one is algorithm used It is not mandatory that the AT_IV attribute be included whenever the AT_ENCR_DATA attribute is However the AT_IV attribute MUST NOT be included unless th Messages that do not meet this condition AT_ENCR_DATA is i ncluded MUST be silently discarded Attributes can be encrypted only after a ciphersuite has been agreed on
49. sks Sco aaa la sd amen aS Bom Sled ante ais 6 ATEO ii a io ed Sid ta lee a ca cing Jase ie eel ig dni a peice etd agile il ade 7 AT SPI Potae eiaa o a pt Sete pao 8 AT ANY STD REO eave tte Sets Brie ated aura ae ad eee Bel ee eer a aries 9 AT PERM lt L Bec RE Oise tajada ie alec eh liada elie fa ee eile eine sap a epee ai 10 Vanderveen amp Soliman Informational Page 37 REC 4763 EAP SAK E November 2006 ATAENER DATA pei DA oP ae tee A a ae elated 128 ATI a e a e 6 129 AT BADDING c rc ii Siete iia 130 AT NEX F o TFMP TD e ls ete as lo e tds ee 131 AT MSK EIEE ga pee na a daa ae Mons OER ee 132 All requests for value assignment from the two number spaces described in this memo require proper documentation according to the Specification Required policy described in IANA All assignments of values from the two number spaces described in this memo require IETF consensus 5 Security Considerations The EAP specification EAP describes the security vulnerabilities of EAP which does not include its method specific security mechanisms This section discusses the claimed security properties of the EAP SAKE method along with vulnerabilities and security recommendations Brel Denial of Service Attacks Since EAP SAKE is not a tunneling method the EAP Response SAKE Auth Reject EAP Success and EAP Failure packets are not integrity o
50. ssion Key MSK and Extended Master Session Key EMSK Root Secret B and Root Secret A MUST be cryptographically separate When a Backend Authentication Server is used the Server typically communicates with the Authenticator using an AAA protocol The AAA communications are outside the scope of this document Some of the advantages of EAP SAKE are as follows o It is based on well established Bellare Rogaway mutual authentication protocol o It supports key derivation for local EAP method use and for export to other third parties to use them independently of EAP o It employs only two request respons xchanges T o It relies on the corrected IEEE 802 11i function for key derivation and message integrity This way a device implementing a lower layer secure association protocol compliant with IEEE 802 111 standard will not need additional cryptographic code T o Its encryption algorithm is securely negotiated with no extra messages yet encryption use is optional o Keys used for authentication and those used for encryption are cryptographically separate o User identity anonymity can be optionally supported Vanderveen amp Soliman Informational Page 4 RFC 4763 EAP SAK E November 2006 o No synchronization e g of counters needed betw peer o There is no one time key pre processing step
51. t ooooooooo oo 32 3 3 8 EAP Response SAKE Auth Reject Format o o ooo oo 33 3 3 9 EAP Request SAKE Identity Format o o oooooo ooo 34 3 3 10 EAP Response SAKE Identity Format oo ooo ooo o o 36 3 3 11 Other EAP Messages Formats o ooooooooooooooooo 37 AA PANA CONS ADE TAE TORSO a id 31 De Security Consideration bn rt at lee ta is ce a de 38 Oil Dental Of SErvrce ACEACKS mea ia aaa e dae a taa aa 38 52s ROGE Secret Considerations ini SD es eS 38 dede Mutital AUGHEHETCAELON sses idsetete ete ekaa oes Gadde Dado dicas Data bane 39 Du Ls Incegrity PrOCECEVON iia ob ib cca ten bh dene sila e wl dene 39 Sd Replay BYOESGELOMN a Weel oud Salone Sle Sens eo ol erated Beton eles See ele Sere 39 Sebe CONE PASNE PALEY we ele SS a oes wees ES le a wap arene lao te 40 Suede Key Dertvatton Strengt sos dss cde rs aio eta ohare 40 9 48 Dictionaty Attacks lena ae e wooed Coke tee He Uh dade Be ww hither eee E 41 9 9 Man 1n the Midd le Attacks ias is e a ae 41 ea 10 Res lbtt Indication Protectoras ds rt si 41 5 d41 Cryptographie Separation Of KEYS tn secs setas da eek a 41 H2l2s Session Independence ici ea it E E Bele BEES Bo 41 Le Ldentity Protection ii wie arte ete Wee als A Shee eR ew 42 Sats Channel Binding a A aia a ek 42 Ss LOs Caphersur te Nggotidtion sti ad a BS we ae aided a RE dt was 42 5 16 Random Number Generation eee eee eee ee eee ee eens 43 6 SECumT
52. t If identity found normal EAP SAKE authentication follows Figure 4 Server Requests Peer Identity 1 The Server sends an EAP Request message of type SAKE and subtype Ident subtype Identity P for any P ity r identifi with the attribute AT_ANY_ID_REQ The Peer constructs an with the attribute AT_P identifier E If the Server ca EAP Response SAK format of th Perm nnot find E Identity message Tas EAP Response messag ERAD co h ID or TempID the Peer identity reported i Peer identi message to the Peer If the Server is unabl et fier the Server MAY send an o look up a Peer by its Templ dictates that the Peer should now use its permanent id Server may specificall Figure 5 The following Vanderveen Soliman ly ask for the permanent identifier of type SAKE indicating a request and ntaining any n the or if it does not recognize the EAP Failure or if policy then the as in D r steps occur Informational Page 12 RFC 4763 EAP SAKE November 2006 Peer Server 1 Server obtains TempID but requires PermID EAP Request SAKE Identity AT_PERM_ID_REQ AT_SERVERID EAP Response SAKE Identity AT_PEERID Server finds and uses Peer PermID to start a EAP SAKE authentication phase
53. te machine SHOULD be able to handle these cases Note that a replay within a session is indistinguishable to a recipient from a network malfunction e g message was first lost and then re transmitted so the recipient thinks it is a duplicate message Replay protection between EAP sessions and within an EAP session is also accomplished via the MIC which covers not only the entire EAP packet including the Session ID but also the nonces RAND_S and RAND_P Thus the recipient of an EAP message can be assured that the message it just received is the one just sent by the other Peer and not a replay since it contains a valid MIC of the recipient s nonce and the other Peer nonce As before th xtent of replay protection is commensurate with the security of the KDF used to derive the MIC the length and entropy of the shared secret used by the KDF and the length of the MIC 5 6 Confidentiality Confidentiality of EAP SAKE attributes is supported through the use of the AT_ENCR_DATA and AT_IV attributes A ciphersuite is negotiated securely s Section 3 2 7 and can be used to encrypt any attributes as needed The default ciphersuite contains a strong cipher based on AES 5 7 Key Derivation Strength EAP SAKE derives a Master Key for EAP use and Master Session Key as well as other lower level keys such as TEKs Some of the lower level keys may or may not be used The strength ent
54. the Server identifier is not integrity protected her 11 subsequent EAP SAKE messages exchanged during a successful EAP A SAKE phase are integrity protected as they contain a Message I a ntegrity Check MIC The MIC is computed over the EAP message and lso over the Server and Peer identities In that both EAP endpoints can verify the identity of the other party 15 Ciphersuite Negotiation EAP SAKE does not support negotiation of the ciphersuite used to integrity protect the EAP conversation However negotiation of a ciphersuite for data protection is supported This ciphersuite negotiation is protected in order to minimize the risk of down negotiation or man in the middle attacks Vanderveen amp Soliman Informational Page 42 RFC 4763 This ne MICs negotia negotia derive the KDF 5 16 Ran EAP SAKI E November 2006 gotiation is secure because of the Message Integrity Checks that cover th ntire EAP messages used for ciphersuite tion see Section 3 2 7 The extent of the security of the tion is commensurate with the security of the KDF used to the MICs the length and entropy of the shared secret used by and the length of the MICs dom Number Generation E EAP SAKE supports key derivation from a 32 byte Root Secret The entropy of all other keys derived from it is reduced somewhat through the us opt
Download Pdf Manuals
Related Search