Setting up SIP TLS from CUBE to 3rd party SBC

[Andrea Morici]

Hi All,

i'd like to ask your valuable help to understand whether the following scenario is feasible or not and, if so, how to set it correctly up ;-)

topology:

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

CUCM ----> |   CUBE A  | 

                    |   CUBE B  |    ->  (WAN) -> 3rd Party SBCs (2)

- CUBE A and CUBE B are configured for HSRP so SBCs will see just one IP

- 3rd Party SBCs will have their own CA

Now question time:

- will this scenario somehow work ? ... I mean, can we set it up with the above specs or this is not supported at all ?

If it will/should work, this is my idea:

- for the certificates/CA part, I'd use the same procedure Cisco suggests for SIP TLS between CUCM and CUBE, namely:

http://www.cisco.com/c/en/us/support/docs/voice/session-initiation-protocol-sip/98746-ios-ccm-sip-tls.html

... in other words, I'll create the local, self signed certificates on the CUBE and export them (somehow!) to the SBC's CA

Then I'll do the opposite: I'll ask the SBC's CA to give me the SBC's (.pem) and import it into the CUBEs.

... are we ok up to this point :-/ ?

If so, I've the following question:

- I'm sure I will need to share the same certificates and keys pair among the two CUBEs so, whichever will be contacted by the SBCs, the 3rd party CA will send them the correct (same) one (public key).

If also the above is correct, how can I share everything I need to make the two CUBE's exactly the same, according to TLS certificates/keys, from the SBCs standpoint ?

Thanks a lot :-)

- Andrea

[Ayodeji Okanlawon]

Andrea,

This is supported and It shouldn't be too difficult to deploy.

1. You will need to create self signed certificate on both CUBE

2.You will need to export the CUBE certificates (from both CUBE) to the SBC. To export he certificate you will use the "crypto pki export pem" command..

To upload the exported certificate to the SBC, you will need to contact the administrator to know how to do this or you just give them the cert from both CUBEs

The link below shows how to use this command

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/a1/sec-a1-cr-book/sec-cr-c5.html#wp4050707879

3. Yes you will need to upload the SBC certificate to both CUBEs. To do this you need the base 64 encoded file as shown in the document.

[Andrea Morici]

Hi Ayodeji, thanks for your kind reply !

... good to hear this is a supported scenario ;-) ... nice starting point.

What it's still not too clear to me is how the SBC's CA will choose the correct CUBE certificate (we have two) if it sees just one IP :-/ ?

... we're indeed in HSRP so, from SBCs and their CA standpoint, there should be just one remote 'box' to contact with one certificate only ... am I missing something :-/ ?

Cheers,

Andrea

[Ayodeji Okanlawon]

I don't think you are missing anything and I don't see an issue also. When SBC needs to talk to CUBE it tries to create a connection using the VIP address. The HSRP process then selects the active CUBE gateway and this is the one the SBC will exchange certs with to establish tls connection and after which sip signalling and messages then flow over the secure transport socket.

This is  how I believe it will work. You might want to get clarification from TAC to put your mind to rest. Please update us on any findings

[Andrea Morici]

... let me try to clarify my doubt a bit further ;-)

I'll borrow your previous words to do that:

"When SBC needs to talk to CUBE it tries to create a connection using the VIP address. The HSRP process then selects the active CUBE gateway and this is the one the SBC will exchange certs with to establish tls connection"

... at this point, I suppose, SBC will ask its CA to send back the corresponding CUBE certificate to check whether the CUBE identity is valid or not.

Since CA won't have any way to understand, from a single IP, if we're talking about CUBE A or CUBE B, it will return a single certificate which, in order to match, needs to be identical (public key) on both CUBEs.

... do you agree Ayodeji :-/ ?

Cheers,

Andrea

[Ayodeji Okanlawon]

The certificate verification is not based on ip address. Its based on the common name and subject alternate names amongst other things in the cert. When CUBE A is selected by hsrp, it exchanges its certs with SBC, SBC looks at its trust store and compares the certificate there with what is presented. CUBE also requests certs from SBC and compares it with what it has in its trust store too, if both matches, the exchange is successful..

[Andrea Morici]

... see ?! ... I was indeed missing something ;-) !

So, if I got your explanation correctly, the SBC and CUBE exchange their respective certificates in first place; then and only then, each of them checks what it got (the certificate of the other peer) against their own trust store (CA?) using the CN to point to the right one. Is that correct ?

If so, I'd expect the two CUBE's certificates (self signed) to be different also if I'd use for them the same CN and Subject Alternate Name.

If this is the case, as I suspect, do I need to export and upload each of them onto the remote SBC's CA ?

Thanks Ayodeji your help is really appreciated ;-)

Cheers,

Andrea

- 

[Ayodeji Okanlawon]

Yes you need to upload both certs to the SBC and you should have unique CN names for them as well as SAN if you are using it.

[Andrea Morici]

Ok, but if we use same CN and SAN for both certificates, how can the SBC/CA tell which one should be used to check CUBE's credentials ?

Example: 

We have two certs, one for CUBE-A and one for CUBE-B; they're different (self generated by each CUBE) but with same CN and SAN.

SBC calls CUBE and exchange the certificate with it; SBC doesn't know if it's talking to CUBE-A or CUBE-B since ip is the same and cert has same CN.

Now the SBC asks its CA to give it the CUBE's 'official' cert to check whether what it got from its peer is valid.

At this point, how can the CA choose the right certificate to send back to the SBC ?

Cheers,

Andrea