Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-token-authnz-17

[Ballot discuss]
Thanks for the updates in the -14 (and -15); they cover most of my points.

Unfortunately, the new security considerations text seems to introduce a
problematic recommendation:

  Because of that, it is critical to make sure that extra security
  measures be taken to safeguard credentials used for Single Sign-On.
  Examples of such measures include long passphrase instead of a
  password, enabling multi-factor factor authentication, and the use of
  embedded browser when possible, as defined in [RFC8252].

Looking at RFC 8252 (Section 8.12), it seems to be rather strongly recommending
to *not* use an embedded browser, which is the opposite of the apparent
recommendation here.  Are we missing a word "avoiding" or similar?

Also, I am not 100% sure my note about refresh tokens was fully addressed;
in Section 2.1.1 we see:

  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 request a new
  access token and refresh token from the AS before the currently used
  access token expires ([RFC6749], Section 1.5).  If the AS does not

Is it accurate to say that the refresh token is used "to request a new access
token and refresh token" (specifically the "and refresh token" part)?  I know that
it is not always returned, but am less sure about whether the semantics always
include an (implicit) request for a new one.

[Ballot comment]
Some other comments on the new text that do not rise to Discuss-level.

Thanks for adding the mention of a whitelist of trusted ASes; I would consider
also mentioning it in Section 4 for the authz_server parameter, and/or in the
security considerations.

I also would have liked to see some guidance about when one should/shouldn't
include the realm parameter in a challenge.

Section 2.1.1

  UAC contacts the AS in order to obtain tokens, and includes the
  requested scopes, based on a local configuration (Figure 1).  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 prevent several
  classes of possible vulnerabilities when a client blindly attempt to
  use any provided authorization.

nits: "attempts", and maybe "any provided authorization server".

Section 3

nit: s/claimes/claims/

Section 5

  When a registrar chooses to challenge a REGISTER request, if the
  registrar can provide access to different levels of services, it is
  RECOMMENDED that the registrar includes a scope in the response in
  order to indicate the minimum scope needed to register and access
  basic services.  The access token might include an extended scope
  that gives the user access to more advanced features beyond basic
  services.

Is there anything to say about how the broader scope value might be learned?

[Ballot comment]
[[ nits ]]

[ section 2.1.1 ]
* "(based on local policy)": Also possibly based on "local implementation
  status", or are all clients expected to support all the authentication
  schemes in this particular scenario?

[Ballot discuss]
I support Roman's Discuss.


The "Bearer" authentication challenge includes the address (or name?) of an
authorization server to contact to obtain tokens, as mentioned in multiple
places in the document (noted in the COMMENT section).  Our experience in
the OAuth world has shown that several classes of vulnerabilities are
possible when the client blindly attempt to use any provided AS, and that a
whitelist of "allowed" or "trusted" ASes is needed for secure operation.  I
believe that the same is true for the SIP usage, and we should mention this
requirement explicitly.


Section 1.2 tries to apply the OAuth confidential/public client distinction
to SIP UACs, but it does so in a non-analogous fashion: the OAuth
distinction is for the client's ability to protect credentials that identify
the client itself; the usage in this document refers to protecting *user*
credentials and obtained tokens.  I don't think that it's appropriate to
invoke the OAuth terminology when using it for a different meaning.
Both Public and Confidential OAuth clients are capable of providing the
necessary protections for *user* credentials (though they are of course not
guaranteed to do so), which leaves me unclear on what the intended
requirements actually are.


Section 2.3 states that:

  When a proxy wishes to authenticate a received request, it MUST
  search the request for Proxy-Authorization header fields with 'realm'
  parameters that match its realm.  It then MUST successfully validate

https://tools.ietf.org/html/rfc7235#section-4.4 suggests that it is not
expected to have a sequence or list of Proxy-Authorization header fields
present in a single request that are intended to be interpreted by different
proxies.  Is this text compatible with that part of RFC 7235?  Furthermore,
I didn't find much guidance in 7235 or 3261 about when to include the
"realm" parameter in Proxy-Authorization; do we want to give any guidance
here?  (That is to say, I almost didn't find where it was even defined as
possible to do so...)


I'm also not sure if we're attempting to profile RFC 6749 and always require
a refresh token to be issued, or just have some editorial tweaks to make to
avoid suggesting that we do have such a requirement (noted in the COMMENT).

[Ballot comment]
Section 1

  The OpenID Connect 1.0 specification [OPENID] defines a simple
  identity layer on top of the OAuth 2.0 protocol, which enables
  clients to verify the identity of the user based on the

Please make it clear that these are OAuth/OIDC clients, not SIP clients.

Section 1.3

OAuth 2.0 doesn't require the issuance of a Refresh token, but the
discussion here implies that for the SIP case there will always be a refresh
token.  If we're profiling 6749 in this manner, we should be more explicit
about the requirement to issue refresh tokens.

  *  ID Token: this token contains the SIP URI and other user-specific
      details that will be consumed by the UAC.

nit: I don't think we should use the definite article in "the SIP URI" since
we haven't discussed any such SIP URI usage yet.  That is, we should say
what it's used for, e.g., "a SIP URI associated with the user".

  *  Structured Token: a token that consists of a structured object
      that contains the claims associated with the token, e.g.  JWT as
      defined in [RFC7519].

nit: comma after "e.g.".

  *  Reference Token: a token that consists of a random string that is
      used to obtain the details of the token and its associated claims,
      as defined in [RFC6749].

It doesn't technically have to be random (though in practice it should
contain signficant random elements); "opaque" might be better wording.

Section 1.4.1

Perhaps Figure 1 could include some indication that steps 5 and 6 are
optional/do not always occur (in the case when the access token is a
self-contained JWT)?

  In step [2], the registrar challenges the UA, by sending a SIP 401
  (Unauthorized) response to the REGISTER request.  In the response,
  the registrar includes information about the AS to contact in order
  to obtain a token.

The UAC needs to have a preconfigured whitelist of acceptable ASes in order
to avoid directing the user's credentials to malicious sites.

  The registrar validates the access token.  If the access token is a
  reference token, the registrar MAY perform an introspection
  [RFC7662], as in steps [5] and [6], in order to obtain more
  information about the access token and its scope, per [RFC7662].

I think we could tighten up the normative language a bit here.
In particular, the registrar MUST validate the token in some fashion; for
reference tokens, the main ways to do that are either inspection or
(essentially) being the party that issued the token in the first place.

  Otherwise, after the registrar validates the token to make sure it
  was signed by a trusted entity, it inspects its claims and acts upon
  it.

I think we can also be more specific than "a trusted entity" -- in this
flow, it looks like the registrar should know exactly which entity should
have signed the token in question (for the user in question), and should not
accept a signed token from a different entity that happens to be trusted to
issue other tokens.

Section 1.4.2

(Similarly, Figure 2 could note that steps 3 and 4 do not always occur, and
the text about token validation should remain parallel between examples.)

Section 2

I note that RFC 3261 explicitly disclaims any definition of authorization
systems, which is not true for this document, given that OAuth is an
authorization system :)

Section 2.1.1

  Required) response with a Proxy-Authenticate header field.  If the
  WWW-Authenticate or Proxy-Authenticate header field indicates
  "Bearer" scheme authentication and contains an address to an
  authorization server, the UAC contacts the authorization server in
  order to obtain tokens, and includes the requested scopes, based on a
  local configuration (Figure 1).

[whitelist of allowed ASes, again]

  The detailed OAuth2 procedure to authenticate the user and obtain
  these tokens is out of scope of this document.  The address of the
  authorization server might already be known to the UAC via
  configuration.  In which case, the UAC can contact the authorization
  server for tokens before it sends a SIP request (Figure 2).

nit: I think that "in which case" functions as a conjunction, which makes
this an incomplete sentence.

  The tokens returned to the UAC depend on the type of authorization
  server (AS): an OAuth AS provides an access token and refresh token
  [RFC6749].  The UAC provides the access token to the SIP servers to

Again, this implies that refresh tokens are always issued; RFC 6749 is quite
clear that "issuing a refresh token is optional at the discretion of the
authorization server".

  authorize UAC's access to the service.  The UAC uses the refresh
  token only with the AS to get a new access token and refresh token
  before the expiry of the current access token (see [RFC6749], section

(New refresh token is also optional.)

  1.5 Refresh Token for details).  An OpenID Connect server returns an
  additional ID-Token containing the SIP URI and other user-specific
  details that will be consumed by the UAC.

[same comment as above about "the SIP URI".]

  If the UAC receives a 401/407 response with multiple WWW-
  Authenticate/Proxy-Authenticate header fields, providing challenges
  using different authentication schemes for the same realm, the UAC
  selects one or more of the provided schemes (based on local policy)
  and provides credentials for those schemes.

RFC 3261 seems to be written in a world that assumed that Basic and Digest
are the only defined HTTP authentication schemes, and since it prohibits
Basic, that there would only be one authentication challenge (type)
possible.  This text righly acknowledges that we are opening the field up
and could have cases where multiple authentication schemes are possible;
however, it goes even further and admits the possibility of using them
simultaneously.  It seems like this places an onus on us to give some
indication of the semantics when multiple schemes are used at the same time.
Do the authenticated identities need to match?  Or are we asserting that
both/all identities are consenting to the request in question?  (If we don't
have a concrete use case in mind, perhaps the "or more" is just opening a
box that we don't need to open right now.)

Section 2.1.2

  access to it.  Endpoints that support this specification MUST support
  encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting
  access tokens when they are included in SIP requests, unless some
  other mechanism is used to guarantee that only authorized SIP
  endpoints have access to the access token.

I think we may want "MUST support" (always) and "MUST use, unless some other
mechanism".

I'd also suggest a quick note that TLS remains fine for protecting the
UAC/AS interaction where the refresh token is used.

Whatever is done, please harmonize with Section 5 that has essentially the
same text.

Section 2.1.3

  Based on local policy, the UAC MAY include an access token that has
  been used for another binding associated with the same Address Of
  Record (AOR) in the request.

Just to check: there's no real privacy considerations with such use, as its
the same parties interacting and there are other identifiers (e.g., IP
addresses) to confirm that it's the same client communicating to the server?

Also, is it clear what will be done (new token request) when the MAY is not
heeded?

Section 2.1.4

The text here just talks about "a valid access token" and similar, without
saying a whole lot about it being related in any way to the specifics of the
authentication challenge.  Is there something useful to say about, e.g., the
token in question having been issued by the authorization server indicated
in the challenge?

Section 2.2

  authorization credentials acceptable to it, it SHOULD challenge the
  request by sending a 401 (Unauthorized) response.  To indicate that
  it is willing to accept an access token as a credential, the UAS/
  Registrar MUST include a Proxy-Authentication header field in the
  response that indicates "Bearer" scheme and includes an address of an

nit(?): I'd consider just making this a declarative statement, a la "the
UAS/registrar includes a Proxy-Authentication header field with the "Bearer"
scheme to indicate that it is willing to accept an access token as a
credential"  (but that wording is incomplete and would need to be fleshed
out a bit more).

  authorization server from which the originator can obtain an access
  token.

nit: "address of" an AS, does that mean bare IP address only or is a DNS
name okay?

  [RFC7519].  If the token provided is an expired access token, then
  the UAS MUST reply with 401 Unauthorized, as defined in section 3 of
  [RFC6750].  If the validation is successful, the UAS/Registrar can
  continue to process the request using normal SIP procedures.  If the
  validation fails, the UAS/Registrar MUST reject the request.

Is "expired" the only case that should get a 401 vs. outright rejection, as
stated here?

Section 2.3

  sending a 407 (Proxy Authentication Required) response.  To indicate
  that it is willing to accept an access token as a credential, the
  proxy MUST include a Proxy-Authentication header field in the
  response that indicates "Bearer" scheme and includes an address to an

[same comment as above about normative vs. declarative statement]
Also, please keep the text parallel between sections -- this copy has at
least one nit ("address to an" vs. "address of an").

Section 3

  If an access token is encoded as a JWT, it might contain a list of
  claims [RFC7519], some registered and some application-specific.  The

I don't think there's a question of whether a JWT will contain a list of
claims :)
Maybe "If the access token is encoded as a JWT, it will contain a list of
claims [RFC7519], which may include both registered and application-specific
claims"?

Section 4

This section claims to cover WWW-Authenticate.  What specification will the
SIP use of Bearer for Authorization operate under?

      challenge  =/  ("Bearer" LWS bearer-cln *(COMMA bearer-cln))

side note: is there a mnemonic for the "cln" in "bearer-cln"?

      bearer-cln = realm / scope / authz-server / error /
                    auth-param

nit: realm is already included in auth-param, though I don't see a harm in
calling it out explicitly.

      realm =
      auth-param =

RFC 3261 defers to RFC 2617 (now obsoleted by 7235) for both of these; we
could perhaps short-circuit the chain and say "defined in RFC 7235".

Section 5

We should probably note that SIP makes much heavier use of proxies than is
common in the web world of OAuth.

I'm happy to see that some privacy considerations are being added in
response to Barry's review.

Section 8

I think RFCs 8252 and 8414 could be just informative.

[Ballot comment]
An additional thing.

Is SIP directly using the HTTP Authentication Schemes IANA registry (https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml#authschemes) or does it have its own tucked away somewhere? And if it is the former, should its references for the "bearer" add this RFC as a reference?

[Ballot discuss]
I think these resolution for this is rather straight forward, however the implications of one is going to break deployed implementations.

1. Section 4:

This is rather straight forward to resolve but you do have a SIP syntax violation in these rules.

      challenge  =/  ("Bearer" LWS bearer-cln *(COMMA bearer-cln))
      bearer-cln = realm / scope / authz-server / error /
                    auth-param
      authz-server = "authz_server" EQUAL authz-server-value
      authz-server-value = https-URI
      realm =
      auth-param =
      scope =
      error =
      https-URI =

So RFC 3261 defines the Challenge construct as:

challenge          =  ("Digest" LWS digest-cln *(COMMA digest-cln))
                      / other-challenge

Where this extension needs to match the syntax of the other-challenge:

other-challenge    =  auth-scheme LWS auth-param
                      *(COMMA auth-param)

Where we need to look at:
auth-param        =  auth-param-name EQUAL
                    ( token / quoted-string )

Please note what is included in the "token" rule.
      token      =  1*(alphanum / "-" / "." / "!" / "%" / "*"
                    / "_" / "+" / "`" / "'" / "~" )

the allowed syntax for https-URI in RFC 7230 is:

    https-URI = "https:" "//" authority path-abempty [ "?" query ]
                [ "#" fragment ]

Which include both "/", "?" and "#" that are not allowed in token. Thus, the URI included in the authz-server-value  MUST be converted into a quoted-string matching syntax rule.

2. In addition should not the "authz_server" be registered in the https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-12 registry?

[Ballot comment]
hank you for the work put into this document. The document is clear, easy to read and quite useful even if examples would be welcome.

Please find below just two NITs.

I hope that this helps to improve the document,

Regards,

-éric

== NITS ==

-- section 1.3 --
Expanding "JWT" on first use will be improve readability. And, it is expanded in section 5 ;)

-- section 6 --
Probably better to write "This document has no IANA consideration; just to be clear."

[Ballot discuss]
The use of the OpenID ID token appears to be underspecified.  Section 1.3 notes the possibility of using it as one of the three possible tokens.  However, the SIP procedures in Section 2 makes no note of it, only covering the use of the “access token” and the “refresh token”.

[Ballot comment]
Thanks for the update based on the SECDIR review (and thanks to Derrell Piper for providing it).

** Section 1.3.  Per “Access Tokens could be represented in one of the above two formats.”, if not one of these two formats, then which other ones?

** Section 2.1.1.  Per “An OpenID Connect server …”, based on the flows depicted in Figure 1 and 2, how the OpenID Connect server fits isn’t clear.

** Section 2.1.2.  Per “Endpoints that support this specification MUST support encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting access tokens when they are included in SIP requests, unless some other mechanism is used to guarantee that only authorized SIP endpoints have access to the access token.” -- is it the “use of” or “support for” JWT that is required if there isn’t an alternative?  Section 5 uses similar language.

** Section 2.1.3.  Per “Note that, if there were multiple challenges with different schemes, then the UAC may be able to successfully retry the request using non-Bearer credentials.”, would that decision be made based on local policy?

** Section 5.  Should the use of the scope parameter be noted (or RECOMMENDED) to narrow the utility of the token?

** Editorial Nits:
Section 1.3.  Typo. s/usualy/usually/

Section 7.  Typo.  s/coversion/conversion/

[Ballot comment]
Thanks for this document.  Enabling Open-ID and OAUTH with SIP is quite useful.

This document specifically calls out single sign-on as a reason to use this mechanism, and SSO has a host of serious security and privacy issues.  As those issues are not discussed in the referenced documents, I think they need to be raised here.  Recommended usage/configuration to avoid or mitigate the issues would be ideal, but at the very least I think they need to be documented, as it’s clear that implementors are not aware of them or don’t think they’re important enough to worry about.

Rifaat and I have discussed the above comment and have come up with some text for the Security Considerations that calls out some of the issues, briefly.  Something with more scope than that -- perhaps a BCP about security/privacy concerns with respect to SSO -- is in order, but, clearly, that's way out of scope for this document.

Other, editorial points.

— Section 1.1 —
Please copy the BCP 14 boilerplate exactly from RFC 8174.

— Section 1.3 —

  Refresh Tokens usualy are represented in a reference format

Typo: “usually”.

— Section 3 —

  The methods used and the access
  provided by the token is based on local policy

“are based”, to match the plural subject.

  Examples of such other
  mechanisms are introspection [RFC7662], user profile lookups, etc.

“Examples” and “etc.” are mutually redundant.  I would remove the latter and replace the comma before “user profile lookups” with “and”.

— Section 6 —
This can’t be empty.  It should say that there are no IANA actions needed for this document.

[Ballot discuss]
Thanks for this document.  Enabling Open-ID and OAUTH with SIP is quite useful.

This document specifically calls out single sign-on as a reason to use this mechanism, and SSO has a host of serious security and privacy issues.  As those issues are not discussed in the referenced documents, I think they need to be raised here.  Recommended usage/configuration to avoid or mitigate the issues would be ideal, but at the very least I think they need to be documented, as it’s clear that implementors are not aware of them or don’t think they’re important enough to worry about.

[Ballot comment]
— Section 1.1 —
Please copy the BCP 14 boilerplate exactly from RFC 8174.

— Section 1.3 —

  Refresh Tokens usualy are represented in a reference format

Typo: “usually”.

— Section 3 —

  The methods used and the access
  provided by the token is based on local policy

“are based”, to match the plural subject.

  Examples of such other
  mechanisms are introspection [RFC7662], user profile lookups, etc.

“Examples” and “etc.” are mutually redundant.  I would remive the latter and replace the comma before “user profile lookups” with “and”.

— Section 6 —
This can’t be empty.  It should say that there are no IANA actions needed for this document.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-sipcore-sip-token-authnz-12, which is currently in Last Call, and has the following comments:

The IANA Functions Operator notes that this document has an empty IANA Considerations section. After examining the draft, we understand that, upon approval of this document, there are no IANA Actions that need completion.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-04-15):

From: The IESG
To: IETF-Announce
CC: superuser@gmail.com, Jean Mahoney , sipcore-chairs@ietf.org, draft-ietf-sipcore-sip-token-authnz@ietf.org, mahoney@nostrum.com, sipcore@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP)) to Proposed Standard


The IESG has received a request from the Session Initiation Protocol Core WG
(sipcore) to consider the following document: - 'Third-Party Token-based
Authentication and Authorization for Session
  Initiation Protocol (SIP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-04-15. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

  Proposed Standard, which is indicated in the header. This draft updates RFC 3261.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  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.


Working Group Summary:

  This work has been discussed the sipcore working group for a
  while. It is much scaled down from its original scope, and
  contains the core of what the working group had consensus on.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification?

  The authors indicated that there was at least one implementation
  of this. It's assumed that it will be deployed in 3GPP networks.
  During WGLC, the chairs asked if there were any other implementation
  plans, but no reviewers chose to share that info.


Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues?

  Several reviewers provided a lot of constructive feedback.
  They are thanked in the Acknowledgments section. 


Personnel:

  Document Shepherd:  Jean Mahoney

  Responsible Area Director:  Murray Kucherawy


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

  The doc shepherd carefully followed review feedback to ensure it
  had been incorporated. She also did her own careful review.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

  No, the concept has been very well reviewed by the sipcore WG.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

  No.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

  The document shepherd doesn't have concerns about this document.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

  The authors are not aware of any IPR disclosures associated with the draft.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
 
  No.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

  Although the document has been thoroughly reviewed multiple times, there
  did not seem to be a lot of enthusiasm among WG participants for implementing
  this solution. More than one reviewer indicated that they were not that
  familiar with OAuth.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

  No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords -- however, there's a paragraph with
    a matching beginning. Boilerplate error?

    Boilerplate looks ok to the shepherd, so not sure what id-nits is complaining
    about.

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)

    The document does not have any content that was submitted before Nov 2008.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  The document does not need a formal review.


(13) Have all references within this document been identified as either normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

  [OPENID]  Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0", February 2014.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

  There are no IANA considerations in this document.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

  N/A


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

  The document shepherd reviewed the ABNF as did other WG participants.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

  N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

  Proposed Standard, which is indicated in the header. This draft updates RFC 3261.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  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.


Working Group Summary:

  This work has been discussed the sipcore working group for a
  while. It is much scaled down from its original scope, and
  contains the core of what the working group had consensus on.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification?

  The authors indicated that there was at least one implementation
  of this. It's assumed that it will be deployed in 3GPP networks.
  During WGLC, the chairs asked if there were any other implementation
  plans, but no reviewers chose to share that info.


Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues?

  Several reviewers provided a lot of constructive feedback.
  They are thanked in the Acknowledgments section. 


Personnel:

  Document Shepherd:  Jean Mahoney

  Responsible Area Director:  Murray Kucherawy


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

  The doc shepherd carefully followed review feedback to ensure it
  had been incorporated. She also did her own careful review.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

  No, the concept has been very well reviewed by the sipcore WG.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

  No.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

  The document shepherd doesn't have concerns about this document.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

  The authors are not aware of any IPR disclosures associated with the draft.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
 
  No.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

  Although the document has been thoroughly reviewed multiple times, there
  did not seem to be a lot of enthusiasm among WG participants for implementing
  this solution. More than one reviewer indicated that they were not that
  familiar with OAuth.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

  No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords -- however, there's a paragraph with
    a matching beginning. Boilerplate error?

    Boilerplate looks ok to the shepherd, so not sure what id-nits is complaining
    about.

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)

    The document does not have any content that was submitted before Nov 2008.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  The document does not need a formal review.


(13) Have all references within this document been identified as either normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

  [OPENID]  Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0", February 2014.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

  There are no IANA considerations in this document.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

  N/A


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

  The document shepherd reviewed the ABNF as did other WG participants.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

  N/A