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

[Paul Kyzivat <[e-mail]>]

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.

>> 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?

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?

> 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?

>> 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. For a given request a challenge only 
has one realm. I guess it would be possible for a UAS to put multiple 
challenges, with different realms, in its response, but I find that 
unlikely. 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.

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.

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

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

This is further motivation for the sort of framework document I just 
proposed in another reply.

	Thanks,
	Paul

> There is work witht OpenID Connect Federations that I haven’t started to look at yet.
> 
> Cheers,
> /O
> 
>