Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply

[Christer Holmberg <[e-mail]>]

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 <[e-mail]> on behalf of Rifaat Shekh-Yusef <[e-mail]>
Date: Sunday, 26 April 2020 at 18.59
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply

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 <[e-mail]<mailto:[e-mail]>> wrote:
On 4/25/20 7:27 PM, Christer Holmberg 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.

* 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

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