Key Exchange Protocols
Key exchange protocols enable secure communications over an untrusted network by deriving and distributing shared keys between two or more parties. The Internet Key Exchange (IKEv1) Protocol, originally defined in RFC 2409, provides a method for creating keys used by IPsec tunnels. Session Description Protocol Security Descriptions for Media Streams (SDES), defined in RFC 4568, provides alternative methods for creating keys used to encrypt Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP) transactions.
Each of these protocols is described in the following sections.
IKEv1 Protocol
IKEv1 is specified by a series of RFCs, specifically RFCs 2401 through 2412. The most relevant are:
- RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP
- RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)
- RFC 2409, The Internet Key Exchange (IKE)
- RFC 2412, Oakley Key Determination Protocol
IKEv1 combines features of the Internet Security Association and Key Management Protocol (ISAKMP) and Oakley Key Determination Protocol in order to negotiate Security Associations (SA) for two communicating peers. IKEv1 also provides for key agreement using Diffie-Hellman.
IKEv1 uses two phases. Phase 1 is used to establish an ISAKMP Security Association for IKEv1 itself. Phase 1 negotiates the authentication method and symmetric encryption algorithm to be used. Phase 1 requires either six messages (main mode) or three messages (aggressive mode).
Phase 2 negotiates the SA for two IPsec peers and is accomplished with three messages.
The initial IKEv1 implementation supports RFC 2409, Internet Key Exchange, and RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers.
IKEv1 Configuration
IKEv1 configuration consists of five steps.
- Configure IKEv1 global parameters.
- Optionally, enable and configure Dead Peer Detection (DPD) Protocol.
- Configure IKEv1 interfaces.
- Configure IKEv1 Security Associations (SA).
- Assign the IKEv1 SA to an IPsec Security Policy.
DPD Protocol Configuration
If you enabled the DPD protocol with the dpd-time-interval parameter, use the following procedure to create a DPD template, an operational set of DPD parameters, that you subsequently assign to one or more IKEv1 interfaces.
Note:
DPD only works with IPv6.IKEv1 Security Association Configuration
An IKEv1 SA identifies cryptographic material available for IPsec tunnel establishment.
To configure IKEv1 SA parameters:
- Use the
security-protocol
parameter to specify the IPsec security (authentication and encryption)
protocols supported by this SA.
The following security protocols are available.
Authentication Header (AH) — the default value — as defined by RFC 4302, IP Authentication Header, which provides authentication integrity to include the mutual identification of remote peers, non-repudiation of received traffic, detection of data that has been altered in transit, and detection of data that has been replayed, that is copied and then re-injected into the data stream at a later time. Authentication services utilize the authentication algorithm specified by the auth-algo property.
Encapsulating Security Payload (ESP) as defined by RFC 4303, IP Encapsulating Security Payload, which provides both authentication and privacy services. Privacy services utilize the encryption algorithm specified by the encryption-algo property.
ESP-AUTH (also RFC 4303-based), which supports ESP’s optional authentication.
ESP-NULL (also RFC 4303-based) which proves NULL encryption as described in RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec. This option provides no privacy services, and is not recommended for production environments.
Refer to the following figures for additional details.
Figure 14-1 AH Transport Mode
Figure 14-2 AH Tunnel Mode
Figure 14-3 ESP Transport Mode
Figure 14-4 ESP Tunnel Mode
ORACLE(ike-sainfo)# security-protocol esp ORACLE(ike-sainfo)#
Secure Real-Time Transport Protocol
The Secure Real-Time Transport Protocol, as described in RFC 3711, The Secure Real-time Transport Protocol (SRTP), provides a framework for the encryption and authentication of Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) streams. Both RTP and RTCP are defined by RFC 3550, RTP: A Transport Protocol for Real-Time Applications.
Encryption ensures that the call content and associated signaling remains private during transmission. Authentication ensures that (1) received packets are from the purported source, (2) packets are not been tampered with during transmission, and (3) a packet has not been replayed by a malicious server.
Protocol Overview
While the RFC 3711 framework provides encryption and authentication procedures and defines a set of default cryptographic transforms required for RFC compliance, it does not specify a key management protocol to securely derive and exchange cryptographic keys. RFC4568, Session Description Protocol (SDP) Security Description for Media Streams, defines such a protocol specifically designed to exchange cryptographic material using a newly defined SDP crypto attribute. Cryptographic parameters are established with only a single message or in single round-trip exchange using the offer/answer model defined in RFC 3264, An Offer/Answer Model with the Session Description Protocol.
Release S-C6.2.0 provides support for an initial SDP Security Descriptions (SDES) implementation that generates keys used to encrypt SRTP/SRTCP packets. Authentication of packets will be added to a subsequent release.
A sample SDP exchange is shown below:
The SDP offerer sends:
v=0
o=sam 2890844526 2890842807 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson)
c=IN IP4 168.2.17.12
t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4The SDP answerer replies:
v=0
o=sam 2890844526 2890842807 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson)
c=IN IP4 168.2.17.12
t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4The media-level SDP attribute, crypto, describes the cryptographic suite, key parameters, and session parameters for the preceding unicast media line. The crypto attribute takes the form:
a=crypto: tag crypto-suite key-parameter [session-parameters]
tag
The tag field contains a decimal number that identifies a specific attribute instance. When an offer contains multiple crypto attributes, the answer uses the tag value to identify the accepted offer.
In the sample offer the tag value is 1.
crypto-suite
The crypto-suite field contains the encryption and authentication algorithms, either AES_CM_128_HMAC_SHA1_80 orAES_CM_128_HMAC_SHA1_32.
The key-parameter field contains one or more sets of keying material for the selected crypto-suite and it has following format.
"inline:" <key||salt> ["|" lifetime] ["|" MKI ":" length]inline is a method and specifies that the crypto material to be used by the offerer is transmitted via the SDP.
The key||salt field contains a base64-encoded concatenated master key and salt.
Assuming the offer is accepted, the key || salt provides the crypto material used by the offerer to encrypt SRTP/SRTCP packets, and used by the answerer to decrypt SRTP/SRTCP packets.
Conversely the key || salt contained in the answer to the offer provides the crypto material used by the answerer to encrypt SRTP/SRTCP packets, and used by the offerer to decrypt SRTP/SRTCP packets.
The lifetime field optionally contains the master key lifetime (maximum number of SRTP or SRTCP packets encoded using this master key).
In the sample offer the lifetime value is 1,048, 576 (220) packets.
The MKI:length field optionally contains the Master Key Index (MKI) value and the MKI length.
The MKI is used only when the offer contains multiple keys; it provides a means to differentiate one key from another. The MKI takes the form of an integer, followed by its byte length when included in SRTP/SRTCP packets.
In the sample offer the MKI value is 1 with a length of 4 bytes.
The session-parameters field contains a set of optional parameters that may override SRTP session defaults for the SRTP and SRTCP streams.
UNENCRYPTED_SRTP — SRTP messages are not encrypted
UNENCRYPTED_SRTCP — SRTCP messages are not encrypted
UNAUTHENTICATED_SRTP — SRTP messages are not authenticated
When generating an initial offer, the offerer must ensure that there is at least one crypto attribute for each media stream for which security is desired. Each crypto attribute for a given media stream must contain a unique tag. The ordering of multiple crypto attributes is significant — the most preferred crypto suite is listed first.
Upon receiving the initial offer, the answerer must either accept one of the offered crypto attributes, or reject the offer in its entirety.
When an offered crypto attribute is accepted, the crypto attribute in the answer MUST contain the tag and crypto-suite from the accepted crypto attribute in the offer, and the key(s) the answerer will be using for media sent to the offerer.
The crypto-suite is bidirectional and specifies encryption and authentication algorithms for both ends of the connection. The keys are unidirectional in that one key or key set encrypts and decrypts traffic originated by the offerer, while the other key or key set encrypts and decrypts traffic originated by the answerer. The use of symmetric keying, where the same key is used for both encryption and decryption, mandates the key exchange between the offerer and the answerer.
Key exchange via text-based SDP is unacceptable in that malicious network elements could easily eavesdrop and obtain the plaintext keys, thus compromising the privacy and integrity of the encrypted media stream. Consequently, the SDP exchange must be protected by a security protocol such as IPsec or TLS.
Licensing and Hardware Requirements
SRTP/SRTCP support requires the presence of an IPsec NIU and an SSM (Security Service Module).
No additional licences are required.
Operational Modes
SRTP topologies can be reduced to three basic topologies which are described in the following sections.
Single-Ended SRTP Termination
Single-ended SRTP termination is illustrated in the following figure.
Single-Ended SRTP Termination
If SRTP is enabled for the inbound realm/interface, the Oracle Communications Session Border Controller handles the incoming call as specified by the Media Security Policy assigned to the inbound realm. If there is crypto attribute contained in the offer, the Oracle Communications Session Border Controller parses the crypto attributes and optional parameters, if any. If the offer contains a crypto attribute or attributes compatible with the requirements specified by the SDES profile assigned to the Media Security policy, it selects the most preferred compatible attribute. Otherwise, the Oracle Communications Session Border Controller rejects the offer. Before the SDP is forwarded to the called party, the Oracle Communications Session Border Controller allocates resources, established SRTP and SRTCP Security Associations and updates the SDP by removing the crypto attribute and inserting possibly NAT’ed media addresses and ports. At the same time, the original crypto attribute is also removed from the SDP.
Once the reply from the called party is received, the Oracle Communications Session Border Controller inserts appropriate crypto attribute(s) to form a new SDP, and forward the response back to the calling party.
Back-to-Back SRTP Termination
Back-to-back SRTP termination is illustrated in the following figure.
Back-to-Back SRTP Termination
Initial processing is similar to the single-ended termination described above. Before forwarding the request to the called party, the Oracle Communications Session Border Controller replaces the original crypto attribute with a new one whose crypto attribute conforms to the media security policy for the outbound realm/interface. Upon receiving the answer from the called party, the Oracle Communications Session Border Controller accepts or rejects it, again based upon conformity to the media security policy. If accepted, the Oracle Communications Session Border Controller replaces the original crypto attribute from the called party with its own to form a new SDP, which it forwards back to the calling party. At this point, SRTP media sessions are established on both sides for both calling and called parties.
SRTP Pass-Thru
SRTP pass-thru is illustrated in the following figure.
SRTP Pass-Thru
If the media security policy specifies pass-through mode, the Oracle Communications Session Border Controller does not alter the crypto attribute exchange between the calling and the called party; the attribute is transparently passed.
SDES Configuration
SDES configuration consists of the following steps.
- Create one or more SDES profiles which specify parameter values negotiated during the offer/answer exchange.
- Create one or more Media Security Policies that specify key exchange protocols and protocol-specific profiles.
- Assign a Media Security Policy to a realm.
- Create an interface-specific Security Policy.
SDES Profile Configuration
An SDES profile specifies the parameter values offered or accepted during SDES negotiation.
To configure SDES profile parameters:
Media Security Policy Configuration
Use the following procedure to create a Media Security Policy that specifies the role of the Oracle Communications Session Border Controller in the security negotiation. If the Oracle Communications Session Border Controller takes part in the negotiation, the policy specifies a key exchange protocol and SDES profile for both incoming and outgoing calls.
Note:
The media security policy configuration does not apply to hairpin calls.To configure media-security-policy parameters:
ACLI Example Configurations
The following section contain relevant sections of system configurations for basic operational modes.
Single-Ended SRTP Termination Configuration
ORACLE# show running-config
...
...
...
sdes-profile
name sdes1
crypto-list AES_CM_128_HMAC_SHA1_80
srtp-auth enabled
srtp-encrypt enabled
srtcp-encrypt enabled
mki disabled
key
salt
last-modified-by admin@console
last-modified-date 2009-11-16 15:37:13
media-sec-policy
name msp2
pass-through disabled
inbound
profile sdes1
mode srtp
protocol sdes
outbound
profile sdes1
mode srtp
protocol sdes
last-modified-by admin@console
last-modified-date 2009-11-16 15:37:51
...
...
...
realm-config
identifier peer
description
addr-prefix 192.168.0.0/16
network-interfaces M00:0
mm-in-realm enabled
mm-in-network enabled
mm-same-ip enabled
mm-in-system enabled
bw-cac-non-mm disabled
msm-release disabled
qos-enable disabled
generate-UDP-checksum disabled
max-bandwidth 0
fallback-bandwidth 0
max-priority-bandwidth 0
max-latency 0
max-jitter 0
max-packet-loss 0
observ-window-size 0
parent-realm
dns-realm
media-policy
media-sec-policy msp2
in-translationid
...
...
...
last-modified-by admin@console
last-modified-date 2009-11-10 15:38:19Back-to-Back SRTP Termination Configuration
ORACLE# show running-config
...
...
...
sdes-profile
name sdes1
crypto-list AES_CM_128_HMAC_SHA1_80
srtp-auth enabled
srtp-encrypt enabled
srtcp-encrypt enabled
mki disabled
key
salt
last-modified-by admin@console
last-modified-date 2009-11-16 15:37:13
media-sec-policy
name msp2
pass-through disabled
inbound
profile sdes1
mode srtp
protocol sdes
outbound
profile sdes1
mode srtp
protocol sdes
last-modified-by admin@console
last-modified-date 2009-11-16 15:37:51
...
...
...
realm-config
identifier peer
description
addr-prefix 192.168.0.0/16
network-interfaces M00:0
mm-in-realm enabled
mm-in-network enabled
mm-same-ip enabled
mm-in-system enabled
bw-cac-non-mm disabled
msm-release disabled
qos-enable disabled
generate-UDP-checksum disabled
max-bandwidth 0
fallback-bandwidth 0
max-priority-bandwidth 0
max-latency 0
max-jitter 0
max-packet-loss 0
observ-window-size 0
parent-realm
dns-realm
media-policy
media-sec-policy msp2
...
...
...
realm-config
identifier core
description
addr-prefix 172.16.0.0/16
network-interfaces M10:0
mm-in-realm enabled
mm-in-network enabled
mm-same-ip enabled
mm-in-system enabled
bw-cac-non-mm disabled
msm-release disabled
qos-enable disabled
generate-UDP-checksum disabled
max-bandwidth 0
fallback-bandwidth 0
max-priority-bandwidth 0
max-latency 0
max-jitter 0
max-packet-loss 0
observ-window-size 0
parent-realm
dns-realm
media-policy
media-sec-policy msp2
in-translationid
...
...
...
last-modified-by admin@console
last-modified-date 2009-11-10 15:38:19SRTP Pass-Thru Configuration
ORACLE# show running-config
...
...
...
sdes-profile
name sdes1
crypto-list AES_CM_128_HMAC_SHA1_80
srtp-auth enabled
srtp-encrypt enabled
srtcp-encrypt enabled
mki disabled
key
salt
last-modified-by admin@console
last-modified-date 2009-11-16 15:37:13
media-sec-policy
name msp2
pass-through enabled
inbound
profile sdes1
mode srtp
protocol sdes
outbound
profile sdes1
mode srtp
protocol sdes
last-modified-by admin@console
last-modified-date 2009-11-16 15:37:51
...
...
...
realm-config
identifier peer
description
addr-prefix 192.168.0.0/16
network-interfaces M00:0
mm-in-realm enabled
mm-in-network enabled
mm-same-ip enabled
mm-in-system enabled
bw-cac-non-mm disabled
msm-release disabled
qos-enable disabled
generate-UDP-checksum disabled
max-bandwidth 0
fallback-bandwidth 0
max-priority-bandwidth 0
max-latency 0
max-jitter 0
max-packet-loss 0
observ-window-size 0
parent-realm
dns-realm
media-policy
media-sec-policy msp2
...
...
...
realm-config
identifier core
description
addr-prefix 172.16.0.0/16
network-interfaces M10:0
mm-in-realm enabled
mm-in-network enabled
mm-same-ip enabled
mm-in-system enabled
bw-cac-non-mm disabled
msm-release disabled
qos-enable disabled
generate-UDP-checksum disabled
max-bandwidth 0
fallback-bandwidth 0
max-priority-bandwidth 0
max-latency 0
max-jitter 0
max-packet-loss 0
observ-window-size 0
parent-realm
dns-realm
media-policy
media-sec-policy msp2
in-translationid
...
...
...
last-modified-by admin@console
last-modified-date 2009-11-10 15:38:19
Security Policy
A Security Policy enables the Oracle Communications Session Border Controller to identify inbound and outbound media streams that are treated as SRTP/SRTCP. The high-priority Security Policy, p1, (shown below) allows signaling traffic from source 172.16.1.3 to destination 172.16.1.10:5060. The lower-priority Security Policy, p2, (also shown below) matches media traffic with the same source and destination, but without any specific ports. Consequently, SIP signaling traffic (from local port 5060) go through, but the media stream will be handled by appropriate SRTP SA.
security-policy
name p1
network-interface private:0
priority 0
local-ip-addr-match 172.16.1.3
remote-ip-addr-match 172.16.1.10
local-port-match 5060
remote-port-match 0
trans-protocol-match UDP
direction both
local-ip-mask 255.255.255.255
remote-ip-mask 255.255.255.255
action allow
ike-sainfo-name
outbound-sa-fine-grained-mask
local-ip-mask 255.255.255.255
remote-ip-mask 255.255.255.255
local-port-mask 0
remote-port-mask 0
trans-protocol-mask 0
valid enabled
vlan-mask 0xFFF
last-modified-by admin@console
last-modified-date 2009-11-09 15:01:55
security-policy
name p2
network-interface private:0
priority 10
local-ip-addr-match 172.16.1.3
remote-ip-addr-match 172.16.1.10
local-port-match 0
remote-port-match 0
trans-protocol-match UDP
direction both
local-ip-mask 255.255.255.255
remote-ip-mask 255.255.255.255
action ipsec
ike-sainfo-name
outbound-sa-fine-grained-mask
local-ip-mask 0.0.0.0
remote-ip-mask 255.255.255.255
local-port-mask 0
remote-port-mask 65535
trans-protocol-mask 255
valid enabled
vlan-mask 0xFFF
last-modified-by admin@console
last-modified-date 2009-11-09 15:38:19