Subject: [Sip] On the need for a visual identifier of trusted identity - Fwd: I-D Action:draft-york-sip-visual-identifier-trusted-identity-00.txt

From: Dan York <[email-masked]>
Date: Mon, 7 Jul 2008 19:45:39 -0400

So after writing my response to Paul Kyzivat's response to Cullen, I  
thought about it some more and realized that I ought to collect those  
thoughts into an I-D, which I have now submitted.  I did so primarily  
because I haven't really seen discussion of the end user's  
*experience* of working with "trusted identity" (if I missed such a  
discussion, please feel free to point it out to me).  To the person  
using a SIP phone to call another SIP phone, how do they know that  
they can trust the identity of the caller on the other end?    If we  
solve the various issues we are discussing related to RFC 4474, P-A-I,  
etc., what might the end user experience look like?

As I note in the draft, it's not entirely clear to me that the IETF is  
the appropriate body to address this question.  It's more of a "user  
interface" question that is more about how to have users adopt/accept  
a SIP feature and feels to me like it's something more appropriate for  
a more vendor-centric "industry consortium" type of entity.  Something  
like the SIP Forum or some other similar entity.  I'm certainly open  
to comments and feedback along those lines... In the meantime, I  
thought I'd at least throw something out there for discussion.

Thanks,
Dan

A New Internet-Draft is available from the on-line Internet-Drafts  
directories.

	Title           : The Importance of a Visual Identifier of Trusted  
Identity
	Author(s)       : D. York
	Filename        : draft-york-sip-visual-identifier-trusted- 
identity-00.txt
	Pages           : 9
	Date            : 2008-07-07

This document discusses the need for a visual identifier in Session
Initiation Protocol (SIP) endpoints to indicate to the end user that
they are speaking with someone whose identity is trusted.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-york-sip-visual-identifier-trusted-identity-00.txt

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 07 Jul 2008 23:54:20 -0500

Dan York wrote:
> because I haven't really seen discussion of the end user's *experience* 
> of working with "trusted identity" (if I missed such a discussion, 
> please feel free to point it out to me).  

Dan: A while ago -- maybe early last year -- we had a great
big thread on the idea of showing a locked padlock to impart
the notion of a secure call.  This discussion was in the
context of the sipsec URI draft (see
http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01).  The
allegory we adopted, which is also discussed in the draft, was
that of a "hopping bunny with a lock in its mouth" (as a
tribute to SIP's hop-by-hop security model.)  In any case,
among other discussions that resulted in the thread were
reasons why this is not completely attainable (although at that
time, the work on dtls-srtp was not as advanced as it is now.)

The draft is a good starting point that distills a lot of
the discussion that preceded it, so it may be worth a read.
I will attempt to find the threaded discussion in the mailing
list archives and send you a link to it tomorrow.

Ciao.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 08 Jul 2008 08:13:43 +0100

Dan,

Thanks for writing this, which I believe is an important part of the
whole SIP Identity discussion going on at present. 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.

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.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dan York
> Sent: 08 July 2008 00:46
> To: IETF SIP List
> Subject: [Sip] On the need for a visual identifier of trusted 
> identity - Fwd: I-D 
> Action:draft-york-sip-visual-identifier-trusted-identity-00.txt
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Jul 2008 09:52:18 -0400

Dan,

Thanks for writing this. As (John?) said, this subject has been 
discussed before, but I don't think it was ever put in the form of a 
draft - which gives it a bit more tangibility.

A few observations about the draft:

- I think the key here is not the details about the form of
   presentation. Rather it is a matter of boiling down all that
   may, or may not, be available in protocol exchanges into
   some simple concepts that can be expected to be presented to
   end users. The chanllenge is coming up with concepts that we
   believe are capable of being presented on a wide variety of
   devices, and that are capable of being understood by most
   users.

- Your concern over the meaning of the indicator - that it
   isn't about the media - is a real one. I think we need to
   consider the variations that are possible, and how to
   indicate them without getting confusing. If it is only the
   "callerid" that is secure, then IMO the ideal way to indicate
   that is to annotate the callerid display itself. This could
   be some sort of icon as part of that display. Or it could be
   done with color - green for trusted id, red for untrusted.
   (Yellow for id from PSTN?)

   The above solves the problem you are concerned about for
   local conferences. If you can see the identity of each
   party then you can see whether each is trusted or not.

   In cases where the media is also secure some other sort of
   indicator is needed. But providing this kind of information
   in a way that can be understood by everyone is a challenge.
   It gets even worse when when there are multiple media in
   the call, because they may not all have the same security.

I do think it would be well worth the time of the group to work on this. 
We keep working on security mechanisms. But it is far from clear that 
any of them have much value unless that can be reflected to the user in 
some comprehensible way. Starting with what needs to be displayed, and 
then working backwards to what is needed to drive that display, may be 
helpful.

	Thanks,
	Paul

Dan York wrote:
> please feel free to point it out to me).  To the person using a SIP 
> phone to call another SIP phone, how do they know that they can trust 
> the identity of the caller on the other end?    If we solve the various 
> issues we are discussing related to RFC 4474, P-A-I, etc., what might 
> the end user experience look like?
> 
> interface" question that is more about how to have users adopt/accept a 
> SIP feature and feels to me like it's something more appropriate for a 
> more vendor-centric "industry consortium" type of entity.  Something 
> like the SIP Forum or some other similar entity.  I'm certainly open to 
> comments and feedback along those lines... In the meantime, I thought 
> I'd at least throw something out there for discussion.
> 
> Thanks,
> Dan
> 
>     Filename        : 
> draft-york-sip-visual-identifier-trusted-identity-00.txt
>     Pages           : 9
>     Date            : 2008-07-07
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 08 Jul 2008 09:07:55 -0500

And I wrote:
> the notion of a secure call.  
> [...]

So I went back and trawled through the saved emails and archived
emails to see when we had this discussion.  It was between
May 2006 - Jun 2006 -- 2 years ago.

On Jun 19, 2006 we had distilled the hopping bunny thread
discussions into the sipsec I-D (see
http://www.ietf.org/mail-archive/web/sip/current/msg14799.html).
In the archives, keep going back to May 2006 and you will
see a long thread that has been re-named many times.  The
source of that renamed thread is an email by Francois Audet when
he was doing the work on sip-sips that started the thread (see
http://www.ietf.org/mail-archive/web/sip/current/msg14306.html
for the beginning of Francois' email and then track forward to
Jun 2006 following the thread as it is renamed multiple times.)

 From May 2006 to June 2006, if you follow Francois' thread
and all its renamed derivatives, you will get a good idea of
all the discussion that has gone into the topic of user-
visualizable lock icon a la HTTP and the various issues around
it.

The work culminated in the Jul 2006 IETF meeting in a
SIP Security Breakout session where the issue was framed by
Cullen and is captured in the minutes (search for the text
"hopping bunny" in this URL:
http://www.ietf.org/proceedings/06jul/minutes/sip.html)

That I believe is the last word on this topic until now.

Hope that helps.

Ciao.

- vijay

---

From: Dan York <[email-masked]>
Date: Tue, 8 Jul 2008 14:53:02 -0400

John,

On Jul 8, 2008, at 3:13 AM, Elwell, John wrote:

> whole SIP Identity discussion going on at present.

You're welcome.

> Even if (as is

Agreed.

> - 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?

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.
   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.

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?

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?

It's an interesting problem.

Dan

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 09 Jul 2008 09:17:19 +0100

Dan,

> From: Dan York [mailto:[email-masked]] 
> 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 
[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.

>    b. Trusted identity with signaling encryption but without media  
[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.

> the vast majority of people using the actual systems.
[JRE] To a first approximation this might be just "encrypted" or
"unencrypted".

> in ______ getting that number?
[JRE] Agreed.

> 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Jul 2008 09:17:54 -0400

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 9 Jul 2008 09:17:41 -0500

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

> 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 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.
>
> 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 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.
>
> 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,
>>
>>> From: Dan York [mailto:[email-masked]] 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 
>>> 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?
>>> 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:
>>>
>>> possibilities.  (Since you note you could also add in the *strength*  of 
>>> the encryption.)
>>>
>>> 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?

---

From: David R Oran <[email-masked]>
Date: Wed, 9 Jul 2008 10:38:07 -0400

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
>
>
>> 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 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.
>>
>> nearly impossible to present without a sophisticated UI. So it  
>> needs to be boiled down into just a few alternatives.
>>
>> 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.
>>
>> 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,
>>>
>>>> identity - Fwd: I-D Action:draft-york-sip-visual-identifier- 
>>>> trusted-identity-00.txt
>>>>
>>>> John,
>>>>
>>>> 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?
>>>> 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:
>>>>
>>>> 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.)
>>>>
>>>> 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.
>>>> 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?

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 09 Jul 2008 17:43:38 +0100

Yes, while I agree to some extent with Paul's analysis, I think from a
pragmatic point of view
Spencer's analysis is more realistic.

John 

> Behalf Of Spencer Dawkins
> Sent: 09 July 2008 15:18
> To: IETF SIP List
> trusted identity -Fwd: I-D 
> >>>> likely) the IETF does not standardise such a visual 
> indicator, the 
> >>>> IETF

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Jul 2008 10:04:14 -0700

> Sent: Wednesday, July 09, 2008 7:18 AM
> To: IETF SIP List
> trusted identity -Fwd:I-D 

IPsec AH does not work across NATs.

-d

---

From: Dan York <[email-masked]>
Date: Wed, 9 Jul 2008 13:52:17 -0400

>> media is/is not secure").

DY> I agree that I don't think "normal users" out there care about (or  
even know about) the differences between secure signaling and secure  
media.  If we were to ask them what makes a call "secure" they would  
probably almost always think of the media.  I think there is zero  
value in distinguishing between secure signaling and media.  It should  
just be "secure" or "not secure" where "secure" equals both signaling  
and media security.

DY> However, I wonder if there's a need for a separate indicator for  
authenticated *identity*.  If I'm in a meeting and a call comes in and  
the "Caller ID" displayed on the screen is for my wife, I might want  
to interrupt what I'm doing and answer the phone.  If I have some  
unethical salesperson on the other end who was masquerading as my  
wife's caller ID, I'm going to be very upset.

DY> Likewise, when I call my bank and wind up in some call center, I  
would like assurance that I *am* talking to my bank and not some other  
call center that I was re-directed to.

DY> In those cases, I want to be sure of the *identity* and I'm  
potentially less concerned about the "security" of the call (although  
with a bank I hopefully am).   Does this need to be separate  
indicator? Or could this fall into the same as the "secure"  
indicator?  I'm not sure. Given the woeful lack of implementation of  
media encryption, I guess I could see more success of an identity  
indicator being implemented than of a "secure" indicator.

On Jul 9, 2008, at 10:38 AM, David R Oran wrote:

> really care about, which is in nearly all cases only three things,  
> and they are pretty tightly related:
>

DY> And "- Is the company/organization/person I am speaking with who I  
think they are?"  Obviously we can "authenticate" the voices of people  
we know with our ears, but for large companies, call centers, etc. we  
don't really have any way to do so.

> 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  

DY> And such a light look far better in a spy movie! :-)

DY> Seriously, though, this does point out the challenge with "visual  
indicators" and perhaps why they can never really be standardized.  On  
the "hard" IP phone on my desk, having a light like this suggestion  
would be far better than having an icon on the small little display  
screen that is there. (Yeah, I should get an IP phone with a larger/ 
nicer display.)  But if I'm using a SIP softphone, what does that  
light mean?  There, you need an icon or something like that.

>>> security, but I think I am willing to roll all media security  

DY> As I noted above, I agree.

>>> I would render this as some sort of annotation on the callerid  

DY> Agreed.

>>> 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.

DY> Interesting.  I hadn't thought of the PSTN as a special case with  
media encryption but of course it is.  We can do end-to-end media  
encryption from a SIP endpoint to the SIP-to-PSTN gateway but after  
that it's unencrypted.

>>> 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.

DY> Agreed.

>>> Treating PSTN identity as totally insecure will distress people.

DY> (laughing) Wonderful statement!  And very true. It continually  
amazes me the degree to which people believe PSTN identity is solid  
and reliable.  But on one level, why not?  The vast majority of people  
out there have probably never received a PSTN call with a spoofed  
Caller ID.

DY> That trust in the integrity of the PSTN identity will probably  
remain until such time as the spammers start abusing it and people are  
getting calls they think are from people they know.... and then over  
time they realize that they can't trust Caller ID just like they can't  
trust sender email addresses.

Regards,
Dan

P.S. Sadly, if you think about it, the components for abuse are very  
readily available... an attacker could have a piece of malware on a PC  
that grabs a users Outlook address book (or similar address list) and  
sends that to the attacker. The attacker could then call everyone in  
that address book and use some VoIP server/system that lets the  
attacker set the Caller ID to that of the original user.   The  
recipients think they are getting a call from someone they know and  
answer... only to get some telemarketing pitch.  The economic model is  
probably not there yet for doing this, but you could see how it could  
be done very easily on a *technical* level.
-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Jul 2008 13:02:32 -0500

On 7/9/08 9:38 AM, David R Oran wrote:

[analysis removed]

> the user is not something the IETF has the skill set to do a good job of.
>
> establishment time, or allows an attempt to secure the call via 
> re-invite, transfer, or whatever, during the call.

That works well for handling of this kind of information during the 
call. But I think there are two very different sets of decisions people 
want to be able to make:

   1. Am I (reasonably) certain that the caller identity on my ringing,
      unanswered phone is accurate?
   2. Once I am in a call, how do I conduct myself?

I think your analysis is spot on for #2.

But #1 is a fairly different kind of decision based on a different kind 
of information, and would probably be rendered differently.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Jul 2008 14:20:41 -0400

Both Dan and Adam have now restated the distinction I was trying to 
make. Hopefully they have been more successful.

One criterion that I think is important, though perhaps irrational, is 
how calls to/from the PSTN are represented. Among all the possible ways 
that the trustworthiness of the callerid may be represented, this case 
had better be one that makes sense to most users. That probably means it 
should not be "no trust at all", because that will be interpreted as 
indicating that this new phone system makes calls less reliable. That is 
why, as irrational is it may be, I'm thinking of three levels (bad, far, 
good / red, yellow, green / ...) where an identity from the PSTN that 
has been secured for the sip portion of the path, probably falls in the 
middle.

	Paul