Re: [Dime] [dime] #12: Review of draft-ietf-dime-ikev2-psk-diameter-02

["Cakulev, Violeta (Violeta)" <[e-mail]>]

Lionel,
Thanks for the reply.
Please see inline (>>VC:)

-Violeta

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Monday, August 30, 2010 9:33 PM
To: Cakulev, Violeta (Violeta); [e-mail]
Subject: RE: [dime] #12: Review of draft-ietf-dime-ikev2-psk-diameter-02

Hi Violeta,

Thank you for having taken into account my comments.

About the Auth-Request-AVP, no problem for me to state that AUTHORIZE-ONLY is the unique value to use.
However, this AVP is defined in RFC3588, and is defined with the following possible values:

   AUTHENTICATE_ONLY          1
      The request being sent is for authentication only, and MUST
      contain the relevant application specific authentication AVPs that
      are needed by the Diameter server to authenticate the user.

   AUTHORIZE_ONLY             2
      The request being sent is for authorization only, and MUST contain
      the application specific authorization AVPs that are necessary to
      identify the service being requested/offered.

   AUTHORIZE_AUTHENTICATE     3

What should be the behaviour 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?
>>VC: I agree 1 and 3 are the valid values in general but not for the application the document is defining. So we can return DIAMETER_INVALID_AVP_VALUE and include the Auth-Request-AVP in the Failed-AVP AVP.
DIAMETER_UNABLE_TO_COMPLY could also be returned, but in this case the receiver will not know why.

Regards,

Lionel

> -----Message d'origine-----
> De : Cakulev, Violeta (Violeta)
> [mailto:[e-mail]]
> Envoyé : lundi 30 août 2010 22:14
> À : [e-mail]; MORAND Lionel RD-CORE-ISS Objet : RE: [dime] #12:
> Review of
> draft-ietf-dime-ikev2-psk-diameter-02
>
>
> Lionel,
> Thanks for the comments.
> Please see inline (>>[VC]).
>
> I'll upload a new version (v3) of the draft shortly.
>
> -Violeta
>
> -----Original Message-----
> From: dime issue tracker [mailto:[e-mail]]
> Sent: Monday, August 16, 2010 12:46 PM
> To: [e-mail]
> Cc: [e-mail]; Cakulev, Violeta (Violeta)
> Subject: [dime] #12: Review of draft-ietf-dime-ikev2-psk-diameter-02
>
> #12: Review of draft-ietf-dime-ikev2-psk-diameter-02
> ----------------------------------------------+---------------
> ----------
> ----------------------------------------------+----
>  Reporter:  lionel.morand@...                   |       Owner:
>      Type:  defect                            |      Status:  new
>  Priority:  major                             |   Milestone:
> Component:  ikev2-psk-diameter                |     Version:
>  Severity:  In WG Last Call                   |    Keywords:
> ----------------------------------------------+---------------
> ----------
> ----------------------------------------------+----
>  I have reviewed this draft and is pretty good for publication.
>
>  One remaining open issue from my side:
>
>  1/Is there any need for Authorize-Type AVP in the request if only
> Authorize-Only is used in this application?
> >>[VC] Please see my response to Sebastien. In short, today
> this value is constrained and probably not necessary, but in future it
> may change. In addition, it is better to be explicit.
>
>  Additional comments/proposed modifications below.
>
>  Regards,
>
>  Lionel.
>
>  ******************
>
>
>
>  1.  Introduction
>
>     [RFC4306] defines Internet Key Exchange v2 as a protocol that
>
>  ==> s/[RFC4306] defines Internet Key Exchange v2 as a protocol that/
>        [RFC4306] defines the version 2 of the Internet Key Exchange
> (IKE)  protocol that
> >>[VC] Changed.
>
>     performs mutual authentication between two parties and establishes
> a
>     security association (SA) that includes shared secret information
>     that can be used to efficiently establish SAs for Encapsulating
>     Security Payload (ESP) [RFC4303] and/or Authentication Header (AH)
>     [RFC4302], and a set of cryptographic algorithms to be used by the
>     SAs to protect the traffic that they carry.  IKEv2 protocol allows
>     several different mechanisms for authenticating a IKEv2 Peer to be
>     used, such as the Extensible Authentication Protocol,
> certificates,
>     and pre-shared secrets.
>
>     From a service provider perspective it is important to ensure that
> a
>
>  ==> s/From a service provider perspective it is/From a service
> provider  perspective, it is
> >>[VC] Changed.
>
>     user is authorized to use the services.  Therefore, the
> IKEv2 Server
>     must verify that the IKEv2 Peer is authorized for the requested
>     services possibly with the assistance of the operator's Diameter
>     servers.  [RFC 5778] defines the home agent as a Diameter client
> to
>     the Diameter server communication when the mobile node
> authenticates
>     using the IKEv2 protocol with the Extensible Authentication
> Protocol
>     or using the Mobile IPv6 Authentication Protocol.  This document
>
>  ==> s/the Extensible Authentication Protocol or using the Mobile IPv6
> Authentication Protocol/
>        the Extensible Authentication Protocol (EAP) [RFC 3748] or
> using the  Mobile IPv6 Authentication Protocol [RFC 4285]/
> >>[VC] Changed.
>
>     extends the functionality offered by [RFC 5778] with pre-shared
> key
>     based authentication offered by IKEv2.  This document does not
> assume
>     that the IKEv2 Server has the pre-shared secrets (PSK) with the
> IKEv2
>     Peer.  Instead, it allows for PSK to be derived for a specific
> IKEv2
>     session and exchanged between IKEv2 Server and HAAA.  This is
>     accomplished through the use of a new Diameter application
>     specifically designed for performing IKEv2 authorization
> decisions.
>
>
>  [skip]
>
>
>  4.  Protocol Description
>
>  4.1.  Support for IKEv2 and Pre-Shared Secrets
>
>     When IKEv2 is used with PSK-based initiator authentication, the
>     Diameter commands IKEv2-PSK-Request and IKEv2-PSK-Answer defined
> in
>
>  ==> s/the Diameter commands IKEv2-PSK-Request and IKEv2-PSK-Answer
> defined/
>        the Diameter command pair IKEv2-PSK-Request/Answer defined
> >>[VC] Changed.
>
>     this document are used to authorize the IKEv2 Peer for the
> services.
>
>  ==> s/are used to authorize/are used between IKEv2 server and a Home
> AAA  server (HAAA) to authorize
> >>[VC] Changed.
>
>
>     Upon receiving the IKE_AUTH message from the IKEv2 Peer, the IKEv2
>     Server uses the information received in IDi to determine if it has
>     the PSK for this IKEv2 Peer.  If there is no PSK found associated
>     with this IKEv2 Peer, the IKEv2 Server MUST send an Authorize-Only
>     (Auth-Request-Type set to "Authorize-Only") Diameter IKEv2-PSK
>     message with the IKEv2 Peer's IDi payload to the HAAA to obtain
> the
>     PSK.
>
>  ==> I think that the initial intention was to re-use RFC5778 and
> existing  commands. Now, as you're creating new command, why do you
> have to re-use  Auth-Request-Type AVP as it seems that only
> "Authorize-Only" will be used  in this application?
> If removed from the command, this part will be  modified.
> >>[VC] Discussed above.
>
>     The IDi payload extracted from the IKE_AUTH message has to
>
>  ==> s/has to/MUST
> >>[VC] Changed.
>
>     contain an identity that is meaningful for the Diameter
>     infrastructure, such as a Network Access Identifier (NAI), since
> it
>     is used by the IKEv2 Server to populate the User-Name AVP in the
>     Diameter message.  The IKEv2 Server also includes in the
> IKEv2-Nonces
>     AVP of the same Diameter message the initiator and responder
> nonces
>     (Ni and Nr) exchanged during initial IKEv2 exchange.
>
>     This message is routed to the IKEv2 Peer's HAAA.  Upon receiving
>     Diameter IKEv2-PSK-Request message from the IKEv2 Server, the HAAA
>     SHALL use the User-Name AVP to retrieve the associated keying
>     material.  The HAAA SHALL use the nonces Ni and Nr received in
> IKEv2-
>     Nonces AVP to generate the PSK.  It is outside of scope of this
>     document how the HAAA obtains or generates the PSK.  For example,
> if
>     the HAAA previously performed EAP based access authentication and
>     authorization of the IKEv2 Peer, it can use the available EMSK to
>     generate the PSK [RFC5295].  The HAAA returns the PSK to the IKEv2
>     Server using the Key AVP as specified in
>     [I-D.ietf-dime-local-keytran].
>
>  ==> I would reorder the end of this paragraph and move the "it is
> outside  of scope..." at the end. It would look like:
>
>    "This message is routed to the IKEv2 Peer's HAAA.  Upon receiving
>     Diameter IKEv2-PSK-Request message from the IKEv2 Server, the HAAA
>     SHALL use the User-Name AVP to retrieve the associated keying
>     material.  The HAAA SHALL use the nonces Ni and Nr received in
> IKEv2-
>     Nonces AVP to generate the PSK. The HAAA returns the PSK to the
> IKEv2
>     Server using the Key AVP as specified in
>     [I-D.ietf-dime-local-keytran].
>
>     It is outside of scope of this document how the HAAA obtains or
>     generates the PSK.  For example, if the HAAA previously performed
> EAP
>     based access authentication and authorization of the
> IKEv2 Peer, it
>     can use the available EMSK to generate the PSK [RFC5295]."
>
> >>[VC] Reordered.
>
>  [skip]
>
>
>  4.2.2.  AbortSession-Request
>
>  ==> AbortSession/Abort-Session
> >>[VC] Changed.
>
>     The Abort-Session-Request (ASR) message [RFC3588] is sent by the
> HAAA
>     to the IKEv2 Server to terminate the authorized session.  When the
>     IKEv2 Server receives the ASR message, it MUST delete the
>     corresponding IKE_SA and all CHILD_SAs set up through it.
>
>     The Abort-Session-Answer (ASA) message [RFC3588] is sent by the
> IKEv2
>     Server in response to an ASR message.
>
>
>  [skip]
>
>
>  5.1.  IKEv2-PSK-Request (IKEPSKR) Command
>
>     The IKEv2-PSK-Request message, indicated with the Command-Code set
> to
>     TBD2 and the 'R' bit set in the Command Flags field is sent from
> the
>     IKEv2 Server to the HAAA to initiate IKEv2 with PSK authorization.
>     In this case, the Application-ID field of the Diameter Header MUST
> be
>     set to the Diameter IKE PSK Application ID (value of TDB1).
>
>     Message format
>
>
>           <IKEv2-PSK-Request> ::= < Diameter Header: TBD2, REQ, PXY >
>                                   < Session-Id >
>                                   { Auth-Application-Id }
>                                   { Origin-Host }
>                                   { Origin-Realm }
>                                   { Destination-Realm }
>                                   { Auth-Request-Type }
>                                   [ Destination-Host ]
>                                   [ NAS-Identifier ]
>                                   [ NAS-IP-Address ]
>                                   [ NAS-IPv6-Address ]
>                                   [ NAS-Port ]
>                                   [ Origin-State-Id ]
>                                   { User-Name }
>                                   [ Auth-Session-State ]
>                                   { IKEv2-Nonces }
>                                 * [ Proxy-Info ]
>                                 * [ Route-Record ]
>                                   ...
>                                 * [ AVP ]
>
>     IKEv2-PSK-Request message MUST include a IKEv2-Nonces AVP
> containing
>     Ni and Nr nonces exchanged during initial IKEv2 exchange.
>
>  ==> Check if the use of Auth-Request-Type AVp is really needed. If
> not,  remove it.
> >>[VC] Discussed above.
>
>  ==> Why do we have to insist on the presence of IKEv2-Nonces AVP as
> this  AVP is described as required in the ABNF?
> >>[VC] Makes sense. However, focus was more on the fact that
> those are the nonces exchanged between the peer and the server in IKE
> messages. I believe it is not wrong to leave the text as it is.
>
>  ==> In the AVP Occurence table, Key AVP can be found in the request
> while  this AVP is missing in the ABNF description.
> inconsistency must fixed.
>  Moreover, if Key AVP can be found in the request, add some text to
> explain  why.
> >>[VC] Good catch. Key AVP needs to be an optional AVP in the
> request. If present it contains SPI. Some applications might use SPI
> values for key identification purposes. Key AVP is added in the ABNF
> description.
>
>  [skip]
>
>
>  7.  AVP Occurrence Tables
>
>     The following tables present the AVPs defined or used in this
>     document and their occurrences in Diameter messages.
> Note that AVPs
>     that can only be present within a Grouped AVP are not represented
> in
>     this table.
>
>     The table uses the following symbols:
>
>     0:
>
>        The AVP MUST NOT be present in the message.
>
>
>     0+:
>
>        Zero or more instances of the AVP MAY be present in the
> message.
>
>
>     0-1:
>
>        Zero or one instance of the AVP MAY be present in the message.
>
>
>     1:
>
>        One instance of the AVP MUST be present in the message.
>
>
>
>                                       +-------------------+
>                                       |   Command-Code    |
>                                       |---------+---------+
>        AVP Name                       | IKEPSKR | IKEPSKA |
>        -------------------------------|---------+---------+
>        Key                            |   0-1   |   0-1   |
>        IKEv2-Nonces                   |   0-1   |    0    |
>                                       +---------+---------+
>
>                    IKEPSKR and IKEPSKA Commands AVP Table
>
>  ==> Inconsistency! IKEv2-Nonces is described are required in the
> Request  and the Occurence is then 1. Moreover, the use of Key AVP in
> the request  is not described, neither in the text nor in the request
> ABNF description.
> >>[VC] Agreed. Table is changed.
>
>
>  [skip]
>
>  11.2.  Informative References
>
>     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>                Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>     [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
> H.
>                Levkowetz, "Extensible Authentication Protocol (EAP)",
>                RFC 3748, June 2004.
>
>     [RFC5295]  Salowey, J., Dondeti, L., Narayanan, V., and M.
> Nakhjiri,
>                "Specification for the Derivation of Root Keys from an
>                Extended Master Session Key (EMSK)", RFC 5295,
>                August 2008.
>
>
>  ==> an informative reference to RFC 4285 should be added (cf.
> previous
>  comment)
> >>[VC] Added.
>
> --
> Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/12>
> dime <http://tools.ietf.org/wg/dime/>
>
>