Re: [sipcore] draft-ietf-sipcore-sip-token-authnz-02 - www and/or proxy auth

["Olle E. Johansson" <[e-mail]>]

> On 11 Jul 2019, at 16:09, Paul Kyzivat <[e-mail]> wrote:
> 
> On 7/11/19 3:40 AM, Olle E. Johansson wrote:
>>> On 10 Jul 2019, at 17:39, Paul Kyzivat <[e-mail]> wrote:
>>> 
>>> Ollie,
>>> 
>>> On 7/10/19 9:21 AM, Olle E. Johansson wrote:
>>>> Why was proxy auth deemed out of scope for this document?
>>> 
>>> Are you aware of any deployed uses of Proxy-Authenticate? I have never heard of any.
>> We do support it in both Asterisk and Kamailio. All my Kamailio installations during the years
>> use WWW auth for the registrar and proxy auth for calls.
>> I do notice however that realm-based authentication with many challenges in the same
>> transaction is not widely supported, like your example below.
> 
> I would be shocked if it was well supported given how ill-defined it is.
:-)
I think another reason is that Internet federated SIP did never take off… So you’re locked into one service platform on a private network.

> 
>>> IMO Proxy-Authenticate is underspecified, at least for some obscure cases. Consider:
>>> 
>>> - Alice sends a request
>>> - It is challenged (Proxy-Authenticate) by P1
>>> - Alice resends with credentials for P1
>>> - P1 accepts credentials and forwards to P2
>>> - P2 challenges for a different realm
>>> - For request to succeed, Alice will now have to
>>>  resend the request with credentials for both P1 & P2
>>> 
>>> What logic should Alice use to decide what credentials to include in requests to this target, both for the immediate resend, and in future requests to the same target?
>> Well, in Asterisk chan_sip I added realm-based authentication in order to select credentials based on the realm.
> 
> Can you clarify? Do you mean that after a challenge for a realm you can look up on the key ring for matching credentials for the realm of the challenge?
In Asterisk chan_sip you can either define a global list of realms that we use for lookup or a per-service (“peer”) list. When challenged, the code first
tries to find the realm in the service definition then looks up the global list to find a matching set of credentials to use.
> 
> Or do you mean that you can preemptively select credentials by realm to be added to a request before it is challenged based on somehow deriving a realm from properties of the request?
No, magic doesn’t apply here :-)
It’s after we’ve received the auth request.

> 
>> I don’t actually remember if we ever did run tests on this at SIPit. Early SNOM phones had realm-based auth so you could enter
>> credentials per realm and your example did work with those devices.
>>> 
>>> And another one:
>>> 
>>> - Alice sends a request
>>> - It is challenged (Proxy-Authenticate) by P1
>>> - Alice resends with credentials for P1
>>> - P1 forks to P2A and P2B
>>> - Both P2A and P2B challenge, with different realms
>>> 
>>> 
>>> Now what happens? Ideally P1 would aggregate the www-authenticate from both P2A and P2B. And then Alice would gather credentials for both and include them both in a retry, along with the credentials for P1. None of this is well defined.
>> I think it’s defined, but not implemented or tested much.
> 
> Can you point me to where you think it is defined?
Paul - are you asking me to dive into the mountain of SIP documents again? :-) He he. I was checking this while helping with the updated digest auth. Let me dig a bit and come back.
I know I was thinking about receiving MULTIPLE auth headers with different checksum algorithms in addition to receiving multiple auth headers from a forking scenario. The first list
is ordered too, so a user agent may end up with a lot of work.

Found this in 3261, section 22.3

"If a request is forked (as described in Section 16.7 <https://tools.ietf.org/html/rfc3261#section-16.7>), various proxy
   servers and/or UAs may wish to challenge the UAC.  In this case, the
   forking proxy server is responsible for aggregating these challenges
   into a single response.  Each WWW-Authenticate and Proxy-Authenticate
   value received in responses to the forked request MUST be placed into
   the single response that is sent by the forking proxy to the UA; the
   ordering of these header field values is not significant.
      When a proxy server issues a challenge in response to a request,
      it will not proxy the request until the UAC has retried the
      request with valid credentials.  A forking proxy may forward a
      request simultaneously to multiple proxy servers that require
      authentication, each of which in turn will not forward the request
      until the originating UAC has authenticated itself in their
      respective realm.  If the UAC does not provide credentials for
     each challenge, the proxy servers that issued the challenges will
      not forward requests to the UA where the destination user might be
      located, and therefore, the virtues of forking are largely lost.

“
That section continues wiith additiional comments about forking.

Side note: The order will become significant…


> 
>>> I had suggested earlier that I wouldn't be too bent out of shape if this draft left that out of scope. OTOH, I would prefer that this all be well defined. Or else, if it isn't being used, then maybe Proxy-Authenticate should be deprecated.
>> That is not really “proxy auth” - you mean authentication in multiple realms in the same transaction.
> 
> I think the two are closely intertwined. If proxies don't challenge then the only challenge is from the UAS.
Right, but there are situations where you get only *ONE* proxy auth challenge too.

> For a given request a challenge only has one realm.
No, for a given request each proxy challenge has a unique realm until the new draft comes into play.

> I guess it would be possible for a UAS to put multiple challenges, with different realms, in its response, but I find that unlikely.
You can only have one WWW auth which is what a non-proxying UAS is supposed to issue. But I guess you can write code that adds a list of
proxy-auth and one www auth for different realms. 

> And if it does, then I *think* the expectation is that the UAC can choose to respond to any *one* of them and that should be sufficient.
I think we’re outside of the RFCs now, discussing implementation code…

> 
> Proxies provide another source of challenges. Of course any one attempt at the request will only get one challenge. But with Proxy-Authenticate the UAC then knows that it will have to provide a matching credential for it in a subsequent try and then still be prepared for challenges by subsequent proxies and eventually the UAS. Each of these challenges may well be a different realm.
Yep, and that’s covered by RFC 3261.

> 
>> With Oauth2/OpenID connect that would be a very very complex scenario with multiple login pages, unless we can come up with some
>> level of chain of trust between the proxys, forwarding the access token or something else that likely will never be implemented… :-)
> 
> I realize it would be complex, and probably contrived. That is why I think the notion of Proxy-Authenticate is half baked.
There is actually some work on this in the Oauth working group - trust between resource servers. I will read up on it
unless Rifaat wants to comment.
> 
>> I would suggest forwarding the token - possibly signed by the first proxy - as a way forward, stating that all proxys in the service must be in the same authentticaion federation.
> 
> I am not aware of any standards for this. Without those what you are describing is just a proprietary thing.
After reading the security update on Oauth, I realise thatt forwarding an access token is a big NO NO.  If we use the 
bearer token as outlined in the current draft we must make a MUST not forward statement on that header.
> 
> This is further motivation for the sort of framework document I just proposed in another reply.
Yes, a problem/requireiment statement would propably be a good thing. I think there was a discussion on this list and
at IETF SIPcore meetings about all this a very long time ago (as expressed by Christer) which ended up in this draft and the other draft. 
One group said that we can’t continue updating digest auth, we need something new. Another group did not object but also wanted
a quick way out of MD5, an easy upgrade for existing implementations.

/O
> 
> 	Thanks,
> 	Paul
> 
>> There is work witht OpenID Connect Federations that I haven’t started to look at yet.
>> Cheers,
>> /O
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore