Rfc5296bis changes proposal
Download
1 / 11

Rfc5296bis Changes proposal - PowerPoint PPT Presentation


  • 64 Views
  • 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha

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


Rfc5296bisChanges proposal

SebastienDecugis


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”


ad
  • Login