IPSec ESP Security Associations for UDP OMA Enablers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The current Security Common Function (SEC_CF) over the application layer in OMA is not applicable to OMA enablers that use UDP as a transport protocol, as it relies on TLS/PSK-TLS, which is not suitable for UDP-based enablers, and the existing IPSec ESP setup procedure is inefficient due to assumptions of unknown endpoints.
Innovation Solution
Adapting IPSec ESP to establish security associations (SAs) without shared key negotiation by deriving traffic data security keys from a pre-shared key, optimizing the SA setup procedure and reducing network overhead by embedding only necessary parameters in service access messages.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If TLS/PSK-TLS is used to provide security functionality in SEC_CF, then security services are available for TCP-based OMA enablers, but the solution cannot be applied to UDP-based OMA enablers
Solution Approach 1:
The patent changes the underlying security protocol from TLS/PSK-TLS to IPSec ESP, fundamentally altering the security mechanism to be compatible with UDP transport. This parameter change enables SEC_CF to serve both TCP and UDP-based OMA enablers, resolving the limitation of protocol compatibility while maintaining security service availability.
2Productivity
If the general SA set-up procedure is used to establish IPSec ESP, then security associations can be established between unknown endpoints, but the procedure becomes inefficient for OMA SEC_CF where endpoints may know each other via prior authentication
Solution Approach 1:
The patent extracts and removes the shared key negotiation phase from the general IPSec SA set-up procedure. Since OMA SEC_CF endpoints may already know each other via prior authentication mechanisms, the patent eliminates the unnecessary key negotiation step, directly establishing SAs using pre-shared keys or other prior authentication results, thereby significantly improving SA set-up efficiency.
3Reliability
If shared key negotiation is performed during SA set-up, then security keys can be established between endpoints, but network overhead increases due to additional negotiation messages
Solution Approach 1:
The patent applies preliminary action by pre-establishing security keys through prior authentication mechanisms before the actual SA set-up. Instead of performing key negotiation during the SA establishment phase, the keys are prepared in advance, allowing the SA set-up to proceed directly without additional key exchange messages, thus reducing network overhead while maintaining reliable key establishment.
Data Source
Figure 1~2
Figure 3~6
Figure 4
AI summary
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.