1 / 6

EAP Extensions for EAP Re-authentication Protocol (ERP) draft-wu-hokey-rfc5296bis-01

EAP Extensions for EAP Re-authentication Protocol (ERP) draft-wu-hokey-rfc5296bis-01. Yang Shi (young@h3c.com) Qin Wu (sunseawq@huawei.com) Zhen Cao ( zehn.cao@gmail.com ) Baohong He (hebaohong@catr.cn). Status. Presented in IETF 78, Masstricht, adopted as work item after IETF 78

odetta
Download Presentation

EAP Extensions for EAP Re-authentication Protocol (ERP) draft-wu-hokey-rfc5296bis-01

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 Extensions for EAP Re-authentication Protocol (ERP)draft-wu-hokey-rfc5296bis-01 Yang Shi (young@h3c.com) Qin Wu (sunseawq@huawei.com) Zhen Cao (zehn.cao@gmail.com) Baohong He (hebaohong@catr.cn)

  2. Status • Presented in IETF 78, Masstricht, adopted as work item after IETF 78 • The changes to the previous version • Incorporate existing Technical Erratas into this document • Constrain ERP with only one ER server • Allow ER Explicit Bootstrapping with the ER server in the same domain as the peer. • Move generic text from the section 3.1 and associated figures to the front of section 3.1. • Allow local domain name discovery through DHCP extension and ERP with the local ER server

  3. Issue1# ERP with one ER server vs ERP with multiple server • ERP with one ER server • case 1: Peer -> ER authenticator -> Local ER server • case 2: Peer -> ER authenticator -> home ER server • case 3: Peer -> EAP authenticator/ER authenticator ->Local ER server -> Home EAP server • ERP with multiple server • case 4: Peer -> ER authenticator -> local ER server -> home ER server • Proposal: a) restrict the ERP with only one ER server b) Or restrict ERP with the local ER server in the domain as the peer

  4. Issue2#: Clarification of Bootstrapping • Two typical example f bootstrapping described in RFC5296 • In ER Explicit bootstrapping, ‘B’ flag is used to trigger the peer to learn  local domain name through ERP exchange and trigger the local ER server to request DSRK. • in ER implicit bootstrapping ‘There is no ‘B’ flag to be used. the local ER server in the path will be triggered to request DSRK. The local domain name can be leant from ER authenticator or Local ER server through subsequent ERP exchange. • Proposal • bootstrapping does not means that the peer MUST go back to the home domain to obtain the local domain name. • the peer may learn the local domain name from local domain through local ERP exchange or other lower layer announcement mechanism.

  5. Issue3#: Allow local domain discovery within the local domain • Local domain name discovery • Through the EAP-Initiate/Re-auth-Start message during subsequent ERP with local ER server if the authenticator know. • Through ERP with bootstrapping flag on if the local ER server know or home ER server know • Through DHCP based local domain name discovery if DHCP server or relay know • Proposal: • Revise the draft to reflect this.

  6. Follow Up • Encourage more review of draft and early feedback • Expect to issue new version based on feedback from group

More Related