1 / 5

Violeta Cakulev Alcatel-Lucent Avi Lior Bridgewater Systems ITEF 79 – Beijing, China

Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction draft-ietf-dime-ikev2-psk-diameter-0 3. Violeta Cakulev Alcatel-Lucent Avi Lior Bridgewater Systems ITEF 79 – Beijing, China . Diameter IKEv2 PSK.

akio
Télécharger la présentation

Violeta Cakulev Alcatel-Lucent Avi Lior Bridgewater Systems ITEF 79 – Beijing, China

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Diameter IKEv2 PSK: Pre-Shared Secret-basedSupport for IKEv2 Server toDiameter Server Interaction draft-ietf-dime-ikev2-psk-diameter-03 Violeta CakulevAlcatel-LucentAvi LiorBridgewater Systems ITEF 79 – Beijing, China

  2. Diameter IKEv2 PSK • Specification of the interaction between the IKEv2 Server (e.g. Home Agent, Access Gateway) and Diameter server for the IKEv2 based on pre-shared secrets • Not covered in RFC 5778

  3. Status Update • One revisions since IETF 77 • Revision -03 • IKEv2-PSK-Request may contain Key AVP • If included it contains Key-SPI AVP with Security Parameter Index (SPI) to be used to identify the appropriate PSK • AVP occurrence table is updated • Missing references • RFC 4285 and 5778 added as informative references • Various editorial changes

  4. Open Issues (1/2) • Issue: Auth-Request-Type AVP in the Request MUST be set to Authorize-Only (value 2) • Is there any need for Auth-Request-Type AVP in the request if only Authorize-Only (value 2) is used in this application? • Today this value is constrained, but it may change in the future • Better to be explicit then implicit • What should be the behavior of the receiver if the Auth-Request-Type AVP is set to the value 1 or 3, which are valid values?What is the error code send back to the sender? • Send Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE and include the Auth-Request-AVP in the Failed-AVP AVP • Other possibility is to send DIAMETER_UNABLE_TO_COMPLY • In this case the receiver does not know what went wrong • No further discussion • Close the issue?

  5. Open Issues (2/2) • Issue: Keying-Material AVP is mandatory AVP in Key AVP • When IKEv2 Server requests the key it may use SPI to help AAA determine which key needs to be returned • In this case Key AVP would need to be in the request • What would Keying-Material AVP contain? • Solutions • Modify draft-ietf-dime-local-keytran such that Keying-Material AVP is optional • Preferable solution • Do not modify draft-ietf-dime-local-keytran • If Key AVP is sent in the request it is populated with all 0s or ignored by the AAA

More Related