Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)
Note: This ballot was opened for revision 06 and is now closed.
(Allison Mankin) Yes
(Harald Alvestrand) No Objection
Comment (2005-02-03 for -)
Reviewed by Suzanne Woolf, Gen-ART Her review: This document seems to be in pretty good shape to be published as Informational; it motivates the need for e2m and describes the characteristics of successful e2m security for SIP. However, I have some reservations. I may have found it hard to follow simply because I know little about the underlying protocol. But it may need to be clarified in several places, e.g. "This requirement is not necessary when a provider that operates the proxy server does not permit to reveal the security policies to a different provider that the recipient UA belongs to." I *think* I know what it means but it might be clearer to say "This requirement is not necessary when the provider operating the proxy service does not allow its security policies to be revealed to the provider serving the recipient UA."
(Margaret Cullen) No Objection
(Ted Hardie) (was Discuss) No Objection
(Sam Hartman) (was Discuss) No Objection
(Scott Hollenbeck) No Objection
(Russ Housley) (was Discuss) No Objection
Section 2.1: s/request base on/request based on/ Section 2.1: ASCII Art is difficult, and often subjective. To me, the following is more self-consistent. In the original, I was asking myself if the inconsistencies meant anything, and I convinced myself that they did not. Second, I propose "[C]" to denote a content that is protected. This allows multiple layers of encapsulation to be shown if needed. Home Network /---------------------\ | +-----+ +-----+ | +-----+ +-----+ User #1-----| C |-----| [C] |-----| [C] |-----| C |-----User #2 | +-----+ +-----+ | +-----+ +-----+ | UA #1 Proxy #1 | Proxy #2 UA #2 \---------------------/ If you accept any of these changes, please consistently use them in the rest of the figures too. Section 2.2.1: The 2nd paragraph of this section should read: > > This service might be deployed in financial networks, health care > service provider's networks, as well as other networks where > archiving communication is required by their security policies. Section 4.1: I think the following revised text has the same meaning, but I think it is more straightforward: > > REQ-GEN-2: It SHOULD NOT have an impact on proxy servers that do > not provide services based on S/MIME-protected bodies > in terms of handling the existing SIP headers. Reference  should point to RFC 3850. Reference  should point to a specification of the Location Object, not the requirements for the location object.