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

Hi Ben,

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


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


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

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

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


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

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