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

[Ben Campbell <[e-mail]>]

On May 28, 2012, at 2:19 AM, Christer Holmberg wrote:

> Hi,
> 
>>> --1, 2nd paragraph" "middleboxes must read the message"
>>> 
>>> Just read? Or parse, or modify?
>> 
>> I don't see a reply to this one
> 
> I guess it should be "parse and modify".

Okay

> 
> 
> -----------------------
> 
> 
>>> --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.]
> 
> The definitions looks good, except that matching the identity against the domain name of the peer wouldn't work in the peer-to-peer case (see RFC 4975, Section 14.2, 3rd paragraph). 

Sure, but we're not talking about the peer to peer case. I can't imagine why a b2bua would insert a different domain name unless it also intended to redirect the media.

> 
> A better idea is probably to match the identity against the SIP address-of-record in the to/from header field of the SIP INVITE, i.e. similar to how S/MIME certificates are being 
> used (see RFC 3261, Section 23.1). This method is not described by MSRP though, and using domain names is probably the only option right now. But, I would still like to change
> the last sentence in the definition to "contains the domain name or SIP address-of-record of the peer."

Right now there is no requirement that the endpoint use the same name for signaling and for MSRP. The expectation is that a name in the cert matches the MSRP URI supplied by the peer. Maybe there should be some tighter coupling between the MSRP name and the SIP AoR, I think that's out of scope for this draft.

I don't think the definition needs to describe the entire process. could we just say "name of the peer", perhaps with a disclaimer that that the meaning of "name" is as described by the protocol?


> 
> Whether name-based authentication can be used together with B2B middleboxes depends on the client behavior, but typically the answer would be no.  
> The user expects that the certificate used by the other endpoint of the TLS connection matches the identity of the peer (the user corresponding to the 
> SIP address-of-record in the from/to header field). Both peers would therefore notice if a middlebox acts as an MSRP B2BUA and can decide if the session 
> should be aborted. 

See my comment above. Right now, MSRP as defined in RFC4975 has no such expectation.

> 
> 
> -----------------------
> 
> 
>>>> -- 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..."
> 
> That is an editorial nit, and should be removed.
> 
>> 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."
> 
> In order to be consistent with terminology uses elsewhere, I would like to say "the offerer will beomce "passive", instead of using "forced".

Works for me.


> 
> 
> -----------------------
> 
> 
>>>> -- 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?
> 
> I still have some problems to understand the comment.
> 
> The assumption is that, when the offerer indicates support of CEMA, the Middlebox can modify the c/m line.
> 
> If the offerer does not indicate support of CEMA (e.g. due to the procedures in section 4), the Middlebox will enable MSRP B2BUA.

There are situations described in section 4 where an endpoint can attempt to use CEMA even if the other party did not indicate support. Do we assume the middlebox is also going to try to figure out those cases, or is it purely going to look for the CEMA tag? If the second,  does it require both parties to include it?

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

And of course the definition of trusting the channel I gave in the separate email a couple of minutes ago is completely inconsistent with that :-) But here I think we are talking about trust in operator middleboxes, right?

>> . 
>> 
>> 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?
> 
> Just because the SDP is integrity protected "end-to-end" does not necessarily mean that you don't have to trust the signalling path. 
> 
> If the entity signing the  SDP is part of the signalling path as in SIP Identity (RFC 4474), then the users are in effect trusting the signalling path (or at least parts of it). 
> If you're using some out-of-band mechanism such as S/MIME with user certificates then I agree with your statement (in my eyes this is true end-to-end integrity 
> protection).
> 
> Integrity protecting the entire SDP would not work since signalling nodes need to be able modify the c/m lines. Some new mechanism would need to specified 
> that lets you sign only the fingerprints.

Again, I think breaking down "trust the network" assertions to talk about what elements you trust for what purposes would help a lot here.