EAP Extensions for EAP Re- authentication Protocol (ERP) draft-wu-hokey-rfc5296bis-01 Glen Zorn Qin Wu Zhen Cao

Status First Presented in IETF 78, Masstricht Initial version, no changes to RFC5296

Three key issues raised by Erratas Insert ER server in the path of EAP messages ER edit AAA messages –The local ER server is an ERP entity, incapable of inserting anything into a AAA message Places unnecessar restrictions upon deployment options, makes two unwarranted assumptions –the EAP server in the home domain is located on a back-end authentication (i.e., AAA) server –the home ERP server is also located there Suggestion/Action: –Need to Revise the RFC5296bis to reflect these key issues?

Open issues (1) Is there any difference between “EAP Extensions for EAP Re-authentication Protocol “ and “EAP Re-authentication Extension”? –Not clear what needs to be extended? EAP or Re-authentication when say “EAP Re- authentication Extension” –EAP extension or ER extension

Open Issues (2) Original text in RFC5296: “keyName-NAI - ERP messages are integrity protected with the rIK or the DS-rIK. The use of rIK or DS-rIK for integrity protection of ERP messages is indicated by the EMSKname [RFC5295]; the protocol, which is ERP; and the realm, which indicates the domain name of the ER server. The EMSKname is copied into the username part of the NAI. “ Notes: –The text in this defintion does not tell what the keyName-NAI is but how to look up rIK based on EMSKname Suggested text instead of original one “keyName-NAI - Refers to one instance of NAI with EMSKname as the username part. the EMSKname can be used to look up rIK or DS-rIK for integrity protection of ERP message. The realm part of keyName-NAI could be "home domain" or "local domain" name and can be obtained from original text in the full EAP exchange, through a lower-layer mechanism or the ERP exchange.”

Open Issues (3) Structure of Section 3.1 to RFC5296 –The title of the section 3.1 is not consistent with the texts in the section 3.1 –Unlike section 3.2 “ERP with a Local ER Server”, no clear text to address ERP with home ER server

Open Issues (4) Original text in section 3.1 of RFC5296: “ The exchange (ERP) itself may happen when the peer attaches to a new authenticator supporting EAP re-authentication, or prior to attachment. ” Notes “ The ERP exchange is difficult to happen before attachment” Without attachment, how does the peer receive the ERP message from the authenticator tied with that attachment point “ Suggested text: Remove the “or prior to attachment” from original text

Open Issues (5) Original text in sec 3.1 of RFC5296 “The peer sends an EAP-Initiate/Re-auth message that contains the keyName-NAI to identify the ER server's domain and the rIK used to protect the message, and a sequence number for replay protection.” Notes: “Cause confusion to say that the ERP message contain the rIK” “rIK will not leave Peer and ER server according to RFC5296. And the ER server can use EMSKname in the ERP message to look up the rIK.” Suggested text: “The peer sends an EAP-Initiate/Re-auth message that contains the keyName-NAI to identify the rIK used to protect the message, ER server’s domain, and a sequence number for replay protection”

Open Issues (6) Original text of RFC5296: “Figure 3 shows the full EAP and subsequent local ERP exchange; Figure 4 shows it with a local ER server.” Notes: Figure 3 doesn’t show the local exchange with the local ER server, figure 4 show how local ERP exchange works. Suggested text instead of original one: “Figure 3 shows the full EAP with the involvement of Local ER Server; Figure 4 shows subsequent local ERP exchange with a local ER server.”

Open Issues (6) Original figure 3 of RFC5296 Notes: Figure 3 didn’t show local ERP exchange, what we can see is DSRK is pushed from the Home EAP server to the local ER server Suggested revision

Follow Up Expect to incorporate existing Technical Errata into this draft and continue filing new errata Issue new version based on feedback from group and errata. Encourage more review of draft and early feedback