draft-ietf-sipcore-sip-token-authnz-16.txt   draft-ietf-sipcore-sip-token-authnz-17.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
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: 6 November 2020 V. Pascual Expires: 6 November 2020 V. Pascual
webrtchacks webrtchacks
5 May 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-16 draft-ietf-sipcore-sip-token-authnz-17
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 13, line 45 skipping to change at page 13, line 45
important to call these out in privacy disclosures and policies, and important to call these out in privacy disclosures and policies, and
to make sure that users can be aware of the tradeoffs between to make sure that users can be aware of the tradeoffs between
convenience and privacy when they choose to use SSO. convenience and privacy when they choose to use SSO.
When a registrar chooses to challenge a REGISTER request, if the When a registrar chooses to challenge a REGISTER request, if the
registrar can provide access to different levels of services, it is registrar can provide access to different levels of services, it is
RECOMMENDED that the registrar includes a scope in the response in RECOMMENDED that the registrar includes a scope in the response in
order to indicate the minimum scope needed to register and access order to indicate the minimum scope needed to register and access
basic services. The access token might include an extended scope basic services. The access token might include an extended scope
that gives the user access to more advanced features beyond basic that gives the user access to more advanced features beyond basic
services. In SIP, the AS administrator will typicall decide what services. In SIP, the AS administrator will typically decide what
level of access is provided for a given user. level of access is provided for a given user.
The UAC MUST check the AS URL received in the 401/407 response The UAC MUST check the AS URL received in the 401/407 response
against a list of trusted ASs configured on the UAC, in order to against a list of trusted ASs configured on the UAC, in order to
prevent several classes of possible vulnerabilities when a client prevent several classes of possible vulnerabilities when a client
blindly attempts to use any provided AS. blindly attempts to use any provided AS.
6. IANA Considerations 6. IANA Considerations
6.1. New Proxy-Authenticate header field parameters 6.1. New Proxy-Authenticate header field parameters
skipping to change at page 15, line 28 skipping to change at page 15, line 28
and feedback of the original document that was replaced with this and feedback of the original document that was replaced with this
document: document:
Andrew Allen, Martin Dolly, Keith Drage, Paul Kyzivat, Jon Peterson, Andrew Allen, Martin Dolly, Keith Drage, Paul Kyzivat, Jon Peterson,
Michael Procter, Roy Radhika, Matt Ryan, Ivo Sedlacek, Roman Shpount, Michael Procter, Roy Radhika, Matt Ryan, Ivo Sedlacek, Roman Shpount,
Robert Sparks, Asveren Tolga, Dale Worley, and Yehoshua Gev. Robert Sparks, Asveren Tolga, Dale Worley, and Yehoshua Gev.
Roman Danyliw, Benjamin Kaduk, Erik Kline, Barry Leiba, Eric Vyncke Roman Danyliw, Benjamin Kaduk, Erik Kline, Barry Leiba, Eric Vyncke
and Magnus Westerlund provided feedback and suggestions for and Magnus Westerlund provided feedback and suggestions for
improvements as part of the IESG evaluation of the document. Special improvements as part of the IESG evaluation of the document. Special
thanks to Benjamin Kaduk for his detailed and comprehinsive reviews thanks to Benjamin Kaduk for his detailed and comprehensive reviews
and comments. and comments.
The authors would also like to specially thank Jean Mahoney for her The authors would also like to specially thank Jean Mahoney for her
multiple reviews, editorial help, and the coversion of the XML source multiple reviews, editorial help, and the coversion of the XML source
file from v2 to v3. file from v2 to v3.
8. Normative References 8. Normative References
[OPENID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and [OPENID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", February 2014. C. Mortimore, "OpenID Connect Core 1.0", February 2014.
 End of changes. 3 change blocks. 
3 lines changed or deleted 3 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/