Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP)
RFC 8898
| Document | Type |
RFC - Proposed Standard
(September 2020; No errata)
Updates RFC 3261
|
|
|---|---|---|---|
| Authors | Rifaat Shekh-Yusef , Christer Holmberg , Victor Pascual | ||
| Last updated | 2020-09-10 | ||
| Replaces | draft-ietf-sipcore-sip-authn | ||
| Stream | Internent Engineering Task Force (IETF) | ||
| Formats | plain text html xml pdf htmlized (tools) htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Jean Mahoney | ||
| Shepherd write-up | Show (last changed 2020-03-28) | ||
| IESG | IESG state | RFC 8898 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Yes | ||
| Telechat date | |||
| Responsible AD | Murray Kucherawy | ||
| Send notices to | Jean Mahoney <mahoney@nostrum.com> | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA action state | RFC-Ed-Ack | ||
Internet Engineering Task Force (IETF) R. Shekh-Yusef
Request for Comments: 8898 Auth0
Updates: 3261 C. Holmberg
Category: Standards Track Ericsson
ISSN: 2070-1721 V. Pascual
Nokia
September 2020
Third-Party Token-Based Authentication and Authorization for Session
Initiation Protocol (SIP)
Abstract
This document defines the "Bearer" authentication scheme for the
Session Initiation Protocol (SIP) and a mechanism by which user
authentication and SIP registration authorization is delegated to a
third party, using the OAuth 2.0 framework and OpenID Connect Core
1.0. This document updates RFC 3261 to provide guidance on how a SIP
User Agent Client (UAC) responds to a SIP 401/407 response that
contains multiple WWW-Authenticate/Proxy-Authenticate header fields.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8898.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
1.1. Terminology
1.2. Applicability
1.3. Token Types and Formats
1.4. Example Flows
1.4.1. Registration
1.4.2. Registration with Preconfigured AS
2. SIP Procedures
2.1. UAC Behavior
2.1.1. Obtaining Tokens and Responding to Challenges
2.1.2. Protecting the Access Token
2.1.3. REGISTER Request
2.1.4. Non-REGISTER Request
2.2. User Agent Server (UAS) and Registrar Behavior
2.3. Proxy Behavior
3. Access Token Claims
4. WWW-Authenticate Response Header Field
5. Security Considerations
6. IANA Considerations
6.1. New Proxy-Authenticate Header Field Parameters
6.2. New WWW-Authenticate Header Field Parameters
7. Normative References
8. Informative References
Acknowledgments
Authors' Addresses
1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] uses the same
framework as HTTP [RFC7230] to authenticate users: a simple
challenge-response authentication mechanism that allows a SIP User
Agent Server (UAS), proxy, or registrar to challenge a SIP User Agent
Client (UAC) request and allows the UAC to provide authentication
information in response to that challenge.
OAuth 2.0 [RFC6749] defines a token-based authorization framework to
allow an OAuth client to access resources on behalf of its user.
The OpenID Connect Core 1.0 specification [OPENID] defines a simple
identity layer on top of the OAuth 2.0 protocol, which enables OAuth/
OpenID clients to verify the identity of the user based on the
authentication performed by a dedicated authorization server (AS),
referred to as OpenID Provider (OP), as well as to obtain basic
profile information about the user.
This document defines the "Bearer" authentication scheme for SIP and
a mechanism by which user authentication and SIP registration
authorization is delegated to a third party, using the OAuth 2.0
framework and OpenID Connect Core 1.0. This kind of user
authentication enables single sign-on, which allows the user to
authenticate once and gain access to both SIP and non-SIP services.
This document also updates [RFC3261] by defining the UAC procedures
when a UAC receives a 401/407 response with multiple WWW-
Authenticate/Proxy-Authenticate header fields, providing challenges
using different authentication schemes for the same realm.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
Show full document text