Re: [Simple] MSRP-ACM compatibility

["Christer Holmberg" <christer.holmberg at ericsson.com>]

Hi, 

>>> To make this interop with MSRP relays, we would need more work. 
>>> Relays are not involved in the SIP signaling, so there's no
>> opportunity for
>>> them to send a fingerprint. We would need some way for endpoints to 
>>> get fingerprints from the relays, and include them in the signaling.
>>
>> Just for my clarification: how is that related to routing based on 
>> c/m/a=path, and possibly having a B2BUA which may modify the address 
>> information of the ACM client's c/m/a=path?
>
> It's specific to the idea of having TLS cert fingerprints sent in SIP 
> for each relay. It's only needed in case where a middlebox modified 
> the path attribute to modify the IP addresses or host names in the 
> MSRP uris, creating the certificate mismatch we have discussed.

A few questions:


FIRST, RFC4572 already defines the usage of the fingerprint attribute,
so wouldn't your issue also apply if you ONLY use COMEDIA, with relays?


SECOND, as Hadriel wrote earlier (see copy of his e-mail below), the IP
address/ports are not used for the certificate. So, as long as both the
ACM client/SBC belong to foobar.dom, and the MSRP client/relay belong to
anotherfoobar.com, the SBC and relay can have the same certificate as
the client behind them. Or?


THIRD, if a fingerprint is to be provided to/from the relay when an MSRP
message is sent, I guess it could be sent as a To/From-path URI
parameter. Getting the fingerprint to/from the relay BEFORE an MSRP
message is sent is of course more tricky.


Hadriel's e-mail (fri 17th april):
==================================

If I understand your comment, the property you believe is important is
that when a MSRP client is given an MSRPS next-hop to connect to, that
it be able to verify at the MSRP TLS connection level that it is in fact
talking to that next-hop.  Correct?  I agree with that being a very good
property.  

Luckily TLS relies on Certificate CNs/SANs, not IP Addresses/ports, for
identity. (unlike some other identity mechanisms we've been discussing
lately ;) 

If I am told to talk to foobar.com, it does not matter what IP/port at
layer-3 I am talking to, so long as it has foobar.com's Cert.  

So I think what we need in ACM is to provide a way to indicate what (1)
the IP/port to connect to is, vs. (2) what Cert identity to be verified
is.  Comedia-tls (rfc4572) does that with a fingerprint attribute, but
we have been discussing on this list what the appropriate way to do that
for the ACM case is.

Regards,

Christer