On Apr 14, 2008, at 3:22 PM, Hearty, John wrote: > Forgive me for jumping in very late and not understanding some of > the issues, but this caught my eye: > >> 2. An RFC 4474 signature from the PSTN gateway doesn't do anything >> useful for Bob unless Bob can trust the *identity* claimed >> in that signature. Again, this isn't about DTLS-SRTP, but >> purely about the semantics of the PSTN. >> >> Say, for the sake of argument, that Alice's GW *did* sign >> with [EMAIL PROTECTED] This stops EP from changing >> the fingerprint while retaining the signature, but it just >> inserts its own fingerprint, changes the identity to >> [EMAIL PROTECTED], which it does own, and resigns. The >> problem here is that Bob has no way of a priori knowing that >> there is any important difference between these two identities, >> and so he's not really doing endpoint auth. >> >> Note, however, that this is a consequence of only looking at >> the LHS. If Bob's UA was configured to show "Alice" >> for [EMAIL PROTECTED] and "Unknown" for [EMAIL PROTECTED] >> (e.g., via an address book) then this would all work fine. >> >> So, absent some way for Bob (the RP) to know which AS should be >> signing a given E.164 number, I don't see any useful change to >> RFC 4474 that helps against this class of attack. > > Bob does know which AS to trust for any E.164 numbers. He signed up > with a service provider that, from a PSTN standpoint, owns the PSTN > number Bob uses for PSTN callers to reach his SIP endpoint. Bob > only expects calls from the PSTN to come from that service > provider. He can't trust any other GWs. So if Bob's UA is > configured with the list of GWs his service provider supplied and a > policy to trust only those GWs, all we need now is the proposed > identifier (such as user=phone) that says to lower your trust > expectations for the user part of the URI because it came from a > PSTN assertion. Bob can then trust his connection is fully secured > all the way to the PSTN GW but no further.
Exactly. And the "stacked" Identity header approach (that I think Jon Peterson proposed) allows Bob to transitively trust other ASes which are trusted by his AS, but that Bob may have no direct relationship with. -- Deab _______________________________________________ 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
