Re: [stir] current draft charter

["Peterson, Jon" <[e-mail]>]

I don¹t think I previously replied to say, works for me. Those fixes are
added.

Jon Peterson
Neustar, Inc.

On 6/12/13 2:50 AM, "[e-mail]"
<[e-mail]> wrote:

>Jon,
>
>The only comment I would have is on the general phrasing of the first
>paragraph, which at least for an outsider, may sometimes seem to be
>focused on anonymous calls rather than on 'illegitimate' CPNs in general
>(whilst the "more serious" problems that are listed there have indeed
>more to do with the latter than the former).
>
>If this restriction is not deliberate, maybe you want to say "can be
>hidden or forged" instead of only "hidden" and "that obscure or falsify"
>as opposed to only "obscure".
>
>Regards,
>
>Philippe Fouquart
>Orange Labs Networks
>[phone]
>
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Peterson, Jon
>Sent: Wednesday, June 12, 2013 3:03 AM
>To: [e-mail]
>Subject: [stir] current draft charter
>
>
>Below is the current draft of the charter, based on our prior discussions.
>
>Jon Peterson
>Neustar, Inc.
>
>----
>
>Name: Secure Telephone Identity Revisited (stir)
>Area: RAI
>
>Chairs: TBD
>Area Advisor: TBD (Barnes)
>
>Mailing list: (current source-auth)
>To Subscribe: --
>
>Over the last decade, a growing set of problems have resulted from the
>lack of security mechanisms for attesting the origins of real-time
>communications. Many of these problems are familiar from our experience
>with email: bulk unsolicited commercial communications remain a challenge
>for the traditional telephone network largely because the source of calls
>can be hidden. Others are potentially more serious: voicemail hacking,
>impersonating banks and similar attacks are becoming commonplace. The
>technologies that obscure the caller's identity are frequently gateways
>between the telephone network and the Internet.
>
>SIP is one of the main VoIP technologies employed by these gateways. A
>number of previous efforts have attacked the problem of securing the
>origins of SIP communications, including RFC3325, RFC4474 and the VIPR
>WG. To date, however, true cryptographic authentication of the source of
>SIP calls has not seen any appreciable deployment. While several factors
>contributed to this lack of success, two seem like the largest culprits:
>1) the lack of any real means of asserting authority over telephone
>numbers on the Internet; and 2) a misalignment of the integrity
>mechanisms proposed by RFC4474 with the highly interworked, mediated and
>policy-driven deployment environment that has emerged for SIP. The VIPR
>alternative, while promising, faced apparently unavoidable privacy
>problems and other significant deployment hurdles.
>
>Given the pressing difficulties caused by the lack of a useful identity
>solution, the problem of securing the origins of SIP communication must
>be revisited. Because SIP deployments are so closely tied to the
>telephone network, we moreover must investigate solutions that can work
>when one side of a call is in the PSTN - or potentially even both. This
>will require a two-pronged approach: one prong relying on information
>carried in SIP signaling; the other prong relying on forming out-of-band
>connections between IP endpoints that are participating in a call.
>
>The changes to the RFC4474 approach to SIP signaling must include a new
>capability for Identity assertions to cover telephone numbers, rather
>than domain names. To conform with realistic deployments, we must also
>study ways to rebalance the requirements for the scope of RFC4474's
>integrity protection to emphasize preventing third-party impersonation
>over preventing men-in-the-middle from capturing media.
>
>Finally, the solution must encompass an out-of-band means for endpoints
>to establish identity when there is no direct SIP signaling path between
>them available, due to interworking or similar factors. This working
>group will investigate a means for Internet endpoints to discover one
>another in real time to verify that a telephone call between them is in
>progress based on minimal evidence or configuration. This architecture
>will, to the degree that is possible, reuse the credentials defined for
>telephone numbers for the in-band signaling solution, and define a
>discovery mechanism that provides better than hop-by-hop security.
>
>The working group will coordinate with the security area on certificate
>management.
>
>The working group will coordinate with RAI area groups studying the
>problem of signaling through existing deployments, including INSIPID.
>
>Identity is closely linked to privacy, and frequently one comes at the
>cost of the other. This working group is not chartered to mandate the
>presence of identity in SIP requests, and to the extent feasible it will
>find privacy-friendly solutions that leak minimal information about calls
>to third parties.
>
>The working group will deliver the following:
>
>- A problem statement detailing the deployment environment and
>difficulties motivate work on secure origins
>
>- A revision to SIP's identity features to provide several fixes:
>    Changes to support certification for telephone numbers
>    Changes to the signature
>
>- A document describing the certificate profile required to support
>telephone numbers in certificates
>
>- A fallback mechanism to allow out-of-band identity establishment during
>call setup
>
>Milestones
>
>Sep 2013   Submit problem statement for Info
>Nov 2013   Submit RFC4474bis for PS
>Jan 2013   Submit TN cert profile for Info
>Mar 2014   Submit fallback for PS
>
>
>__________________________________________________________________________
>_______________________________________________
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>France Telecom - Orange decline toute responsabilite si ce message a ete
>altere, deforme ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>they should not be distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and
>delete this message and its attachments.
>As emails may be altered, France Telecom - Orange is not liable for
>messages that have been modified, changed or falsified.
>Thank you.
>