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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 20 Apr 2004 16:51:34 -0400

Okay. At a high level, I understand that you don't think transitive trust
meets your requirements, because you envision situations in which there are
multiple intermediaries or in which there is a need for a security asseriton
between entities that are not directly connected to one another. In those
circumstances, I agree that mutual TLS is not sufficient. I do think that
mutual TLS is (by definition) sufficient for the (hopefully) common
trapezoid case in which P1 and P2 need to mutually authenticate one another.

I also understand that you feel request history is trying to solve a
different problem. I agree that request history is (possibly) broader than
what you want to do, but I do think it nicely encompasses the use cases and
requirements that you have articulated so far. While your note suggests that
Digest challenges from P2 could be customized in some fashion to the
particular circumstances of the transaction, that idea would need to be
flushed out a bit more before we can make any judgment about whether or not
request history cannot meet the underlying requirement. Whatever the
requirement is there, it could possibly serve as input to ongoing
considerations of the request history problem.

Finally, I remain unpersuaded that Digest authentication challenge
interception at proxies is really the right way to go, for two main reasons:

- I think you underestimate the complexity of pre-sharing symmetric keys for
proxy servers. Sharing symmetric keys works well as a deployment model for
the sorts of cases where usernames and passwords are successful today. For
monolithic servers like proxies, a PKI-based approach has a much cleaner
deployment model that does not suffer from any n-squared pre-sharing
problems. Proxy servers shouldn't have to have pre-shared keys in order to
be able to identify one another; their relationships are just too transient
and they may need to relate to way too many peers (unlike, say an end user's
relationship with a PSTN termination service).
- Challenge interception bends the semantics of the Digest authentication
system in ways that have foreseen undesirable consequences, and may have
unforeseen undesirable consequences. If we really need a way to do this, it
should be specific to challenging proxies, and not conflated with challenges
that are semantically designated for end users in RFC3261.

More details responses are below, for the truly dedicated.

Jon Peterson
NeuStar, Inc.

----

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

Well, as I said, I wasn't sure if you were satisfied with transitive trust,
or if you wanted to solve the full gamut of middle-to-middle problems. I was
trying to flush out your problem a bit. If the cases above are in your
requirements space, then I agree, TLS is not sufficient, and you need
something like request history / m2m. I also get the sense that you require
middle-to-end authentication as well.

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

I said that they do not have to pre-share their keying material with one
another. In order for Digest to work, P1 and P2 need to have shared
symmetric keys at some prior point in time. In TLS, P1 and P2 need never to
have met before in order to validate one anothers' certificates when they
are exchanged during the TLS handshake. One cannot dynamically exchange
symmetric keys in the same fashion for the purposes of Digest
authentication. In order for TLS to work, P1 and P2 only need to be in the
same PKI. There is a world of difference between the deployments for which
these alternatives are valid.

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

This argument is of the form "your mechanism isn't implemented or used very
widely, but my (purely conceptual and totally unimplemented) proposal
doesn't suffer from that problem." While it may be annoying to deploy a PKI,
I believe it is much more annoying to deploy and n-squared mesh of symmetric
keys to proxy servers, especially given the fact that it is very difficult
to anticipate which proxy servers are likely to need to have a relationship
with one another.

And again, just so there's no mistake, I'm talking about giving certificates
to proxy servers here, not end users. The issues with giving certificates to
end users are well known, and essentially insurmountable in our problem
space.

> 
> > So why isn't 26.3.2.2 sufficient to solve all request history problems? 
> 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.
<snip>

But surely you agree that solving the request history problem also solves
the problem of determining whether or not a request when through a given
proxy server - it is sufficient, if not necessary. I also pointed you to the
m2m/m2e work, which is perhaps more directly applicable. The two are pretty
inextricably linked in my mind, though.

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

Well, this is a requirement I didn't understand from your previous mails,
and one I'm still not sure I understand now. In what sense might the
credential challenge be different? Isn't the purpose of this challenge to
ascertain the identity of an intermediary? If so, that identity information
will be provided by request history. The "billability" of a URI wouldn't
impact P2's challenge in any obvious way - except perhaps insofar as it
might choose not to issue a call if the transaction has no settlement
implications, or something.

Whatever it is you mean here, it sounds like you are going beyond just
knowing that a request passed through P1 on the way to P2. If there is
additional information that P1 might provide which would be instrumental in
P2's decision, that's something that should be factored into the request
history work as well. As you noted, request history can carry additional
information that helps its consumer to make decisions.

If you mean that P2 might challenge with a different realm, or something,
see my notes on realm below. I'm not really sure what else about the
challenge P2 might change in order to elicit a different response from P1,
and realms in SIP are intended to be scoped to domain, not chosen
arbitrarily.

> >
> > 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?
>
<snip> 
> 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.)
> 

This is more or less exactly my point. P1 is shielding the UAC from the
authentication system. What if P2 wants to authenticate the UAC, not P1?
What gives P1 the right to interpose? This is why, if we want to
authenticate proxies with Digest, we should use a new, unambiguous status
code - so P1 can know whether it should consume and reply to the challenge,
or whether it should forward them back. You're conflating two semantically
distinct operations.

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

So it's a policy decision, one that can be made by any old proxy server in
the response path, whether or not the UAC should be entitled to respond to a
407 challenge? That sets a very dangerous precedent of interventionism, from
my perspective. I can imagine several cases where I personally might have an
account on P2 (say, P2 is a proxy for a PSTN termination service), but my
local proxy server, which obstinantly insists in the face of all evidence
that it has or must have an account at P2, refuses to let me answer the
challenge. The Digest tools are intended for authentication of the UAC. If
you want a tool to authenticate middlemen, then please propose something
distinct that accomplishes that function rather than conflating this with an
existing tool which does something else entirely.

But of course, once you do, you're effectively in the m2m space, and you
should be contributing to the longstanding existing work that has been done
there.

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

This is contrary to the meaning of realm as it is defined in RFC3261, which
is not as broad as the definition of realm in RFC2617.

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

"Unhappy" = my PSTN termination service might be getting revenue from a
paying customer, if the proxy at P1 were not preventing me from
authenticating my customer. Understand? I agree that this isn't a potential
security violation as such, it's an introduction of an intermediary that can
impede the operation of an existing security mechanism (as a trade-off in
order to facilitate an unrelated security operation).

SIP intermediaries today can also choose to replace the Contact header
field, the m= and c= lines of the SDP, and other aspects of messages with
the content of their choosing, in apparent breach of the RFC, as you say.
This does not mean that we should publish standards that condone any
possible course of action that a protocol entity might take to mangle SIP.

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

Well, in your case as described above, if the interceptor in the middle does
not have valid credentials, they send back a cryptic 4xx message to the UAC,
effectively saying "your call failed". So, if P1 does act this way, and the
UAC has valid credentials, a call fails which should not have failed.
Perhaps that is 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.
> 

... well, that isn't how I originally understood your requirements from your
earlier mail, but okay. I think that this just broadens your problem space,
and makes it much clearer to me that you want something like RH/M2M/M2E.

Also, be careful when you say that it doesn't care who authenticated the
request. I assume you mean that it doesn't care who replied to the
challenge. But what is the purpose of replying to the challenge? To provided
credentials proving someone's identity. That is the key to this. I don't
think there's something magical about Digest as a means to prove identity.
With request history, P4 would see the identity of P1, P2 and P3, with a
cryptographic assurance, and could make its own decision whether or not any
or all of them were authorized to proxy this transaction.

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

No, but I can see why that might be requirement (and the username portion of
Proxy-Authorization would no doubt make it clear who is providing the
credentials). I was thinking more that P2 should have a way to say who it
intends to challenge when it issues a 407. Today, 407 means ONLY that P2
intends to challenge the UAC. If you want to change that, then we need some
way of qualifying the challenge to indicate that someone other than the UAC
should answer it.

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

Of course. Your proposal does not make this problem any worse. It was raised
to show that your solution is unnecessary in transitive trapezoid cases. If
your solution space goes beyond transitive cases, though, then this will not
apply. You clearly seem to want a direct assurance, rather than a transitive
assurance, so I agree, mutual TLS is not sufficent for that.

<big snip of discussion of whether or not your case is transitive or direct
assurance>
> 
> 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.
> 

In trapezoid cases where your interest is in P2 determining that a request
was received via P1, it is sufficient. In that sense, it's not orthogonal to
the problem - the issue is that it is only valid for that one case (though
it is a case that seems to be a common one). Again, you clearly want to
cover other spaces.

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

Above, I did not see any reason that request-history does not solve your
problem. You argued, perhaps, that request-history is broader than your
problem, but that doesn't mean that it doesn't solve it. If you have some
additional requirements for request history that have not yet been captured
(whatever flavor you think you might get from a dynamic challenge from P2),
those should be submitted for consideration to the request history work.

> 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

---

From: Alex Bligh <[email-masked]>
Date: Tue, 20 Apr 2004 23:39:12 +0100

Jon,

> what you want to do, but I do think it nicely encompasses the use cases
> and requirements that you have articulated so far.

The requirements possibly, but it doesn't actually provide a solution (see
draft-barnes-sipping-sec-inserted-info-01.txt section 4. for why :-) ). Of
course this is not to say it couldn't provide a solution, but it is a bit
difficult to compare a concrete proposal to what in essence is a framework
stating a problem, but not yet proposing a solution.

Note that I am in no way trying to denigrate either the request history
work or the sec-inserted-info work; all I am saying is that a simple
change will provide a pragmatic solution to a particular problem space.
Not in either as general terms or as secure terms as you are proposing,
but in a manner which works /currently/ with all devices producing
a challenge (as far as I can see).

> While your note
> suggests that Digest challenges from P2 could be customized in some
> fashion to the particular circumstances of the transaction, that idea
> would need to be flushed out a bit more before we can make any judgment
> about whether or not request history cannot meet the underlying
> requirement.

See below.

> - I think you underestimate the complexity of pre-sharing symmetric keys
> for proxy servers. Sharing symmetric keys works well as a deployment
> model for the sorts of cases where usernames and passwords are successful
> today. For monolithic servers like proxies, a PKI-based approach has a
> much cleaner deployment model that does not suffer from any n-squared
> pre-sharing problems. Proxy servers shouldn't have to have pre-shared
> keys in order to be able to identify one another; their relationships are
> just too transient and they may need to relate to way too many peers
> (unlike, say an end user's relationship with a PSTN termination service).

I am not sure why the problem is n-squared. In all the examples of problems
in the space this solution is proposed to solve, there is a 1:few problem,
and more relevantly the authentication relationship is a "symptom" of some
greater trust relationship that has already been set up. For instance, in
the "my proxy diverts incoming SIP calls to me to my cellphone when my SIP
UAS is unavailble" environment, there is already some form of
(administrative) trust relationship between the SIP proxy and the gateway
used to perform the diversion.

You are entirely correct that digest authentication does not and could
not solve the general problem of how a given proxy P(n) authenticates
that any and all intermediate notes P(1)..P(n-1) are who they say they
are. However, I am not sure of what problem that is a solution to.

> unforeseen undesirable consequences.

I am still not sure what the /foreseen/ undesirable consequences are
(modulo those that you mention below which I have sought to address).
Any protocol change might have unforeseen undesirable consequences,
but that is not per-se an excuse not to ever change any protocols. The
key it seems to me is minimizing the risk of ill-effect, and getting
as many bright people on this list and elsewhere to look through and
say "well I can't think of any".

> If we really need a way to do this,
> it should be specific to challenging proxies, and not conflated with
> challenges that are semantically designated for end users in RFC3261.

I respectfully disagree with you there. If you can use a general mechanism
safely, rather than 2 specific mechanisms, the former seems better. If
there is an inherent danger in using a general mechanism, then that
should be avoided, but in the absence of that danger, I would suggest
as much commonality as possible is a good thing in terms of protocol
simplification.
> In order for TLS to work, P1 and P2 only need to be in the
> same PKI.

Sure, but then you have added the additional necessity of full PKI
certificates in order to provide authentication by a proxy. Whilst
I can see why this may be useful in some circumstances, in a real
world deployment, that sounds pretty heavyweight if the security
of a simple digest challenge would be sufficient.

> This argument is of the form "your mechanism isn't implemented or used
> very widely, but my (purely conceptual and totally unimplemented) proposal
> doesn't suffer from that problem."

:-)

Whilst there is some truth in that, I think you've missed the point.
My (purely conceptual) proposal is already currently implemented on
every device (UAS and Proxy) which can provide a challenge. It's
only unimplemented on those that need to respond to the challenge.
Having looked at the code for ser (and, admittedly, nothing else),
it doesn't seem like too great a change to me - I would suggest
rather less of a change than to add (say) TLS and appropriate PKI.

Besides which, your proposed solution that /does/ fully address the
problem, IE the request history stuff, if the security aspect is maximally
documented at in draft-barnes-sipping-sec-inserted-info-01.txt, is not even
*DESCRIBED* in full yet , thus cannot be implemented or used at all.
Again, I am not in any way denigrating the work, I am just saying from
a pragmatic point of view what I am suggesting is a minimal change
fix.

> While it may be annoying to deploy a
> PKI, I believe it is much more annoying to deploy and n-squared mesh of
> symmetric keys to proxy servers, especially given the fact that it is
> very difficult to anticipate which proxy servers are likely to need to
> have a relationship with one another.

There is no argument that if the problem space demands an n-squared
mesh, PKI is better than any digest system (and, for authentication
of UACs too). However, I don't believe this (requirement for
n to m authentication) is the case.

> proxy server - it is sufficient, if not necessary. I also pointed you to
> the m2m/m2e work, which is perhaps more directly applicable. The two are
> pretty inextricably linked in my mind, though.

Well it might well solve that problem. But it's difficult to see
whether it actually does or will solve that problem as the security
stuff is at quite an early stage.

>> 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.
>
> ascertain the identity of an intermediary?

To ascertain the that an intermediary has appropriate credentials.
IE I don't necessarily care which server from an authorized intermediate
administrative domain inserted them, I just care they have a username
and password tuple.

If I can tell only that it is a specific intermediate server, I then
have to map that back to an appropriate administrative domain etc.;
not necessarily a problem, but it does mean if administrative domain
X has 100 different servers, all with different certificates, then
proxy server Y outside there has to have each of the 100 different
certificates (or have some other way of mapping each of the ID's
to administrative domain X).

> If so, that identity
> information will be provided by request history. The "billability" of a
> URI wouldn't impact P2's challenge in any obvious way - except perhaps
> insofar as it might choose not to issue a call if the transaction has no
> settlement implications, or something.

What I was suggesting is the information P1 might provide (or chose not
to provide) might depend on information P2 would pass it in the challenge.
As relatively trivial examples, it could pass the cost of the call,
the QoS it could provide, the RTT etc. It needn't be passed in the
realm necessarily. P1 might decide not to authenticate the request
based on this information.

> code - so P1 can know whether it should consume and reply to the
> challenge, or whether it should forward them back. You're conflating two
> semantically distinct operations.

The advantage of using the same status code is that both proxies and
UAC's can authenticate to the same proxy. Very useful in the case of
(say) a media gateway service where some of its subscribers are UAs,
some are (effectively) B2BUAs or media-gateway-esque devices (asterisk
for example), and some are other proxies. As the proxy does not at this
stage know who the call came from, how would it know to respond with
"Proxy Authentication Required" or your new code?

However, saying that I do think you make a reasonable point that there
should be some mechanism to forbid an intervening proxy from intercepting
(perhaps a perjorative word) the 407. I am unsure whether it would
be best that an originating UAC said "No, *I* want to authenticate
this call", or whether the proxy should be saying "I want this
to go right back to the UAC".

> the response path, whether or not the UAC should be entitled to respond
> to a 407 challenge?

The UAC is always entitled to respond. The question is whether an
intervening proxy is entitled to "intercept" (as you call it). And my
answer is that this MUST NOT be done UNLESS there is a preexisting
trust relationship between the proxy issuing the challenge and the
proxy replying to the challenge. That is not "any old proxy server".
That is a proxy server which the administrators of both systems
have agreed should respond (as it has credentials).

>> 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,
> This is contrary to the meaning of realm as it is defined in RFC3261,
> which is not as broad as the definition of realm in RFC2617.

Are you saying that under RFC3261 I can't configure a single machine
to carry two security certificates (i.e. act as sip.mynet.com and
sip.mywhitelabel.com)?

> authenticating my customer. Understand?

Nope I don't understand. P1 is only "preventing" you from authenticating
your customer as you (P2) have previously come to an agreement with
P1 that P1 is your customer (which does not exclude UAC being your
customer too), and P1 is thus attempting to give you customer traffic
as per a previously established customer relationship.

P1 must not arbitrarily respond to realms "on the off chance" it can
authenticated the transaction.

> Well, in your case as described above, if the interceptor in the middle
> does not have valid credentials, they send back a cryptic 4xx message to
> the UAC, effectively saying "your call failed". So, if P1 does act this
> way, and the UAC has valid credentials, a call fails which should not
> have failed. Perhaps that is the point here.

I am not sure the above call should NOT have failed. Let's take the case
where UAC makes a SIP call via P1 and P2 to a switched off UASX, and P2
wants to divert the call to a cellphone via P3 and a media-gw.

The idea here is that P3 or media-gw (UAS) authenticates the call came via
P2, as P2 (providing service to UAS) is going to be billed for it.

UAC thinks the call is going to cost whatever a SIP call normally costs. If
P2's authentication works, then indeed the call should proceed.

However, let's suppose P2's authentication fails (perhaps they've forgotten
to pay their bill), and by some chance, UAC also has credentials with P3
(perhaps P3 is actually the same administrative domain as P1, i.e. UAC's
provider). Then automagically UAC will supply its own credentials to P3,
the call will get through, but UAC will be billed for the privilege. This
was exactly what UASX sought to avoid.

The message back need only be as cryptic or descriptive as P2 wants it to
be. If the call went to a media-gateway that hadn't paid its POTS bill, it
will get a far more cryptic message back.

> ... well, that isn't how I originally understood your requirements from
> your earlier mail, but okay. I think that this just broadens your problem
> space, and makes it much clearer to me that you want something like
> RH/M2M/M2E.
>
> challenge.

I mean I care only that valid credentials identifying are presented
(whether they are used to identify individual servers, or administrative
domains is not necessarily relevant). In many applications it is
unnecessary to identify individual nodes.

> But what is the purpose of replying to the challenge? To
> provided credentials proving someone's identity. That is the key to this.
> I don't think there's something magical about Digest as a means to prove
> identity. With request history, P4 would see the identity of P1, P2 and
> P3, with a cryptographic assurance, and could make its own decision
> whether or not any or all of them were authorized to proxy this
> transaction.

This would indeed be true, if the specification and the software
to implement it existed. What I am proposing (a) has a specification,
(b) has one end of the software already written.

> No, but I can see why that might be requirement (and the username portion
> of Proxy-Authorization would no doubt make it clear who is providing the
> intends to challenge the UAC. If you want to change that, then we need
> some way of qualifying the challenge to indicate that someone other than
> the UAC should answer it.

Perhaps "noone other than UAC should answer it".

> additional requirements for request history that have not yet been
> captured (whatever flavor you think you might get from a dynamic
> challenge from P2), those should be submitted for consideration to the
> request history work.

This argument sounds a bit like "we cannot solve a small isolated problem
by generalizing an existing mechanism, if we have the opportunity of
solving at a rather later date a much larger more complicated problem which
a rather heavier-weight solution that will probably solve the small problem
too". That's one of the things that broke OSI, X.400 etc.; not doing that
made IP et al. work.

I am not suggesting this replace request-history etc. - there is
no reason the two cannot live together in harmony. I will take
your word for it than when request-history & appropriate security
stuff is written you can use it to satisfactorily authenticate a
request has passed through a proxy, but it seems a bit like a
sledgehammer to crack a nut.

Alex