Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft

From: Jiri Kuthan <[email-masked]>
Date: Tue, 04 Mar 2003 16:10:15 +0100

The issue is that you do not wish to force all requests to authenticate.
(Your new potential customer could never call you otherwise).

It is easy to decide which INVITEs to authenticate, it is hard
to decide which subsequent in-dialog requests to authenticate.
You no longer know the INVITE r-uri, which might have been
a key to the policy question "authenticate" or not?".

-jiri

At 11:35 AM 2/28/2003, Gonzalo Camarillo wrote:
>Juha,
>
>I still do not quite understand your arguments. Could you please
>elaborate on why a proxy cannot know that a message comes from a
>particular UA?
>
>Thanks,
>
>Gonzalo
>
>
>[email-masked] wrote:
>> 
>> Beck01, Wolfgang writes:
>> 
>>  > What kind of accounting information do we want to collect: The number
>>  > > of SIP messages per user? This is possible with an accounting
>>  > proxy.
>> 
>> unfortunately not.
>> 
>> -- juha
>_______________________________________________
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments of core SIP 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 04 Mar 2003 16:15:25 +0100

At 01:26 PM 2/28/2003, Gonzalo Camarillo wrote:
>Juha,
>
>OK, now I understand what you mean. Your proxy decides to perform or to
>not perform accounting for a particular request based on the From header
>field of the request. That is a poor choice. 

That is a very *good* choice.

There may be many conditions, which may make a server decide whether to
authenticate or not. From HF alone may or may not be sufficient, but there
are cases in which you definitely want to do that. In particular, you
do not wish foo.bar proxy to rubberstamp and forward a request with
foo.bar in From without verifying who is sending it.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 04 Mar 2003 16:20:41 +0100

At 02:14 PM 2/28/2003, Gonzalo Camarillo wrote:
>And if you are not concerned about security either and you want to base
>your service in the contents of the To (or From) fields, then your UA
>can actually modify the To field. What it cannot modify is the tag.

That's absolutely not applicable due to backward compatibility issues.

>If your proxy does not trust the UA because it is a billing proxy, for
>instance, your proxy will only accept requests with proper credentials
>or requests that are going to be routed to a known (by the proxy) UA.

What makes it hard is there are some transaction that take AAA and some
that don't. You need to distinguish between them. Authenticating everything
is not an option.

>But ensuring that the UA does not cheat is outside of the scope of the
>requirements, and it can be done in several ways.

Actually, being cheating-proof is a very good accounting requirements,
don't you think so?

> also, if the proxy serves multiple realms, how can it know which realm
>> the user that send the request within a dialog belongs to so that it can
>> insert the proper realm in the digest challenge?  today there is no
>> header in the request where the user could tell that it belongs to a
>> certain realm.  the from header is the only one, but it only works for
>> sure for initial requests.
>
>You can change the contents of the From field. No problem. In fact, one
>of the reasons we removed the To and From URIs from the dialog
>identifiers (only the tags remain) was to address this type of
>situation.

backwards-incompatible.

-jiri

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 05 Mar 2003 12:45:54 +0200

Hello,

a proxy can place this type of information in its Record-Route entry.

In Juha's example, the proxy routing the INVITE can notice that the To
field is for [email-masked], but the request-URI is [email-masked].
It can add a Record-Route entry that consists of this information
(encrypted with a key, if you want).

The proxy will not have to store state for the call, and will not have
to inspect the From field anymore.

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP