NRF Key ID Versioning for 5G Access Token Verification

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In 5G telecommunications networks, there is a lack of standardized guidelines for sharing certificates and public keys between network functions and the Network Function Repository (NRF), leading to inefficient and error-prone custom solutions, particularly in managing and verifying access tokens.

Innovation Solution

A method and system for dynamically sharing key identification (key ID) and public certificate data through custom header sections in NF registration and update messages, where the NRF manages key ID versioning and distributes updated digital certificates and public keys to producer NFs, enabling efficient access token verification.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If custom solutions are implemented for certificate and public key sharing between network functions and NRF, then vendor-specific requirements and protocols can be accommodated, but the provisioning process becomes tedious and error-prone

Engineering Contradiction:

Improvevendor-specific requirements accommodationVSAvoidprovisioning process

Core Design Contradiction:

Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The patent implements a universal NFUpdate mechanism that serves multiple functions: it carries both certificate data and public key data in standardized custom headers, works across different vendor implementations, and handles both initial registration and update scenarios. This multi-functional approach eliminates the need for vendor-specific custom solutions while maintaining adaptability through the standardized header structure.

Inventive Principle:

Principle #6Universality (Multi-functionality)

2Device complexity

If static provisioning of certificates is used at numerous NFs, then certificate distribution can be simplified, but the process becomes tedious and error-prone

Engineering Contradiction:

Improvecertificate distribution complexityVSAvoidprovisioning process

Core Design Contradiction:

Device complexityVSEase of manufacture

Solution Approach 1:

The patent transitions from static certificate provisioning to a dynamic update mechanism. Certificates and public keys are initially provided during NF registration, then automatically updated through periodic NFUpdate messages from the NRF. This dynamic approach allows the system to adapt to key rotations and certificate renewals without manual intervention, eliminating the tedium and errors of static provisioning while maintaining manageable complexity.

Inventive Principle:

Principle #15Dynamics

3Adaptability or versatility

If a PKI and vault model is shared by NFs and NRF, then certificate management can be centralized, but various vendor entities with different requirements and protocols create challenges

Engineering Contradiction:

Improvevendor protocol compatibilityVSAvoidcertificate management system

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces the NRF as an intermediary that mediates between the PKI/vault system and diverse vendor NFs. The NRF receives certificates and public keys from the PKI system, then distributes them to NFs through standardized NFUpdate messages with custom headers. This intermediary layer abstracts away vendor-specific protocol differences, enabling centralized certificate management while maintaining broad compatibility without increasing overall system complexity.

Inventive Principle:

Principle #24Intermediary (Mediator)

4Reliability

If key ID version information is tracked and updated through NF update messages, then access token verification security is enhanced, but the message exchange complexity increases

Engineering Contradiction:

Improveaccess token verification securityVSAvoidmessage exchange protocol

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements preliminary action by including key ID version information in the initial NF registration message. This allows the NF to establish the correct version baseline before service operations begin. Subsequent NFUpdate messages then only need to indicate version changes rather than transmit complete certificate sets, enhancing security through version tracking while minimizing message exchange complexity through incremental updates.

Inventive Principle:

Principle #10Preliminary action

Data Source

PatentUS12192351B2Methods, systems, and computer readable media for sharing key identification and public certificate data for access token verification

Publication Date: 2025.01.07 ORACLE INT CORP

AI summary

A method for sharing key identification (key ID) and public certificate data for access token verification comprises, at a network function (NF) repository function (NRF) including at least one processor, receiving, from a producer NF, an NF registration message including key ID version information. In response to detecting the key ID version information, sending, to the producer NF, an NF registration response message including a current key ID version value, at least one digital certificate, and at least one corresponding public key to the producer NF. The method further includes receiving, from the producer NF, an NF update message that includes the current key ID version value and in response to determining that the current key ID version value in the NF update message does not match an updated key ID version value maintained at the NRF, sending an NF update response message that the updated key ID version value, at least one updated digital certificate, and at least one corresponding updated public key to the producer NF.