1 / 11

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

EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying draft-wang-hokey-erp-aak-00. Zhen Cao, Hui Deng (China Mobile) Qin Wu, Yungui Wang (Huawei) Glen Zorn Ed. (Network Zen). Status of this I-D.

jalbright
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related