[AAA-WG]: review of draft-ietf-aaa-diameter-sip-04.txt

[Jari Arkko <[e-mail]>]

I read the draft, and it looks very good! I do
have a few technical and editorial comments, however --
see below.

--Jari

P.S. Sorry for being so late. And I'm still working on
draft-sterman...

TECHNICAL
=========

 > 5.1  General architecture
 >
 >    The Diameter SIP application can be used in a SIP environment where
 >    an interface to a AAA infrastructure is required to authenticate,
 >    authorize or provide accounting information.  Figure 1 below shows a

You talk about accounting above, but yet this spec does not define any
specific accounting AVPs for SIP. Do you expect base accounting to be
used as-is, is accounting out of scope for you, or should you be
talking about what SIP-specific AVPs can and should appear in
accounting requests?

 >   This application does not require or is not related to other
 >   authentication services provided by the Mobile IP Diameter
 >   [I-D.ietf-aaa-diameter-mobileip] or the Network Access Server
 >   Diameter [I-D.ietf-aaa-diameter-nasreq] applications.

What about Diameter CC/prepaid? I think the reader may be interested
in whether this application works together with that.

 >                     +--------+           +--------+         +--------+
 >                     |  SIP   |           |Diameter|         |  SIP   |
 >                     |server 1|           | server |         |server 2|
 >                     +--------+           +--------+         +--------+
 >                          |                   |                   |
 >     1. SIP REGISTER      |                   |                   |
 >     -------------------->|     2. UAR        |                   |
 >                          |------------------>|                   |
 >                          |     3. UAA        |                   |
 >                          |<------------------|                   |
 >                          |         4. SIP REGISTER               |
 >                          |-------------------------------------->|
 >                          |                   |      5. MAR       |
 >                          |                   |<------------------|
 >                          |                   |      6. MAA       |
 >                          |                   |------------------>|

So, how does a SIP server know that it is of type 1 or type 2? I would
presume that there can be a case where this choice depends on the
particular user. For instance, some local users are known and
authenticated by the server, but for others we pass the SIP request
somewhere else.

 >    SIP server 1 will forward the SIP REGISTER request (step 4) to an
 >    appropriate SIP server (SIP server 2).  The Diameter client in SIP
 >    server 2 will then request user authentication from the Diameter
 >    server by sending a Diameter Multimedia-Auth-Request (MAR) message

Question: Can the Diameter server decide that this particular SIP
request does not require authentication? Can I use just the routing
aspect of this spec, or do I always need to authenticate too?

 >    If the Diameter client in SIP server 2 is interested in downloading
 >    the user profile information, then it will send a Diameter SAR
 >    message (step 17) to the Diameter server.  The Diameter server will
 >    reply with a Diameter SAA message (step 18) that contains the
 >    requested user profile information.  These actions are only needed
 >    when the SIP server needs to retrieve a user profile used to provide
 >    services to the served user.

Question: Does the download exchange have to happen in a separate
roundtrip, or can we do it in parallel with the MAR/MAA? And why do we
need a separate message, this does not seem to be the case in other
applications such as NASREQ, all authz information is provided in the
same return messages?

 > If the Diameter server requires a User-Name AVP value to process the
 > Diameter PPR request, but the Diameter PPR message did not contain a

I'm not sure I understand how the user name would not be
required. Would this be a global profile change for all users?

 >    [RFC3588]).  The location of the authentication user name in the SIP
 >    REGISTER request varies depending on the authentication mechanism.
 >    When the authentication mechanism is HTTP Digest as defined in RFC
 >    2617 [RFC2617], the authentication user name is found in the
 >    "username" directive of the SIP Authorization header field value.

Is there some other alternative? A current one? If not, it might be
better to say that you support HTTP Digest only.

 > 8.11  SIP-User-Data AVP
 >
 >    The SIP-User-Data AVP (AVP Code TBD) is of type OctetString.  The
 >    Diameter peers do not need to understand the value of this AVP.
 >
 >    The AVP contains the user profile data required for a SIP server to
 >    give service to the user.

Hmm... capabilities are defined in the network, the user profile is an
opaque string of data. Does this imply that it isn't possible to use
equipment from multiple vendors in a networking involving SIP and
Diameter? Is there an existing 3GPP definition of these profiles?
What is the reason to avoid the user profile definition, diversity of
SIP services? Do the SIP nodes have to *act* upon the profile data, or
is it just somehow passed on?

 > 12.  Security Considerations
 >
 >    This memo does not describe a stand-alone protocol, but a particular
 >    application for the Diameter protocol [RFC3588].  Consequently, all
 >    the security considerations applicable to Diameter automatically
 >    apply to this memo.  In particular, section 13 of RFC 3588 applies to
 >    this memo.

Some references to the security of Digest might also be applicable. At
the very least point to the Security Considerations sections of RFCs
2617 and 3310, maybe also draft-torvinen-http-digest-aka-v2-01.txt.

EDITORIAL
=========

 >    This document assumes a general architecture where a Home Realm is
 >    composed of one or more nodes implementing Diameter or SIP functions.
 >    At least, one of such nodes implements the Diameter Server
 >    functionality and the Diameter Server has access to a user database.
 >    The user data associated to a particular user is stored in a single
 >    point in the network referred to as the user database.  There may be
 >    more than a single Diameter Server in the network, and all these
 >    servers have access to such user database.  But at a given time, the
 >    data a Diameter Server returns is independent of the Diameter Server
 >    that returns the information.

I found the above seven lines hard to understand. Perhaps one way to
restructure the text would be to concentrate on the following key
aspects of your assumed architecture:

       - Per-user information may be needed for authentication and/or routing purposes
       - User database resides outside the SIP node
       - User database may be distributed

 > Table of Contents

How about capitalizing first letters of words in section
titles?

 >    The Diameter Subscriber Locator (SL) serves for the purposes of
 >    locating the Diameter server that contains the user related data.
 >    Its functionality is further described in Section 5.8.

So, Diameter Redirect would not be sufficient for this?. Reading
on... it seems that you _are_ using redirect.  Perhaps you could say
this upfront. Maybe "Its functionality is based on the Diameter
redirect mechanism, and is further described in Section 5.8."

 > 5.2  Diameter server authenticates the user

I would actually start with the pure authentication
MAR/MAA/SAR/SAA exchange, and have another section for the
UAR/UAA case.

 >    If the Diameter client in SIP server 2 is interested in downloading
 >    the user profile information, then it will send a Diameter SAR
 >    message (step 17) to the Diameter server.  The Diameter server will
 >    reply with a Diameter SAA message (step 18) that contains the
 >    requested user profile information.  These actions are only needed
 >    when the SIP server needs to retrieve a user profile used to provide
 >    services to the served user.

Section 7.3 talks about the URI storage as the primary function of the
SAR/SAA exchange. Add something about that to the above?

 > 5.3  Diameter server delegates authentication to the SIP server
 >
 >    An operator with a large base of installed SIP servers may wish to
 >    minimize the impact of modifying SIP servers to interact with
 >    Diameter servers.  This can be achieved by allowing SIP servers to
 >    retain the functionality of authentication, rather than centralizing
 >    this capability in a Diameter server.  However, it should be noted

I would classify the difference in another manner.  Basically, it
seems that the authentication is still factually performed at the
Diameter server, because it calculates the expected response. But the
real difference is that one roundtrip is eliminated through sending
the response to the SIP server rather than having it checked in
Diameter. And the price we have to pay for this is the loss of support
for client nonces.  Maybe you could rename the section to "Delegating
final authentication check to the SIP server", and include some of the
above tradeoffs when you describe the properties of this variant.

 >    SIP server 1 will then forward the SIP REGISTER request to SIP server
 >    2 (step 12).  If the credentials include a client nounce, then SIP

s/nounce/nonce/

 > 5.5  Session attempt

Session attempt? Would "Locating a called user" be better?

 >    Termination of the session can be initiated either by the Diameter
 >    client or the Diameter server.  We provide support for both Diameter
 >    client and Diameter server initiated session termination.

The second sentence seems to duplicate what the first sentence said.

 >  7.1   User-Authorization-Request (UAR) Command
 >
 >    The User-Authorization-Request (UAR) is indicated by the Command-Code
 >    set to aaa and the Command Flags' 'R' bit set.  The Diameter client
 >    in a SIP server sends this command to the Diameter server to request
 >    authorization for the SIP User Agent to route a SIP REGISTER request.
 >    As the SIP REGISTER request implicitly carries a permision to bind an

s/permision/permission/

 >    The user name used for authentication of the user is conveyed in a
 >    User-Name AVP (imported from the Diameter base protocol, RFC 3588

s/imported from/defined in/

 >        <SAA> ::= < Diameter Header: bbb, PXY >
 >                  < Session-Id >
 >                  { Auth-Application-Id }
 >                  { Result-Code }
 >                  { Auth-Session-State }
 >                  { Origin-Host }
 >                  { Origin-Realm }
 >                  [ SIP-User-Data ]
 >                  [ SIP-Accouting-Information ]

s/Accouting/Accounting/

 >    This Diameter application provides Diameter clients in SIP servers
 >    with a centralized routing information functionality, so that if a
 >    Diameter client in a SIP server wants to find out routing information
 >    for a particular user, the Diameter server can return (in a Diameter
 >    LIA message) the SIP URI of the SIP server allocated to the user.
 >    This allows SIP servers operating in a stateful mode to receive all
 >    the SIP traffic addressed to the user.  For this functionality to
 >    work, the SIP server allocated to the user ought to register its URI
 >    to the Diameter server.  This is accomplished with the SIP-Server-URI
 >    AVP provided in the Diameter MAR command that we describe in this
 >    section.

The above paragraph seems a bit out of place here.  Maybe just: "The
MAR command also registers the SIP server's own URI to the Diameter
server so that future LIR/LIA messages can return this URI."

 >    +-------------------------------+------+-------------+--------------+
 >    | AVP Name                      |  AVP |  Reference  |   Data-Type  |
 >    |                               | Code |             |              |
 >    +-------------------------------+------+-------------+--------------+
 >    | SIP-User-Authorization-Type   | xx25 |   Section   |  Enumerated  |
 >    |                               |      |     8.10    |              |
 >    | SIP-User-Data-Already-Availab | xx27 |   Section   |  Enumerated  |
 >    | le                            |      |     8.12    |              |

Suggest breaking the line at "-" rather than in the middle of the
word.

 >    value combination per AVP value.  If the Digest header contains
 >    serval unknown parameters, then the Diameter implementation MUST

s/serval/several/

 > 8.5.23  Digest-Expected-Response AVP
 >
 >    The Digest-Expected-Response AVP (AVP code TBD) is of type UTF8String
 >    and contains the value, pre-calculated at the Diameter server, of the
 >    Digest response that the SIP UA is expected to include in the
 >    response parameter in the Digest authentication.  The Diameter server
 >    MAY include this AVP to enable and assist the SIP server in
 >    authenticating the SIP UA.  This pre-authentication mechanism is only
 >    applicable when the SIP UA does not use client nounces (see below).

s/nounces/nonces/

 >    It is up to the Diameter server to include a Digest-Expected-Response
 >    AVP.  The Diameter server calculates the Digest expected response
 >    with the username, password, realm and nounce as inputs, and places

s/nounce/nonce/

 >    o  DIAMETER_SUCCESS_SERVER_NOT_STORED              2xx7
 >       The user was successfully authenticate.  The Diameter server does

s/authenticate/authenticated/

 >    (i.e., the Digest-Expected-Response AVP is available to the SIP
 >    server) is not enough to conclude that authentication will take place
 >    in the SIP server.  It might be still possible that the SIP UA
 >    includes client nounces in the expected response (e.g., "qop"

s/nounces/nonces/

 >    o  Added a new Digest-Expected-Response AVP that allows the Diameter
 >       server to send a pre-calculated expected digest response to the
 >       Diameter client.  This is only applicable to the case when the SIP
 >       UA does not use client nounces.

s/nounces/nonces/

 >    o  List of auhors trimmed.  Contributors section added.

s/auhors/authors/

 >    o  The scenario "Diameter server authenticates the user" had an
 >       error, because it was assuming that the MAR/MAA commands were used
 >       to download the user profile.  However, MAR/MAA do not contain
 >       provisions to donwload any user profile.  The solution is to add a

s/donwload/download/