idnits 2.17.1 draft-farrell-sacred-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 126 has weird spacing: '...arts of the...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2000) is 8679 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) == Missing Reference: 'RFC2617' is mentioned on line 236, but not defined ** Obsolete undefined reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) == Missing Reference: 'RFC2289' is mentioned on line 248, but not defined == Missing Reference: 'RFC1760' is mentioned on line 248, but not defined == Unused Reference: 'PKCS15' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 346, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS15' ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Farrell 3 Expires: January 2001 Baltimore Technologies 4 M. Nystr�m 5 RSA Security 6 July 2000 8 Securely Available Credentials 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of [RFC2026]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 As the number, and more particularly the number of different types, 34 of devices, connecting to the Internet increases, credential 35 mobility becomes an issue for IETF standardization. This draft 36 presents some requirements, a strawman framework and outlines a 37 protocol for securely available credentials. 39 Table Of Contents 41 Status of this Memo.............................................1 42 Abstract........................................................1 43 Table Of Contents...............................................1 44 1. Introduction.................................................2 45 2. Requirements.................................................2 46 3. Framework....................................................3 47 4. Outline Protocol.............................................5 48 5. A "strong" password scheme...................................5 49 6. Open Issues..................................................6 50 7. Security Considerations......................................7 51 8. References...................................................7 52 Author's Addresses..............................................7 53 Full Copyright Statement........................................8 55 1. Introduction. 57 Private credentials are used to support various Internet protocols, 58 e.g. S/MIME, IPSec, TLS. In a number of environments end users wish 59 to use the same set of private credentials from different end user 60 equipment. In a "typical" desktop environment, the user already has 61 many tools available to allow import/export of these credentials. 62 However, with some devices, especially wireless and other more 63 constrained devices, the tools required simply do not exist. 65 This leads to a high level requirement for protocol(s) that allow 66 these private credentials to be made available over the Internet. 67 Such credentials are highly sensitive, since they are the basis for 68 many of the security features of the Internet protocols referred to 69 above. There are therefore stringent security requirements that any 70 proposed protocol(s) must meet. 72 The typical credential envisaged here is often either the entirety 73 or just the private part of what is often called a personal security 74 environment or PSE [RFC2459]. Other forms of credential are of less 75 direct interest here. 77 Since the credential concerned may be required to be present in 78 order to use PKI based authentication mechanisms, we cannot rely on 79 such mechanisms, at least for "download" (towards the end user) 80 operations. Note also that since PSEs often include "root" CA 81 information, (as well as private keys), it may not be possible to 82 depend on PKI based authentication of network servers. 84 In the remainder of this draft we present a set of requirements, 85 propose a general framework and provide an outline of a protocol to 86 meet the requirements. 88 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 89 in this document are to be interpreted as described in [RFC2119]. 91 <> 93 2. Requirements 95 The following requirements assume that the is a credential server 96 from which credentials are downloaded to the end user device, and to 97 which credentials are uploaded from an end user device. 99 1. Credential download (to end user) and upload (to credential 100 server) MUST be supported 101 2. Credentials MUST only be downloadable following user 102 authentication 103 3. Credential upload MAY require user authentication 104 4. Users MUST be able to manage their credentials stored on the 105 credential server <> 107 5. The protocol(s) MUST support a range of user authentication 108 mechanisms 109 6. The protocol(s) MUST support a range of credential formats. 110 7. The protocol(s) MUST be extensible so as to be able to support a 111 wide range of end user devices, accessed using a range of 112 transport protocols 113 8. Different end user devices MAY be used to download/upload/manage 114 the same set of credentials 115 9. Credentials MUST be protected whilst in transit 116 10. The credential server MUST NOT have easy access to the cleartext 117 credentials 118 11. It MUST be possible to ensure the confidentiality/privacy of all 119 interactions between users and credential servers 120 12. Credential servers MUST be authenticated to the user for all 121 operations except (possibly) download 122 13. It MUST be possible to authenticate the credential server to the 123 user prior to download (if the user is able to verify the 124 authentication) 125 14. It MUST be possible to cache credentials locally on the end user 126 device without unnecessarily exposing the private parts of the 127 credential 128 15. The user SHOULD only have to enter a single secret value in 129 order to download a credential. 131 3. Framework 133 The diagram below shows the components involved in the sacred 134 framework. The numbers refer to protocols that may be defined. 136 +--------+ +------------+ 137 | Client +-----------+ Credential | 138 +--------+ 1. | Server | 139 \ +-----+------+ 140 \ | 141 3.\ | 2. 142 \ | 143 \ +-----+------+ 144 +-----+ Repository | 145 +------------+ 147 Client: The entity that wants the credential. 148 Credential Server: The server that knows how/who/when to give 149 the credential to the client. 150 Repository: Where the credentials are stored. The 151 repository 152 might have access control features but 153 those generally aren't sufficient in 154 themselves for protecting credentials. 156 Private information in credentials must be protected by encryption. 157 The key for this encryption can be derived from a password, but can 158 also be something stronger. As an example of a stronger method, one 159 could consider the user authenticating to the credential store using 160 some strong authentication method (not requiring public-key 161 cryptography) and then downloading (over a confidentiality-protected 162 connection) not only the credentials but also (parts of) the key to 163 unlock the card. This way, the key used to protect the credentials 164 will not be derived from the user's password solely. Further, in 165 order to make it harder for a credential store administrator to find 166 out about users' private objects, the key stored at the operator's 167 server may be combined with a user-derived key to form an actual 168 key-encryption key. 170 Credentials must be integrity protected, since it would otherwise be 171 possible for an attacker to substitute parts of the credentials 172 (e.g. trusted certificates) with something more advantageous for the 173 attacker. Once again, the key for this integrity-protection may be 174 derived from a user password, but in this case, it could also be the 175 user's own private key (assuming that private objects on the token 176 are decrypted before the integrity check is done). 178 The basic framework is as follows: 180 - credential servers MUST NOT be presented with credentials in 181 cleartext form 182 - all user, credential server communications MUST use HTTP over TLS 183 - only TLS ciphersuites providing strong confidentiality MAY be used 185 The framework for uploads is as follows: 187 - the credential server MUST be authenticated, that is only TLS 188 ciphersuites providing strong confidentiality and server 189 authentication MAY be used 190 - the user sends a POST message with the POST data containing the 191 credentials and other required information 192 - upload of credentials can either be authenticated, or 193 unauthenticated, any authentication information (for the upload 194 operation itself) is carried inside the POST data 195 - the POST data MUST include information which will be used later 196 for authentication during download, this information may take 197 various forms 199 <> 202 This upload message is described in the following XML DTD: 204 205 208 209 210 211 212 213 215 OperationUploadData, if present, is intended to authenticate the 216 user for the upload operation. DownloadAuthenticationData, which 217 MUST be present, contains indicates how the user will authenticate 218 for subsequent downloads and contains method specific data. 219 CredentialData contains the format information and the actual 220 credential itself. 222 The HTTP response to this POST message SHOULD be a text/html page 223 containing a HREF, which indicates URL from which the credential MAY 224 subsequently be downloaded. 226 The download operation is as follows: 228 - HTTP authentication is used to authenticate users to credential 229 servers(*) 230 - a simple GET request for the download URL is issued 231 - the HTTP response contains the credential and information about 232 the credential format 234 (*) This assumes that an HTTP SASL authentication scheme is defined 235 in addition to the current HTTP Basic and Digest authentication 236 schemes [RFC2617]. Work on such a scheme is on-going [<>]. 238 The HTTP response MUST contain a CredentialData element as defined 239 in the above DTD. 241 <> 243 4. Outline Protocol 245 In terms of the framework above, the specific protocol proposed as 246 mandatory to implement requires support for: 248 - OTP [RFC2289] and, optionally, S/KEY [RFC1760] for user 249 authentication 250 - uploads are unauthenticated and contain the OTP or S/KEY username 251 for downloads, and optionally the pass-phrase in the 252 DownloadAuthenticationData 253 - PKCS#15 [PKCS#15] is the credential format <> 254 - the OTP (or S/KEY) passphrase is completely separate from any 255 password based encryption keys used to protect the PKCS#15 256 credential <> 259 5. A "strong" password scheme 261 In this section we present an idea for a "strong" password scheme. 262 The idea here is to tie down the "MUST" implement mechanisms for the 263 framework. <> 265 Assumption: User has credential Cd. 267 To secure a credential: 269 Idea is to hash Cd and derive both a key and a password from the 270 hash. The security of the key/password derivation is driven by a 271 "level" (number of bits of hash used to derive password). 273 H=hash(Cd) 275 K=fold(H,level) 276 PWD=password-generator(K) 277 secured-credential=encrypt(K,Cd) 279 password-generator can be the OTP six word picker scheme (apparently 280 about 11 bits per word) 282 fold function can fold/truncate the hash to a key, based on the 283 number of bits indicated in the level (e.g. level1 is 40 bit; level 284 2 = 60 bit; level 3 = 80 bit) 286 User uploads nickname + secured-credential to credential server. 288 When roaming: 290 user->server: nickname 291 server->user: secured-credential 293 To expose credential: 295 K=reverse-password(PWD) 296 recovered=decrypt(K,secured-credential) 297 status=compare(fold(H(recovered)),K) 299 6. Open Issues 301 This document is intended to foster discussion of the requirements, 302 framework and protocols that might be used to support credential 303 mobility. However, the authors recognize that there are many issues 304 that remain to be resolved. Some of the most pressing are: 306 IPR: Some of the useful mechanisms are encumbered 308 Robustness: Credential stores should not unacceptably increase the 309 potential for denial-of-service or other attacks 311 Performance: Users should not typically have to wait too long for 312 access to credentials 314 Bootstrapping: The use of, e.g. TLS server authentication, depends 315 on the client having a (set of) trusted root(s) - as the protocol 316 may be providing these roots, there may be some hard bootstrapping 317 issues. 319 Finally, we note that whether or not the user authentication, 320 credential protection and specific credential formats should 321 be separated, or should be intertwined, is an open issue that 322 warrants careful consideration. 324 7. Security Considerations 326 Mobile credentials will never be as secure as a "pure" smart card 327 solution. However, reasonable security may be accomplished through 328 some simple means, as outlined above. One should keep in mind, 329 however, that platforms to which credentials are downloaded usually 330 cannot be regarded as tamper-resistant, and it therefore is not too 331 hard to analyze contents of their memories. Further, storage of 332 private keys, even if they are encrypted, on a credential server, 333 will be unacceptable in some environments. 335 8. References 337 [PKCS15] "PKCS #15 v1.1: Cryptographic Token Information 338 Syntax Standard," RSA Laboratories, June 2000. 339 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 340 3", RFC 2026. 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", RFC 2119. 343 [RFC2459] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet 344 Public Key Infrastructure - X.509 Certificate and CRL 345 profile", RFC 2459. 346 [RFC2616] "R. Fielding, J. Gettys, J. Mogul,, H. Frysyk, L. 347 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 348 Protocol - HTTP/1.1", RFC 2616. 350 Author's Addresses 352 Stephen Farrell, 353 Baltimore Technologies, 354 61/62 Fitzwilliam Lane, 355 Dublin 2, 356 IRELAND 358 tel: +353-1-647-3000 359 email: stephen.farrell@baltimore.ie 361 Magnus Nystr�m 362 RSA Security 363 Box 10704 364 121 29 Stockholm 365 Sweden 366 tel: +46 8 725 0900 367 email: magnus@rsasecurity.com 369 Full Copyright Statement 371 Copyright (C) The Internet Society (date). All Rights Reserved. 373 This document and translations of it may be copied and furnished to 374 others, and derivative works that comment on or otherwise explain it 375 or assist in its implementation may be prepared, copied, published 376 and distributed, in whole or in part, without restriction of any 377 kind, provided that the above copyright notice and this paragraph 378 are included on all such copies and derivative works. In addition, 379 the ASN.1 module presented in Appendix B may be used in whole or in 380 part without inclusion of the copyright notice. However, this 381 document itself may not be modified in any way, such as by removing 382 the copyright notice or references to the Internet Society or other 383 Internet organizations, except as needed for the purpose of 384 developing Internet standards in which case the procedures for 385 copyrights defined in the Internet Standards process shall be 386 followed, or as required to translate it into languages other than 387 English. 389 The limited permissions granted above are perpetual and will not be 390 revoked by the Internet Society or its successors or assigns. This 391 document and the information contained herein is provided on an "AS 392 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 393 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 394 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 395 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 396 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.