idnits 2.17.1 draft-ietf-msec-mikey-ecc-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 599. 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 abstract seems to contain references ([RFC3830]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (June 11, 2007) is 6157 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: 'P' is mentioned on line 177, but not defined == Missing Reference: 'IDr' is mentioned on line 316, but not defined == Missing Reference: 'CHASH' is mentioned on line 269, but not defined == Missing Reference: 'SIGNr' is mentioned on line 369, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-IEC-15946-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Brown 3 Internet-Draft E. Chin 4 Intended status: Standards Track C. Tse 5 Expires: December 13, 2007 Certicom Corp. 6 June 11, 2007 8 ECC Algorithms for MIKEY 9 draft-ietf-msec-mikey-ecc-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 13, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document proposes extensions to the authentication, encryption 43 and digital signature methods described for use in MIKEY, employing 44 elliptic-curve cryptography (ECC). These extensions are defined to 45 align MIKEY with other ECC implementations and standards. 47 It should be noted that this document is not self-contained; it uses 48 the notations and definitions of [RFC3830]. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. MIKEY-DHSIGN with ECDSA or ECGDSA . . . . . . . . . . . . . . 5 54 3. MIKEY-DHSIGN with ECDH . . . . . . . . . . . . . . . . . . . . 6 55 4. MIKEY-ECIES . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 5. MIKEY-ECMQV . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 6. Additional Payload Encoding . . . . . . . . . . . . . . . . . 11 58 6.1. ECC Point payload (ECCPT) . . . . . . . . . . . . . . . . 11 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 65 Intellectual Property and Copyright Statements . . . . . . . . . . 18 67 1. Introduction 69 This document describes additional algorithms for use in MIKEY. The 70 document assumes that the reader is familiar with the MIKEY protocol. 72 The MIKEY protocol [RFC3830] defines three methods for transporting 73 or establishing keys: with the use of a pre-shared key, public-key 74 encryption (MIKEY-RSA), and Diffie-Hellman (DH) key exchange (MIKEY- 75 DHSIGN). This document extends MIKEY-DHSIGN to use Elliptic Curve 76 Digital Signature Algorithm (ECDSA) or Elliptic Curve German Digital 77 Signature Algorithm (ECGDSA) as the signature algorithm and further 78 extends MIKEY-DHSIGN to use Elliptic Curve Diffie-Hellman (ECDH) 79 groups. In addition, this document introduces two new methods based 80 on the the Elliptic Curve Integrated Encryption Scheme (ECIES) and 81 Elliptic Curve Menezes-Qu-Vanstone (ECMQV). The ECIES method (MIKEY- 82 ECIES) is similar to MIKEY-RSA method, and the ECMQV method (MIKEY- 83 ECMQV) is similar to MIKEY-DHSIGN method. 85 Implementations have shown that elliptic curve algorithms can 86 significantly improve performance and security-per-bit over other 87 recommended algorithms. The purpose of this document is to expand 88 the options available to implementers of MIKEY to take advantage of 89 these benefits. 91 In addition, elliptic curve algorithms are capable of providing 92 security consistent with AES keys of 128, 192, and 256 bits without 93 extensive growth in asymmetric key sizes. The following table, taken 94 from [HOF] and [LEN], gives approximate comparable key sizes for 95 symmetric systems, ECC systems, and DH/DSA/RSA systems. The 96 estimates are based on the running times of the best algorithms known 97 today. 99 Symmetric | ECC2N | ECP | DH/DSA/RSA 100 80 | 163 | 192 | 1024 101 128 | 283 | 256 | 3072 102 192 | 409 | 384 | 7680 103 256 | 571 | 521 | 15360 105 Table 1: Comparable key sizes 107 Thus, for example, when securing a 192-bit symmetric key, it is 108 prudent to use either 409-bit ECC2N, 384-bit ECP, or 7680-bit DH/DSA/ 109 RSA. With smaller key sizes the symmetric keys would be 110 underprotected. 112 Section 2 describes the extension of MIKEY-DHSIGN to use the ECDSA or 113 ECGDSA signature algorithm. Section 3 describes the extension of 114 MIKEY-DHSIGN to use ECDH groups. Section 4 describes the MIKEY-ECIES 115 method. Section 5 describes the MIKEY-ECMQV method. Section 6 116 describes additional payloads required to support these new methods. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 2. MIKEY-DHSIGN with ECDSA or ECGDSA 124 MIKEY-DHSIGN is described in Section 3.3 of [RFC3830]. The 125 Initiator's message includes SIGNi, a signature covering the 126 Initiator's message. As well, the Responder's message includes 127 SIGNr, a signature covering the Responder's message. According to 128 Section 4.2.6 of [RFC3830], the signature algorithm applied is 129 defined by, and dependent on the certificate used. It is MANDATORY 130 to support RSA PKCS#1, v1.5, and it is RECOMMENDED to support RSA 131 PSS. Instead of these signature algorithms, ECDSA or ECGDSA may be 132 used to allow shorter and more efficient signatures. 134 ECDSA signatures are detailed in [ANSI-X9.62] and ECGDSA signatures 135 are detailed in [ISO-IEC-15946-2]. Curve selection and other 136 parameters will be defined by, and dependent on the certificate used. 137 When generating signatures, the hash function that MUST be used 138 depends on the key size, as follows: 140 ECC2N | ECP | Hash To Use 141 163 | 192 | SHA-1 142 233 | 224 | SHA-224 143 283 | 256 | SHA-256 144 409 | 384 | SHA-384 145 571 | 521 | SHA-512 147 Table 2: Hash to use with ECDSA and ECGDSA 149 The signature payload (SIGN) specified in Section 6.5 of [RFC3830] 150 can be used without modification. Two additional S types for ECDSA 151 and ECGDSA are defined as follows: 153 S type | Value | Comments 154 ------------------------------------- 155 ECDSA | 2 | ECDSA signature [ANSI_X9.62] 156 ECGDSA | 3 | ECGDSA signature [ISO/IEC_15946-2] 158 [RFC3279] describes algorithms and identifiers for Internet X.509 159 certificates and CRLs. It includes ECC algorithms and identifiers. 161 To use the ECDSA or ECGDSA signature algorithm with Elliptic Curve 162 Diffie-Hellman, this extension to MIKEY-DHSIGN may be combined with 163 the extension described in Section 3. 165 3. MIKEY-DHSIGN with ECDH 167 MIKEY-DHSIGN is described in Section 3.3 of [RFC3830]. According to 168 Section 4.2.7 of [RFC3830], the support for OAKLEY 5 is MANDATORY and 169 support for OAKLEY 1 and OAKLEY 2 are OPTIONAL. Instead of these 170 Diffie-Hellman (DH) groups, elliptic curve Diffie-Hellman (ECDH) 171 groups may significantly improve performance and security. 173 The ECDH groups to be used by MIKEY are the groups recommended by 174 NIST in FIPS 186-2 [FIPS-186-2]. Detailed descriptions of the ECDH 175 groups can be found in each of FIPS 186-2 [FIPS-186-2] and SEC 2 176 [SEC2]. The ECDH groups use elliptic curves over GF[2^N] with N 177 prime or over GF[P] with P prime. Eleven of the groups proposed here 178 have been assigned identifiers by IANA [IANA] and the remaining five 179 might later be assigned identifiers by IANA. The group with IANA 180 number 6 is described in [ANSI-X9.62] and [SEC2], with object 181 identifier sect163r1, but it is not one of the fifteen curves that 182 NIST recommends [FIPS-186-2]. The remaining NIST recommended groups 183 are suggested and anticipated to be assigned IANA numbers as 184 specified in Table 3. 186 id Group Type Group Description NIST Name SEC 2 OID 187 -- ---------- ----------------- --------- --------- 189 22 2 ECP ECPRGF192Random P-192 secp192r1 190 23 3 EC2N EC2NGF163Random B-163 sect163r2 191 7 3 EC2N EC2NGF163Koblitz K-163 sect163k1 192 6 3 EC2N EC2NGF163Random2 none sect163r1 194 24 2 ECP ECPRGF224Random P-224 secp224r1 195 25 3 EC2N EC2NGF233Random B-233 sect233r1 196 26 3 EC2N EC2NGF233Koblitz K-233 sect233k1 198 19 2 ECP ECPRGF256Random P-256 secp256r1 199 8 3 EC2N EC2NGF283Random B-283 sect283r1 200 9 3 EC2N EC2NGF283Koblitz K-283 sect283k1 202 20 2 ECP ECPRGF384Random P-384 secp384r1 203 10 3 EC2N EC2NGF409Random B-409 sect409r1 204 11 3 EC2N EC2NGF409Koblitz K-409 sect409k1 206 21 2 ECP ECPRGF521Random P-521 secp521r1 207 12 3 EC2N EC2NGF571Random B-571 sect571r1 208 13 3 EC2N EC2NGF571Koblitz K-571 sect571k1 210 Table 3: Recommended Groups and Names 212 The ECDH groups in Table 3 are arranged into 5 classes, corresponding 213 to approximately equivalent security strengths. To encourage 214 interoperability, implementations that support one of these classes, 215 SHOULD support the one group in that class that is defined over a 216 prime field (which will be one of P-192, P-224, P-256, P-384, or 217 P-521). Implementations SHOULD support one of P-256 or P-384. 218 Implementations MAY support any set of groups. 220 The DH data payload (DH) specified in Section 6.4 of [RFC3830] can be 221 used without modification. Additional DH-Group identifiers are 222 required as follows: 224 DH-Group | Value 225 --------------------------------------|------- 226 ECPRGF192Random / P-192 / secp192r1 | 3 227 EC2NGF163Random / B-163 / sect163r2 | 4 228 EC2NGF163Koblitz / K-163 / sect163k1 | 5 229 EC2NGF163Random2 / none / sect163r1 | 6 230 | 231 ECPRGF224Random / P-224 / secp224r1 | 7 232 EC2NGF233Random / B-233 / sect233r1 | 8 233 EC2NGF233Koblitz / K-233 / sect233k1 | 9 234 | 235 ECPRGF256Random / P-256 / secp256r1 | 10 236 EC2NGF283Random / B-283 / sect283r1 | 11 237 EC2NGF283Koblitz / K-283 / sect283k1 | 12 238 | 239 ECPRGF384Random / P-384 / secp384r1 | 13 240 EC2NGF409Random / B-409 / sect409r1 | 14 241 EC2NGF409Koblitz / K-409 / sect409k1 | 15 242 | 243 ECPRGF521Random / P-521 / secp521r1 | 16 244 EC2NGF571Random / B-571 / sect571r1 | 17 245 EC2NGF571Koblitz / K-571 / sect571k1 | 18 247 When using the ECDH groups, the DH-value in the DH data payload (DH) 248 is the octet string representation specified in ANSI X9.62 249 [ANSI-X9.62] and [SEC1]. 251 If the initiator chooses secret i and the responder chooses secret r, 252 then the raw shared secret is the x-coordinate(only) of (ir)*G. 254 To use ECDH and ECDSA signature algorithm or to use ECDH and ECGDSA 255 signature algorithm, this extension to MIKEY-DHSIGN may be combined 256 with the extension described in Section 2. 258 4. MIKEY-ECIES 260 The Elliptic Curve Integrated Encryption Scheme (ECIES) is a public- 261 key encryption scheme based on ECC. Section 3.2 of [RFC3830] already 262 specifies a public-key encryption method (MIKEY-RSA). Here we 263 describe the new MIKEY-ECIES method. 265 Initiator Responder 267 I_MESSAGE = 268 HDR, T, RAND, [IDi|CERTi], [IDr], {SP}, 269 KEMAC, [CHASH], PKE, SIGNi ---> 271 R_MESSAGE = 272 [<---] HDR, T, [IDr], V 274 As with the MIKEY-RSA case, the main objective of the Initiator's 275 message is to transport one or more TGKs and a set of security 276 parameters to the Responder in a secure manner. In general, the 277 MIKEY-ECIES and MIKEY-RSA methods are exactly the same, except that 278 the supported signature algorithm and the public key encryption 279 algorithm are different. 281 The signature algorithm applied is defined by, and dependent on the 282 certificate used. The MIKEY-ECIES method supports ECDSA as described 283 in [ANSI-X9.62] and ECGDSA as described in [ISO-IEC-15946-2]. The 284 SIGNi will use either ECDSA or ECGDSA as a signature algorithm, as 285 described in Section 2. 287 The public key encryption algorithm applied is defined by, and 288 dependent on the certificate used. The MIKEY-ECIES method supports 289 ECIES as described in detail in [SEC1]. For ECIES, the key 290 derivation function that MUST be used is ANSI-X9.63-KDF as described 291 in [SEC1]. As well, the MAC scheme that MUST be used is HMAC-SHA-1- 292 160. The 'standard' elliptic curve Diffie-Hellman primitive MUST be 293 used (as opposed to 'cofactor'). The symmetric encryption scheme 294 that MUST be used depends on the key size, as follows: 296 ECC2N | ECP | Symmetric Cipher To Use 297 163 | 192 | 3DES-CBC 298 233 | 224 | AES-128-CBC 299 283 | 256 | AES-128-CBC 300 409 | 384 | AES-256-CBC 301 571 | 521 | AES-256-CBC 303 Table 4: Symmetric cipher to use with ECIES 305 5. MIKEY-ECMQV 307 ECMQV (Elliptic Curve Menezes-Qu-Vanstone) is defined in ANSI X9.63 308 [ANSI-X9.63]. ECMQV provides mutual authentication between the 309 communicating parties and key establishment for the secure transport 310 of data. Here we describe the new MIKEY-ECMQV method based on the 311 2-pass protocol. 313 Initiator Responder 315 I_MESSAGE = 316 HDR, T, RAND, [IDi|CERTi], [IDr], 317 {SP}, ECCPTi, SIGNi ---> 319 R_MESSAGE = 320 [<---] HDR, T, [IDr|CERTr], 321 IDi, ECCPTr, ECCPTi, V 323 The MIKEY-ECMQV method is similar to the MIKEY-DHSIGN method, except 324 that with MIKEY-ECMQV, a variable-length shared secret is created 325 using ECMQV instead of a fixed-length shared secret. Same as the 326 MIKEY-DHSIGN method, this method cannot be used to create group keys; 327 it can only be used to create single peer-to-peer keys. 329 The MIKEY-ECMQV method create a variable-length shared secret. From 330 this shared secret, the TGK and the auth_key for the Responder's 331 verification message are derived. The first portion of the shared 332 secret is the TGK, and the second portion of the shared secret is the 333 auth_key. The length of TGK is specified in ECCPT payload by the 334 Initiator. The length of auth_key is derived from the authentication 335 algorithm, which is also specified in ECCPT payload by the Initiator. 337 The main objective of the Initiator's message is to provide the 338 Responder with its ephemeral public key represented by the elliptic 339 curve point (ECCPTi), and a set of security protocol parameters. 340 These parameters include the authentication algorithm for the 341 Responder's verification message, the length of TGK, and the key 342 validity information. 344 The SIGNi is a signature covering the Initiator's message using the 345 Initiator's signature key from the Initiator's certificate. The 346 signature algorithm applied is defined by, and dependent on the 347 certificate used. The MIKEY-ECMQV method supports ECDSA as described 348 in [ANSI-X9.62] and ECGDSA as described in [ISO-IEC-15946-2]. The 349 SIGNi will use either ECDSA or ECGDSA as a signature algorithm, as 350 described in Section 2. 352 The main objective of the Responder's message is to provide the 353 Initiator with its ephemeral public key represented by the elliptic 354 curve point (ECCPTr). The set of security protocol parameters are 355 the same as the one in the Initiator's message. 357 If the Initiator's message is authenticated and accepted by the 358 Responder, and the ECMQV shared secret is created successfully, then 359 the verification message (V) is created using the auth_key. V is 360 calculated in the same way as in the MIKEY-PSA method (see Section 361 5.2 of [RFC3830]). 363 If the Responder does not support the set of parameters suggested by 364 the Initiator, the error message SHOULD include the supported 365 parameters (see Section 5.1.1 of [ANSI-X9.63]). 367 The error message is formed as: 369 HDR, T, {ERR}, {SP}, [SIGNr] 371 In case of error, the ECMQV shared secret should not be computed. 372 Without the shared secret, V cannot be generated. As a result, the 373 error message should include a SIGNr instead of V, in the cases when 374 the Responder is able to authenticate the Initiator's message. 376 The SIGNr is a signature covering the Responder's error message using 377 the Responder's signature key from the Responder's certificate. The 378 signature algorithm applied is defined by, and dependent on the 379 certificate used. The MIKEY-ECMQV method support ECDSA as described 380 in [ANSI-X9.62] and ECGDSA as described in [ISO-IEC-15946-2]. The 381 SIGNi will use either ECDSA or ECGDSA as a signature algorithm, as 382 described in Section 2. 384 2-pass ECMQV is described in detail in ANSI X9.63 [ANSI-X9.63]. 386 6. Additional Payload Encoding 388 6.1. ECC Point payload (ECCPT) 390 The ECCPT payload carries a point on the elliptic curve used in 391 MIKEY-ECMQV. The payload identifier is 22. 393 1 2 3 394 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 ! Next payload ! ECC Curve ! ECC Point ~ 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 ! Auth alg ! TGK len ! Reserv! KV ! 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 ! KV data (optional) ~ 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 * Next payload (8 bits): identifies the payload that is added after 404 this payload. See Section 6.1 of [RFC3830] for values. 406 * ECC curve (8 bits): identifies the ECC curve used. 408 ECC curve | Value 409 --------------------------------------------- 410 ECPRGF192Random / P-192 / secp192r1 | 0 411 EC2NGF163Random / B-163 / sect163r2 | 1 412 EC2NGF163Koblitz / K-163 / sect163k1 | 2 413 EC2NGF163Random2 / none / sect163r1 | 3 414 ECPRGF224Random / P-224 / secp224r1 | 4 415 EC2NGF233Random / B-233 / sect233r1 | 5 416 EC2NGF233Koblitz / K-233 / sect233k1 | 6 417 ECPRGF256Random / P-256 / secp256r1 | 7 418 EC2NGF283Random / B-283 / sect283r1 | 8 419 EC2NGF283Koblitz / K-283 / sect283k1 | 9 420 ECPRGF384Random / P-384 / secp384r1 | 10 421 EC2NGF409Random / B-409 / sect409r1 | 11 422 EC2NGF409Koblitz / K-409 / sect409k1 | 12 423 ECPRGF521Random / P-521 / secp521r1 | 13 424 EC2NGF571Random / B-571 / sect571r1 | 14 425 EC2NGF571Koblitz / K-571 / sect571k1 | 15 427 * ECC point (variable length): ECC point data, padded to end on a 428 32-bit boundary, encoded in octet string representation specified 429 in ANSI X9.62 [ANSI-X9.62] and [SEC1]. Uncompressed format MUST be 430 supported. Hybrid and compressed formats MAY be supported. 432 * Auth alg (8 bits): specifies the MAC algorithm used for the 433 verification message. See Section 6.2 of [RFC3830] for defined 434 values. 436 * TGK len (16 bits): the length of the TGK (in bytes). 438 * KV (4 bits): indicates the type of key validity period specified. 439 This may be done by using an SPI (alternatively an MKI in SRTP) or 440 by providing an interval in which the key is valid (e.g., in the 441 latter case, for SRTP this will be the index range where the key 442 is valid). See Section 6.13 of [RFC3830] for pre-defined values. 444 * KV data (variable length): This includes either the SPI/MKI or an 445 interval (see Section 6.14 of [RFC3830]). If KV is NULL, this 446 field is not included. 448 7. Security Considerations 450 Since this document proposes new methods for use within MIKEY, many 451 of the security considerations contained within [RFC3830] apply here 452 as well. Some of the methods proposed in this document offer higher 453 cryptographic strength than those proposed in [RFC3830]. In 454 particular, there are elliptic curves corresponding to each of the 455 symmetric key sizes 80 bits, 128 bits, 192 bits, and 256 bits. This 456 allows the MIKEY key exchange to offer security comparable with 457 higher-strength AES algorithms and SHA implementations. The methods 458 proposed in this document are among those standardized by NIST in 459 FIPS 186-2 [FIPS-186-2], by the SECG in SEC2 [SEC2], and by ANSI in 460 ANSI X9.62 [ANSI-X9.62] and X9.63 [ANSI-X9.63]. 462 8. IANA Considerations 464 This document adds entries to existing MIKEY namespaces in Section 2 465 (S types in signature payloads), Section 3 (DH Group identifier in DH 466 payloads), Section 6.1 (ECCPT payload identifier), and Section 6.1 467 (ECC curve). 469 9. References 471 9.1. Normative References 473 [ANSI-X9.62] 474 American National Standards Institute, "ANSI X9.62: Public 475 Key Cryptography For The Financial Services Industry: The 476 Elliptic Curve Digital Signature Algorithm (ECDSA)", 2005. 478 [ANSI-X9.63] 479 American National Standards Institute, "ANSI X9.63: Public 480 Key Cryptography For The Financial Services Industry: Key 481 Agreement and Key Transport using Elliptic Curve 482 Cryptography", 2001. 484 [FIPS-186-2] 485 National Institute of Standards and Technology, "FIPS 486 186-2 Digital Signature Standard", 2000. 488 [IANA] Internet Assigned Numbers Authority, "Attribute Assigned 489 Numbers.", . 492 [ISO-IEC-15946-2] 493 International Organization for Standardization and 494 International Electrotechnical Commission, "ISO/IEC 495 15946-2: Information technology -- Security techniques -- 496 Cryptographic techniques based on elliptic curves -- Part 497 2: Digital signatures", 2002. 499 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 500 Identifiers for the Internet X.509 Public Key 501 Infrastructure Certificate and Certificate Revocation List 502 (CRL) Profile", RFC 3279, April 2002. 504 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 505 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 506 August 2004. 508 [SEC1] Standards for Efficient Cryptography Group, "Elliptic 509 Curve Cryptography", September 2000. 511 [SEC2] Standards for Efficient Cryptography Group, "Recommended 512 Elliptic Curve Domain Parameters", September 2000. 514 9.2. Informative References 516 [HOF] Hoffman, P. and H. Orman, "Determining strengths for 517 public keys used for exchanging symmetric keys", 518 August 2000. 520 [LEN] Lenstra, A. and E. Verhuel, "Selecting cryptographic key 521 sizes", . 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, March 1997. 526 Authors' Addresses 528 Daniel R. L. Brown 529 Certicom Corp. 530 5520 Explorer Drive 531 Mississauga, Ontario L4W 5L1 532 CANADA 534 Phone: +1-905-507-4220 535 Fax: +1-905-507-4230 536 Email: dbrown@certicom.com 537 URI: http://www.certicom.com 539 Eugene Chin 540 Certicom Corp. 541 5520 Explorer Drive 542 Mississauga, Ontario L4W 5L1 543 CANADA 545 Phone: +1-905-507-4220 546 Fax: +1-905-507-4230 547 Email: echin@certicom.com 548 URI: http://www.certicom.com 550 Chi Chiu Tse 551 Certicom Corp. 552 5520 Explorer Drive 553 Mississauga, Ontario L4W 5L1 554 CANADA 556 Phone: +1-905-507-4220 557 Fax: +1-905-507-4230 558 Email: ctse@certicom.com 559 URI: http://www.certicom.com 561 Full Copyright Statement 563 Copyright (C) The IETF Trust (2007). 565 This document is subject to the rights, licenses and restrictions 566 contained in BCP 78, and except as set forth therein, the authors 567 retain all their rights. 569 This document and the information contained herein are provided on an 570 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 571 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 572 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 573 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 574 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 575 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 577 Intellectual Property 579 The IETF takes no position regarding the validity or scope of any 580 Intellectual Property Rights or other rights that might be claimed to 581 pertain to the implementation or use of the technology described in 582 this document or the extent to which any license under such rights 583 might or might not be available; nor does it represent that it has 584 made any independent effort to identify any such rights. Information 585 on the procedures with respect to rights in RFC documents can be 586 found in BCP 78 and BCP 79. 588 Copies of IPR disclosures made to the IETF Secretariat and any 589 assurances of licenses to be made available, or the result of an 590 attempt made to obtain a general license or permission for the use of 591 such proprietary rights by implementers or users of this 592 specification can be obtained from the IETF on-line IPR repository at 593 http://www.ietf.org/ipr. 595 The IETF invites any interested party to bring to its attention any 596 copyrights, patents or patent applications, or other proprietary 597 rights that may cover technology that may be required to implement 598 this standard. Please address the information to the IETF at 599 ietf-ipr@ietf.org. 601 Acknowledgment 603 Funding for the RFC Editor function is provided by the IETF 604 Administrative Support Activity (IASA).