Rfc5296bis Changes proposal

1. Rfc5296bisChanges proposal SebastienDecugis

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… • 1st proposed change • make peer unaware of ER server state. • remove the error-prone ‘bootstrapping’ exchange. • 2nd proposed change • “home ER server”  “ER backend” • “local ER server”  “ER proxy”