Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP)
RFC 8898
Document | Type |
RFC - Proposed Standard
(September 2020; Errata)
Updates RFC 3261
|
|
---|---|---|---|
Authors | Rifaat Shekh-Yusef , Christer Holmberg , Victor Pascual | ||
Last updated | 2021-03-27 | ||
Replaces | draft-ietf-sipcore-sip-authn | ||
Stream | Internet 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", andShow full document text