idnits 2.17.1 draft-kaufman-rtcweb-security-ui-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 67: '... A client MUST provide a user interf...' RFC 2119 keyword, line 71: '... A client MUST provide a user interf...' RFC 2119 keyword, line 75: '... A client MUST provide a user interf...' RFC 2119 keyword, line 79: '... A client MUST provide a user interf...' RFC 2119 keyword, line 83: '...characteristics" MUST include an indic...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2011) is 4677 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB M. Kaufman 3 Internet-Draft Skype 4 Intended status: Standards Track June 30, 2011 5 Expires: January 1, 2012 7 Client Security User Interface Requirements for RTCWEB 8 draft-kaufman-rtcweb-security-ui-00 10 Abstract 12 This document calls for a requirement to be imposed on RTCWEB client 13 user interfaces whereby the user may inspect the current media 14 security status. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 1, 2012. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Security Inspector Requirements for Clients . . . . . . . . . . 3 52 3. Other Advantages . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1. Introduction 58 RTCWEB clients - including, but not limited to web browsers - should 59 transmit and receive audio and video media over an encrypted channel 60 whenever practical. It is important for a user to be able to 61 determine the level of security provided for the currently-active 62 media channel(s). This document provides a set of requirements that 63 - if implemented - provide the user with that ability. 65 2. Security Inspector Requirements for Clients 67 A client MUST provide a user interface through which a user may 68 determine the security characteristics for the currently-audible 69 audio stream(s). 71 A client MUST provide a user interface through which a user may 72 determine the security characteristics for currently-visible video 73 stream(s). 75 A client MUST provide a user interface through which a user may 76 determine the security characteristics for transmissions of their 77 microphone audio. 79 A client MUST provide a user interface through which a user may 80 determine the security characteristics for transmissions of their 81 camera video. 83 The "security characteristics" MUST include an indication as to 84 whether or not the transmission is encrypted, and if so, a brief 85 description of the cipher in use. (For example: "AES-CBC" or "Null 86 Cipher".) 88 If the transmission is encrypted, the "security characteristics" MUST 89 include an indication as to the source of the keying material, 90 particularly whether the keying material was delivered out-of-band 91 (from a server) or was generated as a result of a pairwise 92 negotiation. 94 If possible for the cryptosystem in use, the "security 95 characteristics" MUST include information regarding the authenticity 96 of the far station identity. (For example, in the case of a self- 97 signed certificate with RSA key the contents of the certificate and 98 the key fingerprint.) 100 If possible for the cryptosystem in use, the "security 101 characteristics" SHOULD include a Short Authentication String which 102 may be used by the user to authenticate the far station identity and 103 keying integrity (specifically, the presence or lack of a man-in-the- 104 middle that may be in collusion with the service provider to attempt 105 to bypass authentication tests) by communicating this string out-of- 106 band with the far party. 108 If the transmission is encrypted, the "security characteristics" 109 SHOULD indicate whether or not the keying algorithm is able to 110 provide perfect forward secrecy. 112 In the case of a web browser client, the "display of security 113 characteristics" MUST take the form of an inspection panel or dialog 114 provided by the browser chrome, as any user interface rendered in- 115 browser cannot be sufficiently trusted. 117 3. Other Advantages 119 In addition to the security advantages provided to users, this 120 requirement will simplify debugging, particularly when building 121 interoperable clients. 123 4. Security Considerations 125 These requirements enhance the communication security experienced by 126 "interested users", that is to say users who are sufficiently careful 127 that they utilize these mechanisms to actually inspect the security 128 of their communications. Like the ability to inspect SSL 129 certificates for HTTPS/TLS connections, this ability is of little use 130 to those who do not actively choose to use it, but is critical to a 131 subset of the user population. 133 Author's Address 135 Matthew Kaufman 136 Skype 137 3210 Porter Drive 138 Palo Alto, California 95060 139 US 141 Phone: +1 831 440 8771 142 Email: matthew.kaufman@skype.net