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

[Christer Holmberg <[e-mail]>]

Hi Paul,

Regarding (1), you commented on that earlier, and we included the following text (updates 3261):

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

Regarding (2), (3) and (4), I am not sure whether the protocol needs to explicitly forbid those scenarios. A network designer can always mess up things - without breaking the protocol. Perhaps it would be useful to put together a BCP regarding SIP authentication, but it is outside the scope of THIS draft.

So, can we now move the draft forward?

Regards,

Christer
 


On 15/01/2020, 22.13, "sipcore on behalf of Paul Kyzivat" <[e-mail] on behalf of [e-mail]> wrote:

    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
    > 
    
    _______________________________________________
    sipcore mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/sipcore