Dean Willis wrote:
Paul Kyzivat wrote:
. . .
I don't think so. For one thing, its quite likely that there is no
business card. The caller may well just guess the sip/sips address
from an email address. And even if given a sips address, they might
not understand what that is and mistype it as sip, or they might use
sip because the client they are using doesn't support sips.
I don't see what harm is being done to the callee in this case. In
normal cases he can detect that the call was placed via sip and simply
refuse to answer. If there was any important info in the request that
might have been observed, it is info of the *caller*, who knew he was
making an insecure call.
No, it is the info of the CALLEE that I am worried about.
Let's take the very first INVITE example from RFC 3665, "Alice Calls Bob
Directly".
INVITE sip:[EMAIL PROTECTED] SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:[EMAIL PROTECTED]>;tag=9fxced76sl
To: Bob <sip:[EMAIL PROTECTED]>
Call-ID: [EMAIL PROTECTED]
CSeq: 1 INVITE
Contact: <sip:[EMAIL PROTECTED];transport=tcp>
Content-Type: application/sdp
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
This message reveals that the target Bob is reachable at host
"biloxi.example.com".
*This* message only reveals that Alice *thinks* Bob is reachable at that
address. Its no worse than intercepting an email from Alice to Charlie
that mentions the sip (or sips) address of Bob.
If you want to prevent Alice from disclosing the address of Bob then you
have a much harder problem. I don't think this is solvable in practice,
nor do I think it needs to be solved.
Since traceroute on biloxi.example.com may well give us a good idea of
the physical location of biloxi.example.com, an interceptor picking up
this message would have a good chance of being able to find Bob.
No. Only Bob's home proxy.
Assuming that this message is sent unencrypted when used with SIP
(instead of SIPS), it's relatively easy to intercept.
The interceptor didn't need credentials to get into a location server
that might translate [EMAIL PROTECTED] to [EMAIL PROTECTED] They
didn't need credentials to look in a directory server. They just pulled
the information "off the wire" in such a way that Bob will be unable to
know how the interceptor got his location.
I don't see how this discloses the address [EMAIL PROTECTED], which
is the only one that Bob has any chance of hiding. All Bob needs to do
is be careful in what he puts into his *response* to the above invite.
(E.g. He shouldn't put his contact address if he is rejecting the call,
and he should ensure his address isn't mentioned in a H-I header.) If he
is really paranoid about this he could simply refuse to send any
response to the invite, and let it timeout.
Paul
The ONLY defenses Bob has against this sort of thing are:
1) use an outbound proxy with TLS, which only works in some architectures
2) Train everybody that calls him to use SIPS instead of SIP.
I'm looking for ways to encourage #2, and don't feel that the current
"SIPS registrations mean you want SIP and SIPS to reach you" is helpful.
What other tricks migt apply? DNS configuration on biloxi.example.com,
maybe?
--
Dean
_______________________________________________
Sip mailing list https://www1.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
