Subject: RE: [Sip] RFC3261 and authenticating PROXIES to other proxies & U AS - 2 possible solutions

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 19 Apr 2004 18:45:09 -0400

I have some (lengthy) comments on this.

First of all, "authenticating that a call has been transmitted by a proxy
that the headers claimed transmitted it" is an aspect of a relatively
familiar SIP problem called the "request history" problem. It is difficult
to discuss this issue, or any solutions to it, outside of the long
back-story of request history and middle-to-middle security. Please see Mary
Barnes' work on the subject, especially her requirements and solutions
drafts (some references are at the end of this mail).

For the very simple SIP trapezoid case you describe below, there is of
course a solution provided in RFC3261, specifically in 26.3.2.2: P1 and P2
would use mutual TLS to authenticate one another. In that fashion, P2 would
have the necessary assurance that "the call came from P1", as your
requirements below state. P1 is happy if the call came from the UAC, P2 is
happy if it came from P1, and the UAS is happy if it came from P2 - we call
all of this collective happiness "transitive trust". And unlike your
solutions, it does not require that P1 and P2 exchange any keying
information with one another. So why isn't 26.3.2.2 sufficient to solve all
request history problems? Because sometimes transitive trust is
insufficient. Request history also takes into account cases where the UAS,
for example, would want to have a direct cryptographic assurance that P1
handled the call, rather than just being content to know that P2 forwarded
it.

So, if you're content with the simple transitive trust case, there's a
solution for you already in RFC3261 - transitive trust and mutual TLS
between P1 and P2. If you require something stronger than transitive trust,
we've landed ourselves in request history / m2m territory.

Now, specifically speaking to your solutions: the first one, as this thread
noted earlier, suffers from a transaction-matching problem. In a nutshell,
the problem is this: if the proxy server resubmits the INVITE (adding a
Proxy-Authorization) with a new CSeq, then the UAC will reject the final
response from the UAS since it is out of sequence (vide RFC3261 22.3). So
why shouldn't P1 just resubmit the INVITE with the old CSeq and a
Proxy-Authorization header? Well, for the sake of argument, let's say it
could (although I remain a little nervous that implementation snafus with P2
matching nonces/transactions/branches/CSeqs could arise, since RFC3261 says
that the resubmitted INVITE will arrive on a new CSeq).

This approach suffers from the general problem of conflating the semantics
of two distinct operations. Suppose that P1 resubmits the INVITE with
credentials that are not accepted by P2, for whatever reason? How is the UAC
going to understand that situation when the call fails? Also, shouldn't the
UAC have its own opportunity to supply credentials to P2? If the user of the
UAC has their own account/relationship with P2, they might want to rely on
that rather than on allowing P1 to assert its own credentials - P1 is
essentially interposing in the challenge. Essentially, by allowing P1 to
consume the 407, you are proposing a change to the security semantics of the
Digest mechanism. If I'm operating a proxy server, and I send a 407, I
expect that the UAC will handle it and resubmit. I can imagine various
scenarios in which I'd be unhappy if that challenge were intercepted and
answered by a proxy server. If we did want to do something like this, I
imagine we'd want a specific mechanism (new response code, or something)
that makes it unambiguous that P2 intends to challenge P1 - see the m2m
work.

Moreover, there is a security concern here. The HTTP Digest authentication
mechanism uses the concept of 'realms' (as has previously been discussed in
this thread). In order to prevent a malicious proxy server from
impersonating a realm (i.e., P3 spoofs, with its own nonces and so on, a
challenge from P2 asserting the realm of P2, in an attempt to capture or
interrupt authentication for P2's realm), realms must be correlated with
certificate-based security. In fact, the recommendations in RFC3261
specifically state that the Digest realm should be identical to the
subjectAltName in the certificate of the issuing proxy server - if they are
not, there's always a potential for a security concern (26.3.2 passim).
Accordingly, the establishment of a TLS connection (and the resulting
certificate exchange) is more or less a prerequisite for the secure use of
HTTP Digest. But of course, in your case, if certificates are exchanged, the
use of HTTP Digest is entirely superfluous - you don't really care about the
usernames/passwords, you just want to know which proxy server is forwarding
the request. You'll get that information from TLS anyway. So using HTTP
Digest without TLS is insecure, using it with TLS is superfluous.

In short, my recommendation would be just to use mutual TLS.

Regarding your second proposed solution, I think the n-squared problem of
distributing and managing shared secrets for MD5 hashes in Via headers is
intractable. For one thing, it requires you (as P1, say) to be able to
anticipate ALL of the proxy servers/UASes to which your request might be
forwarded, and to include suitable MD5 hashes for each. But the problem is,
a proxy in the position of P1 simply doesn't know where their request is
going to be forwarded. Sure, they know it is going to P2, but what if P2
forwards the request to P3 (because all of its UASes are overloaded, or
something)? How is P1 supposed to know that it needs to insert a vauth
parameter that will be verifiable by P3? Moreover, why on earth would P1
have exchanged a shared secret to every possible destination to which its
requests could be forwarded? The fact that proxy servers are not psychic
makes this extremely problematic. Moreover, since it is not a
challenge-response system, it has extreme forgeability/replay problems.
While the 'vauthexpire' parameter is obviously intended to mitigate the
replay issue, as written, it is impracticable (i.e. messages containing it
are silently discarded if vauthexpire is unsupported or invalid).

And finally, as you hint, a malicious proxy server or man-in-the-middle
could just strip this vauth parameter anyway. But of course, the only reason
to have this parameter is because you don't trust the Via headers in the
first place. And why don't you trust the Via headers? Because a malicious
proxy server or man-in-the-middle could just strip or modify Via headers. So
how exactly has the vauth parameter improved our situation? You don't trust
an intermediary to keep leave the meat of the Via headers untouched, but you
do trust them to leave vauth untouched? Mutual TLS between proxy servers
prevents interceptors between the proxies from modifying signaling, but if
the proxies are misbehaving, you're in the same boat with or without vauth.
Might as well just use SIPS and mutual TLS to protect your Vias, or do
something like request history and/or m2m.

Earlier in the request history work, there were a number of proposed
via-signing solutions along the lines of your second solution. I don't think
an MD5-based Via header parameter is a profitable line of inquiry into this
problem. I'd suggest contributing to the request history work if you're
interested in some of the possible alternatives. Today, the mature form of
that work is in:

http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt

You might also be interested inb the work on middle-to-middle security in:

http://www.ietf.org/internet-drafts/draft-barnes-sipping-sec-inserted-info-0
1.txt

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Alex Bligh [mailto:[email-masked]]
> Sent: Thursday, April 08, 2004 5:49 AM
> To: [email-masked]
> Cc: Alex Bligh
> Subject: [Sip] RFC3261 and authenticating PROXIES to other 
> proxies & UAS
> - 2 possible solutions
> 
> 
> I am still trying to work out how one might authenticate that a call has
> been transmitted by a proxy that the headers claimed transmitted it. SIP
> provides facilities (in protocol) for proxies and UAS's to determine that
a
> call originated at a UAC with credentials, but no manner of determining
> whether the call passed through a proxy with credentials. Whilst in some
> circumstances this can be handled with network layer or transport layer
> security, (a) this requires support on a hop by hop basis from the proxy
> downstream, (b) the overhead may be substantial, and (c) it is somewhat
> inconsistent that SIP supports this type of authentication 
> for the UAC but
> not proxies.
> 
> I've come up with 2 mechanisms to provide the support - one I posted
> earlier (which requires only a change on the proxy with 
> credentials) and
> goes into the "Despite being against RFC3261, I can't see 
> what this would
> break" category, and the second (which requires a change both 
> at the proxy
> supplying credentials and at the server authenticating them) certainly
> breaks nothing, but is less functional.
> 
> I'd appreciate comments, particularly on what the first 
> mechanism breaks.
> I (now) know that it is (today) against various bits of RFC3261. But I
> cannot see what in practice it would break. And as a couple of people
> (on and off list) have pointed out, it would be very useful (even for
> reasons I hadn't thought of).
> 
> BACKGROUND
> ==========
> 
> The (general) problem I am trying to solve looks like this:
> 
> 
>    UAC <-----/\/\/\/\/---> P1 <--/\/--> P2 <---> UAS => PSTN
>   (CPE)                 (proxy)      (proxy)  (media
>                                               gateway)
> 
> P2 may or may not be present.
> 
> Let us assume UAC and P1 are very distant, and P1 & either P2 
> or UAS are
> sufficiently distant that host security is impractical 
> without adding some
> additional layer (ipsec, tls etc.).
> 
> UAC is CPE on a site of a customer of SP1, who operates P1. 
> UAS is a media
> gateway, and P2 a (possibly) intervening proxy, operated by SP2.
> 
> Let us further assume that UAC registers to P1, and that P1 
> has already
> authenticated UAC, and that any INVITE passed through P1 has 
> already been
> authenticated as coming from UAC and been authorized by P1 
> according to
> SP1's local policy, prior to being forwarded to P2.
> 
> Let us further assume that it is the local policy of SP1 that any such
> authorized calls it passes to SP2 would be authorized by SP1. So for
> instance SP2 is a VoIP termination provider, and SP1 a VoIP service
> provider.
> 
> SP2 wishes to authenticate & authorize calls made to UAS. It 
> uses some form
> of authentication. What it in essence is trying to 
> authenticate is that the
> call actually came from P1, not that the call actually came 
> from UAC. This
> could either be done at P2, or at UAS.
> 
> I have two mechanisms of doing this
> 
> MECHANISM (AB)USING HTTP DIGEST AUTHENTICATION
> ==============================================
> 
> As per previous email, (ab)use HTTP digest authentication so
> that the proxy retries the Invite with the same CSeq but with
> a different branch parameter. This seems to me indistinguishable
> from a spiraling scenario where the proxy concerned happens to
> call the same Request-URI twice but other information in the message
> header (in this case authentication) that may be used to route the
> call has changed.
> 
> As such, I can't see what it would break, and it has the major
> advantage it works with all existing (challenging) UA's & proxies,
> and that being challenge-response, it is more secure than
> other mechanisms.
> 
> But, for the sake of argument
> 
> ALTERNATIVE MECHANISM USING vauth Via-Parameter
> ===============================================
> 
> This mechanism introduces a new Via Parameter (vauth).
> 
> A UAC or Proxy inserting a Via Header with a RFC3261 compliant branch
> parameter MAY introduce one or vauth parameter into the Via 
> header, in each
> case to identify authenticate the via header to one or more downstream
> proxies or UAS's. Such UAS's or proxies MAY use a vauth header to take
> local-policy dependent routing or access decisions. A UAC or 
> Proxy which
> does not insert a Via Header with a RFC3261 compliant branch 
> parameter MUST
> NOT insert any vauth parameters.
> 
> The vauth parameter is intended to allow a server to 
> authenticate a subset
> of the Via: header (being the sent-by entry and the branch 
> token), together
> with an opaque string, to downstream servers. Multiple vauth 
> parameters MAY
> be used in order to support multiple realms of 
> authentication. The vauth
> parameter supports extensible mechanisms of authentication, but the
> mechanism specified herein is MD5 authentication using a 
> shared secret.
> The mechanism of exchange of the shared secret and 
> authentication realm
> is outside the scope of this document.
> 
> The vauthid field specifies the realm of authentication. The 
> vauthid field
> MUST be unique across instances if the vauth parameter in a 
> single Via:
> header. Those specifying vauth fields SHOULD ensure that they 
> are globally
> unique, for example a domain name MAY be used.
> 
> The vauthopaque field is an opaque field intended to pass 
> information to
> servers in the authentication realm which MAY be used to 
> influence their
> routing decisions - for instance it might be used to specify 
> that access
> should be permitted or denied, or have an accounting function.
> 
> The vauthmeth field specifies the mechanism of 
> authentication. The only
> currently defined method of authentication is MD5. In this 
> mechanism, the
> vauthmd5data field contains a hash of the sent-by field, the branch
> parameter (which is, by RFC3261 unique across time and 
> space), the vauthid
> field, the vauthopaque field, the vauthexpire field (if any), and the
> shared secret, which should be a string of printable 
> characters no more
> than 64 octets in length. The hash is calculated using MD5 
> (RFC 1321 [35]),
> expressed in hexadecimal.
> 
> The optional vauthexpire field is a date in the SIP date 
> format (i.e. the
> preferred RFC1123 format) after which it should be assumed that the
> header is not authentic. If a vauthexpire field is inserted, 
> the server
> MUST be synchronized to an accurate time source, and the expiry time
> MUST be no shorter than 32 seconds beyond the time at which the Via:
> header is to be transmitted.
> 
> A server MAY check the authenticity of a Via: header using 
> vauth parameters
> by performing each of the following checks:
> 
> 1. Isolate the vauth field(s) corresponding to a realm for which the
>    checking server possesses a shared secret.
> 
> 2. If vauthexpire is present: if the checking server does not support
>    vauthexpire, it MUST silently discard the request. If the checking
>    server does support vauthexpire, it MUST check that the current
>    time is not beyond the expiry time, and if it is, it MUST
>    silently discard the request, else proceed.
>    The silent discards are used to ensure that excessive
>    transmission delays result only in the symptoms of packet loss,
>    rather than false authentication refusals.
> 
> 3. The server MUST recalculate the hash value and check whether
>    it corresponds to the hash value in the vauthmd5data field.
> 
> 4. The result of (3), the vauthopaque field, and the presence or
>    absence of a vauthexpire field, MAY then be used
>    to influence routing decisions
> 
> The vauth mechnanism is primarily designed to protect against spoofing
> attacks, as the shared secret will not be known. It provides 
> only limited
> protection against replay attacks, in that replays are 
> time-limited by the
> vauth-expire header. Further limitation of replay attacks can 
> be given by
> the implementor using the vauthopaque field - for instance in an
> environment where the Request-URI is known not to change 
> between the server
> inserting the Via header and the server checking it, the 
> vauthopaque field
> could be set to contain a hash of the Request-URI, which 
> could be checked
> upon receipt. Further, it should be noted that mechanism provides no
> protection against malicious or accidental modification of the message
> between transmission by the server inserting the Via: header 
> and the server
> analyzing it. It is not intended as a substitute for network 
> or transport
> layer security.
> 
> An example of a Via: header with vauth parameters follows:
> Via: SIP/2/0/UDP 4.3.2.1:5060 branch=1fe452.12;
>  
> vauth="server.example.com:5061,y,MD5=1234567890abcdef123456789
> 0abcdef";
>  
> vauth="server2.example.com:5060,,MD5=fedcba0987654321fedcba098
> 7654321:Fri, 
> 13 Oct 1998 23:50:00 GMT"
> 
> RFC3261 specifies:
> 
>     via-params        =  via-ttl / via-maddr
>                          / via-received / via-branch
>                          / via-extension
>     via-extension     =  generic-param
>     generic-param     =  token [ EQUAL gen-value ]
>     gen-value         =  token / host / quoted-string
>     token             =  1*(alphanum / "-" / "." / "!" / "%" / "*"
>                         / "_" / "+" / "`" / "'" / "~" )
> 
> This document introduces a new via-param which matches the 
> generic-param
> model:
> 
>     via-params        =  via-ttl / via-maddr
>                          / via-received / via-branch
>                          / via-vauth ; new
>                          / via-extension
>     via-vauth         =  "vauth" EQUAL vauth
>     vauth             = LTQUOT vauthid COMMA vauthopaque
>                         COMMA vauthmeth [ COLON vauthexpire ]RDQUOT
>     vauthid           = vauthstr
>     vauthopaque       = [ vauthstr ]
>     vauthexpire       = SIP-date
>     vauthstr          = 1*(alphanum / "-" / "." / "/" / ":" / "_" /
>                         "[" / "]")
>     vauthmeth         = vauthmeth-md5 / vauthmeth-ext
>     vauthmeth-ext     = vauthextension EQUAL vauthextdata
>     vauthextension    = 1*(alphanum)
>     vauthextdat       = 1*(alphanum)
>     vauthmeth-md5     = vauthmmd5 EQUAL vauthmd5data
>     vauthmmd5         = "MD5"
>     vauthmd5data      = 32LHEX
> 
> 
> Alex
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Michael Thomas <[email-masked]>
Date: Mon, 19 Apr 2004 16:19:49 -0700 (PDT)

> Digest without TLS is insecure, using it with TLS is superfluous.

   I can think of a pretty trivial example, I think,
   that breaks this assumption. Suppose that I'm at
   a public kiosk UAC and want to read my voice mail
   back at mega.corprahome.com. The UAC would use TLS
   and cert based credentials to the first hop proxy,
   but my home proxie or UAS is going to want to see
   _my_ (as in [email-masked]'s) credentials, not
   the UAC's. And telling me personally that I
   have to, well, use x.509 credentials is going
   to be something of a problem as I can barely
   remember a half way decent password, let alone
   ~2k characters of credentials.

   So it seems fairly obvious to me that you'd
   want to use x.509 credentials if you can, but
   the real world sez that they're not always
   going to be feasible, so you're really to have
   to deal with e2m, m2m, and e2e symmetric key
   credentials for... anything you can envision
   using asymmetric key credentials. In that case,
   TLS is providing a useful service (keeping
   outsiders of the conversation out), but doesn't
   really solve a pretty important case.

		Mike

---

From: Alex Bligh <[email-masked]>
Date: Tue, 20 Apr 2004 09:44:33 +0100

Jon,

Thanks for your mail. There are several things I will have to think
further about in it, but here are some comments on bits of it:

> would use mutual TLS to authenticate one another. In that fashion, P2
> would have the necessary assurance that "the call came from P1", as your
> happy if it came from P1, and the UAS is happy if it came from P2 - we
> call all of this collective happiness "transitive trust". And unlike your
> information with one another.

TLS is neither a necessary nor sufficient solution, I think. Here are
some reasons.
a) In the trapezoid, it does not cover the situation where UAS wants
   to authenticate P1 (possibly against injection at P2), or where a
   third proxy P3 wants to authenticate P1. This is because TLS is
   essentially hop-by-hop. A further consequence of this is we need to
   TLS secure every possible hop between authenticator and authenticatee,
   which presupposes we know each possible route packets may take in
   advance. Certainly in the trapezoid illustration I presented, that
   is true, but I think it would be a mistake to assume hop-by-hop
   security is per-se equivalent to middle-to-middle security (or,
   in the case of UAS, end-to-middle security). This is precisely
   because we may not always be able to rely on hop-wise transitive
   trust.
b) You say P1 and P2 don't exchange any keying information; I think
   that's not entirely true. They do exchange keying, just at the TLS
   layer.
c) Using TLS requires it to be supported and switched on. Whilst this
   may well be a "good thing", there are plenty of instances in
   where it currently is unsupported, and plenty of instances in
   applications crossing administrative domains where turning it on
   is not necessarily simple. It also requires certification which
   may be a too heavyweight solution. We allow non-TLS digest
   authentication under 3261 providing the UAC is providing the
   credentials (misusing the terminology start-to-middle auth) -
   my argument is not to replace TLS, simply that the same mechanism
   could be used for middle-to-middle and middle-to-end.

> So why isn't 26.3.2.2 sufficient to solve
> all request history problems? Because sometimes transitive trust is

I think the request-history stuff (which I have only briefly read) is
trying to solve a slightly different problem; it seems to be more about the
ability for a downstream node to be able to determine how and why a request
reached it. In the problem space I'm looking out, the downstream node (P2
or UAS) does not care how the request reached it, merely that it has passed
through P1. Further, it's eminently possible that any credential challenge
it seeks to make may be dependent on routing information available to P2
only when the packet arrives - for instance some URIs might be billable,
and some not billable. As request-history doesn't give P2 the mechanism to
challenge P1, this would seem to require P1 either giving P2 "free reign",
or having a complete understanding of P2's own authentication rules.

> Now, specifically speaking to your solutions: the first one, as this
> thread noted earlier, suffers from a transaction-matching problem. In a
> nutshell, the problem is this: if the proxy server resubmits the INVITE
> (adding a Proxy-Authorization) with a new CSeq, then the UAC will reject
> the final response from the UAS since it is out of sequence (vide RFC3261
> 22.3).

To be clear, I am advocating resubmitting with the same CSeq and a different
branch ID.

> So why shouldn't P1 just resubmit the INVITE with the old CSeq and
> a Proxy-Authorization header? Well, for the sake of argument, let's say it
> could (although I remain a little nervous that implementation snafus with
> P2 matching nonces/transactions/branches/CSeqs could arise, since RFC3261
> says that the resubmitted INVITE will arrive on a new CSeq).
>
> credentials that are not accepted by P2, for whatever reason? How is the
> UAC going to understand that situation when the call fails?

When P1 resubmits the invite, P2 will respond with a further 407. Just as a
UAC can distinguish the "first" 407 (when it needs to add credentials, or
notes the nonce has expired) from a subsequent 407, so can P1, using the
same mechanism. On receipt of a second 407, P1 sends a 4xx upstream to the
UAC saying "call failed" - doesn't much matter which 4xx code so long as it
isn't 407 etc.; alternatively it can reroute just as it might if it
received a 404 (say) from P2. What it isn't to do is pass the 407
straight to UAC (as it will then seek credentials etc.)

> Also,
> shouldn't the UAC have its own opportunity to supply credentials to P2?
> If the user of the UAC has their own account/relationship with P2, they
> might want to rely on that rather than on allowing P1 to assert its own
> credentials - P1 is essentially interposing in the challenge.

This, it seems to me, is a policy decision for P1 and P2. P2 sees the
packet purports to come via P1 (it is unimportant for this purpose whether
it actually comes via P1), and thus use a realm identifier that P1 matches,
on the basis that P1 has asked that /it/ supply credentials to P2. If
the packet does not purport to come via P1, P2 might use a different
realm. I fail to see a useful application where P2 wishes first
to challenge P1, and then P1. I'm not saying there is no such case,
and to the extent there is, it is a limitation of this mechanism.

> Essentially, by allowing P1 to consume the 407, you are proposing a
> change to the security semantics of the Digest mechanism. If I'm
> operating a proxy server, and I send a 407, I expect that the UAC will
> handle it and resubmit. I can imagine various scenarios in which I'd be
> unhappy if that challenge were intercepted and answered by a proxy
> server.

I don't understand why. You may well be "unhappy" about it, but it
doesn't weaken security any putting it in the standard, as people
can do this /now/ (in apparent breach of the RFC). IE as P2 you already
have to cope with the situation that people might attempt to
intercept and reply to an upstream challenge. Note the intercept
will be unsuccessful unless the interceptor has valid credentials.
So if you don't like it, don't give credentials to those "in the
middle". Perhaps I am missing the point here.

> If we did want to do something like this, I imagine we'd want a
> specific mechanism (new response code, or something) that makes it
> unambiguous that P2 intends to challenge P1 - see the m2m work.

That's what I am trying to /avoid/. Take an extended trapezoid
UAC ... P1 ... P2 ... P3 ... P4 ... UAS, and let's say P4 or UAS is
performing the challenge. P3 is in the same administrative domain
as P4 & UAS. P4/UAS may not know whether it's P1, or P2 that is
going to authenticate the request. And moreover, it may not care.
All it cares is that /someone/ has authenticated the request.

If you are suggesting that there should be some additional field
in the Authorization: header, which P1 (etc.) must fill in indicating
that it is the one providing the credentials, then (provided it
isn't going to break existing challengers) that seems like a good
idea, as it will allow those challengers to discard such responses
if they want.

> mechanism uses the concept of 'realms' (as has previously been discussed
> in this thread). In order to prevent a malicious proxy server from
> certificate-based security.

Perhaps I am missing something here, but doesn't this problem
exist to EXACTLY the same extent whether credentials are supplied
to P2 by P1 (as suggested), or by UAC (as per the existing standard).
IE yes, it exists, but no, the proposal doesn't make it any worse.

Moreover, they both can be solved to the same extent in the same
manner.

> In fact, the recommendations in RFC3261
> subjectAltName in the certificate of the issuing proxy server - if they
> are not, there's always a potential for a security concern (26.3.2
> passim). Accordingly, the establishment of a TLS connection (and the
> resulting certificate exchange) is more or less a prerequisite for the
> secure use of HTTP Digest.

... (depending on which aspect of security you are concerned about),
yes, but equally so for conventional challenges and the challenges
I suggest.

However, unless I'm mistaken, even TLS doesn't solve everything:

   D1 :     D2A    :   D3  :    D4
      :            :       :
    --:--P1-----P2-:---P3--:--P4----P5--
   /  :            :   |   :            \
UAC   :............:   |   :             UAS
   \  :            :  /
    --:--P11---P12-:-/
      :            :
      :     D2B    :

Let's assume D1, D2A, D2B, D3, D4 are different administrative domains.
Suppose P5 challenges UAC. TLS on each hop will prevent an attack
from an arbitrary P99, but it won't (as far as I can see) prevent
(say) P2, P3 impersonating P5's realm, unless UAC has some
direct certificate exchange with P5.

And that's no greater and no lesser a problem than if P5 is challenging P1
(as I suggest), and or P5 challenging UAC.

> But of course, in your case, if certificates
> are exchanged, the use of HTTP Digest is entirely superfluous - you don't
> really care about the usernames/passwords, you just want to know which
> proxy server is forwarding the request.

No, that's not true - possibly that impression has been given by me
being less than clear. Using the above extended trapezoid, P5 wants
to know an administrative domain with whom it has a trust relationship
authorizes the routing. That might be (say) any one of P1..P2 or
their redundant siblings. So it wants to know someone from D2A
authenticated the transaction. It does indeed care about the username
(which identifies it came from D2A, as opposed to D2B). And it cares
about the password too, as that authenticates it comes from D2A as
opposed to D2B.

> You'll get that information from
> TLS anyway. So using HTTP Digest without TLS is insecure, using it with
> TLS is superfluous.

Only if it is the immediately preceding hop (unless I've missed something)

> In short, my recommendation would be just to use mutual TLS.

I am not denying that TLS is helpful - I think it's orthogonal to
the problem though, just as TLS does not replace the existing digest
authentication but is best used in parallel with it.

> Regarding your second proposed solution,

It's (the vauth header stuff) is clearly inferior to the first, and if the
request-history stuff can be authenticated, it's largely pointless. But for
the same reasons I identify above, I don't think even an authenticated
request-history solves the problems I am talking about.

Alex