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

[Paul Kyzivat <[e-mail]>]

On 4/26/20 3:22 PM, Rifaat Shekh-Yusef wrote:
> Why should we do that?
> Why can't we just acknowledge that this was a nice idea in theory that 
> never materialized in practice because they was never a need for it?
> Why can't this document explicitly state that this theoretical case is 
> *not *cover and move on to do something more useful that people actually 
> care about?

I didn't say what we should do about it. I was just explaining the use case.

I generally agree that this document isn't the place to discuss such 
cases. (Especially since the case I describe doesn't even involve 
multiple schemes, and is scheme independent, so it is nothing that this 
document impacts.)

This is something that is implicit in 3261, and something that 
implementors ought to support as a matter of course. Somebody can argue 
that it isn't used and so shouldn't have to be supported. If so, then 
there is a need to define exactly what *should* be supported. But again, 
this isn't the right document for that.

	Thanks,
	Paul

> Regards,
>   Rifaat
> 
> 
> On Sun, Apr 26, 2020 at 2:54 PM Paul Kyzivat <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     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]>
>      > <mailto:[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]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      > https://www.ietf.org/mailman/listinfo/sipcore
>      >
>