Subject: RE: [Sipping] proxy accounting, was: New version of the SIP-AAA reqs draft

From: "Beck01, Wolfgang" <[email-masked]>
Date: Fri, 28 Feb 2003 10:08:10 +0100

> -----Original Message-----
> From: Peterson, Jon [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 10:20 PM
> 
> I agree with Juha that it's pretty unlikely that a UA will 
> have an X.509
> cert it can use to do mutual TLS auth with a proxy. The proxy should
> definitely authenticate itself to the UA with a certificate, 
> but it is much
> more plausible that the UA will authenticate itself to the proxy with
> Digest. This is the model presented in RFC3261,  anyway.
> 

I was referring to theoretical possibility, deliberately ignoring
ugly real-world details. Btw, RfC3261 proposes S/MIME certificates
stored in UAs to identify end users.

Maybe Juha and I are talking about different things. The question
was: can any proxy on the path do a per-user accounting? If it is
not used for billing, there is no incentive for users to tamper
with the SIP headers and a certain percentage of incorrect
accounting records is tolerable. If it is used for billing - proxy
usage, not call duration - then we need some proof of origin. We
have:

- Digest + P-Asserted-Identity -> Problems with BYE and CANCEL, untrusted proxies
- TLS + P-Asserted-Identity -> no certs on today's UAs, only within one trust domain
- S/MIME signatures -> no implementations in sight
- OSP-Token -> not a standard yet, no implementations (?)

--
Wolfgang Beck
T-Systems Nova GmbH 
_______________________________________________
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: Jari Arkko <[email-masked]>
Date: Fri, 28 Feb 2003 11:32:38 +0200

> - OSP-Token -> not a standard yet, no implementations (?)

Yes, though I would modify this a bit. I wouldn't group Digest and
P-Asserted-Identity under the same heading; the difference is that
in the first the proxy itself is doing the checking whereas in the
other you are relying on someone else to have done it for you.

Also, what is "proxy usage"? Is it routing an INVITE, REGISTER
through the proxy, or is it counting every SIP protocol message?
If former, limitations you mentioned above may not matter.
Aren't the digest problems with ACK and CANCEL, not with BYE?
And I believe there's limited support for authentication of ACK,
just that no new challenge can be generated.

Thus, I think the table should be:

- P-Asserted-Identity -> Only reliable in an environment with trusted proxies
- Digest -> Ok in some cases, Digest limitations for CANCEL maybe ACK in
             some other cases
- TLS + P-Asserted-Identity -> no certs on today's UAs, only within one trust domain
- S/MIME signatures -> no implementations in sight
- OSP-Token -> not a standard yet, no implementations (?)

(This table applies only when talking about accounting for the purpose
of billing.)

Jari

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 28 Feb 2003 13:32:44 +0200

Beck01, Wolfgang writes:

 > - Digest + P-Asserted-Identity -> Problems with BYE and CANCEL,
 > - untrusted proxies

as i said, it would help quite a bit if we would change the rule how
from header is constructed when sending a request within a dialog.  i
propose that in the next version of the sip rfc, the uri of the sender
of the request is always used.  that would help the proxy to figure out
if it can challenge the request.

-- juha

---

From: [email-masked]
Date: Fri, 28 Feb 2003 12:28:48 +0200

> Aren't the digest problems with ACK and CANCEL, not with BYE?

no the problem is with any request within a dialog.

-- juha

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 28 Feb 2003 15:43:35 +0200

Juha,

> i

This is what I said in one of my previous mails. Per RFC 3261, you are
free to change your URL if you want. No change to the spec needed.

Gonzalo

---

From: [email-masked]
Date: Fri, 28 Feb 2003 15:48:39 +0200

> free to change your URL if you want. No change to the spec needed.

the text that i quoted, doesn't say so.  in order to get this capability
implemented in UAs, it must be a MUST in the text, or. alternatively, we
must have a new header/field where the realm can be placed.  the same
goes for the P header.  i don't know any general purpose sip ua that is
implementing it.

-- juha