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

[Paul Kyzivat <[e-mail]>]

On 4/26/20 11:58 AM, Rifaat Shekh-Yusef wrote:
> Paul,
> 
> What you described is the theory; have you seen this deployed in practice?

Its just theory. But the specs should cover all the theoretical cases.

	Thanks,
	Paul

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