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
