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