Subject: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 23 Apr 2020 12:25:10 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sipcore-sip-token-authnz-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/

----------------------------------------------------------------------
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).

----------------------------------------------------------------------
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 = <defined in RFC3261>
       auth-param = <defined in RFC3261>

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Apr 2020 16:55:10 -0400

> box that we don't need to open right now.)

I pushed quite a bit on this area during the development of this draft. 
As you note we are definitely expanding into an area that wasn't 
anticipated in RFC3261. The whole topic of how authentication works in 
the presence of multiple schemes and realms could use some elaboration. 
The authors of this draft were reluctant to get into those weeds. It 
isn't clear what the right mechanism is to do that.

I had a (non-sip) use case in mind: a site I visit allows you register 
directly with the site, resulting in an ability to use Digest 
credentials. The login page on the site offers that as an option, along 
with the alternatives of Facebook, Google, and maybe some others. I can 
see something just like that for SIP. Presumably it would be achieved by 
challenging with Digest and also with Bearer for Facebook, Google, etc. 
The UAC then "chooses" by delegating the choice to the user through the UI.

This is also the case where the "whitelist" really resides within the 
end user's head rather than in the UAC.

It gets harder for devices that might be connecting when there is no end 
user present. This can happen with a "phone" that attempts to be 
permanently registered to its sip server so that in can receive incoming 
calls. If it reboots in the middle of the night there is no user handy 
to interact in the authentication process. It all has to take place 
using credentials preconfigured (or cached) in the UAC.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 24 Apr 2020 08:08:56 +0200

> On 23 Apr 2020, at 22:55, Paul Kyzivat <[email-masked]> wrote:
> 
> I pushed quite a bit on this area during the development of this draft. As you note we are definitely expanding into an area that wasn't anticipated in RFC3261. The whole topic of how authentication works in the presence of multiple schemes and realms could use some elaboration. The authors of this draft were reluctant to get into those weeds. It isn't clear what the right mechanism is to do that.
> 
> I had a (non-sip) use case in mind: a site I visit allows you register directly with the site, resulting in an ability to use Digest credentials. The login page on the site offers that as an option, along with the alternatives of Facebook, Google, and maybe some others. I can see something just like that for SIP. Presumably it would be achieved by challenging with Digest and also with Bearer for Facebook, Google, etc. The UAC then "chooses" by delegating the choice to the user through the UI.
> 
> This is also the case where the "whitelist" really resides within the end user's head rather than in the UAC.
> 
> It gets harder for devices that might be connecting when there is no end user present. This can happen with a "phone" that attempts to be permanently registered to its sip server so that in can receive incoming calls. If it reboots in the middle of the night there is no user handy to interact in the authentication process. It all has to take place using credentials preconfigured (or cached) in the UAC.
> 
I think it’s critical - and I’ve also raised the issue before like Paul - that we develop a BCP for the various combinations we have - both two types of digest algorithms and now the OAuth2/OpenID Connect. There are huge risks of mis-configured platforms allowing for downgrade attacks, so even if you’ve added stronger authentication, someone will misuse your system because MD5 was still open with simple passwords for some very old SIP phones.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Apr 2020 06:40:14 +0000

Hi,

    >> I pushed quite a bit on this area during the development of this draft. As you note we are definitely expanding into an area that wasn't anticipated in RFC3261.
    >> The whole topic of how authentication works in the presence of multiple schemes and realms could use some elaboration. The authors of this draft were
    >> reluctant to get into those weeds. It isn't clear what the right mechanism is to do that.
    >> 
    >> I had a (non-sip) use case in mind: a site I visit allows you register directly with the site, resulting in an ability to use Digest credentials. The login page on the
    >> site offers that as an option, along with the alternatives of Facebook, Google, and maybe some others. I can see something just like that for SIP. Presumably it
    >> would be achieved by challenging with Digest and also with Bearer for Facebook, Google, etc. The UAC then "chooses" by delegating the choice to the user through the UI.
    >> 
    >> It gets harder for devices that might be connecting when there is no end user present. This can happen with a "phone" that attempts to be permanently registered
    >> to its sip server so that in can receive incoming calls. If it reboots in the middle of the night there is no user handy to interact in the authentication process. It all
    >> has to take place using credentials preconfigured (or cached) in the UAC.
    > 
    > I think it’s critical - and I’ve also raised the issue before like Paul - that we develop a BCP for the various combinations we have - both two types of digest algorithms and now the OAuth2/OpenID Connect.
    > There are huge risks of mis-configured platforms allowing for downgrade attacks, so even if you’ve added stronger authentication, someone will misuse your system because MD5 was still open with simple passwords for some very old SIP phones.

    I agree that such BCP (or whatever form it would take) would be useful. As I said before, I think it should be done as a separate task.

    Therefore, in the authnz draft the suggestion is to say that the processing is based on "local policy".

    If people want, we can add a note saying that a future specification may provide more detailed procedures and guidance regarding processing multiple schemes.

    Regards,

    Christer

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 24 Apr 2020 13:13:16 -0700

>     I agree that such BCP (or whatever form it would take) would be useful. As I said before, I think it should be done as a separate task.

How much do you think would be SIP-specific in such a document, vs. being
applicable to both SIP and HTTP?

>     Therefore, in the authnz draft the suggestion is to say that the processing is based on "local policy".

I'm happy to leave the choice of which one to use as up to local policy,
but would object to giving local policy the ability to use multiple
mechanisms in combination without defining the semantics of such
combinations.

>     If people want, we can add a note saying that a future specification may provide more detailed procedures and guidance regarding processing multiple schemes.

That seems reasonable, if consistent with the above.

-Ben

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Apr 2020 21:51:35 +0000

Hi,

    > applicable to both SIP and HTTP?
    
    I don't know - perhaps there would be nothing SIP-specific. 

    > That seems reasonable, if consistent with the above.
    
    I suggest the following:

OLD:

   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
   provides credentials for one or more of the schemes that it supports,
   based on local policy.

NEW:

   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
   provides credentials for one of the schemes that it supports,
   based on local policy.

   NOTE: At the time of writing this specification, detailed procedures for the cases where a UAC receives multiple 
   different authentication schemes had not been defined. A future specification might define such procedures.

   Regards,

   Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 25 Apr 2020 08:42:27 +0200

> On 24 Apr 2020, at 23:51, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
Food for thought. As mentioned earlier SIP has more proxys, ingress proxys between the authenticating part
and the client. Let’s start and see where it goes.
>> mechanisms in combination without defining the semantics of such

Based on personal experience, referring to local policy results in “do whatever you want” which in
all likelyhood means opening for problems. We need guidelines here.

>   based on local polic
Until we have a point where we know we can securely handle multiple authentication schemes from the same UAS,
I think we should recommend one policy per realm and/or domain.

That will mean that until we have the BCP we determine method per device - new devices gets the challenge
that they support and we limit the possibilities of downgrade attacks.

/O

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 25 Apr 2020 08:57:51 -0400

Hi Ben,

Thanks for the detailed and comprehensive review.
I will try to address the DISCUSS in this email with my inline comments
below.

Regards,
 Rifaat

On Thu, Apr 23, 2020 at 3:25 PM Benjamin Kaduk via Datatracker <
[email-masked]> wrote:

>  Yeah, good point. I will add some text to address that.

> Well, a browser-based client apps do not have client credentials at all,
and they are considered public clients.
I think the clarification needed here is to make it clear that we are
talking about persistent storage of credentials.
What I am trying to do with these two definitions is to differentiate
between a browser-based UAC and non-browser based UAC.
Because a browser-based UAC should be using a different flow, the
authorization code grant flow, which is not covered by this document.
Would adding such clarification address this comment?

> There is a separate thread already on this one.

> This part is out of scope for this document, as it is related to the
interaction between the UAC and the AS.
This document is not trying to deviate from the OAuth 2.0 recommendations;
we will clarify this.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 25 Apr 2020 14:43:04 -0400

> that they support and we limit the possibilities of downgrade attacks.

I don't understand what you are suggesting here.

Is it that the UAS should only challenge with one scheme? That could be 
problematic, since it means either only use Digest, or else use Bearer 
and fail to work with any device that doesn't support it. (Can you say 
"flag day"?)

Or do you mean that the UAC should only respond with credentials for one 
of the schemes it receives challenges for?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 25 Apr 2020 20:56:16 +0000

> of the schemes it receives challenges for?
 
    The UAC only responding with credentials for one scheme is the suggestion based on Benjamin's review.

    Regards,

    Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 25 Apr 2020 23:27:34 +0000

Hi Benjamin,
 
> proxies.  Is this text compatible with that part of RFC 7235? 

RFC 3261 allows multiple Proxy-Authorization header fields.

> Furthermore, I didn't find much guidance in 7235 or 3261 about when to include the

I think it is clear from Section 22.3 (and the example in Section 20.28) in RFC 3261 that the "realm" is included in the Proxy-Authorization header field.

If we think 7235 and/or 3261 needs to be improved regarding that I think it is a separate task, outside the scope of this document.
 
(The thread Rifaat mentioned is not really related to this. It is whether the UAC provides credentials for one or more schemes.)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 26 Apr 2020 10:28:36 -0400

> RFC 3261 allows multiple Proxy-Authorization header fields.

* Here is a situation when they come into play:

UAC ----- P1 ------- P2 ------- UAS

On the first request from UAC toward UAS, P1 challenges with a 
Proxy-Authenticate containing realm P1.

UAC retries, including Proxy-Authorization for realm P1. P1 is happy and 
passes the request along. P2 challenges with realm P2.

UAC retries again. It adds Proxy-Authorization for realm P2, but also 
including the credentials for P1. P1 is happy and passes the request 
along. P2 is also happy and passes the request along to UAS.

Note that UAC must *remember* to include the P1 credentials in the 
second retry because there is no Proxy-Authenticate for P1 in the 407 
from P2. Similarly, in future messages toward UAS the UAC should 
remember to include credentials for P1 and P1.

* A more complex case is:

UAC ----- P1 -|------ P2 ------ UAS-A
               |
               |------ P3 ------ UAS-B

On the first request from UAC toward UAS, P1 challenges with a 
Proxy-Authenticate containing realm P1.

UAC retries, including Proxy-Authorization for realm P1. P1 is happy.
If it does parallel forking then it passes the request along to both P2 
and P3.

P2 challenges by returning a Proxy-Authenticate for realm P2.

P1 buffers that response while awaiting a response from P3.

P3 challenges by returning a Proxy-Authenticate for realm P3.

P2 passes a response back to UAC with Proxy-Authenticates for realms P2 
and P3.

UAC retries again. It adds Proxy-Authorization for realms P2 and P3, but 
also including the credentials for P1. P1 is happy and passes the 
request along to both P2 and P3.

P2 finds its Proxy-Authorization and happily passes the request along to 
UAS-A.

P3 finds its Proxy-Authorization and happily passes the request along to 
UAS-B.

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 26 Apr 2020 11:58:34 -0400

Paul,

What you described is the theory; have you seen this deployed in practice?

Regards,
 Rifaat

On Sun, Apr 26, 2020 at 10:28 AM Paul Kyzivat <[email-masked]> wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 26 Apr 2020 17:12:56 +0000

FWIW, I can’t remember that would even have seen Proxy-Authenticate in a real deployment, and I have definitely never seen a chain of proxies authenticating the UAC.

In my experience, the authentication is done by the home registrar, and it is done before a request has been forked.

In any case, RFC 3261 allows for other scenarios, so thanks to Paul for explaining :)

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Rifaat Shekh-Yusef <[email-masked]>
Date: Sunday, 26 April 2020 at 18.59
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply

Paul,

Regards,
 Rifaat

On Sun, Apr 26, 2020 at 10:28 AM Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

        Thanks,
        Paul

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 26 Apr 2020 14:53:56 -0400

> What you described is the theory; have you seen this deployed in practice?

Its just theory. But the specs should cover all the theoretical cases.

	Thanks,
	Paul

>     [email-masked] <mailto:[email-masked]>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 26 Apr 2020 15:22:07 -0400

Why should we do that?
Why can't we just acknowledge that this was a nice idea in theory that
never materialized in practice because they was never a need for it?
Why can't this document explicitly state that this theoretical case is *not
*cover and move on to do something more useful that people actually care
about?

Regards,
 Rifaat

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 26 Apr 2020 19:30:56 +0000

Paul,
 
> Its just theory. But the specs should cover all the theoretical cases.
   
AFAIK, what you explained in generic SIP, and not specific to this draft?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 26 Apr 2020 15:43:27 -0400

On 4/26/20 3:22 PM, Rifaat Shekh-Yusef wrote:
> Why can't this document explicitly state that this theoretical case is 
> *not *cover and move on to do something more useful that people actually 
> care about?

I didn't say what we should do about it. I was just explaining the use case.

I generally agree that this document isn't the place to discuss such 
cases. (Especially since the case I describe doesn't even involve 
multiple schemes, and is scheme independent, so it is nothing that this 
document impacts.)

This is something that is implicit in 3261, and something that 
implementors ought to support as a matter of course. Somebody can argue 
that it isn't used and so shouldn't have to be supported. If so, then 
there is a need to define exactly what *should* be supported. But again, 
this isn't the right document for that.

	Thanks,
	Paul

> Regards,
>   Rifaat
> 
> 
> On Sun, Apr 26, 2020 at 2:54 PM Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > On Sun, Apr 26, 2020 at 10:28 AM Paul Kyzivat
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >      > Hi Benjamin,
>      >      >
>      >      >>> 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?
>      >      >
>      >      > RFC 3261 allows multiple Proxy-Authorization header fields.
>      >
>      >     UAC retries, including Proxy-Authorization for realm P1. P1
>     is happy
>      >     and
>      >     UAC retries again. It adds Proxy-Authorization for realms P2
>     and P3,
>      >     but
>     <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 26 Apr 2020 15:53:46 -0400

Thanks Paul!

I guess I misunderstood your statement about this, as I thought you were
arguing for this to be covered in this document.

Regards,
 Rifaat

On Sun, Apr 26, 2020 at 3:43 PM Paul Kyzivat <[email-masked]> wrote:

> >      >      >>>     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
> >     is happy.
> >      >     P2 finds its Proxy-Authorization and happily passes the
> request
> >      >     along to
> >      >     UAS-A.
> >      >
> >      >     P3 finds its Proxy-Authorization and happily passes the
> request
> >      >     along to
> >      >     UAS-B.
> >      >
> >      >              Thanks,
> >      >              Paul
> >      >

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Apr 2020 10:32:24 -0700

On Sat, Apr 25, 2020 at 08:57:51AM -0400, Rifaat Shekh-Yusef wrote:
>    On Thu, Apr 23, 2020 at 3:25 PM Benjamin Kaduk via Datatracker
>    <[email-masked]> wrote:
> 
>      Please refer to
>      https://www.ietf.org/iesg/statement/discuss-criteria.html

Yes.

>    Would adding such clarification address this comment?

Well, this paragraph leaves me confused as to what we're trying to convey.
To try to clarify my current understanding, let me consider the current
text in the -13, which talks about "user credentials and any tokens
obtained using these user credentials".  Splitting that apart, I assume
"user credentials" is a password or analogue, and the "tokens" are, well,
the OAuth/OIDC tokens this document uses.  My (admittedly not perfect)
understanding of analogous cases in stock OAuth is that for a browser-based
SPA the browser gets redirected to an IdP where the user enters credentials
to authenticate, and is returned to the SPA along with the token(s).  So in
that case the SPA has the tokens but not the user credentials.

Your paragraph quoted above seems to imply that the browser-based UAC would
not have the tokens, either?  But then how would anything work?
>      Furthermore,

Okay, thanks.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Apr 2020 10:35:48 -0700

> RFC 3261 allows multiple Proxy-Authorization header fields.

Ah, thanks.

> I think it is clear from Section 22.3 (and the example in Section 20.28) in RFC 3261 that the "realm" is included in the Proxy-Authorization header field.

So it is, thanks for the pointer and sorry for having missed it.

> If we think 7235 and/or 3261 needs to be improved regarding that I think it is a separate task, outside the scope of this document.

Okay; in light of the above I don't see a pressing need to do anything in
this document.

Thanks,

Ben

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 27 Apr 2020 13:48:26 -0400

On Mon, Apr 27, 2020 at 1:32 PM Benjamin Kaduk <[email-masked]> wrote:

> >      The "Bearer" authentication challenge includes the address (or
> name?) of
> >      an
> >      places in the document (noted in the COMMENT section).  Our
> experience
> >      in
> >      believe that the same is true for the SIP usage, and we should
> mention
> >      this
> >      requirement explicitly.
> >
> >      necessary protections for *user* credentials (though they are of
> course
> >      not

What you described above is what happens with an SPA *without *a backend
server.
The case I am thinking about is for an SPA *with *a backend server, which
would be the SIP registrar in this case.
So, the SPA obtains a code form the AS, sends it to the registrar, which
exchanges that with the AS to obtain access token that enables the
registration and potentially access to down stream services.

But all of this really out of scope for this document, and all I was trying
to do is differentiate what we have covered in the document from this use
case.
If this is confusing and not helping, I do not mind removing this section
completely.

Regards,
 Rifaat

> >      here?  (That is to say, I almost didn't find where it was even
> defined
> >      as
> >      possible to do so...)
> >
> >      a refresh token to be issued, or just have some editorial tweaks to
> make
> >      to

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Apr 2020 06:57:08 +0000

Hi,

>>>      necessary protections for *user* credentials (though they are of course
>>>      not guaranteed to do so), which leaves me unclear on what the intended
> What you described above is what happens with an SPA without a backend server.
> The case I am thinking about is for an SPA with a backend server, which would be
> the SIP registrar in this case. So, the SPA obtains a code form the AS, sends it to the
> registrar, which exchanges that with the AS to obtain access token that enables the
> But all of this really out of scope for this document, and all I was trying to do is differentiate
> what we have covered in the document from this use case.
>If this is confusing and not helping, I do not mind removing this section completely.

What about replacing the current text in Section 1.2 with the following:

---

1.2.  Applicability

   This document covers cases where grants that allow the UAC to obtain an
   access token from the AS are used. Cases where the UAC is not able to obtain
   an access token (e.g., in the case of an authorization code grant) are not covered.

---

Regards,

Christer