Methods and entities using IPSec ESP to support security functionality for UDP-based traffic
Methods in OMA SEC_CF for providing security services to traffic over UDP between a client and a server and the relevant entities are provided. A pre-shared key is pre-shared between the client and the server. A pair of IPSec ESP SAs between the client and the server is established without shared key negotiation, wherein traffic data cryptographic algorithms are determined. Traffic data security keys are derived from the pre-shared key via the determined traffic data cryptographic algorithms. Then, data of the traffic can be provided with security services with the traffic data security keys through use of IPSec ESP.
1. A method in a client for providing security services to traffic over User Datagram Protocol (UDP) between the client and a server, comprising:
establishing a pair of Internet Protocol Security (IPSec) Encapsulating Security Payload (ESP) Security Associations (SAs) for UDP traffic without shared key negotiation, wherein traffic data cryptographic algorithms are determined;
deriving traffic data security keys for traffic over UDP from a pre-shared key, via the determined traffic data cryptographic algorithms; and
providing security services to data of the traffic over UDP with the traffic data security keys through use of IPSec ESP.
2. The method of claim 1 , wherein said establishing the pair of IPSec ESP SAs comprises:
generating a request message for transmission to the server to initiate an establishment of the IPSec ESP SA, the request message containing a first set of SA-related parameters including:
a receiving Security Parameter Index (SPI) and a transmitting SPI assigned by the client for the pair of IPSec ESP SAs,
a receiving UDP port and a transmitting UDP port assigned by the client for the traffic, and
a list of identifiers for cryptographic algorithms which the client supports; and
receiving from the server a response message containing a second set of SA-related parameters including:
a receiving SPI and a transmitting SPI assigned by the server for the pair of IPSec ESP SAs,
a receiving UDP port and a transmitting UDP port assigned by the server for the traffic, and
a list of identifiers for the selected cryptographic algorithms.
3. The method of claim 2 , wherein said establishing the pair of IPSec ESP SAs further comprises:
in response to a reception of the response message, generating a confirmation message containing a third set of SA-related parameters including the receiving SPI, the transmitting SPI, the receiving UDP port and the transmitting UDP port that are assigned by the client, and the second set of SA-related parameters received in the response message, for transmission to the server.
4. The method of claim 3 , wherein said establishing the pair of IPSec ESP SAs further comprises embedding a first challenge random into the request message to authenticate the server for service access;
checking a first challenge response received from the server in the response message; and
embedding a second challenge response corresponding to a second challenge random received from the server in the response message, into the confirmation message.
5. A method in a server for providing security services to traffic over User Datagram Protocol (UDP) between a client and the server, comprising:
establishing a pair of Internet Protocol Security (IPSec) Encapsulating Security Payload (ESP) Security Associations (SAs) for UDP traffic without shared key negotiation, wherein traffic data cryptographic algorithms are determined;
deriving traffic data security keys for traffic over UDP from a pre-shared key, via the determined traffic data cryptographic algorithms; and
providing security services to data of the traffic over UDP with the traffic data security keys through use of IPSec ESP.
6. The method of claim 5 , wherein said establishing the pair of IPSec ESP SAs comprises:
receiving from the client a request message to initiate an establishment of the IPSec ESP SA, and the request message containing a first set of SA-related parameters including:
a receiving Security Parameter Index (SPI) and a transmitting SPI assigned by the client for the pair of IPSec ESP SAs,
a receiving UDP port and a transmitting UDP port assigned by the client for the traffic, and
a list of identifiers for cryptographic algorithms which the client supports;
in response to a reception of the request message, selecting the traffic data cryptographic algorithms it supports from the list of identifiers for cryptographic algorithms; and
generating a response message for transmission to the client, the response message containing a second set of SA-related parameters including:
a receiving SPI and a transmitting SPI assigned by the server for the pair of IPSec ESP SAs,
a receiving UDP port and a transmitting UDP port assigned by the server for the traffic, and
a list of identifiers for the selected cryptographic algorithms.
7. The method of claim 6 , wherein said establishing the pair of IPSec ESP SAs further comprises:
receiving a confirmation message transmitted in response to the response message from the client, the confirmation message containing a third set of SA-related parameters including the receiving SPI, the transmitting SPI, the receiving UDP port and the transmitting UDP port that are assigned by the client, and the second set of SA-related parameters received in the response message; and
checking whether or not parameters in the third set of SA-related parameters are identical with corresponding parameters of the first and second set of SA-related parameters.
8. The method of claim 7 , wherein said establishing the pair of IPSec ESP SAs further comprises:
receiving a first challenge random embedded into the request message by the client for service access authenticate;
embedding the first challenge response into the response message, together with a second challenge random for service access authenticate; and
checking a second challenge response received from the confirmation message corresponding to the second challenge random.
9. A controller for providing security services to traffic over User Datagram Protocol (UDP) between a client entity and a server entity, comprising at least one processor programmed to perform the steps of:
obtaining a pre-shared key;
establishing a pair of Internet Protocol Security (IPSec) Encapsulating Security Payload (ESP) Security Associations (SAs) for UDP traffic so that traffic data cryptographic algorithms are determined, without shared key negotiation;
deriving traffic data security keys for traffic over UDP from the pre-shared key via the determined traffic data cryptographic algorithms; and
providing security services to data of the traffic over UDP with the traffic data security keys through use of IPSec ESP.
10. The controller of claim 9 , wherein the at least one processor is further programmed to:
generate a request message for transmission to the server entity to initiate an establishment of the IPSec ESP SA, the request message containing a first set of SA-related parameters including:
a receiving Security Parameter Index (SPI) and a transmitting SPI assigned by the client entity for the pair of IPSec ESP SAs;
a receiving UDP port and a transmitting UDP port assigned by the client entity for the traffic; and
a list of identifiers for cryptographic algorithms which the client entity supports; and
receive from the server entity a response message containing a second set of SA related parameters including:
a receiving SPI and a transmitting SPI assigned by the server entity for the pair of IPSec ESP SAs;
a receiving UDP port and a transmitting UDP port assigned by the server entity for the traffic; and
a list of identifiers for the selected cryptographic algorithms.
11. The controller of claim 10 , wherein, the at least one processor is further programmed to:
in response to a reception of the response message, generate a confirmation message containing a third set of SA-related parameters including the receiving SPI, the transmitting SPI, the receiving UDP port and the transmitting UDP port that are assigned by the client, and the second set of SA-related parameters received in the response message, for transmission to the server.
12. The controller of claim 11 , wherein the at least one processor is further programmed to:
embed a first challenge random into the request message to authenticate the server entity for service access,
check a first challenge response received from the server in the response message; and
embed a second challenge response corresponding to a second challenge random received from the server in the response message, into the confirmation message.
13. A controller for providing security services to traffic over User Datagram Protocol (UDP) between a client entity and the server entity, comprising at least one processor programmed to perform the steps of:
obtaining a pre-shared key;
establishing a pair of Internet Protocol Security (IPSec) Encapsulating Security Payload (ESP) Security Associations (SAs) for UDP traffic so that traffic data cryptographic algorithms are determined, without shared key negotiation;
deriving traffic data security keys for traffic over UDP from the pre-shared key via the determined traffic data cryptographic algorithms; and
providing security services to data of the traffic over UDP with the traffic data security keys through use of IPSec ESP.
14. The controller of claim 13 , wherein the at least one processor is further programmed to:
receive from the client entity a request message to initiate an establishment of the IPSec ESP SA, the request message containing a first set of SA-related parameters including:
a receiving Security Parameter Index (SPI) and a transmitting SPI assigned by the client entity for the pair of IPSec ESP SAs,
a receiving UDP port and a transmitting UDP port assigned by the client entity for the traffic, and
a list of identifiers for cryptographic algorithms which the client entity supports; and
in responses to the reception of the request message, select the traffic data cryptographic algorithms it supports from the list of identifiers for cryptographic algorithms; and
generate a response message for transmission to the client entity, the response message containing a second set of SA related parameters including:
a receiving SPI and a transmitting SPI assigned by the server entity for the pair of IPSec ESP SAs,
a receiving UDP port and a transmitting UDP port assigned by the server entity for the traffic, and
a list of identifiers for the selected cryptographic algorithms.
15. The controller of claim 14 , wherein the at least one processor is further programmed to:
receive a confirmation message transmitted in response to the response message from the client, the confirmation message containing a third set of SA-related parameters including the receiving SPI, the transmitting SPI, the receiving UDP port and the transmitting UDP port that are assigned by the client, and the second set of SA-related parameters received in the response message; and
check whether or not parameters in the third set of SA-related parameters are identical with corresponding parameters of the first and second set of SA-related parameters.