Download
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Zhen Cao, Hui Deng (China Mobile) Qin Wu, Yungui Wang (Huawei) Glen Zorn Ed. (Network Zen) PowerPoint Presentation
Download Presentation
Zhen Cao, Hui Deng (China Mobile) Qin Wu, Yungui Wang (Huawei) Glen Zorn Ed. (Network Zen)

Zhen Cao, Hui Deng (China Mobile) Qin Wu, Yungui Wang (Huawei) Glen Zorn Ed. (Network Zen)

2 Vues Download Presentation
Télécharger la présentation

Zhen Cao, Hui Deng (China Mobile) Qin Wu, Yungui Wang (Huawei) Glen Zorn Ed. (Network Zen)

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keyingdraft-wang-hokey-erp-aak-00 Zhen Cao, Hui Deng (China Mobile) Qin Wu, Yungui Wang (Huawei) Glen Zorn Ed. (Network Zen) HOKEY IETF 77

  2. Status of this I-D • Presented the slides in IETF 76th discussing the idea of ERP extension for EAP Early Authentication. The draft is not ready before IETF 76 • Submit the 00 version after IETF 76 • ERP Authenticated Anticipatory Keying (AAK) this time HOKEY IETF 77

  3. Terminology • SAP: Serving Attachment Point defined in [I-D.ietf-hokey-preauth-ps] • CAP: Candidate Attachment Point defined in [I-D.ietf-hokey-preauth-ps] • ERP/AAK(EA): EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying HOKEY IETF 77

  4. Background • ERP is specified in RFC5296 • Authenticated Anticipatory Keying (AAK) is a method defined in [I-D.ietf-hokey-preauth-ps], by which cryptographic keying material may be established prior to handover among one or more candidate attachment points (CAPs). AAK is one typical model in pre-auth PS document. • Therefore a separate draft for pre-auth solution is required. HOKEY IETF 77

  5. Protocol Overview 1~2. The peer initiates ERP/AAK itself with ‘E’ Flag set, or do so in response to an EAP-Initiate/ Re-Auth-Start message from the SAP 3. The SAP encapsulates the ERP/AAK message into a AAA message and sends it to the peer's ERP/AAK server 4.The ERP/AAK server authorizes CAP And derive pRK and pMSK. 5. The ERP/AAK transports pMSK to the authenticated and authorized CAP 6. The ERP/AAK responds to the SAP with ERP/AAK Message containing the determinate CAP. 7. The SAP responds to the peer with ERP AAK Message with E-flag set. HOKEY IETF 77

  6. Packet and TLV extension(1) • EAP-Initiate/Re-auth-Start Packet Extension HOKEY IETF 77

  7. Packet and TLV extension(2) • EAP-Initiate/Re-auth Packet Extension HOKEY IETF 77

  8. Packet and TLV extension(3) • TV and TLV: • keyName-NAI: As defined in RFC 5296 [RFC5296], the Type is 1. The username part of the NAI is the EMSKname used identify the peer. The realm part of the NAI is the peer's home domain name or the domain to which the peer is currently attached. Exactly one keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth packet. • NAS-Identifier: TLV, to indicate the CAP • Sequence number: TV HOKEY IETF 77

  9. Packet and TLV extension(4) • EAP-Finish/Re-auth extension HOKEY IETF 77

  10. Packet and TLV extension(5) • TVs or TLVs, subTLV: • keyName-NAI: As defined in [RFC5296], this is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. The realm part of the NAI is the home domain name. Exactly one keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth packet. • ERP/AAK-Key: It is carried in a TLV payload for the key container. The type is TBD. One or more than one ERP/AAK-key may be present in an EAP-Finish/Re-auth packet. • ERP/AAK-Key ::= { sub-TLV: NAS-Identifier } { sub-TLV: pMSK-lifetime } { sub-TLV: pRK-lifetime } { sub-TLV: Cryptosuites } HOKEY IETF 77

  11. Moving Forward • Accept it as a WG work item? HOKEY IETF 77