Re: [sipcore] draft-ietf-sipcore-sip-token-authnz-07.txt broader issues

[Paul Kyzivat <[e-mail]>]

While reviewing this new version I began to wonder if the general 
procedures for authentication in sip are sufficiently clear and 
unambiguous. This isn't strictly an issue for this draft, but because 
this draft introduces a new authentication scheme along side digest it 
has the potential to aggravate thee issues. ISTM that without answers to 
these issues it will be difficult to deploy this new token authnz draft. 
But that draft may not be the appropriate place to answer them. I'd like 
to hear what others here think is the proper way to deal with this.

My general issue is what to do when, while trying to send a request, a 
UAC receives authorization challenges for multiple schemes and/or 
multiple realms. This can potentially occur in a single 401 response, a 
single 407 response, or some combination of 407 and 401 responses.

Note that a forking proxy may aggregate 401 and 407 responses from 
multiple forks and pass the multiple WWW-Authenticate and 
Proxy-Authenticate responses back to the UAC. How the UAC deals with 
this is also at issue.

Also, if there are multiple authenticating proxies on an unforked path 
from UAC to UAS, then the UAC will receive the challenges one at a time. 
The request will only reach a subsequent proxy after the request is sent 
with adequate credentials for every early proxy in the change. Note that 
this means that the UAC must remember to include the credentials from 
earlier challenges when retrying after a subsequent challenge because 
that subsequent challenge won't include the earlier challenges.

(1) is it valid for a single UAS or proxy to issue concurrent challenges 
specifying differing schemes? I believe it is or should be.

(2) is it valid for a single UAS or proxy to issue concurrent challenges 
on its own behalf specifying differing realms? I'm not sure if this 
makes sense or not. (This is distinct from a forking proxy aggregating 
downstream challenges.)

(3) If a UAS or proxy does issue concurrent challenges specifying 
differing schemes, how is the UAC expected to successfully respond? Is 
the UAC expected to respond with credentials for *each* scheme, or is it 
sufficient to respond to one of them? I am inclined to think that the 
different schemes should be considered alternatives, so that it is 
sufficient to respond to one of them. At least in the case where they 
are for the same realm. It may be more confusing if they are for 
differing realms.

(4) If multiple UASs and/or proxies claim the same realm then are they 
expected to accept the same credentials? I think this must be so, else 
the user and UAC won't be able to sort out what credential to use for a 
given challenge.

Generally, ISTM that the UAC should group challenges by realm, 
attempting to obtain a single set of credentials for each realm. If 
there is more than one realm mentioned in the response, then it should 
obtain a set of credentials for each. And then, if there 407 responses 
to prior attempts to send this same request then the credentials chosen 
for them should also be included in this retry.

What do others think about this? Do you think this is sufficiently 
specified in existing RFCs? If so, can you explain this?

	Thanks,
	Paul

On 1/15/20 12:42 PM, Rifaat Shekh-Yusef wrote:
> All,
> 
> We have just submitted a new version of the document that hopefully 
> addresses all the comments received so far.
> Please, take a look and let us know what you think.
> 
> Regards,
>   Rifaat
> 
> 
> On Wed, Jan 15, 2020 at 12:40 PM <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
> 
>     A New Internet-Draft is available from the on-line Internet-Drafts
>     directories.
>     This draft is a work item of the Session Initiation Protocol Core WG
>     of the IETF.
> 
>              Title           : Third-Party Token-based Authentication
>     and Authorization for Session Initiation Protocol (SIP)
>              Authors         : Rifaat Shekh-Yusef
>                                Christer Holmberg
>                                Victor Pascual
>              Filename        : draft-ietf-sipcore-sip-token-authnz-07.txt
>              Pages           : 14
>              Date            : 2020-01-15
> 
>     Abstract:
>         This document defines a SIP mechanism that relies on the OAuth 2.0
>         and OpenID Connect Core 1.0 to enable delegation of the user
>         authentication and SIP registration authorization to a third-party.
>         The document updates RFC 3261.
> 
> 
>     The IETF datatracker status page for this draft is:
>     https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/
> 
>     There are also htmlized versions available at:
>     https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-07
>     https://datatracker.ietf..org/doc/html/draft-ietf-sipcore-sip-token-authnz-07
>     <https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-07>
> 
>     A diff from the previous version is available at:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-07
> 
> 
>     Please note that it may take a couple of minutes from the time of
>     submission
>     until the htmlized version and diff are available at tools.ietf.org
>     <http://tools.ietf.org>.
> 
>     Internet-Drafts are also available by anonymous FTP at:
>     ftp://ftp.ietf.org/internet-drafts/
> 
>     _______________________________________________
>     sipcore mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/sipcore
> 
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>