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

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 May 2012 11:17:38 +0200

Hi,

> -- 4.2, 4.3, and 4.4: I'm still afraid that sections 4.2, 4.3 are not going to result in interoperable implementations. The various efforts to decide you can still use CEMA even when the peer does not advertise it remind me of the rules of Fizzbin ( 
> http://en.wikipedia.org/wiki/Fizbin#Fizzbin ). Adding in the need to resolve names to IP addresses for comparison purposes in 4.4, I have to ask if we really think the benefit is worth the complexity? Can it be streamlined somehow?

In the past, we spent lots of time in order to clarify these sections, based on input from e.g. Eric Burger and yourself.  And, there aren't any major changes compared to version -03.

I really don't know how it can be further streamlined, and suggest to keep it as it is.

-----------------------

--1, 2nd paragraph" "middleboxes must read the message"

Just read? Or parse, or modify?

> -- "address:port"  (recurs throughout document)
>
> address and port. 

Ok.

-----------------------

> -- "c/m- line"  (recurs throughout document)
>
> c and m-lines, or c-line and m-line. (i.e. don't use "/" as a conjunction)

Ok.

-----------------------

> -- 1, 3rd paragraph: "...that normally result in negative performance impact"
>
> _which_ normally _results_...

Ok.

-----------------------

> -- 2, "Fingerprint Based TLS Authentication: An MSRP endpoint..."
>
> I don't think Fingerprint based TLS authn _is_ an endpoint--it's an action. (repeats for name-based..)

Ok.

-----------------------

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

-----------------------

> --2, "MSRP B2BUA" "... terminates an MSRP connection from one MSRP endpoint and reoriginates that connection..."
>
> s/connection/session

Ok.

-----------------------

> -- "...SIP B2BUA terminates a SIP session...
>
> s/session/dialog  (or transaction).

Ok.

-----------------------

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

-----------------------

> -- 4.2, step 3 on receipt of an answer
>
> -- 4.4, paragraph 6 (Note) : "... MSRP URI must always contain a port."
>
> ... when used in an SDP path attribute.

Ok.

-----------------------

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

-----------------------

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

-----------------------

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 15 May 2012 09:11:15 -0500

(Quick response on the "4.2, 4.2, and 4.4"  comments--I will follow up on the rest shortly.)

> I really don't know how it can be further streamlined, and suggest to keep it as it is.

I agree there have no substantial change since the work group pubreq'd this before. Since I'm the only one who is complaining about it at this point, I suspect the _chair_ will agree to let it go as is ;-)

---

From: Ben Campbell <[email-masked]>
Date: Tue, 15 May 2012 16:45:00 -0500

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.

[...]

> Just read? Or parse, or modify?

I don't see a reply to this one

[...]

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

[...]

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

[...]

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

[...]

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

---

From: Eric Burger <[email-masked]>
Date: Sun, 20 May 2012 20:57:54 -0400

I'm not complaining...

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 May 2012 09:19:41 +0200

Hi,

> I don't see a reply to this one

I guess it should be "parse and modify".

 -----------------------

> "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."
>
> [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). 

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

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. 

-----------------------

Quoting the text here for convenience:
>    MSRP URI of the 'path' attribute(s) (in which case is assumed that
>    SDP answer contains an SDP 'setup:active' attribute).
>

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

-----------------------

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

-----------------------

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

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.

-----------------------

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 29 May 2012 17:35:02 -0500

> I guess it should be "parse and modify".

Okay

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.

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

> 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 

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

Works for me.

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?

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

>> . 

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 May 2012 11:46:34 +0200

Hi Ben,

I will move the issue on section 7.7 to the other e-mail, where the other section 7 issues are discussed.

-----------------------

>>> "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."
>>> 
>>> [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.]
>> 
>> 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.
>

So, something like:

	"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 name (as indicated in SIP/SDP) of the 
	peer."

 -----------------------

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

Ok, now I understand :)

The Middlebox does not need to be aware of different cases. It only looks for the CEMA tag in the offer.

Then, if the answerer does not support CEMA, and CEMA cannot be used (based on the criteria in section 4.2), the offerer will send a new offer, without the CEMA tag.

-----------------------

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Thu, 31 May 2012 13:47:48 -0500

On May 31, 2012, at 4:46 AM, Christer Holmberg wrote:

[...]

Works for me.

> ---------------------

[...]

> Then, if the answerer does not support CEMA, and CEMA cannot be used (based on the criteria in section 4.2), the offerer will send a new offer, without the CEMA tag.

Okay.