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

[<[e-mail]>]

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?

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/>
> 
>