Hi, Paul,
This was a helpful note.
("analogy alert") - when I was working at a network monitoring company, we
were asked to provide traffic counts for IPsec. Looking at customer network
traces (for large ISPs) we saw way more people deploying ESP
("authentication plus confidentiality") than AH ("authentication without
confidentiality") - I'm not sure that we even implemented AH, but I left
before that feature shipped.
I'm thinking that if we didn't even see much uptake on "knowing who you were
talking to without confidentiality" at the IP layer - that's what AH gives
you - from networks operators, we're not likely to be able to explain what's
happening at the application layer to end users with much subtlety.
So I'd expect a single indicator ("it's all secure") to see more uptake than
two indicators ("the signaling is/is not secure", "the media is/is not
secure").
Your mileage may vary, and it's worth noting that my information is about
three years old, so things could have changed since then...
Thanks,
Spencer
I'm conflicted here. Its a tricky job to sort out which "security
combinations" can be meaningfully distinguished to the end user. They have
to be both comprehensible and useful. And it must be possible to convey
them via a range of commonly used UAs.
On one hand I think this is not an area that we ought to be
standardizing - it is potentially a good area for innovation. OTOH,
without some minimal expectations the whole thing is useless.
I can see a bunch of combinations that potentially might be in common use:
1) for single medium (e.g. audio) calls:
a) nothing is secure
b) identity is secure, media is not
c) both identity and media is secure
d) media is secure, identity is not
2) for multimedia calls (e.g. audio+video)
a-d) as above
*) combos where some media is secure and some not
On top of that, we have the cases where the other end is a gateway that we
may trust, but which has to represent security properties from its far
side.
And, there is the distinction between trust based on transitive trust
domains vs trust based on e2e encryption and certificates.
Clearly this is *way* too much to present to the average user, and nearly
impossible to present without a sophisticated UI. So it needs to be boiled
down into just a few alternatives.
John is proposing that it should all be condensed into *two* alternatives:
secure, and non-secure. In this case "secure" would be only cases 1c or 2c
above, and everything else would be insecure.
Its my feeling that isn't going to be good enough. For one thing, it means
that there probably will be almost no secure commercial deployments. It
also means that vendors will want to "bend the truth" a bit - perhaps by
claiming that certain cases are handled more securely than they really
are.
So, I'm leaning towards separating identity security from media security,
but I think I am willing to roll all media security together.
For identity security, I'm thinking of possibly three cases:
- secure (e2e or via transitive trust with some rules TBD)
- secure to the PSTN (secure as above, to a PSTN gw)
- insecure (all the rest)
I would render this as some sort of annotation on the callerid display.
(Colors, icon, etc.)
For media security, I suppose the same three cases apply. This would need
to be rendered independently of the callerid display. It might be in the
media stream itself. (Ring tone?) If in display, maybe it would be a lock,
rendered in different colors - but separate from the callerid.
I think this is important because callerid is important to people, and
because there is probably a lot better chance of getting secure callerid
than secure media. Treating the PSTN as a special case is clearly a hack.
But again, its probably an important hack because people think they know
what they are getting with the PSTN (even if they are wrong), and trust it
more than our new fangled stuff. Also, for quite some time most calls are
likely to have one PSTN endpoint. Treating PSTN identity as totally
insecure will distress people.
Thanks,
Paul
Elwell, John wrote:
Dan,
-----Original Message-----
From: Dan York [mailto:[EMAIL PROTECTED] Sent: 08 July 2008 19:53
To: Elwell, John
Cc: IETF SIP List
Subject: Re: [Sip] On the need for a visual identifier of trusted
identity - Fwd: I-D
Action:draft-york-sip-visual-identifier-trusted-identity-00.txt
John,
On Jul 8, 2008, at 3:13 AM, Elwell, John wrote:
Thanks for writing this, which I believe is an important part of the
whole SIP Identity discussion going on at present.
You're welcome.
Even if (as is
likely) the IETF does not standardise such a visual indicator, the
IETF
should still give consideration to what sort of indicators
are needed
and ensure that its protocols are able to supply sufficient
information
for a UA to be able to select the appropriate indicator.
Agreed.
The only other comment I have is that I didn't see anything
about the
impact of PSTN interworking. So there would seem to be at least 3
elements that make up the security status of a call:
- the strength of authentication of the peer user or domain;
- the strength of encryption;
- whether the call is via PSTN.
So as I read this comment, there are really two separate issues I see
here:
1. How do you symbolize the "trusted identity" of the PSTN Caller ID
transmitted by the PSTN-to-SIP gateway? Assuming we can come up with a
mechanism to arrive at end-to-end authenticated identity between two
SIP endpoints, we could get a "trusted identity" of the *PSTN
gateway*, but we have no way of really knowing whether the Caller ID of
the call was spoofed out on the PSTN before it reached the gateway. We
therefore can't really trust the "identity" of the caller provided to
us by the PSTN gateway - even if we can get an authenticated *SIP*
identity of the gateway itself. Perhaps this is represented to the end
user as any other "untrusted" call would be. Perhaps some systems could
display that this is an inbound call from the PSTN?
[JRE] We could provide the gateway identity as a trusted identity, but
it seems unhelpful not also to provide the PSTN number as an untrusted
identity. Unfortunately this complicates the UI.
2. Should the "visual identifier" be for more than just "trusted
identity"? In the draft, I specifically was focusing on the issue of
trusted identity and NOT on the issue of the call being encrypted. But
in your comments you mention the "security status" of a call which is
really something more. In the context of identity, there are several
possibilities for a call two SIP endpoints:
a. "Trusted identity" without signaling or media encryption.
b. Trusted identity with signaling encryption but without media
encryption.
[JRE] The average user will not understand the difference between
signalling encryption and media encryption. I think any indication of
encryption should mean that anything the user "sends" is encrypted,
which might include voice, video, messages, pictures, geographic
location, the fact that user A is making a call to user B, etc.. I don't
think it is helpful to give the user separate indications for these - a
secure call indication should mean everything is secure. So what I
really mean to say is that all these different factors should be taken
into consideration before indicating that the call is secure.
I understand that your draft was focusing only on the strength of
identity authentication. However, the padlock on browsers means that the
web site has been authenticated AND that data is encrypted. The average
user might not be able to cope with two separate indicators on SIP
devices for these.
c. Trusted identity with both signaling and media encryption.
And really there are another identical three possibilities for a call
between a SIP endpoint and PSTN gateway, for a total of at least six
possibilities. (Since you note you could also add in the *strength* of
the encryption.)
We are rapidly leaving simple-icon-that-nontechnical-people-can-
understand land.
And probably getting into nuances (like encryption strength) that may
be of interest to the more paranoid of us (like me) but not at all to
the vast majority of people using the actual systems.
[JRE] To a first approximation this might be just "encrypted" or
"unencrypted".
My guess is that probably the average user *might* care about:
1. When I dial this number, am I really talking to my bank? (Or when
they called me, is it really them?)
2. Can I give them my credit card number without fear of some hacker in
______ getting that number?
[JRE] Agreed.
Ideally, they'd get both in one icon or identifier.... but I'm not sure
that's always possible. There may be times when I want to be sure it
really is Hadriel Kaplan calling me but I don't really care whether
what we talk about is encrypted. But for many SIP endpoints is it
desirable - or even possible - to have multiple icons?
[JRE] I don't know the answer, but I think we are in basic agreement.
It's an interesting problem.
Dan
--
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO Voxeo Corporation [EMAIL PROTECTED]
Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com
Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com
Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free
_______________________________________________
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
_______________________________________________
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
