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
