RFC5296BISCHANGES PROPOSAL

Sebastien Decugis

Presentation outline

Quick reminder on ERP (RFC5296)

2 change proposals Problem description Solution proposed

Discussion about these issues is welcome.

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, …)

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.

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.

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.

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).

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)

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.

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)

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”