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

From: Jari Arkko <[email-masked]>
Date: Thu, 26 Aug 2004 23:42:35 +0300

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/

---

From: Pete McCann <[email-masked]>
Date: Thu, 26 Aug 2004 19:54:31 -0500

Hi,

Apologies for being so very last-minute with these, but here are some
comments on draft-ietf-aaa-diameter-sip-app-04(pre).txt

I just saw Jari's note (haven't read it yet) so some of these may be
duplicates of his comments.  Also I still need to read carefully the
command and AVP specs but I assume they are in reasonable shape.

Most of these are editorial but I have a few technical questions as
well.

-Pete

Change:
   (SIP) Application.  This is a Diameter application that allows a
   Diameter client to request authentication and authorization
   information to a Diameter server for Session Initiation Protocol
To:
   (SIP) Application.  This is a Diameter application that allows a
   Diameter client to request authentication and authorization
   information from a Diameter server for Session Initiation Protocol

Change:
   the SIP server is able to receive and process SIP requests and
   responses which in turn relies on the AAA infrastructure for
To:
   the SIP server is able to receive and process SIP requests and
   responses and in turn relies on the AAA infrastructure for

Change:
   This application does not require or is not related to other
   authentication services provided by the Mobile IP Diameter
To:
   This application does not require and is not related to other
   authentication services provided by the Mobile IP Diameter

Change:
   At least, one of such nodes implements the Diameter Server
To:
   At least one of the nodes implements the Diameter Server

Change:
   The user data associated to a particular user is stored in a single
To:
   The user data associated with a particular user is stored in a single

Change:
   more than a single Diameter Server in the network, and all these
To:
   more than one Diameter Server in the network, and all these

Change:
   This document allows several configurations of the Home Realm.  In
   one of such configurations, a SIP server is allocated to a user for
To:
   This document allows several configurations of the Home Realm.  In
   one such configuration, a SIP server is allocated to a user for
Hmm... sort of reads like a patent application... :)

In section 5.2:
   According to Figure 2 a SIP User Agent Client (UAC) sends a SIP
   REGISTER request (step 1) to its home domain. 
It's not clear that the SIP server 1 is in its home domain, right?
Maybe just say "to a first-hop SIP proxy".

In section 5.2:
   Diameter server will respond with a Diameter Multimedia-Auth-Answer
   (MAA) message (step 6) with Result-Code AVP set to the value
   DIAMETER_MULTI_ROUND_AUTH.  The Diameter server will also include a
   challenge, which SIP server 2 will use to map into the
So, this document rules out the scenario where the SIP server chooses
the challenge, right?  Does this cause some backwards-compatibility problems
with draft-sterman, especially in light of the rsp-auth issue?  Maybe it's
not a problem.

Section 5.3:
Should note in the security considerations section that if an attacker has
access to the Diameter server to send MAR, it may be able to get a set of
expected responses if operating in delegated authentication mode.

Section 5.8:

This section describes a mechanism for redirecting to a particular
Diameter server based on an AVP contained within the request.  While
it does state:

      Note that according to the Diameter procedures the redirect
      functionality in the Diameter client is performed automatically in
      the Diameter stack, and it does not require any knowledge or
      support by the Diameter application.

However, this text seems to be contradicted by the use of an
application-specific AVP (the SIP-AOR) to do the proxy/redirect.  It
seems like message routing should be based on the User-Name AVP and/or
the Application ID and nothing else if you want compatibility with the
redirect functionality in the base Diameter protocol.  Would it be
possible to encode the SIP-AOR in the User-Name AVP?

Change:
   All the data associated to a user will be still stored in a single
To:
   All the data associated with a user will be still stored in a single

Change:
   This configuration, although scales well, introduces a new problem,
   namely: giving the SIP AOR as an input, how to determine which of
To:
   This configuration, although scales well, introduces a new problem,
   namely: given the SIP AOR as an input, how to determine which of

The Security Considerations seem inadequate and I expect this document
would be returned by the IESG on that basis... unfortunately I only
have the one concrete suggestion for this section (given above) but I
would recommend that a more thorough investigation of the security
considerations be performed.

On the issue of compatibility with draft-sterman, I note that this
application contains a lot more functionality than draft-sterman; the
capabilities to route SIP messages and download/update subscriber
profiles are not contemplated by draft-sterman, which is a simple
mapping of HTTP-Digest onto RADIUS.  Maybe this is ok, if the only
goal is to allow draft-sterman networks to use a Diameter back-end,
but maybe it should be noted that a SIP server using the SIP-Diameter
application cannot be supported by a RADIUS back-end.

---

From: Miguel Garcia <[email-masked]>
Date: Sun, 29 Aug 2004 12:48:05 +0300

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

> talking about what SIP-specific AVPs can and should appear in

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

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

> authenticated by the server, but for others we pass the SIP request

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.

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

> applications such as NASREQ, all authz information is provided in the

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.

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

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

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

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

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

> How about capitalizing first letters of words in section

Yeap. Done.

> redirect mechanism, and is further described in Section 5.8."

Done.

> MAR/MAA/SAR/SAA exchange, and have another section for the

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.

> SAR/SAA exchange. Add something about that to the above?

Ok, I will add it.

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

>  >    2 (step 12).  If the credentials include a client nounce, then SIP

Ooops, I fixed it across all document.

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

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

Agree. I deleted the first sentence.

>  >    As the SIP REGISTER request implicitly carries a permision to bind an

ok

> s/imported from/defined in/

ok

>  >                  [ SIP-Accouting-Information ]

ok

> server so that future LIR/LIA messages can return this URI."

Ok, changed as suggested.

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

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.

>  >    serval unknown parameters, then the Diameter implementation MUST

Fixed. I also spell checked the whole buffer.

>  >    applicable when the SIP UA does not use client nounces (see below).

Ok

>  >    with the username, password, realm and nounce as inputs, and places

Ok

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

>  >    includes client nounces in the expected response (e.g., "qop"

OK

>  >       UA does not use client nounces.

Ok

>  >    o  List of auhors trimmed.  Contributors section added.

Ok

>  >       provisions to donwload any user profile.  The solution is to add a

OK

Regards,

       Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 30 Aug 2004 15:22:49 +0300

Hi Pete:

Thanks for the comments. Yersterday I posted an update of the forthcomng 
draft, fixing most of Jari's comments. I have now created another update 
(dating August 30th) that includes your comments:

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

HTML version:

Now, Inline discussion:

>    information from a Diameter server for Session Initiation Protocol

ok.

>    responses and in turn relies on the AAA infrastructure for

ok.

>    authentication services provided by the Mobile IP Diameter

ok.

>    At least one of the nodes implements the Diameter Server

This text has changed dur to Jari's comments.

OK

ok

> Hmm... sort of reads like a patent application... :)

Ok. I also removed "such", so it does not smell to any legal wording. So 
the text reads:

"In one configuration, a SIP server is allocated to ..."

> It's not clear that the SIP server 1 is in its home domain, right?

Right, it does not necessarily be located in the home domain.

> Maybe just say "to a first-hop SIP proxy".

It does not even need to be a "first-hop SIP proxy", AKA as an "outbound 
SIP proxy". It is just a proxy. Full stop.

> with draft-sterman, especially in light of the rsp-auth issue?  Maybe it's

At least I never heard a requirement where the SIP server chooses the 
challenge. I thought that what we want is to store the user's 
configuration (including shared secrets) in the Diameter server. I don't 
quite figure out what will be the role of the Diameter server if the SIP 
server challenges the user, which is standard SIP functionality (RFC 3261).

> expected responses if operating in delegated authentication mode.

What you mention is correct, but I don't see the security breach here. 
So a malicius SIP server gets an expected response from the Diameter 
server. So what can the malicious server do with the expected response? 
It does not contain the user's shared secret. And if the malicious 
server wants to bypass authentication of the user, what did it contact 
the Diameter server in the first place?

I think if there is a security concern we need to document it, but I am 
trying to find out what this security concern it. Please elaborate.

>       support by the Diameter application.

I believe the above text is not valid anymore.

> possible to encode the SIP-AOR in the User-Name AVP?

No, it is not possible because, in general, SIP messages do not carry a 
User-Name, unless the message has been re-sent due to a challenge. So if 
a User-Name is not included in the SIP message, we can only base this 
functionality on the SIP-AOR.

So what I would do: I would remove the text that indicates that the 
Diameter redirection takes placein the Diameter stack. I will also 
emphasize that the SLF is "based" on a Diameter redirect, although is 
not the same thing.

ok

ok

> considerations be performed.

Mmm... I would like to know what to write. I would like to understand 
what the IESG would be looking for here. Unfortunately I cannot read the 
IESG's minds, so I cannot foresee their concerns.

> application cannot be supported by a RADIUS back-end.

Yes, your assumption of operation is correct. I think we agreed that the 
compatibility issues will be documented in draft-sterman, so I would 
expect this discussion to be covered there.

Regards,

          Miguel