Subject: [AAA-WG]: RE: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt

From: "Jayshree Bharatia" <[email-masked]>
Date: Wed, 9 Jul 2003 18:00:01 -0500

Hi Miguel,

Please see my response below.

Thanks,
Jayshree

> -----Original Message-----
> From: Miguel A. Garcia [mailto:[email-masked]] 
> Sent: Wednesday, July 09, 2003 2:03 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: [email-masked]'; [email-masked]'
> Subject: Re: Comments: draft-belinchon-aaa-diameter-mm-app-01.txt
> 
> 
...
> > Section 3.1 and 3.2 (general)
> > - I don't see much difference between the scenarios 
> discussed in section
> >   3.1-"Diameter server authenticate the user" and section 
> 3.2 -"SIP server
> >   authenticate the user". There are just couple of steps (13 and 14)
> > which are 
> >   different from the description of these sections. Since 
> these scenarios
> >   are discussed in different context, it's better to show 
> which commands 
> > are
> >   used for what purpose and consolidate the description.
> 
> I think it is important to highlight the difference between these two 
> scenarios. 3.1 is more aligned with the AAA architecture, 
> where a Diameter 
> server is authenticating users. This is the main role of the 
> AAA server. 
> Section 3.2 describes a scenario that is used in 3GPP, where 
> the Diameter 
> server delegates authentication to the SIP server.
> 
[JB] The current title of section 3.2 is "SIP server authenticates the user"
so you may need to correct this to reflect your above point. I am not sure
how (and where) SIP server delegates authentication to the SIP server in the
current flow. I thought SAR basically does what MAR is doing plus provides
SIP server address to the Diameter Server for the future use. Is it what you
are referring to? It will be useful if you show set of commands used when
the Diameter server is authenticate the user vs the SIP server authenticate
the user. 
 
> I believe both scenarios have different values in different 
> networks. From 
> the point of view of the application, we just want to provide 
> the means to 
> use either of the scenarios. 3GPP has chosen to go for 
> scenario 3.2, but 
> other networks will most likely use scenario 3.1.
> 
> Please, let me know exactly what is missing. I am able to add any 
> clarification to the text.
> 
...
> >   Additionally,  I would think that it will be better to 
> mention what
> > value will
> >   be assign to SIP-Public-User-Identity parameter in case 
> of non-3GPP 
> > usage.
> 
> This is not dependent on 3GPP or not-3GPP. The 
> SIP-Public-User-Identity is 
> what in normal SIP is called an Address Of Record (AOR). In an INVITE 
> request, the SIP AOR comes in the Request-URI. In a REGISTER 
> request it 
> comes in the To field.
> 
> The 4th paragraph in section 5.1 should answer your concern:
> 
>     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.
> 
> And that makes me think that the SIP-Public-User-Identity 
> should be renamed 
> to SIP-AOR (Address of Record) to align the terminology with SIP...
> 
> 
[JB] Agree. It will be good if you can rename this field.
> 
> > - This section says that the Diameter server must include either the
> > address of
> >   the SIP server  or the capability needed by the SIP 
> server. Does it 
> > mean that
> >   requesting SIP server always have capability to derive 
> next hope based 
> > on the
> >   capabilities received from the AAA? Why do we have this additional
> >   requirement.
> > 
> 
[JB] Sorry for the confusion I am referring to section 5.2 only (4th
paragraph) which is specific to UAA. 

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

My point is why UAA (and hence UAR) is tied with having SIP server address
or SIP server capabilities? My understanding from reading this draft is that
UAR can be triggered upon receipt of any SIP request and may be used any
time during the transaction. If this is the case than the requirement on
having the SIP server address or capabilities should be soften. My
suggestion is to separate Authorization operation from the explicit
Assignment/Retrieval of the SIP server address.

> Here I am lost. Are you still discussing section 5.1??? Which 
> paragraph are 
> you referring to??? I don't find the text you mention.
> 
> Thanks a lot for reviewing the text. Please, keep on posting 
> additional 
> comments.
> 
> Regards,
> 
>      Miguel
> 
> > Regards,
> > Jayshree
> > 
> 
> 
> -- 
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                          Jorvas, Finland
> mailto:[email-masked]     Phone:  +358 9 299 3553
> mailto:[email-masked]        Mobile: +358 40 5140002
> 
> 
> 
> 
> 
>

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 10 Jul 2003 14:13:21 +0300

Inline...

Jayshree Bharatia wrote:

> [JB] The current title of section 3.2 is "SIP server authenticates the 
> user" so you may need to correct this to reflect your above point. I am 
> not sure how (and where) SIP server delegates authentication to the SIP 
> server in the current flow. I thought SAR basically does what MAR is 
> doing plus provides SIP server address to the Diameter Server for the 
> future use. Is it what you are referring to? It will be useful if you 
> show set of commands used when the Diameter server is authenticate the 
> user vs the SIP server authenticate the user.

I will change the title of section 3.2 to reflect the delegation.

The Diameter server delegates authentication to the user in a MAA command. 
MAA contains, in this case, one or more SIP-Auth-Data-Item  (authentication 
vectors). SAR has another functionality of downloading the user profile.

[snap]
> "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."
> 
> My point is why UAA (and hence UAR) is tied with having SIP server 
> address or SIP server capabilities? My understanding from reading this 
> draft is that UAR can be triggered upon receipt of any SIP request and 
> may be used any time during the transaction. If this is the case than 
> the requirement on having the SIP server address or capabilities should 
> be soften. My suggestion is to separate Authorization operation from the 
> explicit Assignment/Retrieval of the SIP server address.

We agree that the SIP server uses UAR (and UAA) to request Authorization to 
  provide a service. The service may be "user wants to register (REGISTER 
message)" or "user wants to establish a session with another guy (INVITE 
message)". That is clear for you and me.

I think that in any case a SIP edge proxy may need to know:
a) Whether the proxy is authorized to provide the service to the user
b) If the proxy needs some routing information (e.g., the address of 
another proxy that is serving the user).

We could of course separate both commands, but then we require one more 
roundtrip operation, because afterach each UAR, the Diameter client will 
require routing information, always. That's the reason why they are 
combined. And because this command is used for routing realtime traffic, I 
wouldn't like to add one more rountrip of delays to the session setup time. 
Don't you agree with this motivation?

Regards,

       Miguel