Por que o 3GPP não usou o RFC 8705 para tokens OAuth2 do NRF no 5G Core?
Autenticação TLS mútua do cliente OAuth 2.0 e tokens de acesso vinculados a certificados no 5G Core!
Enquanto lia o 3GPP TS33.501, percebi que um item na segurança do 5G pode ter uma terceira opção de implementação e gostaria de destacá-lo.
Assumirá-se que o leitor tenha conhecimento de PKI, TLS mútuo, Oauth2 e procedimentos do 5G Core.
Este item diz respeito à verificação/validação da assinatura do token OAuth2 ou token de autorização pelo NRF (Network Repository function), que funciona como um servidor de autorização na rede 5G Core.
Qual é o papel dos tokens OAuth2 no 5G Core?
O 5G Core é uma rede baseada em serviços, que usa o token de acesso da mesma forma que os servidores na internet pública. Este token é usado para conceder acesso temporário a recursos ou serviços sem compartilhar credenciais.
Antes que uma função de rede (consumidora) na rede 5G acesse um recurso hospedado em outra função de rede (produtora), ela deve obter um token de autorização com o escopo de acesso ao recurso do NRF (servidor de autorização), conforme a imagem abaixo:
Quando a função de rede consumidora apresenta o token de acesso à função de rede proprietária do recurso (produtora em terminologia do 5G Core), a função de rede produtora deve verificar o token usando a chave pública do NRF (servidor de autorização) porque o token fornecido ao consumidor foi assinado com a chave privada do NRF. Veja a imagem abaixo:
Como o 3GPP especifica a abordagem de validação ou verificação?
Exatamente como fiz acima, veja a imagem abaixo das especificações:
Por que isso é um problema?
A especificação é muito vaga a esse respeito, conforme ilustrado no trecho acima do documento. Uma declaração como essa dá ao leitor um universo de interpretação e imaginação porque a abordagem de implementação não está escrita na pedra.
Uma das propostas para resolver esse problema é adicionar uma terceira opção à especificação para acomodar “Autenticação TLS mútua do cliente OAuth 2.0 e tokens de acesso vinculados a certificados” com base no RFC 8705, que foi usado por outros produtos de companhias como IBM, Curity e outros.
Este RFC possui uma maneira mais simples de garantir que o token de acesso foi realmente concedido ao NF consumidor pelo NRF. Portanto, veja o resumo abaixo:
Em palavras mais simples, “Ao realizar a autenticação TLS mútua com o NRF, o NF consumidor. O NRF obtém o hash do certificado TLS do consumidor, calcula o hash do certificado TLS e adiciona-o ao token de acesso JWT.”
Ao conectar-se ao NF produtor, o NF consumidor é forçado a realizar uma autenticação TLS mútua com o NF produtor. O NF produtor receberá o certificado TLS do NF consumidor (o mesmo certificado TLS apresentado anteriormente ao NRF) e poderá calcular o hash do certificado no token de acesso. Isso mostra que o NF consumidor solicitou o token do NRF em um procedimento de TLS mútuo e o mesmo certificado TLS apresentado ao NRF é o mesmo que está sendo apresentado ao NF produtor.
Mesmo que um NF mal-intencionado obtenha o certificado TLS do NF consumidor, será inútil para o NF mal-intencionado porque ele não possui a chave privada do NF consumidor, tornando a impersonação inviável.
Afinal, não é essa uma boa terceira opção para as especificações além de usar a chave pública do NRF ou segredo pré-compartilhado conforme especificado nas especificações?
PS: Entregue meus tokens com segurança ou o monstro de token vai comê-los.
REFERENCIAS
- https://www.rfc-editor.org/rfc/rfc8705.html
- https://www.ibm.com/docs/en/security-verify?topic=cssiocoba-openid-connect-mutual-tls-client-authentication-certificate-bound-access-token
- https://curity.io/resources/learn/oauth-certificate-bound-access-token/
- https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3169
- https://oauth.net/2/mtls/
- ssh.com/academy/pki
- https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/