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

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Sep 2004 15:10:16 +0300

Hi Miguel, and thanks for your quick updates!
Some further discussion inline:

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

I wonder if it would be useful to provide a recommendation of
what AVPs can be carried in an accounting request. Or define
a one or two new ones. So that you could get the basic accounting
information from SIP at least. Say, caller and callee? Or do you
have them already?

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

Ok!

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

Yes, its fine.

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

Perhaps you could state this somewhere, just in the interest of
having orthogonal functions...

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

I see your point. How does this match with what is being done
in RADIUS. I can see that you might answer "there is no user profile".
However, I suspect vendors will be adding user profile VSAs anyway...

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

Great!

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

Ok.

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

This sounds like a useful compromise between no definition and
standard-only definitions.

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

Why not?

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

I see the problem.

You could use an informative reference -- its not like you are depending
on those references. Just that you carry Digest in your protocol, and
if people want to read on general Digest security issues they should
go to <SET OF DOCUMENTS>.

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

Ok.

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

Ok. Thanks.

--Jari

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 06 Sep 2004 12:14:58 +0300

Hi Jari:

Some more discussion inline.

> information from SIP at least. Say, caller and callee? Or do you

Let me see if I understand. Do you want to extend the Diameter SIP 
application to be able to carry caller, callee and so on, so that the 
Diameter SIP app. can do accounting?

I wonder if there is a need for it. I believe the Diameter CC app and/or 
the Diameter base can do this work. So I don't think we need to 
re-invent the wheel.

[snap]

> having orthogonal functions...

OK, I have added this text at the end of Section 5.5 Locating the 
recipient of the SIP request (formerly Session attempt):

"he scenario described in this section is also applicable in case an 
outbound SIP server is interested not in authenticating the user, but 
requires to locate a further SIP server to route the outbound SIP 
requests. In this case, the outbound SIP server is mapped to SIP server 
1 in Figure 5."

> However, I suspect vendors will be adding user profile VSAs anyway...

So I guess this should be a question addressed to the RADIUS draft.

[snap]

> go to <SET OF DOCUMENTS>.

To me the dependency on AKAv2 is a lower priority issue. Therefore, I 
would like to focuson errors (a few of them reported already). I am 
willing to add support to AKAv2 if someone assists me to indicate what 
is actually neeeded, if something is really needed.

Issue 27 created:

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

[snap]

Thanks a lot,

     Miguel

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Sep 2004 12:24:05 +0300

> Diameter SIP app. can do accounting?

What I meant was that Diameter SIP would define caller,
callee etc AVP which would be carried by Base/CC accounting
commands.

> the Diameter base can do this work. So I don't think we need to 

No commands should be defined, that's clear. But I'm basically
asking if the current set of AVPs (base/cc/sip) plus the base/cc
accounting commands are sufficient to do SIP accounting over
Diameter. Or do we need a "Diameter SIP Accounting AVPs" RFC
at some point in time? If we do, how many AVPs would it contain?
If its just two, then it might be more economical to add them
to Diameter SIP now.

Ok.

>>> 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 
>>> indicates "This SIP server will be serving this user, and please send 
>>> me the user profile".
>>>

Maybe. But I fear Wolfgang might say the question should be
addressed to you :-) What I'd like achieve is that the two
RFCs are aligned.

> To me the dependency on AKAv2 is a lower priority issue. Therefore, I 

Fair enough.

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

Thanks, I'll see if can get some suggested text to you.

--Jari

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 06 Sep 2004 13:40:52 +0300

> callee etc AVP which would be carried by Base/CC accounting

Ok, clear.

> 
>> I wonder if there is a need for it. I believe the Diameter CC app 
>> and/or the Diameter base can do this work. So I don't think we need to 
>> re-invent the wheel.
> 
> 

I did a fast analysis, and this is the result.

Diameter base include a User-Name AVP in the ACR/ACA commands. That is 
obviously not enough to carry all the charging information. A more 
detailed charging information should, in addition to the User-Name, include:

- Caller identity (Any URI: sip, tel, im, pres)
- Callee identity (Any URI: sip, tel, im, pres)
- SIP method (INVITE, SUBSCRIBE, MESSAGE)
- SIP server reporting URI, perhaps including role
- Redirected to: other SIP server
- Event type (for SUBSCRIBE/NOTIFY/PUBLISH requests)
- Call-ID
- Charging ID
- Timestamp
- Information linking to lower layers (e.g., authorized QoS, edge 
router, access information session, etc.)

Having seen this, I don't think it is feasible, at this stage, trying to 
  complete this work when there are not even requirements written. I 
have the feeling that, if we go in this direcction, we will not be able 
to produce something useful, since we don't know what the requirements are.

I propose that, in the future, someone may write an I-D that defines 
these AVPs that work in with the Diameter base protocol and the CC 
application.

[snap]

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

But what do you want me to write? Something like this?

"Note that the [draft-sterman] does not support the functionality of 
downloading the user profile from the server. Note also that 
[draft-sterman] is much narrower in scope and does not support routing 
capabilities, and some other functions".

To be honest with you, I wouldn't like to write this text.

Regards,

            Miguel

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Sep 2004 16:01:03 +0300

Hi Miguel,

>  complete this work when there are not even requirements written. I have 
> the feeling that, if we go in this direcction, we will not be able to 
> produce something useful, since we don't know what the requirements are.
> 

Ok. Your analysis looks very good, this was exactly what I was
looking for, thanks! And yes, I agree with you that defining
these is probably too much right now for your document. But hey,
at least we have identified a future work item for someone!

> To be honest with you, I wouldn't like to write this text.

This wasn't exactly what I was looking for. I guess I
still somewhat confused about the role of MAR/MAA vs.
SAR/SAA, and whether that has something to do with the
difference of authentication and authorization or not.
IF that is the split, one could perhaps ask if the
RFC 3588 Auth-Request-Type could be used to distinguish
the two from each other. This would probably work better
with RADIUS too, since Auth-Request-Type=AUTHORIZE_AUTHENTICATE
would map easier to Access-Request.

But I could be missing something very obvious.

--Jari