Re: draft-ietf-simple-msrp-cema-05 WGLC comments - Section 4 and editorials (Ben)

Hi, I replied to the first section (4.2, 4.3, 4.4) separately. This is in response to the rest. I removed sections where I think no further comment is needed.

On May 15, 2012, at 4:17 AM, Christer Holmberg wrote:

[...]

> 
> 
> --1, 2nd paragraph" "middleboxes must read the message"
> 
> Just read? Or parse, or modify?

I don't see a reply to this one

[...]
> -----------------------
> 
> --2, "Name-Based..."
> 
> Definition is hard to parse. I think the point is two-fold. The endpoint uses a trusted CA to establish the validity of the peer certificate, then compares the SAN of the peer certificate has a match for the peer's  MSRP URI.
> 
> I am not sure I understand. Do you have a suggestion for modified text?
> 

How about the following:

"Name Based Authentication: An authentication method in which an endpoint receives an X.509 certificate from its peer as part of the TLS authentication. The endpoint validates that a chain of issuers exists from the certificate to a trusted certification authority, and that the certificate contains the domain name of the peer."

We could specify the SubjectAltName part, but I don't think that really adds to the definition.

[By the way, this brings up a question. Have we been assuming that name-based authentication survives an untrusted middlebox? It seems like if the middlebox acts as an MSRP B2BUA, it can just substitute an MSRP URI with its own domain name during the offer/answer.]

 
[...]
> 
> -----------------------
> 
> 
>> -- 4.2, step one  on receipt of an answer:
>> 
>> I have trouble parsing this
> 
> I think the text is clear. It says that the c/m does not match path, and that the endpoint will become passive.
> 
> But, if you think the text can be improved, feel free to suggest text.
> 
> 

Quoting the text here for convenience:

>  
> 1.  The SDP c/m-line address information associated with the MSRP
>    media description does not match Section 4.4 the information in the
>    MSRP URI of the ’path’ attribute(s) (in which case is assumed that
>    the SDP c/m-line contains the address to a Middlebox), and the MSRP
>    endpoint will become "passive" (if the MSRP media description of the
>    SDP answer contains an SDP ’setup:active’ attribute).

what do you mean by "... does not match Section 4.4..."

Suggested text:

"The SDP c-line and m-line do not match the address and port from the MSRP URI in the "path" attribute, and the offerer is forced to become "passive" by an a "setup:active" attribute in the SDP answer. This indicates that the m-line and c-line in the answer probably refer to a middlebox."

[...]

> 
> 
>> -- 6.2, 1st paragraph: "... where the offerer does not support the CEMA extension."
>> 
>> Doesn't that preempt some of the endpoint workarounds for when the peer does not advertise CEMA?
> 
> Yes, and the Middlebox doesn't need to enable MSRP B2BUA functionality in cases where the workarounds can be used.
> 
> 

So the middlebox is also assumed to check for the cases in 4.2 and 4.3?


[...]

> 
>> -- 7.7, 2nd paragraph" "...may be hard for the endpoint to decide."
>> 
>> Decide what?
> 
> I suggest to remove that sentence, and re-write the subsequent sentence in the following way:
> 
> 	"In the end it is up to the endpoint to decide whether the signaling path is trusted or not, and unless
> 	unless cryptographic end-to-end SDP integrity protection or encryption is used it may be hard for the
> 	 endpoint to make that decision."
> 

I guess my confusion is that I don't think the fact that the SDP is integrity protected or not changes whether the user trusts the signaling channel. If the SDP is integrity protected end to end, he doesn't _have_ to trust the signaling channel. If it's not, then he must decide if he trusts the network. 

I assume the text resulted from Robert's objection to the previous revision's assertion that an endpoint might decide it was okay to continue to communicate if authentication failed. I'm not sure just stepping back and saying "deciding is hard" is the right approach here. That may need further discussion with Robert and/or the security ADs.

OTOH, should a CEMA endpoint even try to use an end-to-end SDP integrity protection mechanism?