Subject: [Sip] comments on draft-ietf-sip-e2m-sec-00

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 30 Jul 2005 23:37:56 -0400

A few comments on this. I'm not sure if these have been discussed 
before; sorry if they have.

I'm not sure its such a good idea to reuse the 493 response code. Though 
it is true that the error here is that the request is undecipherable, 
the 493 response was defined in the context of it being undecipherable 
by the UAS, not an intermediate proxy. Indeed, the UAC behavior in the 
case where it is undecipherable for a UAS is different. There, the 
response body contains a public key that is supposed to be used, and the 
UAC re-encrypts with this public key as the only desired recipient. In 
the e2m case, the client keeps the original public key, but adds a new 
one to the set of recipients. This is a fundamentally different behavior 
IMHO.

I'm also a bit puzzled about why a target needs to be specified for the 
signatures. A signed body doesn't need to be targeted for a specific 
proxy; any proxy can verify the signature if it likes. Perhaps I am 
missing something...

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: Kumiko Ono <[email-masked]>
Date: Sun, 31 Jul 2005 17:49:29 -0400

Jonathan,

Thank you for the comments.  See inline.

>one to the set of recipients. This is a fundamentally different behavior 

I agree. As you pointed out, the UAC is expected to react differently 
when receiving the 493 response code from the proxy. In addition, the 
error response doesn't include who the sender is,  so there is no way 
for the UAC to know whether it's the UAS or the proxy server. 
For the UAC to behave properly, we need a new error code (496 Proxy 
Undecipherable).

>proxy; any proxy can verify the signature if it likes. Perhaps I am 

A motivation for this was the validation service at a specific proxy 
invocated by a UA, although any proxy on the signaling path can verify 
the signature. If there is no compelling usecase, we could drop this 
mechanism to simplify the mechanism. 

Thanks,
Kumiko Ono