draft-ietf-sipcore-sip-token-authnz-14.txt   draft-ietf-sipcore-sip-token-authnz-15.txt 
SIP Core R. Shekh-Yusef SIP Core R. Shekh-Yusef
Internet-Draft Avaya Internet-Draft Avaya
Updates: 3261 (if approved) C. Holmberg Updates: 3261 (if approved) C. Holmberg
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: 1 November 2020 V. Pascual Expires: 6 November 2020 V. Pascual
webrtchacks webrtchacks
30 April 2020 5 May 2020
Third-Party Token-based Authentication and Authorization for Session Third-Party Token-based Authentication and Authorization for Session
Initiation Protocol (SIP) Initiation Protocol (SIP)
draft-ietf-sipcore-sip-token-authnz-14 draft-ietf-sipcore-sip-token-authnz-15
Abstract Abstract
This document defines the "Bearer" authentication scheme for the This document defines the "Bearer" authentication scheme for the
Session Initiation Protocol (SIP), and a mechanism by which user Session Initiation Protocol (SIP), and a mechanism by which user
authentication and SIP registration authorization is delegated to a authentication and SIP registration authorization is delegated to a
third party, using the OAuth 2.0 framework and OpenID Connect Core 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 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 User Agent Client (UAC) responds to a SIP 401/407 response that
contains multiple WWW-Authenticate/Proxy-Authenticate header fields. contains multiple WWW-Authenticate/Proxy-Authenticate header fields.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 November 2020. This Internet-Draft will expire on 6 November 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
skipping to change at page 8, line 19 skipping to change at page 8, line 19
(Figure 2). Procedures for native applications are defined in (Figure 2). Procedures for native applications are defined in
[RFC8252]. When using the mechanism defined in [RFC8252] the user of [RFC8252]. When using the mechanism defined in [RFC8252] the user of
the UAC will be directed to interact with the AS using a web browser, the UAC will be directed to interact with the AS using a web browser,
allowing the AS to prompt the user for multi-factor authentication, allowing the AS to prompt the user for multi-factor authentication,
to redirect the user to third-party identity providers, and to enable to redirect the user to third-party identity providers, and to enable
the use of single sign-on sessions. the use of single sign-on sessions.
The tokens returned to the UAC depend on the type of AS: an OAuth AS The tokens returned to the UAC depend on the type of AS: an OAuth AS
provides an access token and optionally a refresh token [RFC6749]. provides an access token and optionally a refresh token [RFC6749].
The refresh token is only used between the UAC and the AS. If the AS The refresh token is only used between the UAC and the AS. If the AS
provides a refresh token to the UAC, the UAC uses it to to request a provides a refresh token to the UAC, the UAC uses it to request a new
new access token and refresh token from the AS before the currently access token and refresh token from the AS before the currently used
used access token expires token ([RFC6749], Section 1.5). If the AS access token expires ([RFC6749], Section 1.5). If the AS does not
does not provide a refresh token, the UAC needs to re-authenticate provide a refresh token, the UAC needs to re-authenticate the user,
the user, in order to get a new access token, before the currently in order to get a new access token, before the currently used access
used access token expires. An OP returns an additional ID Token that token expires. An OP returns an additional ID Token that contains
contains claims about the authentication of the user by an claims about the authentication of the user by an authorization
authorization server. The ID Token can potentially include other server. The ID Token can potentially include other optional claims
optional claims about the user, e.g. the SIP URI, that will be about the user, e.g. the SIP URI, that will be consumed by the UAC
consumed by the UAC and later used to register with the registrar. and later used to register with the registrar.
If the UAC receives a 401/407 response with multiple WWW- If the UAC receives a 401/407 response with multiple WWW-
Authenticate/Proxy-Authenticate header fields, providing challenges Authenticate/Proxy-Authenticate header fields, providing challenges
using different authentication schemes for the same realm, the UAC using different authentication schemes for the same realm, the UAC
provides credentials for one of the schemes that it supports, based provides credentials for one of the schemes that it supports, based
on local policy. on local policy.
NOTE: At the time of writing this document, detailed procedures for NOTE: At the time of writing this document, detailed procedures for
the cases where a UAC receives multiple different authentication the cases where a UAC receives multiple different authentication
schemes had not been defined. A future specification might define schemes had not been defined. A future specification might define
such procedures. such procedures.
NOTE: The address of the AS might be known to the UAC e.g., using NOTE: The address of the AS might be known to the UAC e.g., using
means of configuration, in which case the UAC can contact the AS in means of configuration, in which case the UAC can contact the AS in
order to obtain the access token before it sends SIP request without order to obtain the access token before it sends SIP request without
credentials. credentials.
2.1.2. Protecting the Access Token 2.1.2. Protecting the Access Token
[RFC6749] mandates that access tokens are protected with TLS when in [RFC6749] mandates that access tokens are protected with TLS when in
transit. However, SIP makes have use of intermediary SIP proxies, transit. However, SIP makes use of intermediary SIP proxies, and TLS
and TLS only guarantees hop-to-hop protection when used to protect only guarantees hop-to-hop protection when used to protect SIP
SIP signaling. Therefore the access token MUST be protected in a way signaling. Therefore the access token MUST be protected in a way so
so that only authorized SIP servers will have access to it. SIP that only authorized SIP servers will have access to it. SIP
endpoints that support this document MUST use encrypted JSON Web endpoints that support this document MUST use encrypted JSON Web
Tokens (JWT) [RFC7519] for encoding and protecting access tokens when Tokens (JWT) [RFC7519] for encoding and protecting access tokens when
they are included in SIP requests, unless some other mechanism is they are included in SIP requests, unless some other mechanism is
used to guarantee that only authorized SIP endpoints have access to used to guarantee that only authorized SIP endpoints have access to
the access token. TLS can still be used for protecting traffic the access token. TLS can still be used for protecting traffic
between SIP endpoints and the AS. between SIP endpoints and the AS, as defined in [RFC6749].
2.1.3. REGISTER Request 2.1.3. REGISTER Request
The procedures in this section apply when the UAC has received a The procedures in this section apply when the UAC has received a
challenge that contains a "Bearer" scheme, and the UAC has obtained a challenge that contains a "Bearer" scheme, and the UAC has obtained a
token as specified in Section 2.1.1. token as specified in Section 2.1.1.
The UAC sends a REGISTER request with an Authorization header field The UAC sends a REGISTER request with an Authorization header field
containing the response to the challenge, including the Bearer scheme containing the response to the challenge, including the Bearer scheme
carrying a valid access token in the request, as specified in carrying a valid access token in the request, as specified in
skipping to change at page 12, line 50 skipping to change at page 12, line 50
[RFC6749] mandates that access tokens are protected with TLS when in [RFC6749] mandates that access tokens are protected with TLS when in
transit. However, SIP makes have use of intermediary SIP proxies, transit. However, SIP makes have use of intermediary SIP proxies,
and TLS only guarantees hop-to-hop protection when used to protect and TLS only guarantees hop-to-hop protection when used to protect
SIP signaling. Therefore the access token MUST be protected in a way SIP signaling. Therefore the access token MUST be protected in a way
so that only authorized SIP servers will have access to it. SIP so that only authorized SIP servers will have access to it. SIP
endpoints that support this document MUST use encrypted JSON Web endpoints that support this document MUST use encrypted JSON Web
Tokens (JWT) [RFC7519] for encoding and protecting access tokens when Tokens (JWT) [RFC7519] for encoding and protecting access tokens when
they are included in SIP requests, unless some other mechanism is they are included in SIP requests, unless some other mechanism is
used to guarantee that only authorized SIP endpoints have access to used to guarantee that only authorized SIP endpoints have access to
the access token. TLS can still be used for protecting traffic the access token. TLS can still be used for protecting traffic
between SIP endpoints and the AS. between SIP endpoints and the AS, as defined in [RFC6749].
Single Sign-On (SSO) enables the user to use one set of credentials Single Sign-On (SSO) enables the user to use one set of credentials
to authenticate once and gain access to multiple SIP and non-SIP to authenticate once and gain access to multiple SIP and non-SIP
services using access token(s). If the SSO login is compromised, services using access token(s). If the SSO login is compromised,
that single point of compromise has a much broader effect than is the that single point of compromise has a much broader effect than is the
case without SSO. Further, an attacker can often use a compromised case without SSO. Further, an attacker can often use a compromised
account to set up Single Sign-On for other services that the victim account to set up Single Sign-On for other services that the victim
has not established an account with, and sometimes can even switch a has not established an account with, and sometimes can even switch a
dedicated account into Single-Sign-On mode, creating a still broader dedicated account into Single-Sign-On mode, creating a still broader
attack. attack.
 End of changes. 8 change blocks. 
20 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/