1. RFC5296BIS CHANGES PROPOSAL Sebastien Decugis

2. Presentation outline  Quick reminder on ERP (RFC5296)  2 change proposals  Problem description  Solution proposed  Discussion about these issues is welcome.

3. Some facts on ERP (RFC 5296)  ERP is initiated by the peer  (authenticator SHOULD help with LDN in E-I/R-A-S)  An ER server is available, somewhere  Safe to assume a local server when E-I/R-A-S is received.  Safe to assume a home server exists.  No E-I/R-A-S & in foreign domain: conf, or guess work   This ER server may or may not already have the rRK  (implicit bootstrapping or not, state lost after reboot, …)

4. Some facts on ERP, cont.  Peer sends the first EAP-Initiate, 2 possibilities:  With ‘B’ flag keyName-NAI = EMSKname@homedomain Auth tag signed by rIK derived from rRK.  Without ‘B’ flag keyName-NAI = EMSKname@localdomain Auth tag signed by DS-rIK derived from DS-rRK.  Clear difference when localdomain != homedomain  Otherwise, does not really matter.

5. First change, problem description  For the peer to choose ‘B’ or not ‘B’, it must know if the local ER server is bootstrapped. Otherwise:  If ‘B’ is used while local ER server is bootstrapped: Local ER server cannot verify the authentication tag Message is FW to home domain while not necessary Local ER server receives a duplicate of the same DS-rRK.  If ‘B’ is not used but local ER server not bootstrapped: Local ER server cannot verify the authentication tag, Cannot answer, And cannot forward to home domain because it is unknown.

6. First change, solution  The solution is as follow:  The peer always add enough data in E-I/R-A to allow a local ER server to request the DS-rRK from home domain if it does not have it.  The peer always attempts to use the local ER server, when it knows there is one.

7. First change, protocol impact  This is done with the following changes to ERP:  Deprecate the ‘B’ flag ‘bootstrapping’ message is not used anymore ‘B’ flag is redundant anyway with the keyName-NAI.  Always add the home domain name in a separate TLV.  And slightly change the behavior of the local ER server and home ER server, to request / provide DS-rRK as needed (even for non-`bootstrapping’ exchanges).

8. First change, additional comments  LDN problem: local domain name learned only via ERP protocol (E-I/R-A-S or E-F/R-A), or acquired by other mean but with explicit ERP usage indication, should be used.  Otherwise there is no guarantee that a local ER server exists, which results in an error of the protocol.  It should be safe to re-use last known LDN after a handover, when the LDN of new attachment point is not available, but it requires a few additional changes to the local ER server handling. (FFS)

9. Second change, problem description  RFC 5296 : “local ER server” & “home ER server”.  But:  Differences are not only location but also features.  Home ER server has to: 1. Authorize ER servers in other domains 2. Derive DS-rRK from the EMSK (locked in EAP server) 3. Validate authentication tag of ERP messages. 4. Create ERP answers and derive rMSK from rRK.  Local ER server needs only 3 & 4. And 5. Request a DS-rRK from the home domain.

10. Second change, solution  Use the terms “ER backend” and “ER proxy”  The ER backend has to be collocated with EAP server. It can access the EMSK It supports key derivation for all domains.  ER proxy is optional to deploy. It only operates its domain-specific keys.  These names describe better the functions performed by the logical entities involved in ERP.  It does not preclude on deployment / implementation.  (ex: ER backend can act as ER proxy for visiting peers)

11. Thank you -- Discussion time  Time for comments…  1 st proposed change make peer unaware of ER server state. remove the error-prone ‘bootstrapping’ exchange.  2 nd proposed change “home ER server”  “ER backend” “local ER server”  “ER proxy”