idnits 2.17.1 draft-ietf-smime-bfibecms-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 666. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 654. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (November 2007) is 6001 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- Possible downref: Non-RFC (?) normative reference: ref. 'DER' == Outdated reference: A later version (-07) exists of draft-martin-ibcs-06 ** Downref: Normative reference to an Informational draft: draft-martin-ibcs (ref. 'IBCS') == Outdated reference: A later version (-09) exists of draft-ietf-smime-ibearch-08 ** Downref: Normative reference to an Informational draft: draft-ietf-smime-ibearch (ref. 'IBE') ** Obsolete normative reference: RFC 2822 (ref. 'TEXTMSG') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L. Martin 3 S/MIME Working Group Voltage Security 4 Internet Draft Mark Schertler 5 Expires: May 2008 Tumbleweed Communications 6 November 2007 8 Using the Boneh-Franklin and Boneh-Boyen identity-based 9 encryption algorithms with the Cryptographic Message Syntax 10 (CMS) 12 14 Status of this Document 16 By submitting this Internet-Draft, each author represents 17 that any applicable patent or other IPR claims of which he 18 or she is aware have been or will be disclosed, and any of 19 which he or she becomes aware will be disclosed, in 20 accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet 23 Engineering Task Force (IETF), its areas, and its working 24 groups. Note that other groups may also distribute working 25 documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of 28 six months and may be updated, replaced, or obsoleted by 29 other documents at any time. It is inappropriate to use 30 Internet-Drafts as reference material or to cite them other 31 than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be 37 accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 42 This document describes the conventions for using the Boneh- 43 Franklin (BF) and Boneh-Boyen (BB1) identity-based 44 encryption algorithms in the Cryptographic Message Syntax 45 (CMS) to encrypt content-encryption keys. Object identifiers 46 and the convention for encoding a recipient's identity are 47 also defined. 49 Table of Contents 51 1. Introduction............................................2 52 1.1. Terminology........................................3 53 1.2. IBE overview.......................................3 54 2. Using identity-based encryption.........................4 55 3. Key encryption algorithm identifiers....................7 56 4. Processing by the sender................................8 57 5. Processing by the receiver..............................8 58 6. ASN.1 module............................................9 59 7. Security considerations................................11 60 7.1. Attacks that are outside the scope of this 61 document...............................................11 62 7.2. Attacks that are within the scope of this 63 document...............................................12 64 7.3. Attacks to which the protocols defined in this 65 document are susceptible...............................12 66 8. IANA considerations....................................13 67 9. References.............................................14 68 9.1. Normative references..............................14 69 9.2. Informative references............................14 70 Authors' Addresses........................................15 71 Intellectual property statement...........................15 72 Disclaimer of validity....................................16 73 Copyright statement.......................................16 74 Acknowledgment............................................16 76 1. Introduction 78 This document defines the way to use the Boneh-Franklin 79 [IBCS] and Boneh-Boyen [IBCS] identity-based encryption 80 (IBE) public-key algorithms in the Cryptographic Message 81 Syntax (CMS) [CMS]. IBE is a public key technology for 82 encrypting content-encryption keys (CEKs) that can be 83 implemented within the framework of the CMS: the recipient's 84 identity is incorporated into the EnvelopedData CMS content 85 type using the OtherRecipientInfo CHOICE in the 86 RecipientInfo field as defined in section 6.2.5 of [CMS]. 87 This document does not describe the implementation of the BF 88 and BB1 algorithms, which are described in detail in [IBCS]. 90 IBE algorithms are a type of public-key cryptographic 91 algorithm in which the public key is calculated directly 92 from a user's identity instead of being generated randomly. 93 This requires a different set of steps for encryption and 94 decryption than would be used with other public-key 95 algorithms, and these steps are defined in Sections 4 and 5 96 of this document respectively. 98 This document also defines the object identifiers and syntax 99 of the object that is used to define the identity of a 100 message recipient. 102 CMS values and identity objects are defined using ASN.1 103 [ASN1]. 105 1.1. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 108 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 109 and "OPTIONAL" in this document are to be interpreted as 110 described in RFC-2119 [KEYWORDS]. 112 1.2. IBE overview 114 In addition to the client components that are described in 115 this document, the following additional components are 116 required for a complete IBE messaging system. 118 o A Private-key Generator (PKG). The PKG contains the 119 cryptographic material, known as a master secret, 120 for generating an individual's IBE private key. A 121 PKG accepts an IBE user's private key request and, 122 after successfully authenticating them in some way, 123 returns their IBE private key. 125 o A Public Parameter Server (PPS). IBE System 126 Parameters include publicly sharable cryptographic 127 material, known as IBE public parameters, and 128 policy information for the PKG. A PPS provides a 129 well-known location for distribution of IBE public 130 parameters and policy information for the IBE PKG. 132 The interaction of senders and receivers of IBE-encrypted 133 messages are described in [IBE]. All communications 134 between users of an IBE system and the PPS or PKG MUST be 135 protected using TLS [TLS] as described in [IBE]. This 136 provides confidentiality and integrity of all information 137 that is delivered to users as well as authentication of 138 the PPS and PKG. 140 2. Using identity-based encryption 142 To use IBE, the ori field in RecipientInfo MUST be used. The 143 fields are set as follows: oriType is set to ibeORIType; 144 oriValue is set to ibeORIValue. 146 These fields have the following meanings: 148 ibeORIType defines the object identifier (OID) that 149 indicates that the subsequent ibeORIValue is the information 150 necessary to decrypt the message using IBE. This field MUST 151 be set to 153 ibeORIType OBJECT IDENTIFIER ::= { 154 joint-iso-itu(2) country(16) us(840) 155 organization(1) identicrypt(114334) 156 ibcs(1) cms(4) ori-oid(1) 157 } 159 ibeORIValue defines the identity that was used in the IBE 160 algorithm to encrypt the CEK. This is an IBERecipientInfo 161 type. 163 IBERecipientInfo ::= SEQUENCE { 164 cmsVersion INTEGER { v3(3) }, 165 keyFetchMethod OBJECT IDENTIFIER, 166 recipientIdentity IBEIdentityInfo, 167 serverInfo SEQUENCE SIZE (1..MAX) OF 168 OIDValuePairs OPTIONAL, 169 encryptedKey EncryptedKey 170 } 172 The fields of IBERecipientInfo have the following meanings: 174 The cmsVersion MUST be set to 3. 176 The keyFetchMethod is the OID that defines the method of 177 retrieving the private key that the recipient MUST use. How 178 to retrieve an IBE private key using the steps defined in 179 [IBE] is defined by the keyFetchMethod OID. The method for 180 retrieving private keys that is specified in [IBE] is 181 defined by cmsPPSOID. 183 cmsPPSOID OBJECT IDENTIFIER ::= { 184 joint-iso-itu-t(2) country(16) us(840) 185 organization(1) identicrypt(114334) 186 pps-schemas(3) ic-schemas(1) pps-uri(1) 187 } 189 The recipientIdentity is the data that was used to calculate 190 the IBE public key that was used to encrypt the content- 191 encryption key. This MUST be an IBEIdentityInfo type. This 192 recipientIdentity is used to calculate IBE public and 193 private keys as described in [IBCS]. 195 IBEIdentityInfo ::= SEQUENCE { 196 district IA5String, 197 serial INTEGER, 198 identitySchema OBJECT IDENTIFIER, 199 identityData OCTET STRING 200 } 202 The fields of IBEIdentityInfo have the following meanings. 204 The district and serial are unique identifiers that are used 205 to construct the URI for the location of the necessary IBE 206 public parameters. The construction and use of this URI is 207 defined in [IBE]. 209 The identitySchema defines the format that is used to encode 210 the information that defines the identity of the recipient. 211 This MUST be set to cmsIdentityOID to indicate that 212 identityData contains an EmailIdentitySchema type. 214 cmsIdentityOID OBJECT IDENTIFIER ::= { 215 joint-iso-itu-t(2) country(16) us(840) 216 organization(1) identicrypt(114334) 217 keyschemas(2) icschemas(1) RFC822email(1) 218 } 220 The identityData field contains the identify information for 221 the recipient. If the contents of the field is an ASN.1 222 structure, the structure MUST be DER encoded [DER] before 223 placing it in the OCTET STRING. 225 EmailIdentitySchema ::= SEQUENCE { 226 RFC822Email IA5String, 227 time GeneralizedTime 228 } 230 The RFC822email is the e-mail address of the recipient in 231 the format defined by [TEXTMSG]. E-mail addresses that 232 contain non-ASCII characters MUST be encoded using punycode 233 [PUNYCODE]. 235 The value of "time" is the UTC time after which the sender 236 wants to let the recipient decrypt the message, so it may be 237 called the "not-before" time. This is usually set to the 238 time when the message is encrypted, but MAY be set to a 239 future time. UTC time values are expressed to the nearest 240 second. 242 The sender of an IBE-encrypted message may want to express 243 this time rounded to a time interval to create a key 244 lifetime. A key lifetime reduces the number of IBE private 245 keys that a recipient needs to retrieve, but still forces 246 the IBE user to periodically re-authenticate. Based on the 247 time interval chosen a recipient would only have to retrieve 248 a new IBE key once during the interval. To do this, follow 249 the following steps. Let "time-interval" be the number of 250 seconds in this larger time interval. 252 1. Find the GeneralizedTime for the not-before value. 253 2. Convert this GeneralizedTime into the number of 254 seconds since January 1, 1970. Call this 255 "total-time." 256 3. Calculate reduced-time = (floor (total-time / 257 time-interval)) * time-interval. 258 4. Convert reduced-time to a GeneralizedTime to get the 259 not-before "time" value. 261 An example of this algorithm for computing a one week time 262 interval is as follows. 264 1. Say the GeneralizedTime is 20020401000000Z. 265 2. Then the total-time is 1017612000. 266 3. A time-interval of 1 week is 604800 seconds. 267 So the reduced-time = (floor(1017612000/604800)) * 268 604800 = 1017273600. 269 4. This gives the reduced-time GeneralizedTime 270 form of the reduced-time of 20020328000000Z. 272 When issuing IBE private keys, a PKG SHOULD NOT issue them 273 too far into the future. This restriction is to prevent an 274 adversary who obtains an IBE user's authentication 275 credentials from requesting private keys far into the future 276 and therefore negating the periodic IBE user re- 277 authentication that key lifetime provides. For example if a 278 one week period is chosen for the key lifetime, then IBE 279 private keys should not be issued more than 1 week in 280 advance. Otherwise once an adversary gains access to the PKG 281 via the stolen IBE user credentials they can request all 282 future keys and negate the IBE user authentication 283 restraints in place. 285 The serverInfo is an optional series of OID-value pairs that 286 can be used to convey any other information that might be 287 used by a PKG. Examples of such information could include 288 the user interface that the recipient will experience. 289 Differences in the user interface could include localization 290 information or commercial branding information. 292 The encryptedKey is the result of encrypting the CEK with an 293 IBE algorithm using recipientIdentity as the IBE public key. 295 3. Key encryption algorithm identifiers 297 The BF and BB1 algorithms as defined in [IBCS] have the 298 following object identifiers. These object identifiers are 299 also defined in the ASN.1 module in [IBCS]. 301 bf OBJECT IDENTIFIER ::= { 302 joint-iso-itu-t(2) country(16) us(840) 303 organization(1) identicrypt(114334) 304 ibcs(1) ibcs1(1) ibe-algorithms(2) bf(1) 305 } 307 This is the object identifier that MUST be inserted in the 308 keyEncryptionAlgorithm field in the CMS when the BF 309 algorithm is used to encrypt the CEK. 311 bb1 OBJECT IDENTIFIER ::= { 312 joint-iso-itu-t(2) country(16) us(840) 313 organization(1) identicrypt(114334) 314 ibcs(1) ibcs1(1) ibe-algorithms(2) bb1(2) 315 } 317 This is the object identifier that MUST be inserted in the 318 keyEncryptionAlgorithm field in the CMS when the BB1 319 algorithm is used to encrypt the CEK. 321 4. Processing by the sender 323 The sender of a message that uses IBE to encrypt content- 324 encryption keys performs the following steps: 326 1. Selects a set of IBE public parameters to use in the 327 subsequent steps in accordance with his local security 328 policy. He then determines the URI where the public 329 parameters can be obtained using the process described in 330 [IBE]. This information MUST be encoded in the 331 IBEIdentityInfo as described in Section 2. 333 2. Sets the fields of an OtherRecipientInfo object to 334 their appropriate values as described in Section 2. 336 3. Calculates an IBE public key as defined in [IBCS] 337 using this IBEIdentityInfo as the identity information. 339 4. This IBE public key is then used to encrypt the 340 content-encryption key (CEK), using the algorithms that are 341 defined in [IBCS]. 343 5. Sets encryptedKey to the IBE-encrypted CEK. 345 6. Within the CMS, keyEncryptionAlgorithm MUST then be 346 set to the appropriate OID for the IBE algorithm that was 347 used (see Section 3). 349 5. Processing by the receiver 351 Upon receiving a message that has a CEK encrypted with IBE, 352 the recipient performs the following steps to decrypt the 353 CEK: 355 1. Determines that the CEK is IBE-encrypted by noting that 356 the oriType of the OtherRecipientInfo type is set to 357 ibeORIType. 359 2. Determines that the recipientIdentity was used as the 360 identity in IBE encryption of the CEK. 362 3. Determines the location of the IBE public parameters 363 and the IBE Private Key Generator as described in 364 [IBE]. 366 4. Obtains the IBE public parameters from the location 367 determined in Step 3 using the process defined in 368 [IBE]. 370 5. Obtains the IBE private key needed to decrypt the 371 encrypted CEK using the process defined in [IBE]. 373 6. Decrypts the CEK using the IBE private key obtained in 374 Step 4 using the algorithms described in [IBCS]. 376 6. ASN.1 module 378 The following ASN.1 module summarizes the ASN.1 definitions 379 discussed in this document. 381 IBECMS-module { 382 joint-iso-itu-t(2) country(16) us(840) 383 organization(1) identicrypt(114334) 384 ibcs(1) cms(4) module(5) version(1) 385 } 387 DEFINITIONS IMPLICIT TAGS ::= BEGIN 389 IBEOtherRecipientInfo ::= SEQUENCE { 390 oriType OBJECT IDENTIFIER, 391 oriValue IBERecipientInfo 392 } 394 ibeORIType OBJECT IDENTIFIER ::= { 395 joint-iso-itu-t(2) country(16) us(840) 396 organization(1) identicrypt(114334) 397 ibcs(1) cms(4) ori-oid(1) 398 } 400 IBERecipientInfo ::= SEQUENCE { 401 cmsVersion INTEGER { v3(3) }, 402 keyFetchMethod OBJECT IDENTIFIER, 403 recipientIdentity IBEIdentityInfo, 404 serverInfo SEQUENCE SIZE (1..MAX) OF 405 OIDValuePairs OPTIONAL, 406 encryptedKey EncryptedKey 407 } 409 IBEIdentityInfo ::= SEQUENCE { 410 district IA5String, 411 serial INTEGER, 412 identitySchema OBJECT IDENTIFIER, 413 identityData OCTET STRING 414 } 416 OIDValuePairs ::= SEQUENCE { 417 fieldID OBJECT IDENTIFIER, 418 fieldData OCTET STRING 419 } 421 EncryptedKey ::= OCTET STRING 423 EmailIdentitySchema ::= SEQUENCE { 424 RFC822Email IA5String, 425 time GeneralizedTime 426 } 427 cmsIdentityOID OBJECT IDENTIFIER ::= { 428 joint-iso-itu-t(2) country(16) us(840) 429 organization(1) identicrypt(114334) 430 keyschemas(2) icschemas(1) RFC822email(1) 431 } 433 cmsPPSOID OBJECT IDENTIFIER ::= { 434 joint-iso-itu-t(2) country(16) us(840) 435 organization(1) identicrypt(114334) 436 pps-schemas(3) ic-schemas(1) pps-uri(1) 437 } 439 END 441 7. Security considerations 443 This document is based on [CMS] and [IBCS], and the relevant 444 security considerations of those documents apply. 446 7.1. Attacks that are outside the scope of this document 448 Attacks on the cryptographic algorithms that are used to 449 implement IBE are outside the scope of this document. Such 450 attacks are detailed in [IBCS], which defines parameters 451 that give 80-bit, 112-bit, 128-bit and 256-bit encryption 452 strength. We assume that capable administrators of an IBE 453 system will select parameters that provide a sufficient 454 resistance to cryptanalytic attacks by adversaries. 456 Attacks that give an adversary the ability to access or 457 change the information on a PPS or PKG, especially the 458 cryptographic material (referred to in this document as the 459 master secret), will defeat the security of an IBE system. 460 In particular, if the cryptographic material is compromised 461 the adversary will have the ability to recreate any user's 462 private key and therefore decrypt all messages protected 463 with the corresponding public key. To address this concern, 464 it is highly RECOMMENDED that best practices for physical 465 and operational security for PPS and PKG servers be followed 466 and that these servers be configured (sometimes known as 467 hardened) in accordance with best current practices [NIST]. 468 An IBE system SHOULD be operated in an environment where 469 illicit access to the PKG or the ability to modify the 470 information distributed by the PPS is infeasible for 471 attackers to obtain. 473 Attacks that require administrative or IBE user equivalent 474 access to machines used by either the client or the server 475 components defined in this document are also outside the 476 scope of this document. 478 We also assume that all administrators of a system 479 implementing the protocols that are defined in this document 480 are trustworthy and will not abuse their authority to bypass 481 the security provided by an IBE system. This is of 482 particular importance with an IBE system, for an 483 administrator of a PKG could potentially abuse his authority 484 and configure the PKG to grant him any IBE private key that 485 the PKG is capable of calculating. To minimize the 486 possibility of administrators doing this, a system 487 implementing IBE SHOULD implement n-out-of-m control for 488 critical administrative functions and SHOULD maintain 489 auditable logs of all security-critical events that occur in 490 an operating IBE system. 492 Similarly, we assume that users of an IBE system will behave 493 responsibly, not sharing their authentication credentials 494 with others. Thus attacks that require such assumptions are 495 outside the scope of this document. 497 7.2. Attacks that are within the scope of this document 499 Attacks within the scope of this document are those that 500 allow an adversary to: 502 o passively monitor information transmitted between 503 users of an IBE system and the PPS and PKG 505 o masquerade as a PPS or PKG 507 o perform a DOS attack on a PPS or PKG 509 o easily guess an IBE user's authentication 510 credential 512 7.3. Attacks to which the protocols defined in this document 513 are susceptible 515 All communications between users of an IBE system and the 516 PPS or PKG are protected using TLS [TLS]. The IBE system 517 defined in this document provides no additional security for 518 the communications between IBE users and the PPS or PKG. 519 Therefore the described IBE system is completely dependent 520 on the TLS security mechanisms for authentication of the PKG 521 or PPS server and for confidentiality and integrity of the 522 communications. Should there be a compromise of the TLS 523 security mechanisms, the integrity of all communications 524 between an IBE user and the PPS or PKG will be suspect. 526 The protocols defined in this document do not explicitly 527 defend against an attacker masquerading as a legitimate IBE 528 PPS or PKG. The protocols rely on the server authentication 529 mechanism of TLS [TLS]. In addition to the TLS server 530 authentication mechanism IBE client software can provide 531 protection against this possibility by providing user 532 interface capabilities that allows users to visually 533 determine that a connection to PPS and PKG servers is 534 legitimate. This additional capability can help ensure that 535 users cannot easily be tricked into providing valid 536 authorization credentials to an attacker. 538 The protocols defined in this document are also vulnerable 539 to attacks against an IBE PPS or PKG. Denial of service 540 attacks against either component can result in users unable 541 to encrypt or decrypt using IBE, and users of an IBE system 542 SHOULD take the appropriate countermeasures [DOS, BGPDOS] 543 that their use of IBE requires. 545 The IBE user authentication method used by an IBE PKG SHOULD 546 be of sufficient strength to prevent attackers from easily 547 guessing the IBE user's authentication credentials through 548 trial and error. 550 8. IANA considerations 552 All of the object identifiers used in this document were 553 assigned by the National Institute of Standards and 554 Technology (NIST), so no further action by the IANA is 555 necessary for this document. 557 9. References 559 9.1. Normative references 561 [ASN1] ITU-T Recommendation X.680: Information Technology - 562 Abstract Syntax Notation One, 1997. 564 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3852, 565 July 2004. 567 [DER] CCITT, "Recommendation X.209: Specification of Basic 568 Encoding Rules for Abstract Syntax Notation One 569 (ASN.1)," 1998. 571 [DOS] P. Ferguson and D. Senie, "Network Ingress Filtering: 572 Defeating Denial of Service Attacks which employ 573 IP Source Address Spoofing," RFC 2827, BCP 38, May 574 2000. 576 [IBCS] X. Boyen, L. Martin, "Identity-based Cryptography 577 Standard (IBCS) #1: Supersingular Curve 578 Implementations of the BF and BB1 Cryptosystems," 579 draft-martin-ibcs-06.txt. 581 [IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity- 582 based Encryption Architecture," draft-ietf-smime- 583 ibearch-08.txt. 585 [KEYWORDS] S. Brander, "Key Words for Use in RFCs to 586 Indicate Requirement Levels," BCP 14, RFC 2119, 587 March 1997. 589 [TEXTMSG] D. Crocker, "Standard for the format of ARPA 590 internet text messages," RFC 2822, April 2001. 592 [PUNYCODE] A. Costello, "Punycode: A Bootstring encoding of 593 Unicode for Internationalized Domain Names in 594 Applications (IDNA)," RFC 3492, March 2003. 596 [TLS] T. Dierks and E. Rescorla, "The Transport Layer 597 Security (TLS) Protocol Version 1.1," RFC 4346, 598 April 2006. 600 9.2. Informative references 602 [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of- 603 Service Attacks," RFC 3882, September 2004. 605 [NIST] M. Souppaya, J. Wack and K. Kent, "Security 606 Configuration Checklist Program for IT Products - 607 Guidance for Checklist Users and Developers," NIST 608 Special Publication SP 800-70, May 2005. 610 Authors' Addresses 612 Luther Martin 613 Voltage Security 614 1070 Arastradero Rd Suite 100 615 Palo Alto CA 94304 616 USA 618 Phone: +1 650 543 1280 619 Email: martin@voltage.com 621 Mark Schertler 622 Tumbleweed Communications 623 700 Saginaw Dr 624 Redwood City CA 94063 625 USA 627 Phone: +1 650 216 2039 628 Email: mark.schertler@tumbleweed.com 630 Intellectual property statement 632 The IETF takes no position regarding the validity or scope 633 of any Intellectual Property Rights or other rights that 634 might be claimed to pertain to the implementation or use of 635 the technology described in this document or the extent to 636 which any license under such rights might or might not be 637 available; nor does it represent that it has made any 638 independent effort to identify any such rights. Information 639 on the procedures with respect to rights in RFC documents 640 can be found in BCP 78 and BCP 79. 642 Copies of IPR disclosures made to the IETF Secretariat and 643 any assurances of licenses to be made available, or the 644 result of an attempt made to obtain a general license or 645 permission for the use of such proprietary rights by 646 implementers or users of this specification can be obtained 647 from the IETF on-line IPR repository at 648 http://www.ietf.org/ipr. 650 The IETF invites any interested party to bring to its 651 attention any copyrights, patents or patent applications, or 652 other proprietary rights that may cover technology that may 653 be required to implement this standard. Please address the 654 information to the IETF at ietf-ipr@ietf.org. 656 Disclaimer of validity 658 This document and the information contained herein are 659 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 660 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 661 THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 662 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 663 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 664 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 665 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR 666 A PARTICULAR PURPOSE. 668 Copyright statement 670 Copyright (C) The IETF Trust (2007). 672 This document is subject to the rights, licenses and 673 restrictions contained in BCP 78, and except as set forth 674 therein, the authors retain all their rights. 676 Acknowledgment 678 Funding for the RFC Editor function is currently provided by 679 the Internet Society.