Subject: RE: [Sipping] proxy accounting

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

Jari,
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Friday, February 28, 2003 10:33 AM
> 
> > - 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 (?)
> 
> 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.
I was thinking of a combination where the first proxy authenticates
with digest and inserts a P-Asserted-Identity header afterwards.

taking your comment into account, the list looks like this:

Digest: proxy relies on itself

P-Asserted-Identity: proxy relies on the first proxy to do the checking (using
  digest or TLS) and on intermediate proxies not discarding P-Asserted-Identity.

S/MIME: proxy relies on the CA to do the checking

OSP-Token: proxy relies on the OSP-Server to do the checking

 > Also, what is "proxy usage"? Is it routing an INVITE, REGISTER
> through the proxy, or is it counting every SIP protocol message?
I meant counting protocol messages.

> 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.
You are right, I was mixing things up, Digest has other limitations
here. Imagine a scenario where all proxies in a path subsequently
challenge all requests of a UA. Call setup times will be bad.

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