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

[Miguel Garcia <[e-mail]>]

Hi Jari:

Thanks for reviewing the draft. Inline discussion follows:

I have made a few changes to the current working copy (not submitted 
yet). Note the date of the draft should be August 29 or later, 
otherwise, refresh your browser.

As usually, this working copy can be found at:
http://people.nokia.net/~miguel/drafts/pre/draft-ietf-aaa-diameter-sip-app-04.txt

HTML version:
http://people.nokia.net/~miguel/drafts/pre/draft-ietf-aaa-diameter-sip-app-04.html

The diff with respect version -03 is:
http://people.nokia.net/~miguel/drafts/pre/draft-ietf-aaa-diameter-sip-app-03-to-04.html

Jari Arkko wrote:

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

The text says "provide accounting information", because the Diameter 
server sends the addresses of the AAA servers that collect accounting data.

I agree that the text is not clear: here is the proposed text:

"The Diameter SIP application can be used in a SIP environment where an
interface to a AAA infrastructure is required to authenticate and
authorize the usage of SIP resources. This application provides a 
limited support for accounting serviers, limited to the Diameter server
being able to provide the addresses of accounting severs to the
Diameter client. "

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


Yes, section 8.1.2 provides a linkage to the CC application. But I think 
it is reasonable to link also in this section, since we are describing 
other Diameter applications. I will add the following text:

" This Diameter SIP application is loosely related to the Diameter 
Credit Control Application[I-D.ietf-aaa-diameter-cc]. Although both 
applications are independent, the Diameter SIP application is able to 
supply the addresses of credit control servers that will be implementing 
the Diameter Credit Control Application[I-D.ietf-aaa-diameter-cc]."


> 
>  >                     +--------+           +--------+         +--------+
>  >                     |  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.

This is known because the SIP architecture provides for the existance of 
"roles" of servers. For instance, SIP defines the concet of an "outbound 
proxy" (it could be SIP server 1). Also, SIP server 1 could be an "edge 
proxy" that has knowledge of the topology of the network, so requests 
coming from external networks are treated differently from requests that 
are coming from internal networks.

If an external user happens to send a SIP REGISTER request to SIP server 
1, since the user is external (SIP URI belonging to a different domain), 
the SIP server will either forward, redirect, or reject this request. I 
don't think we need to explain these SIP concepts in this draft.

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

We never had a requirement to use the routing aspects of this spec, so I 
never thought about this scenario. But I believe it is possible. Section 
5.5 (Session attemp) provides an example of a routing scenario. While 
this scenario is meant to route incoming requests from other users, I 
believe it is applicable for the case you have in mind.


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

First of all, let me start indicating that we need to support two 
scenarios (described in Figures 2 and 3).

If we want to avoid one roundtrip less, then we would need to add the 
"please send me the user profile" semantics to MAR/MAA, and I think is 
simpler just to keep those semantics in the existing SAR/SAA.

Another solution would be to use SAR/SAA in steps 13 and 14 of Figure 2, 
but we would be changing the semantics of SAR/SAA and mixing them with 
MAR/MAA. In this figure 2, MAR clearly has the semantics "please 
authenticate/authorize this user with this credentials", whereas SAR 
indicates "This SIP server will be serving this user, and please send me 
the user profile".

I wouldn't like to mix semantics more.

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

No, this is not the idea. But it is good that you point it out, because 
we have already one open issue to this respect:
http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue11

I think there is an error here, since the Diameter server ***sends*** 
the PPR command to the Diameter client, so obviously, the text "if the 
Diameter server requires a User-Name AVP value to process the Diameter 
PPR request" does not make sense. It seems to be a copy/paste error.

So I think the PPR command ought to contain a mandatory User-Name AVP 
(currently optional), and cannot contain SIP-AOR AVPs, because the 
SIP-AOR URIs will be part of the profile sent in the SIP-User-Data.

Additionally, I have deleted the paragraph that used to discuss the 
absence of User-Name in the PPR command.



> 
>  >    [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.

The thing is that SIP provides support for several authentication 
mechanisms: HTTP Digest authentication, S/MIME, TLS, etc. Only HTTP 
Digest is mandatory to implement, and only HTTP Digest is supported by 
the Diameter SIP application.

So that paragraph is just saying that if HTTP Digest is used to 
authenticate the user, then the User-Name comes in the username 
directive of the Authorization header. But if other mechanism is used, 
then the username will come somewhere else (although it is not supported 
by the application).

I will add yet another reminder that we only support HTTP Digest 
authentication.

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

I think this is, by far, the most important issue that we need to solve, 
and this is linked to this open issue:

http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue4

So, basically. I believe we need the means to identify the type of 
profile that is sent. Of course we don't want to describe here the 
contents of the profile, but just list it.

3GPP has defined their own user profile in TS 29.228 version 5.8.0 Annex 
E. I am not aware of the existence of other user profiles.

My suggestion:

- Create a new grouped AVP, by name SIP-User-Profile, that contains two 
other AVPs.
- One is a new integer SIP-User-Profile-Type, that contains an integer 
describing the type of user profile
- The other is the current SIP-User-Data, i.e., the actual user profile.

Additionally, we should create another AVP (that allows repetion), by 
name SIP-Supported-User-Profiles. The idea is that the Diameter client 
can indicate in the SAR command which types of user profiles are 
supported, and the Diameter server can send one that suits the Diameter 
client.

How about that?

Further more: I think this requires to open an IANA registration of the 
types of user profiles. This is the bit that I don't like, so I am open 
to suggestions to avoid this IANA registration process.



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

I added the following paragraphs:

This Diameter SIP application allows a Diameter client to use the 
properties of HTTP Digest authentication[RFC2617] by evaluating or 
sending to the Diameter server the credentials supplied by a user. When 
Section 4 of RFC 2617[RFC2617] discusses HTTP Digest authentication, it 
is also applicable to this memo.

This Diameter SIP application also allows a Diameter client to use the 
properties of HTTP Digest authentication using AKA[RFC3310] by 
evaluating or sending to the Diameter server the credentials supplied by 
a user. Section 5 of RFC 3310[RFC3310] is also applicable to this memo.


I don't want to create a dependency on AKA v2, because of two reasons: 
first we haven't studied whether we support it straight forward or not. 
Second, this will create a normative dependency... and I am not sure of 
the fate of AKA v2.


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

Good. Changed to:

This document assumes a general architecture where a Home Realm is
composed of one or more nodes implementing Diameter or SIP
functions. Users are issuing SIP request to access SIP resources. For
each particular user, the Home Realm needs to authenticate and
authorize the usage of those resources and/or route to the appropriate
node. We assume that the database containing the user related data is
located outside the SIP node that requires authorization. Data
belonging to different users may be stored in different nodes in the
Home Realm, but we assume that all the data related to a particular
user is stored in a single node.

> 
>  > Table of Contents
> 
> How about capitalizing first letters of words in section
> titles?

Yeap. Done.

> 
>  >    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."

Done.

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

This is just an example of operation, wher we can see the whole picture. 
I think that if we move the UAR/UAA case to another section, we will 
miss the whole picture with the REGISTER request. I will keep this as is.

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

Ok, I will add it.

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

Section renamed as suggested. Now this paragraph reads:

An operator with a large base of installed SIP servers may wish to
minimize the number of round trips between the Diameter client and the
Diameter server. We provide support for a mechanism that allows the
Diameter server to delegate the final authentication check to the SIP
server, saving a round trip. However, it must also noted that this
scenario is only applicable when the authentication of the user does
not use client nonces, since the mechanism is based on the computation
of an expected response in the Diameter server, which makes it
available to the SIP server.

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

Ooops, I fixed it across all document.

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

We can't even speak about "called" user, since there may not be a call. 
For instance, the SIP request can be a SUBSCRIBE request, that does not 
create a call.

But I agree that "Session attempt" is not good either. I have renamed 
this section to "Locating the recipient of the SIP request", which I 
believe I generic enough to be valid in all scenarios.


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

Agree. I deleted the first sentence.

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

ok

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

ok

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

ok

> 
>  >    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."

Ok, changed as suggested.

> 
>  >    +-------------------------------+------+-------------+--------------+
>  >    | 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.
> 

I am trying to increase the width of that column. Most of this 
formatting is doing by xml2rfc, so let's see if I am able to do 
something better than what we have now.

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

Fixed. I also spell checked the whole buffer.

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

Ok

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

Ok

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


When I was fixing this one, I discovered another error, documented as 
issue 22 in:
http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue22

There are two Result-Code values with almost the same name, exactly the 
same semantics, but different value (2xx4 vs. 2xx7).

So I have deleted DIAMETER_SUCCESS_SERVER_NOT_STORED and kept 
DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED.


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

OK

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

Ok


> 
>  >    o  List of auhors trimmed.  Contributors section added.
> 
> s/auhors/authors/

Ok

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

OK


Regards,

       Miguel


-- 
Miguel A. Garcia           tel:[phone]
Nokia Research Center      Helsinki, Finland