On Jul 9, 2008, at 10:17 AM, Spencer Dawkins wrote:
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").
I tend to agree, not just for simplicity, but to capture what people
really care about, which is in nearly all cases only three things, and
they are pretty tightly related:
- If I say something sensitive, is only the person/people I want to
hear it going to hear it.
- Is anybody overhearing what they are saying to me?
- Is either of us hearing anything neither of us said, or failing to
hear it due to manipulation of the communication channel.
The first is a coupling of authenticated identity and encryption-
strength confidentiality. The second is media encryption strength
confidentiality. The third is media encryption-strength integrity, and
is carefully worded to separate out simple packet loss from detecting
an active attack.
Note that the above applies equally to non-audio media, such as video
and text. There are cases where you can make do with out authenticated
identity if you don't care who it is you are talking to and only care
that you aren't leaking to anybody else, but those cases are a small
minority, IMO.
I also agree that trying to mandate the way the state is presented to
the user is not something the IETF has the skill set to do a good job
of.
Going onto this tangent however...
My personal preference is for something different from the lock icon
one sees in web browsers. Rather I like having a "go secure" button on
the phone that lights up green if the above conditions are met and
flashes or turns red if they are not. This allows either for the light
to come on in the few cases where everything works out at call
establishment time, or allows an attempt to secure the call via re-
invite, transfer, or whatever, during the call.
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
_______________________________________________
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
