[Simple] ACM SBC TLS issue [was RE: MSRP-ACM compatibility]

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

Hi,

Thanks for the information! I think I can see the missing puzzle piece
now :) 

>>>>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?
>>>
>>>As far as Hadriel's comment, it depends on what one puts _in_ the 
>>>subjectAltName field. You _could_ put just an IP address in there, 
>>>although I submit that would be a bad idea.
>>>
>>>But to put your statement more generally: If the, sbc, or other 
>>>intermediary has a subjectAltName entry that matches the authority 
>>>part of a client's adjacent MSRP device (i.e. the next hop in the 
>>>a=path attribute), then we're fine.
>>>
>>>The problem is, the SBC is not likely to be in the same domain as 
>>>_both_ endpoints. So from at least one endpoint's perspective, 
>>>there's likely to be a mismatch.
>>
>>Why doesn't the relay need to get the certificate information in 
>>legacy MSRP then? I don't think we can assume that the relay belongs 
>>to the same domain as both endpoints, can we?
> 
>I'm not sure I understand your question-The assumption in 
>RFC4576 is that an MSRP Relay will have a certificate that is 
>signed by a well- known certificate authority.  I agree that 
>we can't assume a relay belongs to the same domain as both 
>endpoints, but RFC4976 does not require that. It's only when 
>the device that terminates the TCP connection is not the same 
>device that terminates the TLS handshake that we have a 
>problem. That doesn't happen in RFC4976 natively--only when a 
>middlebox changes the path attribute.
> 
>>I have a feeling that I am missing some piece of the puzzle here, and 
>>I appologise for that, but I am still trying to figure out this is 
>>specific to ACM :)
>
> 
>It's specific to having a middlebox modify the SDP path property. Let
me try an example:
> 
>Alice is behind an SBC. That SBC acts as a TCP relay, but 
>transparently tunnels TLS rather than terminating it. (much 
>in the way an HTTPS proxy tunnels TLS). Alice sends an offer 
>to Bob. Her path attribute looks like:
> 
>a=path: msrps;//alice.atlanta.com:1234/fieru;tcp
> 
>The SBC modifies the authority part of the URI to point to 
>itself, and creates a binding so that all traffic to its port 
>forwards to alice:
> 
>a=path: msrps;//sbc.atlanta.com:88039/fieru;tcp
> 
>Bob uses a relay.  His answer contains:
> 
>a=path:msrps://relay.biloxi.com:84930/asfieu;tcp msrps;// 
>bob.biloxi.com:1234/bzerts;tcp
> 
>Alice's SBC modified the answer to also point to itself, and 
>completes the binding
> 
>a=path:msrps://sbc.atlanta.com:88040/asfieu;tcp 
>msrps;//bob.biloxi.com: 
>1234/bzerts;tcp
> 
>Alice now opens a TCP connection to sbc.atlanta.com:88040, 
>and initiates a TLS handshake. This is forwarded 
>transparently to relay.biloxi.com, which provides its TLS 
>server certificate containing "relay.biloxi.com" in its 
>subjectAltName field.
> 
>Alice's UA checks the certificate for the name 
>"sbc.atlanta.com", since that was the name it saw in the SDP. 
>The cert provided by relay.biloxi.com does not contain that 
>name, so the TLS server authentication fails.

Ok.

<brainstorming>

One way of dealing with this is, as we have discussed, to include
sertificate information in the signalling. In the example above, Alice
would be told to check for the name "relay.biloxi.com", instead of
"sbc.atlanta.com".


Another way of dealing with this is of course to say that the
intermeidate MUST terminate TLS in this case. If BOTH Alice and Bob open
TCP connections (since Bob is behind a relay, I assume he would ALWAYS
be "active"), the intermeidate may need to terminate TLS anyway, in
order to avoid the handshake collision?

Now, one could claim that it is difficult to know what intermediates
will do, since they are not standardized. Jon also asked whether we
would need to specify a new kind of TLS intermediate.

If we want to specify something, I am not sure we need to talk
specifically about intermeidates. I think we can be more generic, and
e.g. talking about "entities which generate SDP for MSRP". That would
then apply to any type of entity.

"An entity which inserts its authority part in the URI of the a=path
header needs to ensure that a matching certificate is provided to other
entities which connect to it. This can be achieved by terminating TLS
connections (instead of being TLS transparent) or by providing correct
certificate information in the signalling to other entities which
connect to it."

...or something like that. I think that applies to all kind of MSRP
entities - including intermediates.

</brainstorming>

Regards,

Christer