Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)
Note: This ballot was opened for revision 03 and is now closed.
(Gonzalo Camarillo) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Ralph Droms) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) (was Discuss) No Objection
Comment (2012-05-03 for -05)
Thanks for addressing my discuss points, I've cleared.
(Russ Housley) No Objection
(Pete Resnick) No Objection
Comment (2011-12-10 for -)
Section 3: "Support of the extension is optional." Do you mean "OPTIONAL"? "MSRP endpoints that support CEMA are required to use RFC 4975 behavior in cases where they detect that the CEMA extension cannot be enabled." Do you mean "REQUIRED"? Section 4.1: In the following cases, where there is a Middlebox in the network, the CEMA extension cannot be used... Do you mean "MUST NOT be used"? Section 4.2: When the offerer receives an SDP answer, if the MSRP media description of the SDP answer does not contain an SDP 'msrp-cema' attribute, the offerer MUST check the criteria below. If either or all of the criteria is met, the offerer MUST fallback to RFC 4975 behavior, by sending a new SDP offer according to the procedures in RFC 4975 and RFC 4976. This is mostly editorial, but since it involves 2119 language, I think it's worth fixing: The first MUST is redundant. If the offerer MUST do things based on the criteria, there is no need to say that you MUST check the criteria. (Also, "either" is the wrong word when there are more than two criteria. You meant "any".) Instead maybe: The offerer MUST fallback to RFC 4975 behavior, by sending a new SDP offer according to the procedures in RFC 4975 and RFC 4976, if it receives an SDP answer whose description does not contain an SDP 'msrp-cema' attribute, any of the following criteria are met: [1... 2... 3...] The new offer MUST NOT contain an SDP 'msrp-cema' attribute.
(Dan Romascanu) No Objection
(Peter Saint-Andre) (was Discuss) No Objection
It seems to me that the security considerations are somewhat underspecified, and I find the concept of a TLS B2BUA unsatisfying, but I will let folks from the security area comment on those aspects of the specification.
(Robert Sparks) (was Discuss) No Objection
(Sean Turner) (was Discuss) No Objection
Comment (2011-12-15 for -05)
s1: strike lawful intercept (I see Stephen made this a discuss otherwise I would have made it one too) s2: Fingerprint Based TLS AUthentication: r/self-signed TLS certificate/self-signed certificate r/fingerprint/fingerprint (i.e., a hash of the self-signed certificate) s2: Name Based TLS Authethication r/certificate authority/certification authority r/SubjectAltName parameter/SubjectAltName extension s3: r/Support of the extension is optional./ Support of the extension is OPTIONAL. s7.2: certificates are by definition public so I'm a little confused by the following: 1. TLS certificates together with support of interacting with a Certificate Management Service [RFC6072], to which it publishes the public version of its own self-signed certificate and from which it fetches on demand the public certificates of other endpoints. Maybe: 1. TLS certificates together with support of interacting with a Certificate Management Service [RFC6072], to which it publishes its self-signed certificate and from which it fetches on demand the self-signed certificates of other endpoints. s7.2: (Stephen caught this too) MIKEY-TICKET is a normative reference. s7.2: I share the same concerns Stephen has wrt the fingerprint authentication. s7.3: Probably worth a pointer to the SIP issues based on the following: Even with seemingly end-to-end media integrity, at the time of the publication of this document there are other vulnerabilities in MSRP, due to vulnerabilities in the SIP signaling.