[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

RTCWEB                                                        M. Kaufman
Internet-Draft                                                     Skype
Intended status: Standards Track                           June 30, 2011
Expires: January 1, 2012


         Client Security User Interface Requirements for RTCWEB
                  draft-kaufman-rtcweb-security-ui-00

Abstract

   This document calls for a requirement to be imposed on RTCWEB client
   user interfaces whereby the user may inspect the current media
   security status.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 1, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Kaufman                  Expires January 1, 2012                [Page 1]


Internet-Draft        Client Security UI for RTCWEB            June 2011


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Security Inspector Requirements for Clients . . . . . . . . . . 3
   3.  Other Advantages  . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 4












































Kaufman                  Expires January 1, 2012                [Page 2]


Internet-Draft        Client Security UI for RTCWEB            June 2011


1.  Introduction

   RTCWEB clients - including, but not limited to web browsers - should
   transmit and receive audio and video media over an encrypted channel
   whenever practical.  It is important for a user to be able to
   determine the level of security provided for the currently-active
   media channel(s).  This document provides a set of requirements that
   - if implemented - provide the user with that ability.


2.  Security Inspector Requirements for Clients

   A client MUST provide a user interface through which a user may
   determine the security characteristics for the currently-audible
   audio stream(s).

   A client MUST provide a user interface through which a user may
   determine the security characteristics for currently-visible video
   stream(s).

   A client MUST provide a user interface through which a user may
   determine the security characteristics for transmissions of their
   microphone audio.

   A client MUST provide a user interface through which a user may
   determine the security characteristics for transmissions of their
   camera video.

   The "security characteristics" MUST include an indication as to
   whether or not the transmission is encrypted, and if so, a brief
   description of the cipher in use.  (For example: "AES-CBC" or "Null
   Cipher".)

   If the transmission is encrypted, the "security characteristics" MUST
   include an indication as to the source of the keying material,
   particularly whether the keying material was delivered out-of-band
   (from a server) or was generated as a result of a pairwise
   negotiation.

   If possible for the cryptosystem in use, the "security
   characteristics" MUST include information regarding the authenticity
   of the far station identity.  (For example, in the case of a self-
   signed certificate with RSA key the contents of the certificate and
   the key fingerprint.)

   If possible for the cryptosystem in use, the "security
   characteristics" SHOULD include a Short Authentication String which
   may be used by the user to authenticate the far station identity and



Kaufman                  Expires January 1, 2012                [Page 3]


Internet-Draft        Client Security UI for RTCWEB            June 2011


   keying integrity (specifically, the presence or lack of a man-in-the-
   middle that may be in collusion with the service provider to attempt
   to bypass authentication tests) by communicating this string out-of-
   band with the far party.

   If the transmission is encrypted, the "security characteristics"
   SHOULD indicate whether or not the keying algorithm is able to
   provide perfect forward secrecy.

   In the case of a web browser client, the "display of security
   characteristics" MUST take the form of an inspection panel or dialog
   provided by the browser chrome, as any user interface rendered in-
   browser cannot be sufficiently trusted.


3.  Other Advantages

   In addition to the security advantages provided to users, this
   requirement will simplify debugging, particularly when building
   interoperable clients.


4.  Security Considerations

   These requirements enhance the communication security experienced by
   "interested users", that is to say users who are sufficiently careful
   that they utilize these mechanisms to actually inspect the security
   of their communications.  Like the ability to inspect SSL
   certificates for HTTPS/TLS connections, this ability is of little use
   to those who do not actively choose to use it, but is critical to a
   subset of the user population.


Author's Address

   Matthew Kaufman
   Skype
   3210 Porter Drive
   Palo Alto, California  95060
   US

   Phone: +1 831 440 8771
   Email: matthew.kaufman@skype.net








Kaufman                  Expires January 1, 2012                [Page 4]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/