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

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

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