Validating the Request-URI Based on Certificate Information

When you configure the Oracle Communications Session Border Controller to cache TLS certificate information to validate Request-URIs, it stores the Certificate Subject Name and Certificate Subject Alternative Name (only DNS) it learns from peer certificate attributes. It then takes these actions:

Extracts the host from the Request-URI of the outgoing INVITE
Compares this host (exact or wildcard match) with the Certificate Common Name or Certificate Subject Alternative name of the certificate it has received
Sends out an INVITE if the Certificate Common Name or Certificate Subject Alternative name match; Sends a 403 Forbidden rejection to the endpoint from it received the INVITE if there is no match

Wildcard matching applies only to the prefix of the Request-URI:

*.acme.com
	*.*.acmepacket.com

This diagram shows a peering scenario where the Oracle Communications Session Border Controller receives an INVITE from the calling party, which it processes and prepares to send out INVITE 2. After establishing a TLS connection with the called party and caching the required information, the Oracle Communications Session Border Controller validates the Request-URI. Once validation occurs, the Oracle Communications Session Border Controller sends INVITE 2.

The Validating the Request-URI - Certificate Information diagram is described above.

The peer certificate from the called party during the TLS handshake with the Oracle Communications Session Border Controller would look like this. Relevant information in the sample appears in bold font.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 9 (0x9)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, ST=MA, L=Woburn, O=Smith Securities, OU=Certificate Authority Dept, CN=Smith Certificate Authority/emailAddress=amith@CA.com
        Validity
            Not Before: Dec 10 21:14:56 2009 GMT
            Not After : Jul 11 21:14:56 2019 GMT
        Subject: C=US, ST=MA, L=Woburn, O=Acme Packet, OU=Certificate Authority Dept, CN=*.acme.com/emailAddress=ph2Server@acme.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
        X509v3 extensions:
            X509v3 Basic Constraints:
            CA:FALSE
            X509v3 Issuer Alternative Name:
            email:Smith@CA.com
            X509v3 Subject Alternative Name:
            DNS:gw1.acme.com, DNS:*.ano.com, DNS:*.some.com
            X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
    Signature Algorithm: sha1WithRSAEncryption

The outgoing SIP INVITE (INVITE 2 in the diagram) would then look like the sample below. The INVITE is sent because smith.acme.com matches the common name *.acme.com. Other valid SIP Request-URIs would be:

222222@gw1.acme.com
222222@smith.ano.com
222222@amith.some.com

You can see where the system uses information from the certificate; the text is bold.

INVITE sip:222222@smith.acme.com:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.27.113:5060;branch=z9hG4bK4jmg29cmm8l0cg7smmrn85o4q7
From: 111111 <sip:111111@acme.com>;tag=_ph1_tag
To: 222222 <sip:222222@acme.com>
Call-ID: _1-2_call_id-10147@acme.com-1-
CSeq: 1 INVITE
Contact: <sip:111111@172.16.27.113:5060;transport=udp>
Max-Forwards: 69
Subject: TBD
Content-Type: application/sdp
Content-Length: 138
Route: <sip:222222@172.16.27.188:5060;lr>
v=0
o=user1 53655765 2353687637 IN IP4 172.16.27.113
s=-
c=IN IP4 172.16.27.113
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000