> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Spencer Dawkins
> Sent: Wednesday, July 09, 2008 7:18 AM
> To: 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
>
> 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.
IPsec AH does not work across NATs.
-d
> 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
>
_______________________________________________
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
