What if the SBC did the following:
- made whatever changes it wants to make to the incoming
request to derive the message it wants to send.
- calculated the reverse diff the transforms its modified
message into the message it received.
- affixed the reverse diff to the new message as another
body part.
- signed the whole thing as itself.
- sent it on.
When the UAS receives this, it first validates the signature and decides
if it trusts the signer.
If so, it may then use the reverse diff to reconstruct the unmodified
message. It can then validate any signature that may contain to verify
the actual caller. This can of course be applied recursively.
At any stage it can just decide to trust any assertions made by the
intermediary.
Paul
Eric Rescorla wrote:
At Fri, 1 Aug 2008 09:36:36 +0100,
Dan Wing wrote:
At Thu, 31 Jul 2008 20:54:43 -0400,
Hadriel Kaplan wrote:
-----Original Message-----
From: Eric Rescorla [mailto:[EMAIL PROTECTED]
Funny you should mention that.
It's becoming increasingly clear that VBR codecs leak a fair
amount of information, even when they are encrypted [WBC+08].
So, if, for instance, you were planning to use a fixed-rate
codec and an attacker could force you into a VBR codec, that
might leak information.
Fascinating paper. (truly) But it sounds more like just a reason to
fix SRTP for VBR, through random padding or whatever.
I haven't studied the problem, but I suspect random padding
is of limited use because it averages out. Probably better
to use a fixed length codec.
However, I think focusing on that misses the larger point: the UAC and
UAS have certain desires as expressed in the messages/SDP
To the extent to which we allow the intermediaries to change
those messages, we need to carefully analyze each instance,
and this analysis may actually depend on facts yet to be
discovered.
4474 allows intermediaries to change SDP, and re-create a new
>From and a new signature.
Well, it allows it in the sense that there's no known
cryptographic way to stop it in any system, then sure.
This (a) destroys end-to-end identity
(which is the subject of this thread) *and* (b) allows
intermediaries to perform the very downgrade attack you
cited ([WBC+08]).
This is why I want to improve upon 4474.
I don't agree with this analysis.
Let's say that [EMAIL PROTECTED] sends [EMAIL PROTECTED] an INVITE.
It's 4474 signed by atlanta.com. Now, some SBC in the middle
edits the SDP. This breaks the signature.
At this point, when Bob gets the message, he knows:
(1) This message claims to be from Alice.
(2) The signature was broken.
He therefore has no knowledge of what happen. He can choose to
accept or reject the call, but can't reasonably infer that
the call came from Alice or anything else about Alice's
intentions.
Now, if the SBC resigns, then Bob gets a valid message
from somebody else other than Alice. Effectively, the
SBC. Now, the SBC claims that it is connecting Bob to
Alice, but it could be lying. If Bob trusts the SBC,
he can accept the call, but he's trusting the SBC.
Sure, the SBC can edit the SDP to replace codecs, but
it can do *anything*. It could, for instance, replace
the DTLS-SRTP fingerprint. This isn't surprising, since
the SBC is really a B2BUA and this is a call from it.
The schemes being proposed here allow the RFC 4474 signature
to survive some editing of the message by the SBC. The
question here is the extent to which that enables *silent*
attacks by the SBC. To take an extreme case, if we allowed
editing of the fingerprint, then Bob could think he was
talking to Alice, but he was actually talking to the
SBC. Editing the codecs to allow this kind of traffic
analysis is a (much) less serious version of the same
threat. Again, this differs qualitatively from the former
case because Bob does not know he is under attack.
The question, then, when someone proposes exempting some
field from the signature, is what silent attacks it enables.
I have yet to see any satisfactory analysis along these
lines.
-Ekr
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
