Rfc5296bis changes proposal
This presentation is the property of its rightful owner.
Sponsored Links
1 / 11

Rfc5296bis Changes proposal PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Rfc5296bis Changes 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

Download Presentation

Rfc5296bis Changes proposal

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Rfc5296bis changes proposal

Rfc5296bisChanges proposal


Presentation outline

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

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

Some facts on ERP, cont.

  • Peer sends the first EAP-Initiate, 2 possibilities:

    • With ‘B’ flag

      • keyName-NAI = [email protected]

      • Auth tag signed by rIK derived from rRK.

    • Without ‘B’ flag

      • keyName-NAI = [email protected]

      • Auth tag signed by DS-rIK derived from DS-rRK.

  • Clear difference when localdomain != homedomain

    • Otherwise, does not really matter.

First change problem description

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

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

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

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

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

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

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”

  • Login