| draft-ietf-hokey-rfc5296bis-00.txt | draft-ietf-hokey-rfc5296bis-01.txt | |||
|---|---|---|---|---|
| Network Working Group G. Zorn, Ed. | Network Working Group Q. Wu, Ed. | |||
| Internet-Draft Network Zen | Internet-Draft Huawei | |||
| Obsoletes: 5296 (if approved) Q. Wu | Obsoletes: 5296 (if approved) Z. Cao | |||
| Intended status: Standards Track Huawei | Intended status: Standards Track China Mobile | |||
| Expires: March 17, 2011 Z. Cao | Expires: April 23, 2011 Y. Shi | |||
| China Mobile | H3C | |||
| September 13, 2010 | B. He | |||
| CATR | ||||
| October 20, 2010 | ||||
| EAP Extensions for EAP Re-authentication Protocol (ERP) | EAP Extensions for EAP Re-authentication Protocol (ERP) | |||
| draft-ietf-hokey-rfc5296bis-00 | draft-ietf-hokey-rfc5296bis-01 | |||
| Abstract | Abstract | |||
| The Extensible Authentication Protocol (EAP) is a generic framework | The Extensible Authentication Protocol (EAP) is a generic framework | |||
| supporting multiple types of authentication methods. In systems | supporting multiple types of authentication methods. In systems | |||
| where EAP is used for authentication, it is desirable to not repeat | where EAP is used for authentication, it is desirable to not repeat | |||
| the entire EAP exchange with another authenticator. This document | the entire EAP exchange with another authenticator. This document | |||
| specifies extensions to EAP and the EAP keying hierarchy to support | specifies extensions to EAP and the EAP keying hierarchy to support | |||
| an EAP method-independent protocol for efficient re-authentication | an EAP method-independent protocol for efficient re-authentication | |||
| between the peer and an EAP re-authentication server through any | between the peer and an EAP re-authentication server through any | |||
| skipping to change at page 1, line 41 | skipping to change at page 1, line 43 | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on March 17, 2011. | This Internet-Draft will expire on April 23, 2011. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 3, line 10 | skipping to change at page 3, line 10 | |||
| outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
| not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
| it for publication as an RFC or to translate it into languages other | it for publication as an RFC or to translate it into languages other | |||
| than English. | than English. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 7 | 3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 9 | |||
| 3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 9 | 3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 10 | |||
| 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 11 | 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 12 | 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 13 | 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 | 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 14 | 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 14 | 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 15 | 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 | 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 16 | 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 16 | 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17 | |||
| 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 19 | 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 21 | 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 22 | |||
| 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 22 | 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 23 | |||
| 5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 23 | 5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 24 | |||
| 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 24 | 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 25 | |||
| 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 25 | 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 26 | |||
| 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 25 | 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 26 | |||
| 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 25 | 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 26 | |||
| 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 27 | 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 28 | |||
| 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 30 | 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31 | |||
| 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 31 | 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32 | |||
| 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 31 | 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32 | |||
| 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 32 | 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33 | |||
| 7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 33 | 7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 34 | |||
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 | |||
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 39 | |||
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 39 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 | |||
| Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 40 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 41 | |||
| A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 40 | A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
| A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 40 | A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
| Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 40 | Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 42 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
| 1. Introduction | 1. Introduction | |||
| The Extensible Authentication Protocol (EAP) is a an authentication | The Extensible Authentication Protocol (EAP) is a an authentication | |||
| framework that supports multiple authentication methods. The primary | framework that supports multiple authentication methods. The primary | |||
| purpose is network access authentication, and a key-generating method | purpose is network access authentication, and a key-generating method | |||
| is used when the lower layer wants to enforce access control. The | is used when the lower layer wants to enforce access control. The | |||
| EAP keying hierarchy defines two keys to be derived by all key- | EAP keying hierarchy defines two keys to be derived by all key- | |||
| generating EAP methods: the Master Session Key (MSK) and the Extended | generating EAP methods: the Master Session Key (MSK) and the Extended | |||
| MSK (EMSK). In the most common deployment scenario, an EAP peer and | MSK (EMSK). In the most common deployment scenario, an EAP peer and | |||
| skipping to change at page 4, line 47 | skipping to change at page 4, line 47 | |||
| via other authenticators. Other solutions for fast re-authentication | via other authenticators. Other solutions for fast re-authentication | |||
| exist in the literature [MSKHierarchy]. | exist in the literature [MSKHierarchy]. | |||
| In conclusion, to achieve low latency handovers, there is a need for | In conclusion, to achieve low latency handovers, there is a need for | |||
| a method-independent re-authentication protocol that completes in | a method-independent re-authentication protocol that completes in | |||
| less than 2 round trips, preferably with a local server. The EAP re- | less than 2 round trips, preferably with a local server. The EAP re- | |||
| authentication problem statement is described in detail in [RFC5169]. | authentication problem statement is described in detail in [RFC5169]. | |||
| This document specifies EAP Re-authentication Extensions (ERXs) for | This document specifies EAP Re-authentication Extensions (ERXs) for | |||
| efficient re-authentication using EAP. The protocol that uses these | efficient re-authentication using EAP. The protocol that uses these | |||
| extensions itself is referred to as the EAP Re-authentication | extensions is itself referred to as the EAP Re-authentication | |||
| Protocol (ERP). It supports EAP method-independent re-authentication | Protocol (ERP). It supports EAP method-independent re-authentication | |||
| for a peer that has valid, unexpired key material from a previously | for a peer that has valid, unexpired key material from a previously | |||
| performed EAP authentication. The protocol and the key hierarchy | performed EAP authentication. The protocol and the key hierarchy | |||
| required for EAP re-authentication are described in this document. | required for EAP re-authentication are described in this document. | |||
| Note that to support ERP, lower-layer specifications may need to be | Note that to support ERP, lower-layer specifications may need to be | |||
| revised to allow carrying EAP messages that have a code value higher | revised to allow carrying EAP messages that have a code value higher | |||
| than 4 and to accommodate the peer-initiated nature of ERP. | than 4 and to accommodate the peer-initiated nature of ERP. | |||
| Specifically, the IEEE802.1x specification must be revised and RFC | Specifically, the IEEE802.1x specification must be revised and RFC | |||
| 4306 must be updated to carry ERP messages. | 4306 must be updated to carry ERP messages. | |||
| skipping to change at page 5, line 34 | skipping to change at page 5, line 34 | |||
| ER Authenticator - An entity that supports the authenticator | ER Authenticator - An entity that supports the authenticator | |||
| functionality for EAP re-authentication described in this | functionality for EAP re-authentication described in this | |||
| document. All references to "authenticator" in this document | document. All references to "authenticator" in this document | |||
| imply an ER authenticator, unless specifically noted otherwise. | imply an ER authenticator, unless specifically noted otherwise. | |||
| ER Server - An entity that performs the server portion of ERP | ER Server - An entity that performs the server portion of ERP | |||
| described here. This entity may or may not be an EAP server. All | described here. This entity may or may not be an EAP server. All | |||
| references to "server" in this document imply an ER server, unless | references to "server" in this document imply an ER server, unless | |||
| specifically noted otherwise. An ER server is a logical entity; | specifically noted otherwise. An ER server is a logical entity; | |||
| the home ER server is located on the same backend authentication | it may not necessarily be co-located with, or physically part of, | |||
| server as the EAP server in the home domain. The local ER server | a full EAP server. | |||
| may not necessarily be a full EAP server. | ||||
| ERX - EAP re-authentication extensions. | ERX - EAP re-authentication extensions. | |||
| ERP - EAP Re-authentication Protocol that uses the re- | ERP - EAP Re-authentication Protocol that uses the re- | |||
| authentication extensions. | authentication extensions. | |||
| rRK - re-authentication Root Key, derived from the EMSK or DSRK. | rRK - re-authentication Root Key, derived from the EMSK or DSRK. | |||
| rIK - re-authentication Integrity Key, derived from the rRK. | rIK - re-authentication Integrity Key, derived from the rRK. | |||
| skipping to change at page 6, line 30 | skipping to change at page 6, line 30 | |||
| ERP allows a peer and server to mutually verify proof of possession | ERP allows a peer and server to mutually verify proof of possession | |||
| of keying material from an earlier EAP method run and to establish a | of keying material from an earlier EAP method run and to establish a | |||
| security association between the peer and the authenticator. The | security association between the peer and the authenticator. The | |||
| authenticator acts as a pass-through entity for the Re-authentication | authenticator acts as a pass-through entity for the Re-authentication | |||
| Protocol in a manner similar to that of an EAP authenticator | Protocol in a manner similar to that of an EAP authenticator | |||
| described in RFC 3748 [RFC3748]. ERP is a single round-trip exchange | described in RFC 3748 [RFC3748]. ERP is a single round-trip exchange | |||
| between the peer and the server; it is independent of the lower layer | between the peer and the server; it is independent of the lower layer | |||
| and the EAP method used during the full EAP exchange. The ER server | and the EAP method used during the full EAP exchange. The ER server | |||
| may be in the home domain or in the same (visited) domain as the peer | may be in the home domain or in the same (visited) domain as the peer | |||
| and the authenticator. | and the authenticator (i.e.,local domain). | |||
| Figure 2 shows the protocol exchange. The first time the peer | Figure 2 shows the protocol exchange. The first time the peer | |||
| attaches to any network, it performs a full EAP exchange (shown in | attaches to any network, it performs a full EAP exchange (shown in | |||
| Figure 1) with the EAP server; as a result, an MSK is distributed to | Figure 1) with the EAP server; as a result, an MSK is distributed to | |||
| the EAP authenticator. The MSK is then used by the authenticator and | the EAP authenticator. The MSK is then used by the authenticator and | |||
| the peer to establish TSKs as needed. At the time of the initial EAP | the peer to establish TSKs as needed. At the time of the initial EAP | |||
| exchange, the peer and the server also derive an EMSK, which is used | exchange, the peer and the server also derive an EMSK, which is used | |||
| to derive a re-authentication Root Key (rRK). More precisely, a re- | to derive a re-authentication Root Key (rRK). More precisely, a re- | |||
| authentication Root Key is derived from the EMSK or from a Domain- | authentication Root Key is derived from the EMSK or from a Domain- | |||
| Specific Root Key (DSRK), which itself is derived from the EMSK. The | Specific Root Key (DSRK), which is itself derived from the EMSK. The | |||
| rRK is only available to the peer and the ER server and is never | rRK is only available to the peer and the ER server and is never | |||
| handed out to any other entity. Further, a re-authentication | handed out to any other entity. Further, a re-authentication | |||
| Integrity Key (rIK) is derived from the rRK; the peer and the ER | Integrity Key (rIK) is derived from the rRK; the peer and the ER | |||
| server use the rIK to provide proof of possession while performing an | server use the rIK to provide proof of possession while performing an | |||
| ERP exchange. The rIK is also never handed out to any entity and is | ERP exchange. The rIK is also never handed out to any entity and is | |||
| only available to the peer and server. | only available to the peer and server. | |||
| When the ER server is in the home domain, the peer and the server use | ||||
| the rIK and rRK derived from the EMSK; and when the ER server is not | ||||
| in the home domain, they use the DS-rIK and DS-rRK corresponding to | ||||
| the local domain. The domain of the ER server is identified by the | ||||
| realm portion of the keyname-NAI in ERP messages. | ||||
| 3.1. ERP With the Home ER Server | ||||
| EAP Peer EAP Authenticator EAP Server | EAP Peer EAP Authenticator EAP Server | |||
| ======== ================= ========== | ======== ================= ========== | |||
| <--- EAP-Request/ ------ | <--- EAP-Request/ ------ | |||
| Identity | Identity | |||
| ----- EAP Response/ ---> | ----- EAP Response/ ---> | |||
| Identity ---AAA(EAP Response/Identity)--> | Identity ---AAA(EAP Response/Identity)--> | |||
| <--- EAP Method -------> <------ AAA(EAP Method --------> | <--- EAP Method -------> <------ AAA(EAP Method --------> | |||
| exchange exchange) | exchange exchange) | |||
| <----AAA(MSK, EAP-Success)------ | <----AAA(MSK, EAP-Success)------ | |||
| <---EAP-Success--------- | <---EAP-Success--------- | |||
| Figure 1: EAP Authentication | Figure 1: EAP Authentication | |||
| Peer Authenticator Server | Peer ER Authenticator ER Server | |||
| ==== ============= ====== | ==== ============= ====== | |||
| [<-- EAP-Initiate/ ----- | [<-- EAP-Initiate/ ----- | |||
| Re-auth-Start] | Re-auth-Start] | |||
| [<-- EAP-Request/ ------ | [<-- EAP-Request/ ------ | |||
| Identity] | Identity] | |||
| ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> | ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> | |||
| Re-auth/ Re-auth/ | Re-auth/ Re-auth/ | |||
| [Bootstrap] [Bootstrap]) | [Bootstrap] [Bootstrap]) | |||
| skipping to change at page 8, line 14 | skipping to change at page 8, line 8 | |||
| Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this | Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this | |||
| document for the purpose of EAP re-authentication. When the peer | document for the purpose of EAP re-authentication. When the peer | |||
| identifies a target authenticator that supports EAP re- | identifies a target authenticator that supports EAP re- | |||
| authentication, it performs an ERP exchange, as shown in Figure 2; | authentication, it performs an ERP exchange, as shown in Figure 2; | |||
| the exchange itself may happen when the peer attaches to a new | the exchange itself may happen when the peer attaches to a new | |||
| authenticator supporting EAP re-authentication, or prior to | authenticator supporting EAP re-authentication, or prior to | |||
| attachment. The peer initiates ERP by itself; it may also do so in | attachment. The peer initiates ERP by itself; it may also do so in | |||
| response to an EAP-Initiate/Re-auth-Start message from the new | response to an EAP-Initiate/Re-auth-Start message from the new | |||
| authenticator. The EAP-Initiate/Re-auth-Start message allows the | authenticator. The EAP-Initiate/Re-auth-Start message allows the | |||
| authenticator to trigger the ERP exchange. | authenticator to trigger the ERP exchange. The EAP-Finish message | |||
| also can be used by the authenticator to announce local domain name. | ||||
| It is plausible that the authenticator does not know whether the peer | It is plausible that the authenticator does not know whether the peer | |||
| supports ERP and whether the peer has performed a full EAP | supports ERP and whether the peer has performed a full EAP | |||
| authentication through another authenticator. The authenticator MAY | authentication through another authenticator. The authenticator MAY | |||
| initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start | initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start | |||
| message, and if there is no response, it will send the EAP-Request/ | message, and if there is no response, it will send the EAP-Request/ | |||
| Identity message. Note that this avoids having two EAP messages in | Identity message. Note that this avoids having two EAP messages in | |||
| flight at the same time [RFC3748]. The authenticator may send the | flight at the same time [RFC3748]. The authenticator may send the | |||
| EAP-Initiate/Re-auth-Start message and wait for a short, locally | EAP-Initiate/Re-auth-Start message and wait for a short, locally | |||
| configured amount of time. If the peer does not already know, this | configured amount of time. If the peer does not already know, this | |||
| skipping to change at page 9, line 39 | skipping to change at page 9, line 36 | |||
| In an ERP bootstrap exchange, the peer MAY request the server for the | In an ERP bootstrap exchange, the peer MAY request the server for the | |||
| rRK lifetime. If so, the ER server sends the rRK lifetime in the | rRK lifetime. If so, the ER server sends the rRK lifetime in the | |||
| EAP-Finish/Re-auth message. | EAP-Finish/Re-auth message. | |||
| The peer verifies the replay protection and the integrity of the | The peer verifies the replay protection and the integrity of the | |||
| message. It then uses the sequence number in the EAP-Finish/Re-auth | message. It then uses the sequence number in the EAP-Finish/Re-auth | |||
| message to compute the rMSK. The lower-layer security association | message to compute the rMSK. The lower-layer security association | |||
| protocol is ready to be triggered after this point. | protocol is ready to be triggered after this point. | |||
| When the ER server is in the home domain, the peer and the server use | ||||
| the rIK and rRK derived from the EMSK; and when the ER server is in | ||||
| the local domain, they use the DS-rIK and DS-rRK corresponding to the | ||||
| local domain. The domain of the ER server is identified by the realm | ||||
| portion of the keyname-NAI in ERP messages. | ||||
| 3.1. ERP With the Home ER Server | ||||
| If the peer is in the home domain and does not know the domain name ( | ||||
| did not receive the domain name through the EAP-Initiate/ | ||||
| Re-auth-Start message or via the lower-layer announcement, due to a | ||||
| missed announcement or lack of support for domain name announcements | ||||
| in a specific lower layer) or there is no the local server in the | ||||
| same domain as the peer, it SHOULD initiate ERP bootstrap exchange | ||||
| with the home ER server to obtain the domain name. | ||||
| The defined ER extensions allow executing the ERP with an ER server | ||||
| in the home domain. The home ER server may be co- located with a | ||||
| home AAA server. The ERP with the Home ER Server is the similar as | ||||
| ERP exchange described in Figure 2. | ||||
| Peer ER Authenticator Home ER Server | ||||
| ==== ============= ====== | ||||
| [<-- EAP-Initiate/ ----- | ||||
| Re-auth-Start] | ||||
| [<-- EAP-Request/ ------ | ||||
| Identity] | ||||
| ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> | ||||
| Re-auth/ Re-auth/ | ||||
| [Bootstrap] [Bootstrap]) | ||||
| <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- | ||||
| Re-auth/ Re-auth/ | ||||
| [Bootstrap] [Bootstrap]) | ||||
| Note: [] brackets indicate optionality. | ||||
| Figure 3: ER ExplicitBootstrapping Exchange/ERP with the Home ER | ||||
| Sever | ||||
| 3.2. ERP with a Local ER Server | 3.2. ERP with a Local ER Server | |||
| The defined ER extensions allow executing the ERP with an ER server | The defined ER extensions allow executing the ERP with an ER server | |||
| in the local domain (access network). The local ER server may be co- | in the local domain (access network) if the peer moves out of home | |||
| located with a local AAA server. The peer may learn about the | domain. The local ER server may be co-located with a local AAA | |||
| presence of a local ER server in the network and the local domain | server. The peer may learn about the presence of a local ER server | |||
| name (or ER server name) either via the lower layer or by means of | in the network and the local domain name (or ER server name) either | |||
| ERP bootstrapping. The peer uses the domain name and the EMSK to | via the lower layer or by means of ERP exchange. The peer uses the | |||
| compute the DSRK and from that key, the DS-rRK; the peer also uses | domain name and the EMSK to compute the DSRK and from that key, the | |||
| the domain name in the realm portion of the keyName-NAI for using ERP | DS-rRK; the peer also uses the domain name in the realm portion of | |||
| in the local domain. Figure 3 shows the full EAP and subsequent | the keyName-NAI for using ERP in the local domain. Figure 4 shows | |||
| local ERP exchange; Figure 4 shows it with a local ER server. | the ER Implicit bootstrapping exchange through local ER | |||
| Server;Figure 5shows ERP with a local ER server. | ||||
| Peer EAP Authenticator Local ER Server Home EAP Server | Peer EAP Authenticator Local AAA Agent Home EAP Server | |||
| /ER Authenticator /Local ER Server | ||||
| ==== ================= =============== =============== | ==== ================= =============== =============== | |||
| <-- EAP-Request/ -- | <-- EAP-Request/ -- | |||
| Identity | Identity | |||
| -- EAP Response/--> | -- EAP Response/--> | |||
| Identity --AAA(EAP Response/--> | Identity --AAA(EAP Response/--> | |||
| Identity) --AAA(EAP Response/ --> | Identity, --AAA(EAP Response/ --> | |||
| Identity, | [domain name]) Identity, | |||
| [DSRK Request, | [DSRK Request, | |||
| domain name]) | domain name]) | |||
| <------------------------ EAP Method exchange------------------> | <------------------------ EAP Method exchange------------------> | |||
| <---AAA(MSK, DSRK, ---- | <---AAA(MSK, DSRK, ---- | |||
| EMSKname, | EMSKname, | |||
| EAP-Success) | EAP-Success) | |||
| <--- AAA(MSK, ----- | <--- AAA(MSK, ----- | |||
| EAP-Success) | EAP-Success) | |||
| <---EAP-Success----- | <---EAP-Success----- | |||
| Figure 3: Local ERP Exchange, Initial EAP Exchange | Figure 4: Local ERP Exchange, Initial EAP Exchange | |||
| Peer ER Authenticator Local ER Server | Peer ER Authenticator Local ER Server | |||
| ==== ================ =============== | ==== ================ =============== | |||
| [<-- EAP-Initiate/ -------- | [<-- EAP-Initiate/ -------- | |||
| Re-auth-Start] | Re-auth-Start] | |||
| [<-- EAP-Request/ --------- | [<-- EAP-Request/ --------- | |||
| Identity] | Identity] | |||
| ---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ --------> | ---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ --------> | |||
| Re-auth Re-auth) | Re-auth Re-auth) | |||
| <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- | <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- | |||
| Re-auth Re-auth) | Re-auth Re-auth) | |||
| Figure 4: Local ERP Exchange | Figure 5: Local ERP Exchange | |||
| As shown in Figure 4, the local ER server may be present in the path | As shown in Figure 4, the local ER server may be present in the path | |||
| of the full EAP exchange (e.g., this may be one of the AAA entities, | of the full EAP exchange (e.g., this may be one of the AAA entities, | |||
| such as AAA proxies, in the path between the authenticator and the | such as AAA proxies, in the path between the EAP authenticator and | |||
| home EAP server of the peer). In that case, the ER server requests | the home EAP server of the peer). In that case, the local ER server | |||
| the DSRK by sending the domain name to the EAP server. In response, | requests the DSRK by sending the domain name to the home EAP server | |||
| the EAP server computes the DSRK by following the procedure specified | through AAA message. In response, the home EAP server computes the | |||
| in [RFC5295] and sends the DSRK and the key name, EMSKname, to the ER | DSRK by following the procedure specified in [RFC5295] and sends the | |||
| server in the claimed domain. The local domain is responsible for | DSRK and the key name, EMSKname, to the ER server in the claimed | |||
| announcing that same domain name via the lower layer to the peer. | domain (i.e., local ER Server). The local domain is responsible for | |||
| announcing that same domain name via the lower layer to the peer, | ||||
| If the peer does not know the domain name (did not receive the domain | e.g., DHCP based local domain name discovery specified in | |||
| name via the lower-layer announcement, due to a missed announcement | [I-D.ietf-hokey-ldn-discovery], or through the EAP-Initiate/ | |||
| or lack of support for domain name announcements in a specific lower | Re-auth-Start message during subsequent ERP with local ER server. | |||
| layer), it SHOULD initiate ERP bootstrap exchange with the home ER | ||||
| server to obtain the domain name. The local ER server SHALL request | ||||
| the home AAA server for the DSRK by sending the domain name in the | ||||
| AAA message that carries the EAP-Initiate/Re-auth bootstrap message. | ||||
| The local ER server MUST be in the path from the peer to the home ER | ||||
| server. If it is not, it cannot request the DSRK. | ||||
| After receiving the DSRK and the EMSKname, the local ER server | After receiving the DSRK and the EMSKname, the local ER server | |||
| computes the DS-rRK and the DS-rIK from the DSRK as defined in | computes the DS-rRK and the DS-rIK from the DSRK as defined in | |||
| Sections 4.1 and 4.3 below. After receiving the domain name, the | Sections 4.1 and 4.3 below. After receiving the domain name, the | |||
| peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys | peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys | |||
| are referred to by a keyName-NAI formed as follows: the username part | are referred to by a keyName-NAI formed as follows: the username part | |||
| of the NAI is the EMSKname, the realm portion of the NAI is the | of the NAI is the EMSKname, the realm portion of the NAI is the | |||
| domain name. Both parties also maintain a sequence number | domain name. Both parties also maintain a sequence number | |||
| (initialized to zero) corresponding to the specific keyName-NAI. | (initialized to zero) corresponding to the specific keyName-NAI. | |||
| Subsequently, when the peer attaches to an authenticator within the | Subsequently, when the peer attaches to an authenticator within the | |||
| local domain, it may perform an ERP exchange with the local ER server | local domain, it may perform an ERP exchange with the local ER server | |||
| to obtain an rMSK for the new authenticator. | to obtain an rMSK for the new authenticator. The ERP with the local | |||
| ER Server is the similar as ERP exchange described in Figure 2. | ||||
| 4. ER Key Hierarchy | 4. ER Key Hierarchy | |||
| Each time the peer re-authenticates to the network, the peer and the | Each time the peer re-authenticates to the network, the peer and the | |||
| authenticator establish an rMSK. The rMSK serves the same purposes | authenticator establish an rMSK. The rMSK serves the same purposes | |||
| that an MSK, which is the result of full EAP authentication, serves. | that an MSK, which is the result of full EAP authentication, serves. | |||
| To prove possession of the rRK, we specify the derivation of another | To prove possession of the rRK, we specify the derivation of another | |||
| key, the rIK. These keys are derived from the rRK. Together they | key, the rIK. These keys are derived from the rRK. Together they | |||
| constitute the ER key hierarchy. | constitute the ER key hierarchy. | |||
| skipping to change at page 12, line 25 | skipping to change at page 13, line 20 | |||
| The rRK is used to derive an rIK, and rMSKs for one or more | The rRK is used to derive an rIK, and rMSKs for one or more | |||
| authenticators. The figure below shows the key hierarchy with the | authenticators. The figure below shows the key hierarchy with the | |||
| rRK, rIK, and rMSKs. | rRK, rIK, and rMSKs. | |||
| rRK | rRK | |||
| | | | | |||
| +--------+--------+ | +--------+--------+ | |||
| | | | | | | | | |||
| rIK rMSK1 ...rMSKn | rIK rMSK1 ...rMSKn | |||
| Figure 5: Re-authentication Key Hierarchy | Figure 6: Re-authentication Key Hierarchy | |||
| The derivations in this document are according to [RFC5295]. Key | The derivations in this document are according to [RFC5295]. Key | |||
| derivations and field encodings, where unspecified, default to that | derivations and field encodings, where unspecified, default to that | |||
| document. | document. | |||
| 4.1. rRK Derivation | 4.1. rRK Derivation | |||
| The rRK may be derived from the EMSK or DSRK. This section provides | The rRK may be derived from the EMSK or DSRK. This section provides | |||
| the relevant key derivations for that purpose. | the relevant key derivations for that purpose. | |||
| skipping to change at page 16, line 31 | skipping to change at page 17, line 25 | |||
| new rRK. Previously delivered rMSKs MAY still be used until the | new rRK. Previously delivered rMSKs MAY still be used until the | |||
| expiry of the lifetime. | expiry of the lifetime. | |||
| o A given rMSK MUST NOT be shared by multiple authenticators. | o A given rMSK MUST NOT be shared by multiple authenticators. | |||
| 5. Protocol Details | 5. Protocol Details | |||
| 5.1. ERP Bootstrapping | 5.1. ERP Bootstrapping | |||
| We identify two types of bootstrapping for ERP: explicit and implicit | We identify two types of bootstrapping for ERP: explicit and implicit | |||
| bootstrapping. In implicit bootstrapping, the local ER server SHOULD | bootstrapping. In implicit bootstrapping, the local AAA client or | |||
| include its domain name and SHOULD request the DSRK from the home AAA | agent supporting EAP re-authentication SHOULD include its domain name | |||
| server during the initial EAP exchange, in the AAA message | and SHOULD request the DSRK from the home AAA server during the | |||
| encapsulating the first EAP Response message sent by the peer. If | initial EAP exchange, in the AAA message encapsulating the first EAP | |||
| the EAP exchange is successful, the server sends the DSRK for the | Response message sent by the peer. If such EAP exchange is | |||
| local ER server (derived using the EMSK and the domain name as | successful, the home EAP server sends the DSRK for the specified | |||
| specified in [RFC5295]), EMSKname, and DSRK lifetime along with the | local AAA client or agent (derived using the EMSK and the domain name | |||
| EAP-Success message. The local ER server MUST extract the DSRK, | as specified in [RFC5295]), EMSKname, and DSRK lifetime along with | |||
| EMSKname, and DSRK lifetime (if present) before forwarding the EAP- | the EAP-Success message. The local AAA client or agent MUST extract | |||
| Success message to the peer, as specified in [I-D.ietf-dime-erp]. | the DSRK, EMSKname, and DSRK lifetime (if present) before forwarding | |||
| Note that the MSK (also present along with the EAP Success message) | the EAP-Success message to the peer, as specified in | |||
| is extracted by the EAP authenticator as usual. The peer learns the | [I-D.ietf-dime-erp]. Note that the MSK (also present along with the | |||
| domain name through the EAP-Initiate/Re-auth-Start message or via | EAP Success message) is extracted by the EAP authenticator as usual. | |||
| lower-layer announcements. When the domain name is available to the | The peer learns the domain name through the EAP-Initiate/ | |||
| peer during or after the full EAP authentication, it attempts to use | Re-auth-Start message, lower-layer announcements | |||
| ERP when it associates with a new authenticator. | [I-D.ietf-hokey-ldn-discovery] or via ER Explicit bootstrapping | |||
| exchange. When the domain name is available to the peer during or | ||||
| after the full EAP authentication, it attempts to use ERP when it | ||||
| associates with a new authenticator. | ||||
| If the peer does not know the domain name (did not receive the domain | If the peer does not know the domain name (did not receive the domain | |||
| name via the lower-layer announcement, due to a missed announcement | name through the EAP-Initiate/Re-auth-Start message or via the lower- | |||
| or lack of support for domain name announcements in a specific lower | layer announcement, due to a missed announcement or lack of support | |||
| layer), it SHOULD initiate ERP bootstrap exchange (ERP exchange with | for domain name announcements in a specific lower layer), it SHOULD | |||
| the bootstrap flag turned on) with the home ER server to obtain the | initiate Explicit ER bootstrap exchange (ERP exchange with the | |||
| domain name. The local ER server behavior is the same as described | bootstrap flag turned on) with the ER server in the same (visited) | |||
| above. The peer MAY also initiate bootstrapping to fetch information | domain as the peer to obtain the local domain name. The peer MAY | |||
| such as the rRK lifetime from the AAA server. | also initiate bootstrapping to fetch information such as the rRK | |||
| lifetime from the AAA server. | ||||
| The following steps describe the ERP explicit bootstrapping process: | The following steps describe the ERP explicit bootstrapping process: | |||
| o The peer sends the EAP-Initiate/Re-auth message with the | o The peer sends the EAP-Initiate/Re-auth message with the | |||
| bootstrapping flag turned on. The bootstrap message is always | bootstrapping flag turned on. The bootstrap message is always | |||
| sent to the home AAA server, and the keyname-NAI attribute in the | sent to the ER server, and the keyname-NAI attribute in the | |||
| bootstrap message is constructed as follows: the username portion | bootstrap message is constructed as follows: the username portion | |||
| of the NAI contains the EMSKname, and the realm portion contains | of the NAI contains the EMSKname, and the realm portion contains | |||
| the home domain name. | the home domain name. | |||
| o In addition, the message MUST contain a sequence number for replay | o In addition, the message MUST contain a sequence number for replay | |||
| protection, a cryptosuite, and an integrity checksum. The | protection, a cryptosuite, and an integrity checksum. The | |||
| cryptosuite indicates the authentication algorithm. The integrity | cryptosuite indicates the authentication algorithm. The integrity | |||
| checksum indicates that the message originated at the claimed | checksum indicates that the message originated at the claimed | |||
| entity, the peer indicated by the Peer-ID, or the rIKname. | entity, the peer indicated by the Peer-ID, or the rIKname. | |||
| o The peer MAY additionally set the lifetime flag to request the key | o The peer MAY additionally set the lifetime flag to request the key | |||
| lifetimes. | lifetimes. | |||
| o When an ERP-capable authenticator receives the EAP-Initiate/ | o When an ERP-capable authenticator receives the EAP-Initiate/ | |||
| Re-auth message from a peer, it copies the contents of the | Re-auth message from a peer, it copies the contents of the | |||
| keyName-NAI into the User-Name attribute of RADIUS [RFC2865]. The | keyName-NAI into the User-Name attribute of RADIUS [RFC2865]. The | |||
| rest of the process is similar to that described in [RFC3579]. | rest of the process is similar to that described in [RFC3579]. | |||
| o If a local ER server is present, the local ER server MUST include | ||||
| the DSRK request and its domain name in the AAA message | ||||
| encapsulating the EAP-Initiate/Re-auth message sent by the peer. | ||||
| o Upon receipt of an EAP-Initiate/Re-auth message, the server | o Upon receipt of an EAP-Initiate/Re-auth message, the server | |||
| verifies whether the message is fresh or is a replay by evaluating | verifies whether the message is fresh or is a replay by evaluating | |||
| whether the received sequence number is equal to or greater than | whether the received sequence number is equal to or greater than | |||
| the expected sequence number for that rIK. The server then | the expected sequence number for that rIK. The server then | |||
| verifies to ensure that the cryptosuite used by the peer is | verifies to ensure that the cryptosuite used by the peer is | |||
| acceptable. Next, it verifies the origin authentication of the | acceptable. Next, it verifies the origin authentication of the | |||
| message by looking up the rIK. If any of the checks fail, the | message by looking up the rIK. If any of the checks fail, the | |||
| server sends an EAP-Finish/Re-auth message with the Result flag | server sends an EAP-Finish/Re-auth message with the Result flag | |||
| set to '1'. Please refer to Section 5.2.2 for details on failure | set to '1'. Please refer to Section 5.2.2 for details on failure | |||
| handling. This error MUST NOT have any correlation to any EAP- | handling. This error MUST NOT have any correlation to any EAP- | |||
| skipping to change at page 18, line 16 | skipping to change at page 19, line 12 | |||
| * The same keyName-NAI as in the EAP-Initiate/Re-auth message. | * The same keyName-NAI as in the EAP-Initiate/Re-auth message. | |||
| * If the lifetime flag was set in the EAP-Initiate/Re-auth | * If the lifetime flag was set in the EAP-Initiate/Re-auth | |||
| message, the ER server SHOULD include the rRK lifetime and the | message, the ER server SHOULD include the rRK lifetime and the | |||
| rMSK lifetime in the EAP-Finish/Re-auth message. The server | rMSK lifetime in the EAP-Finish/Re-auth message. The server | |||
| may have a local policy for the network to maintain and enforce | may have a local policy for the network to maintain and enforce | |||
| lifetime unilaterally. In such cases, the server need not | lifetime unilaterally. In such cases, the server need not | |||
| respond to the peer's request for the lifetime. | respond to the peer's request for the lifetime. | |||
| * If the bootstrap flag is set and a DSRK request is received, | * If the bootstrap flag is set, the ER server MUST include the | |||
| the server MUST include the domain name to which the DSRK is | domain name to which the DSRK is being sent along with the EAP- | |||
| being sent. | Finish/Re-auth message. | |||
| * If the home ER server verifies the authorization of a local | * If the ER server verifies the authorization of a local domain | |||
| domain server, it MAY include the Authorization Indication TLV | server, it MAY include the Authorization Indication TLV to | |||
| to indicate to the peer that the server (that received the DSRK | indicate to the peer that the server (that received the DSRK | |||
| and that is advertising the domain included in the domain name | and that is advertising the domain included in the domain name | |||
| TLV) is authorized. | TLV) is authorized. | |||
| * An authentication tag MUST be included to prove that the EAP- | * An authentication tag MUST be included to prove that the EAP- | |||
| Finish/Re-auth message originates at a server that possesses | Finish/Re-auth message originates at a server that possesses | |||
| the rIK corresponding to the EMSKname-NAI. | the rIK corresponding to the EMSKname-NAI. | |||
| o If the ERP exchange is successful, and the local ER server sent a | o If the ERP exchange is successful, the ER server SHOULD request | |||
| DSRK request, the home ER server MUST include the DSRK for the | the DSRK from the home EAP server during the initial EAP exchange | |||
| local ER server (derived using the EMSK and the domain name as | as specified in [I-D.ietf-dime-local-keytran], the home EAP server | |||
| specified in [RFC5295]), EMSKname, and DSRK lifetime along with | MUST include the DSRK for the local ER server (derived using the | |||
| the EAP-Finish/Re-auth message. | EMSK and the domain name as specified in [RFC5295]), EMSKname, and | |||
| DSRK lifetime along with the EAP-Finish/Re-auth message. | ||||
| o In addition, the rMSK is sent along with the EAP-Finish/Re-auth | o In addition, the rMSK is sent along with the EAP-Finish/Re-auth | |||
| message, in a AAA attribute [I-D.ietf-dime-erp]. | message, in a AAA attribute [I-D.ietf-dime-erp]. | |||
| o The local ER server MUST extract the DSRK, EMSKname, and DSRK | o The ER server MUST extract the DSRK, EMSKname, and DSRK lifetime | |||
| lifetime (if present), before forwarding the EAP-Finish/Re-auth | (if present) before forwarding the EAP-Success message to the | |||
| message to the peer, as specified in [I-D.ietf-dime-erp]. | peer, as specified in [I-D.ietf-dime-erp]. | |||
| o The authenticator receives the rMSK. | o The authenticator receives the rMSK. | |||
| o When the peer receives an EAP-Finish/Re-auth message with the | o When the peer receives an EAP-Finish/Re-auth message with the | |||
| bootstrap flag set, if a local domain name is present, it MUST use | bootstrap flag set, if a local domain name is present, it MUST use | |||
| that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName- | that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName- | |||
| NAI, and initialize the replay counter for the DS-rIK. If not, | NAI, and initialize the replay counter for the DS-rIK. If not, | |||
| the peer SHOULD derive the domain-specific keys using the domain | the peer SHOULD derive the domain-specific keys using the domain | |||
| name it learned via the lower layer or from the EAP-Initiate/ | name it learned via the lower layer or from the EAP-Initiate/ | |||
| Re-auth-Start message. If the peer does not know the domain name, | Re-auth-Start message. If the peer does not know the domain name, | |||
| skipping to change at page 23, line 22 | skipping to change at page 24, line 22 | |||
| packet format defined in RFC 3748 [RFC3748]. | packet format defined in RFC 3748 [RFC3748]. | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Code | Identifier | Length | | | Code | Identifier | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Type-Data ... | | Type | Type-Data ... | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | |||
| Figure 6: EAP Packet | Figure 7: EAP Packet | |||
| Code | Code | |||
| 5 Initiate | 5 Initiate | |||
| 6 Finish | 6 Finish | |||
| Two new code values are defined for the purpose of ERP. | Two new code values are defined for the purpose of ERP. | |||
| Identifier | Identifier | |||
| skipping to change at page 24, line 19 | skipping to change at page 25, line 19 | |||
| auth-Start (assigned Type 1) and Re-auth (assigned Type 2). | auth-Start (assigned Type 1) and Re-auth (assigned Type 2). | |||
| Type-Data | Type-Data | |||
| The Type-Data field varies with the Type of re-authentication | The Type-Data field varies with the Type of re-authentication | |||
| packet. | packet. | |||
| 5.3.1. EAP-Initiate/Re-auth-Start Packet | 5.3.1. EAP-Initiate/Re-auth-Start Packet | |||
| The EAP-Initiate/Re-auth-Start packet contains the parameters shown | The EAP-Initiate/Re-auth-Start packet contains the parameters shown | |||
| in Figure 7. | in Figure 8. | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Code | Identifier | Length | | | Code | Identifier | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Reserved | 1 or more TVs or TLVs ~ | | Type | Reserved | 1 or more TVs or TLVs ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 7: EAP-Initiate/Re-auth-Start Packet | Figure 8: EAP-Initiate/Re-auth-Start Packet | |||
| Type = 1. | Type = 1. | |||
| Reserved, MUST be zero. Set to zero on transmission and ignored | Reserved, MUST be zero. Set to zero on transmission and ignored | |||
| on reception. | on reception. | |||
| One or more TVs or TLVs are used to convey information to the | One or more TVs or TLVs are used to convey information to the | |||
| peer; for instance, the authenticator may send the domain name to | peer; for instance, the authenticator may send the domain name to | |||
| the peer. | the peer. | |||
| skipping to change at page 25, line 6 | skipping to change at page 26, line 6 | |||
| is a 1-octet type payload and a 1-octet length payload. The | is a 1-octet type payload and a 1-octet length payload. The | |||
| length field indicates the length of the value expressed in number | length field indicates the length of the value expressed in number | |||
| of octets. | of octets. | |||
| Domain-Name: This is a TLV payload. The Type is 4. The domain | Domain-Name: This is a TLV payload. The Type is 4. The domain | |||
| name is to be used as the realm in an NAI [RFC4282]. The | name is to be used as the realm in an NAI [RFC4282]. The | |||
| Domain-Name attribute SHOULD be present in an EAP-Initiate/ | Domain-Name attribute SHOULD be present in an EAP-Initiate/ | |||
| Re-auth-Start message. | Re-auth-Start message. | |||
| In addition, channel binding information MAY be included; see | In addition, channel binding information MAY be included; see | |||
| Section 5.5 for discussion. See Figure 11 for parameter | Section 5.5 for discussion. See Figure 12 for parameter | |||
| specification. | specification. | |||
| 5.3.1.1. Authenticator Operation | 5.3.1.1. Authenticator Operation | |||
| The authenticator MAY send the EAP-Initiate/Re-auth-Start message to | The authenticator MAY send the EAP-Initiate/Re-auth-Start message to | |||
| indicate support for ERP to the peer and to initiate ERP if the peer | indicate support for ERP to the peer and to initiate ERP if the peer | |||
| has already performed full EAP authentication and has unexpired key | has already performed full EAP authentication and has unexpired key | |||
| material. The authenticator SHOULD include the domain name TLV to | material. The authenticator SHOULD include the domain name TLV to | |||
| allow the peer to learn it without lower-layer support or the ERP | allow the peer to learn it without lower-layer support or the ERP | |||
| bootstrapping exchange. | bootstrapping exchange. | |||
| skipping to change at page 25, line 39 | skipping to change at page 26, line 39 | |||
| the EAP-Initiate/Re-auth-Start message from the authenticator. If | the EAP-Initiate/Re-auth-Start message from the authenticator. If | |||
| the peer does not recognize the Initiate code value, it silently | the peer does not recognize the Initiate code value, it silently | |||
| discards the message. If the peer has already sent the EAP-Initiate/ | discards the message. If the peer has already sent the EAP-Initiate/ | |||
| Re-auth message to begin the ERP exchange, it silently discards the | Re-auth message to begin the ERP exchange, it silently discards the | |||
| message. | message. | |||
| If the EAP-Initiate/Re-auth-Start message contains the domain name, | If the EAP-Initiate/Re-auth-Start message contains the domain name, | |||
| and if the peer does not already have the domain information, the | and if the peer does not already have the domain information, the | |||
| peer SHOULD use the domain name to compute the DSRK and use the | peer SHOULD use the domain name to compute the DSRK and use the | |||
| corresponding DS-rIK to send an EAP-Initiate/Re-auth message to start | corresponding DS-rIK to send an EAP-Initiate/Re-auth message to start | |||
| an ERP exchange with the local ER server. If the peer has already | an ERP exchange with the local ER server. If there are the local ER | |||
| initiated an ERP exchange with the home ER server, it MAY choose to | server between the peer and the home ER server and the peer has | |||
| not start an ERP exchange with the local ER server. | already initiated an ERP exchange with the local ER server, it SHOULD | |||
| choose to not start an ERP exchange with the home ER server. | ||||
| 5.3.2. EAP-Initiate/Re-auth Packet | 5.3.2. EAP-Initiate/Re-auth Packet | |||
| The EAP-Initiate/Re-auth packet contains the parameters shown in | The EAP-Initiate/Re-auth packet contains the parameters shown in | |||
| Figure 8. | Figure 9. | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Code | Identifier | Length | | | Code | Identifier | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type |R|B|L| Reserved| SEQ | | | Type |R|B|L| Reserved| SEQ | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | 1 or more TVs or TLVs ~ | | 1 or more TVs or TLVs ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | cryptosuite | Authentication Tag ~ | | cryptosuite | Authentication Tag ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 8: EAP-Initiate/Re-auth Packet | Figure 9: EAP-Initiate/Re-auth Packet | |||
| Type = 2. | Type = 2. | |||
| Flags | Flags | |||
| 'R' - The R flag is set to 0 and ignored upon reception. | 'R' - The R flag is set to 0 and ignored upon reception. | |||
| 'B' - The B flag is used as the bootstrapping flag. If the | 'B' - The B flag is used as the bootstrapping flag. If the | |||
| flag is turned on, the message is a bootstrap message. | flag is turned on, the message is a bootstrap message. | |||
| skipping to change at page 27, line 7 | skipping to change at page 28, line 7 | |||
| hexadecimal values. The EMSKname is 64 bits in length and so | hexadecimal values. The EMSKname is 64 bits in length and so | |||
| the username portion takes up 128 octets. If the rIK is | the username portion takes up 128 octets. If the rIK is | |||
| derived from the EMSK, the realm part of the NAI is the home | derived from the EMSK, the realm part of the NAI is the home | |||
| domain name, and if the rIK is derived from a DSRK, the realm | domain name, and if the rIK is derived from a DSRK, the realm | |||
| part of the NAI is the domain name used in the derivation of | part of the NAI is the domain name used in the derivation of | |||
| the DSRK. The NAI syntax follows [RFC4282]. Exactly one | the DSRK. The NAI syntax follows [RFC4282]. Exactly one | |||
| keyName-NAI attribute SHALL be present in an EAP-Initiate/ | keyName-NAI attribute SHALL be present in an EAP-Initiate/ | |||
| Re-auth packet. | Re-auth packet. | |||
| In addition, channel binding information MAY be included; see | In addition, channel binding information MAY be included; see | |||
| Section 5.5 for discussion. See Figure 11 for parameter | Section 5.5 for discussion. See Figure 12 for parameter | |||
| specification. | specification. | |||
| Cryptosuite: This field indicates the integrity algorithm used for | Cryptosuite: This field indicates the integrity algorithm used for | |||
| ERP. Key lengths and output lengths are either indicated or are | ERP. Key lengths and output lengths are either indicated or are | |||
| obvious from the cryptosuite name. We specify some cryptosuites | obvious from the cryptosuite name. We specify some cryptosuites | |||
| below: | below: | |||
| * 0 RESERVED | * 0 RESERVED | |||
| * 1 HMAC-SHA256-64 | * 1 HMAC-SHA256-64 | |||
| skipping to change at page 27, line 33 | skipping to change at page 28, line 33 | |||
| HMAC-SHA256-128 is mandatory to implement and should be enabled in | HMAC-SHA256-128 is mandatory to implement and should be enabled in | |||
| the default configuration. | the default configuration. | |||
| Authentication Tag: This field contains the integrity checksum | Authentication Tag: This field contains the integrity checksum | |||
| over the ERP packet, excluding the authentication tag field | over the ERP packet, excluding the authentication tag field | |||
| itself. The length of the field is indicated by the Cryptosuite. | itself. The length of the field is indicated by the Cryptosuite. | |||
| 5.3.3. EAP-Finish/Re-auth Packet | 5.3.3. EAP-Finish/Re-auth Packet | |||
| The EAP-Finish/Re-auth packet contains the parameters shown in | The EAP-Finish/Re-auth packet contains the parameters shown in | |||
| Figure 9. | Figure 10. | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Code | Identifier | Length | | | Code | Identifier | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type |R|B|L| Reserved | SEQ ~ | | Type |R|B|L| Reserved | SEQ ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | 1 or more TVs or TLVs ~ | | 1 or more TVs or TLVs ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | cryptosuite | Authentication Tag ~ | | cryptosuite | Authentication Tag ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 9: EAP-Finish/Re-auth Packet | Figure 10: EAP-Finish/Re-auth Packet | |||
| Type = 2. | Type = 2. | |||
| Flags | Flags | |||
| 'R' - The R flag is used as the Result flag. When set to 0, it | 'R' - The R flag is used as the Result flag. When set to 0, it | |||
| indicates success, and when set to '1', it indicates a failure. | indicates success, and when set to '1', it indicates a failure. | |||
| 'B' - The B flag is used as the bootstrapping flag. If the | 'B' - The B flag is used as the bootstrapping flag. If the | |||
| flag is turned on, the message is a bootstrap message. | flag is turned on, the message is a bootstrap message. | |||
| skipping to change at page 29, line 13 | skipping to change at page 30, line 13 | |||
| attribute SHOULD be present. | attribute SHOULD be present. | |||
| Domain-Name: This is a TLV payload. The Type is 4. The domain | Domain-Name: This is a TLV payload. The Type is 4. The domain | |||
| name is to be used as the realm in an NAI [RFC4282]. Domain- | name is to be used as the realm in an NAI [RFC4282]. Domain- | |||
| Name attribute MUST be present in an EAP-Finish/Re-auth message | Name attribute MUST be present in an EAP-Finish/Re-auth message | |||
| if the bootstrapping flag is set and if the local ER server | if the bootstrapping flag is set and if the local ER server | |||
| sent a DSRK request. | sent a DSRK request. | |||
| List of cryptosuites: This is a TLV payload. The Type is 5. | List of cryptosuites: This is a TLV payload. The Type is 5. | |||
| The value field contains a list of cryptosuites, each of size 1 | The value field contains a list of cryptosuites, each of size 1 | |||
| octet. The cryptosuite values are as specified in Figure 8. | octet. The cryptosuite values are as specified in Figure 9. | |||
| The server SHOULD include this attribute if the cryptosuite | The server SHOULD include this attribute if the cryptosuite | |||
| used in the EAP-Initiate/Re-auth message was not acceptable and | used in the EAP-Initiate/Re-auth message was not acceptable and | |||
| the message is being rejected. The server MAY include this | the message is being rejected. The server MAY include this | |||
| attribute in other cases. The server MAY use this attribute to | attribute in other cases. The server MAY use this attribute to | |||
| signal to the peer about its cryptographic algorithm | signal to the peer about its cryptographic algorithm | |||
| capabilities. | capabilities. | |||
| Authorization Indication: This is a TLV payload. The Type is | Authorization Indication: This is a TLV payload. The Type is | |||
| 6. This attribute MAY be included in the EAP-Finish/Re-auth | 6. This attribute MAY be included in the EAP-Finish/Re-auth | |||
| message when a DSRK is delivered to a local ER server and if | message when a DSRK is delivered to a local ER server and if | |||
| the home ER server can verify the authorization of the local ER | the home EAP server can verify the authorization of the local | |||
| server to advertise the domain name included in the domain TLV | ER server to advertise the domain name included in the domain | |||
| in the same message. The value field in the TLV contains an | TLV in the same message. The value field in the TLV contains | |||
| authentication tag computed over the entire packet, starting | an authentication tag computed over the entire packet, starting | |||
| from the first bit of the code field to the last bit of the | from the first bit of the code field to the last bit of the | |||
| cryptosuite field, with the value field of the Authorization | cryptosuite field, with the value field of the Authorization | |||
| Indication TLV filled with all 0s for the computation. The key | Indication TLV filled with all 0s for the computation. The key | |||
| used for the computation MUST be derived from the EMSK with key | used for the computation MUST be derived from the EMSK with key | |||
| label "DSRK Delivery Authorized Key@ietf.org" and optional data | label "DSRK Delivery Authorized Key@ietf.org" and optional data | |||
| containing an ASCII string representing the key management | containing an ASCII string representing the key management | |||
| domain that the DSRK is being derived for. | domain that the DSRK is being derived for. | |||
| In addition, channel binding information MAY be included: see | In addition, channel binding information MAY be included: see | |||
| Section 5.5 for discussion. See Figure 11 for parameter | Section 5.5 for discussion. See Figure 12 for parameter | |||
| specification. The server sends this information so that the | specification. The server sends this information so that the | |||
| peer can verify the information seen at the lower layer, if | peer can verify the information seen at the lower layer, if | |||
| channel binding is to be supported. | channel binding is to be supported. | |||
| Cryptosuite: This field indicates the integrity algorithm and the | Cryptosuite: This field indicates the integrity algorithm and the | |||
| PRF used for ERP. Key lengths and output lengths are either | PRF used for ERP. Key lengths and output lengths are either | |||
| indicated or are obvious from the cryptosuite name. | indicated or are obvious from the cryptosuite name. | |||
| Authentication Tag: This field contains the integrity checksum | Authentication Tag: This field contains the integrity checksum | |||
| over the ERP packet, excluding the authentication tag field | over the ERP packet, excluding the authentication tag field | |||
| skipping to change at page 30, line 16 | skipping to change at page 31, line 16 | |||
| The TV attributes that may be present in the EAP-Initiate or EAP- | The TV attributes that may be present in the EAP-Initiate or EAP- | |||
| Finish messages are of the following format: | Finish messages are of the following format: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Value ... | | Type | Value ... | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 10: TV Attribute Format | Figure 11: TV Attribute Format | |||
| The TLV attributes that may be present in the EAP-Initiate or EAP- | The TLV attributes that may be present in the EAP-Initiate or EAP- | |||
| Finish messages are of the following format: | Finish messages are of the following format: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | Value ... | | Type | Length | Value ... | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 11: TLV Attribute Format | Figure 12: TLV Attribute Format | |||
| The following Types are defined in this document: | The following Types are defined in this document: | |||
| '1' - keyName-NAI: This is a TLV payload. | '1' - keyName-NAI: This is a TLV payload. | |||
| '2' - rRK Lifetime: This is a TV payload. | '2' - rRK Lifetime: This is a TV payload. | |||
| '3' - rMSK Lifetime: This is a TV payload. | '3' - rMSK Lifetime: This is a TV payload. | |||
| '4' - domain name: This is a TLV payload. | '4' - domain name: This is a TLV payload. | |||
| skipping to change at page 35, line 48 | skipping to change at page 36, line 48 | |||
| keys derived from it. Moreover, there is no forward secrecy | keys derived from it. Moreover, there is no forward secrecy | |||
| within ERP. Thus, compromise of an DSRK retroactively | within ERP. Thus, compromise of an DSRK retroactively | |||
| compromises all ERP keys. | compromises all ERP keys. | |||
| It is RECOMMENDED that the AAA protocol be protected using | It is RECOMMENDED that the AAA protocol be protected using | |||
| IPsec or TLS so that the keys are protected in transit. Note, | IPsec or TLS so that the keys are protected in transit. Note, | |||
| however, that keys may be exposed to AAA proxies along the way | however, that keys may be exposed to AAA proxies along the way | |||
| and compromise of any of those proxies may result in compromise | and compromise of any of those proxies may result in compromise | |||
| of keys being transported through them. | of keys being transported through them. | |||
| The home ER server MUST NOT hand out a given DSRK to a local | The home EAP server MUST NOT hand out a given DSRK to a local | |||
| domain server more than once, unless it can verify that the | domain server more than once, unless it can verify that the | |||
| entity receiving the DSRK after the first time is the same as | entity receiving the DSRK after the first time is the same as | |||
| that received the DSRK originally. If the home ER server | that received the DSRK originally. If the home EAP server | |||
| verifies authorization of a local domain server, it MAY hand | verifies authorization of a local domain server, it MAY hand | |||
| out the DSRK to that domain more than once. In this case, the | out the DSRK to that domain more than once. In this case, the | |||
| home ER server includes the Authorization Indication TLV to | home EAP server includes the Authorization Indication TLV to | |||
| assure the peer that DSRK delivery is secure. | assure the peer that DSRK delivery is secure. | |||
| Confirm cryptosuite selection | Confirm cryptosuite selection | |||
| Crypto algorithms for integrity and key derivation in the | Crypto algorithms for integrity and key derivation in the | |||
| context of ERP MAY be the same as that used by the EAP method. | context of ERP MAY be the same as that used by the EAP method. | |||
| In that case, the EAP method is responsible for confirming the | In that case, the EAP method is responsible for confirming the | |||
| cryptosuite selection. Furthermore, the cryptosuite is | cryptosuite selection. Furthermore, the cryptosuite is | |||
| included in the ERP exchange by the peer and confirmed by the | included in the ERP exchange by the peer and confirmed by the | |||
| server. The protocol allows the server to reject the | server. The protocol allows the server to reject the | |||
| skipping to change at page 37, line 51 | skipping to change at page 38, line 51 | |||
| To prevent such DoS attacks, an ERP failure should not result in | To prevent such DoS attacks, an ERP failure should not result in | |||
| deletion of any authorization state established by a full EAP | deletion of any authorization state established by a full EAP | |||
| exchange. Alternatively, the lower layers and AAA protocols may | exchange. Alternatively, the lower layers and AAA protocols may | |||
| define mechanisms to allow two link-layer security associations (SAs) | define mechanisms to allow two link-layer security associations (SAs) | |||
| derived from different EAP keying materials for the same peer to | derived from different EAP keying materials for the same peer to | |||
| exist so that smooth migration from the current link layer SA to the | exist so that smooth migration from the current link layer SA to the | |||
| new one is possible during rekey. These mechanisms prevent the link | new one is possible during rekey. These mechanisms prevent the link | |||
| layer connections from being terminated when a re-authentication | layer connections from being terminated when a re-authentication | |||
| procedure fails due to the bogus EAP-Initiate/Re-auth message. | procedure fails due to the bogus EAP-Initiate/Re-auth message. | |||
| When a DSRK is sent from a home ER server to a local domain server or | When a DSRK is sent from a home EAP server to a local domain server | |||
| when a rMSK is sent from an ER server to an authenticator, in the | or when a rMSK is sent from an ER server to an authenticator, in the | |||
| absence of end-to-end security between the entity that is sending the | absence of end-to-end security between the entity that is sending the | |||
| key and the entity receiving the key, it is plausible for other | key and the entity receiving the key, it is plausible for other | |||
| entities to get access to keys being sent to an ER server in another | entities to get access to keys being sent to an ER server in another | |||
| domain. This mode of key transport is similar to that of MSK | domain. This mode of key transport is similar to that of MSK | |||
| transport in the context of EAP authentication. We further observe | transport in the context of EAP authentication. We further observe | |||
| that ERP is for access authentication and does not support end-to-end | that ERP is for access authentication and does not support end-to-end | |||
| data security. In typical implementations, the traffic is in the | data security. In typical implementations, the traffic is in the | |||
| clear beyond the access control enforcement point (the authenticator | clear beyond the access control enforcement point (the authenticator | |||
| or an entity delegated by the authenticator for access control | or an entity delegated by the authenticator for access control | |||
| enforcement). The model works as long as entities in the middle of | enforcement). The model works as long as entities in the middle of | |||
| skipping to change at page 39, line 12 | skipping to change at page 40, line 12 | |||
| Extended Master Session Key (EMSK)", RFC 5295, | Extended Master Session Key (EMSK)", RFC 5295, | |||
| August 2008. | August 2008. | |||
| 10.2. Informative References | 10.2. Informative References | |||
| [I-D.ietf-dime-erp] | [I-D.ietf-dime-erp] | |||
| Bournelle, J., Morand, L., Wu, W., and G. Zorn, "Diameter | Bournelle, J., Morand, L., Wu, W., and G. Zorn, "Diameter | |||
| Support for the EAP Re-authentication Protocol (ERP)", | Support for the EAP Re-authentication Protocol (ERP)", | |||
| draft-ietf-dime-erp-04 (work in progress), September 2010. | draft-ietf-dime-erp-04 (work in progress), September 2010. | |||
| [I-D.ietf-dime-local-keytran] | ||||
| , Q. and G. , "Diameter Attribute-Value Pairs for | ||||
| Cryptographic Key Transport", | ||||
| draft-ietf-dime-local-keytran-07 (work in progress), | ||||
| July 2010. | ||||
| [I-D.ietf-hokey-ldn-discovery] | ||||
| Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name | ||||
| DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in | ||||
| progress), September 2010. | ||||
| [IEEE_802.1X] | [IEEE_802.1X] | |||
| Institute of Electrical and Electronics Engineers, "IEEE | Institute of Electrical and Electronics Engineers, "IEEE | |||
| Standards for Local and Metropolitan Area Networks: Port | Standards for Local and Metropolitan Area Networks: Port | |||
| based Network Access Control, IEEE Std 802.1X-2004", | based Network Access Control, IEEE Std 802.1X-2004", | |||
| December 2004. | December 2004. | |||
| [MSKHierarchy] | [MSKHierarchy] | |||
| Lopez, R., Skarmeta, A., Bournelle, J., Laurent- | Lopez, R., Skarmeta, A., Bournelle, J., Laurent- | |||
| Maknavicus, M., and J. Combes, "Improved EAP keying | Maknavicus, M., and J. Combes, "Improved EAP keying | |||
| framework for a secure mobility access service", | framework for a secure mobility access service", | |||
| skipping to change at page 40, line 35 | skipping to change at page 41, line 45 | |||
| Hoeper suggested the use of the windowing technique to handle | Hoeper suggested the use of the windowing technique to handle | |||
| multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for | multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for | |||
| the suggestion to use hexadecimal encoding for rIKname when sent as | the suggestion to use hexadecimal encoding for rIKname when sent as | |||
| part of keyName-NAI field. Thanks to Bernard Aboba for suggestions | part of keyName-NAI field. Thanks to Bernard Aboba for suggestions | |||
| in clarifying the EAP lock-step operation, and Joe Salowey and Glen | in clarifying the EAP lock-step operation, and Joe Salowey and Glen | |||
| Zorn for help in specifying AAA transport of ERP messages. Thanks to | Zorn for help in specifying AAA transport of ERP messages. Thanks to | |||
| Sam Hartman for the DSRK Authorization Indication mechanism. | Sam Hartman for the DSRK Authorization Indication mechanism. | |||
| A.2. RFC 5296bis | A.2. RFC 5296bis | |||
| TBC | Glen Zorn wrote the initial draft for this document and provided | |||
| useful reviews. Many thanks to him. | ||||
| Appendix B. Example ERP Exchange | Appendix B. Example ERP Exchange | |||
| 0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start] | 0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start] | |||
| 1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI, | 1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI, | |||
| cryptosuite,Auth-tag*) | cryptosuite,Auth-tag*) | |||
| 1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id, | 1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id, | |||
| EAP Initiate/Re-auth(SEQ,keyName-NAI, | EAP Initiate/Re-auth(SEQ,keyName-NAI, | |||
| cryptosuite,Auth-tag*) | cryptosuite,Auth-tag*) | |||
| 2. ER-Server --> Authenticator: AAA-Response{rMSK, | 2. ER-Server --> Authenticator: AAA-Response{rMSK, | |||
| skipping to change at page 41, line 26 | skipping to change at page 42, line 29 | |||
| 2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI, | 2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI, | |||
| cryptosuite,[CB-Info],Auth-tag*) | cryptosuite,[CB-Info],Auth-tag*) | |||
| * Auth-tag computation is over the entire EAP Initiate/Finish message; | * Auth-tag computation is over the entire EAP Initiate/Finish message; | |||
| the code values for Initiate and Finish are different and thus | the code values for Initiate and Finish are different and thus | |||
| reflection attacks are mitigated. | reflection attacks are mitigated. | |||
| Authors' Addresses | Authors' Addresses | |||
| Glen Zorn (editor) | Qin Wu (editor) | |||
| Network Zen | ||||
| 1463 East Republican Street | ||||
| #358 | ||||
| Seattle, Washington 98112 | ||||
| US | ||||
| Email: gwz@net-zen.net | ||||
| Qin Wu | ||||
| Huawei Technologies Co., Ltd. | Huawei Technologies Co., Ltd. | |||
| 101 Software Avenue, Yuhua District | 101 Software Avenue, Yuhua District | |||
| Nanjing, JiangSu 210012 | Nanjing, JiangSu 210012 | |||
| China | China | |||
| Email: Sunseawq@huawei.com | Email: Sunseawq@huawei.com | |||
| Zhen Cao | Zhen Cao | |||
| China Mobile | China Mobile | |||
| 53A Xibianmennei Ave., Xuanwu District | 53A Xibianmennei Ave., Xuanwu District | |||
| Beijing, Beijing 100053 | Beijing, Beijing 100053 | |||
| P.R. China | P.R. China | |||
| Email: caozhen@chinamobile.com | Email: caozhen@chinamobile.com | |||
| Yang Shi | ||||
| H3C Tech. Co., Ltd | ||||
| Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District | ||||
| Beijing 100085 | ||||
| China | ||||
| Email: young@h3c.com | ||||
| Baohong He | ||||
| China | ||||
| Email: hebaohong@catr.cn | ||||
| End of changes. 54 change blocks. | ||||
| 171 lines changed or deleted | 211 lines changed or added | |||
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||