On Mar 30, 2009, at 12:30 AM, Dan Wing wrote:
Would we be willing to accept a model where the fingerprint is
preserved across SBCs but the IP address/port number information is
not? I'm not saying that would be easy to produce; it would seem to
require a very complex modification to RFC 4474's handling of
SDP, or
complementary fundamental changes to RFC 4474 and the DTLS draft
family. But would it get us past this this stone wall?
It would not get us past this stone wall, because this very idea
was already proposed and already rejected,
http://tools.ietf.org/html/draft-wing-sip-identity-
media-02#section-4.2
I'm hoping that we've developed a broader understanding of the problem
since the last time this was circulated,
The reasons for the rejection, as I recall, were along the lines of
"we
don't want to require SRTP to provide identity". That argument is
countered with the ICE technique in Section 4.3 of the same draft;
we could change that from ICE to something else that does not
overload ICE semantics of course. Other reasons included "but SBCs
might [destroy | modify | manipulate]" the messages. The counter
argument to that is that the operators of SBCs have an incentive
to allow identity through (namely, so that people will accept
incoming SIP calls), very much like the long distance phone
companies in the 1980's added echo cancellation tone detectors
(because it was something needed by the end users). Other arguments
questioned how non-Invite requests would get protection (also
answered in that same draft).
Given that a clever on-path attacker could disrupt "identity" without
changing the port/address presentation, I fail to see how protecting
them proves anything.
It is not a lack of solutions in this space. It is a lack of
participation by interested parties and an unwillingness to admit
that voice networks are using SBCs -- as if SBCs operated by service
providers are as real as the tooth fairy or Santa Claus.
If not, why not? And you're going to have to convince me that you're
not just building a phone-tapper protocol here . . .
Strong identity makes it *harder* to build a phone-tapping system.
This
hop-by-hop signing thing that you are describing above, and Jon
described at
the microphone, is transitive trust with extra CPU horsepower and
something
you could fight better in a lawsuit when you learned that a service
provider
lied. I don't see a service provider getting very interested in the
additional capex, opex, and business risk of doing such signing,
especially
compared to the three proposals on the table which require the service
provider do _no_ signing and no stronger attestation than today
(same business
risk as today).
You misunderstand the hop-by-hop signing approach I described. By
adding signatures, rather than replacing them, the original media and
DTLS key identifier properties are preserved. The stack of signatures
and new SDPs provide an audit chain for figuring out what happened and
for a basis of transitive trust where end-to-end trust is not
existent, but do not impede the ability for end-to-end when the
endpoints have that capability.
--
Dean
_______________________________________________
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
