Subject: [AAA-WG]: Avi Comments (second installment): draft-belinchon-aaa- diameter-mm-app-01.txt

From: Avi Lior <[email-masked]>
Date: Mon, 4 Aug 2003 19:55:24 -0400

This is my second installment of comments:

A general comment is the issue of user-name.  As indicated in the following
comments the text is based on the fact that username is know but as you
point out it is sometimes not known. You need to address this issue for this
to be a general SIP solution.

 5.1  User-Authorization-Request (UAR) Command

...................

   The user name used for authentication of the user is conveyed in a
   User-Name AVP (imported from the Diameter baseprotocol [2]). 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 [4],
   the authentication user name is found in the "username" directive of
   the SIP Authorization header field value.

[AL] Sounds like there are other cases -- that is not a HTTP Digest.
What are they or are you just giving an example?

   The SIP or SIPS URI to be registered is conveyed in the
   SIP-Public-User-Identity AVP (Section 7.8). Typically this SIP or
   SIPS URI is found in the To header field value of the SIP REGISTER
   request that triggered the Diameter UAR message.

   The SIP-Visited-Network-Identifier AVP indicates the network that is
   providing SIP services (e.g., SIP proxy functionality or any other
   kind of services) to the SIP User Agent.

   Message Format
       <UAR> ::= < Diameter Header: aaa, REQ, PXY >
                 < Session-ID >
                 < Auth-Application-Id >
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 [ Destination-Host ]
                 { Destination-Realm }
                 { User-Name }
                 { SIP-Public-User-Identity }
                 [ SIP-Visited-Network-Identifier ]
                 [ SIP-User-Authorization-Type ]
               * [ AVP ]
               * [ Proxy-Info ]
               * [ Route-Record ]

[AL] I think you have an error with the Destination-Host the bracket
should either be '{' or it should be moved down the list.

      OPEN ISSUE: according to the above description, the User-Name AVP
      is mandatory in the UAR message. This AVP is always available in a
      3GPP environment, because 3GPP has mandated the private user
      identity to be present in every REGISTER request. However, in a
      general SIP environment, a SIP client will not insert any identity
      without being challenged. Therefore, the User-Name AVP may not be
      present. Action: investigate if this AVP can be set to optional.

[AL] I think this is a serious issue for this document since it seems to
me that you depend very heavily on the existance of the User-Name
attribute. To be a general solution which you would have to be in the
AAA-WG, I would think you would have to allow for this to be optional. I
dont see any other way.

5.2 User-Authorization-Answer (UAA) Command

...................

   When the authorization procedure succeeds, the Diameter server
   constructs a User-Authorization-Answer (UAA) message that MUST
   include either the address of the SIP server already assigned to the
   user or the capabilities needed by the SIP server (Diameter client)
   to select another SIP server for the user. This section will be based
   on the required capabilities of the SIP server to trigger and execute
   services for the user. The former option is used when the Diameter
   server is aware of an allocated SIP server to the user, whereas the
   latter is used when the Diameter server is not aware of an allocated
   SIP server, letting the SIP server to choose, if needed, an
   appropriate SIP server according to the required capabilities.

[AL] The wording of the above par. is awakward. What do you mean by
"This section will be based on the required capabilities...."?

   At reception of the Diameter UAR message, the Diameter server MUST
   verify the existence of the user in the realm, i.e., the User-Name
   AVP value is a valid user within that realm. If the Diameter server
   does not recognize the user name received in the User-Name AVP, the
   Diameter server MUST build a Diameter User-Authorization-Answer (UAA)
   message and MUST set the Result-Code AVP to
   DIAMETER_ERROR_USER_UNKNOWN.

[AL] Change "MUST build a" to "MUST reply with a"

[AL] Is the above paragraph true? Is the user-name the only thing that
can be used to allow the process to continue? This is not really where
the authentication happens right? So other attributes could be used to
verify whether the process should go on? Especially since the username
could be optional.

   Then Diameter server MUST authorize that User-Name AVP value is able
   to register the SIP or SIPS URI included in the
   SIP-Public-User-Identity AVP. If this authorization fails, the
   Diameter server must set the Result-Code AVP to
   DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
   User-Authorization-Answer (UAA) message.
   
[AL] Change "Then Diameter server" to "Next, the Diameter server"

[AL] Again here you are talking about a specific 3GPP behavior no?
user-name can be optional right?

   If there is a SIP-Visited-Network-Identifier AVP in the Diameter UAR
   message, and the SIP-User-Authorization-Type AVP value received in
   the Diameter UAR message is set to REGISTRATION or
   REGISTRATION&CAPABILITIES then the Diameter server SHOULD verify
   whether the user is allowed to roam into the network specified in the
   SIP-Visited-Network-Identifier AVP in the Diameter UAR message. If
   the user is not allowed to roam into such network, the Diameter AAA
   server MUST set the Result-Code AVP value in the Diameter UAA message
   to DIAMETER_ERROR_ROAMING_NOT_ALLOWED.

[AL] Can't i make the decision whether the user is allowed to roam based
only on the SIP-Visited-Network-Identifier? If i dont have a roaming
agreement with the network why should i bother looking up a user? Its
probably faster to do that. SImilar to RADIUS Call Check functionality.

.......................

   In case that the SIP-User-Authorization-Type AVP value received in
   the Diameter UAR message is set to REGISTRATION then:

   o  If the Diameter server is not aware of any previous registration
      of the user name (including registrations of other public user
      identities allocated to the same user name), then the Diameter
      server does not know of any SIP server allocated to the user. In
      this case the Diameter server MUST set the Result-Code AVP value
      to DIAMETER_FIRST_REGISTRATION in the Diameter UAA message, and
      the Diameter server SHOULD include the required SIP server
      capabilities in the SIP-Server-Capabilities AVP value in the
      Diameter UAA message. The SIP-Server-Capabilities AVP will assist
      the Diameter client (SIP server) to select an appropriate SIP
      server for the user, according to the required capabilities.

[AL] what if the diameter server just wants to assign a specific SIP
server could it not set the SIP-Server-Name AVP?

[AL] There seems to be some wording problem between the above and below
par. Above you seem to say that the Diameter Server does not know of any
SIP server allocated to the user If the Diameter server is not aware of
any previous registration of the user name. Yet in the paragraph below
you say that in some cases, the Diameter server is aware of a previously
assigned SIP server

   o  In some cases, the Diameter server is aware of a previously
      assigned SIP server for the same or different public user identity
      allocated to the same user name. In these cases, re-assignment of
      a new SIP server may or may not be needed, depending on the
      capabilities of the SIP server. The Diameter server MUST always
      include the allocated SIP server URI in the SIP-Server-Name AVP of
      the UAA message. If the Diameter server does not return the SIP
      capabilities, the Diameter server MUST set the Result-Code AVP in
      the Diameter UAA message to DIAMETER_SUBSEQUENT_REGISTRATION.
      Otherwise, if the Diameter server includes a
      SIP-Server-Capabilities AVP then the Diameter server MUST set the
      Result-Code AVP in the Diameter UAA message to
      DIAMETER_SERVER_SELECTION. The Diameter client will then
      determine, based on the received information, whether it needs to
      select a new SIP server or not.

   In case that the SIP-User-Authorization-Type AVP value received in
   the Diameter UAR message is set to REGISTRATION&CAPABILITIES then
   Diameter Server MUST return the list of capabilities in the
   SIP-Server-Capabilities AVP value of the Diameter UAA message, it
   MUST set the Result-Code to DIAMETER_SUCCESS and it MUST NOT return a
   SIP-Server-Name AVP. The SIP-Server-Capabilities AVP enables the SIP
   server (Diameter Client) to select another appropriate SIP server for
   invoking and executing services for the user, depending on the
   required capabilities. The Diameter server MAY leave the list of
   capabilities empty to indicate that any SIP proxy can be selected.
   
[AL] What if the Diameter server does not want to allow the Client to
change? What would the response be?

............

End of section 5.2

Avi Lior
Bridgewater Systems Corporation
Phone  :          (613) 591-9104 x6417 or (613) 591-6655
Fax     :          (613) 591-6656
E-mail  :          [email-masked]
www.bridgewatersystems.com

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 11 Aug 2003 12:52:48 +0300

Avi:

Thanks a lot for your second round of comments. Some answers and 
discussion inline.

/Miguel

> to be a general SIP solution.

Yes, I am aware of this situation. We didn't have time to change this 
issue before the deadline, but next version of the draft will work to 
solve this issue.

>  5.1  User-Authorization-Request (UAR) Command

HTTP Digest is just one of the mechanisms used in SIP for 
authenticating users. Other mechanisms are possible, but optional for 
implementation, and they are:
- based on the presence of a P-Asserted-Identity (pre-authenticated)
- S/MIME bodies
- TLS
- perhaps some other (there is work on cryptographical identities in SIP).

The SIP specification mandates to implement HTTP Digest in all User 
Agents (end points), that's the reason why I provided a hint on how to 
find out the username when HTTP Digest is the mechanism.

> should either be '{' or it should be moved down the list.

I think Destination-Host should be mandatory, because the Diameter 
Client must, at this stage, be aware of the Diameter Server the 
request will be sent. But I will check if there is a case where it is 
optional (I doubt it).

> AAA-WG, I would think you would have to allow for this to be optional. I

I agree with you. That requires substantial changes to the document, 
add more example cases, etc. That's the main reason why we didn't have 
time to cover it before the last deadline.

> 5.2 User-Authorization-Answer (UAA) Command

Yes, the explanation is not deep enough. One of the functionalities 
allocated to SIP server 1 (the one at the edge), is the ability to 
select an appropriate SIP server that will execute and trigger 
services to the user (i.e., to select SIP server 2).

It is expected that different users will have different services, and 
that may require different capabilities of the SIP server. For 
instance, a user may require that his/her allocated SIP server is able 
to execute Java applets. So SIP server 1 is able to select an 
appropriate SIP server 2, among all those SIP servers in the network 
that fulfill the required capabilities.

So the functionality that we provide is:
- The Diameter server stores the capabilites required for the SIP 
server that will be serving the user.
- The SIP server may select an appropriate SIP server that fulfills 
the requirements (capabilities).

Of course, we don't enter into the arena of standardizing these 
capabilities, their semantics and so on. The Grouped AVP 
SIP-Server-Capabilities conveys that information, but basically as a 
collection of integers that identified capabilities. As this is an 
intradomain functionality, the administrator will define the semantics 
of "Capability 1" in his network.

For instance, in a network, "Capability 1" may convey the semantics 
"the SIP server has to support Java applets", whereas in another 
network it may mean "the SIP server has to support the Call Processing 
Language".

We don't enter into discussion how does SIP server 1 selects the 
server. That issue is out of the scope of the standardisation of the 
Diameter application for SIP.

> [AL] Change "MUST build a" to "MUST reply with a"

ok

> verify whether the process should go on? Especially since the username

Well, the paragraph will substiantially change when we consider the 
case when the User Name is unavailable. IMHO the User-Name is just 
used for authentication/authorization. So this first discrimination on 
whether the user exists or not should be based on the 
SIP-Public-User-Identity AVP (that is always available in SIP).

> [AL] Change "Then Diameter server" to "Next, the Diameter server"

ok

> user-name can be optional right?

Right. So this case is still valid *when the User-Name AVP is valid*, 
after authentication is requested. We need to add the case when the 
User-Name is not present in the request and the Diameter server 
requests authentication.

> probably faster to do that. SImilar to RADIUS Call Check functionality.

Yes, perhaps you are right. The number of roaming agreements with 
other networks will be significantly smaller than the number of users, 
so perhaps the order of checking should be inverted. We will do it.

This seems like a new case that is very easy to add it. So we will 
write some text with the following ideas:
- If the Diameter server is not aware of any previous registration, 
then there are two options:
a) The Diameter server allocates a SIP server to the user (so it will 
include a SIP-Server-Name AVP and whatever Result-Code).
b) The Diameter server delegates the allocation of the SIP server to 
the Diameter client (this is the text that is currently written).

> you say that in some cases, the Diameter server is aware of a previously

No, there is no wording problem. I will explain why:

The previous paragraph discussing the case when the Diameter Server is 
not aware of any SIP server allocated to the user. You can think of 
this situation as "when the user switches on his/her mobile phone".

During the registration period, the allocated SIP server will "save" 
its URI in the Diameter server (Command MAR, SIP-Server-Name AVP).

After that, the user will re-register oftely, or just register other 
identities allocated to him/her. In all this cases, the UAA command 
will go through the flow described below (when the Diameter server is 
aware of a previously assigned SIP server for the same or different 
public user identity allocated to the same user name)

> change? What would the response be?

Mmmmm... I think you have a point here... I need to ask the rest of 
the authors of the draft, but my first take on this is that the SIP 
server is not able to distinguish between REGISTRATION and 
REGISTRATION&CAPABILITIES. IMHO there should be only one value o fthe 
SIP-User-Authorization-Type: REGISTRATION. Then the Diameter server 
either returns the capabilities to do a selection or returns the 
SIP-Server-Name AVP to direct to another server.

As a conclusion, this issue needs further inverstigation.

Regards,

    Miguel
-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                         Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002