git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@17742 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Love Hörnquist Åstrand
2006-06-29 21:01:34 +00:00
parent 7a06a1faeb
commit d1bebf6e65
4 changed files with 2285 additions and 0 deletions

View File

@@ -0,0 +1,672 @@
Network Working Group L. Hornquist Astrand
Internet-Draft Stockholm University
Expires: September 2, 2006 L. Zhu
Microsoft Corporation
March 2006
PK-INIT algorithm agility
draft-ietf-krb-wg-pkinit-alg-agility-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The PK-INIT protocol have in several places hard coded crypto
algorithms. The protocol specification needs to be updated so it can
support negotiation to upgrading to newer versions of crypto
algorithms. This document addresses this issue.
Hornquist Astrand & Zhu Expires September 2, 2006 [Page 1]
Internet-Draft PK-INIT algorithm agility March 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. paChecksum agility . . . . . . . . . . . . . . . . . . . . . . 5
4. CMS Digest Algorithm agility . . . . . . . . . . . . . . . . . 6
5. Certificate Signer Algorithm Identifier agility . . . . . . . 7
6. octetstring2key function agility . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Hornquist Astrand & Zhu Expires September 2, 2006 [Page 2]
Internet-Draft PK-INIT algorithm agility March 2006
1. Introduction
The Kerberos PK-INIT document contains several hardcoded algorithms
that was know designed at design time that they had to be replaced by
something else at a later time, this document described how to use
other algorithms other then those that are hard-coded.
Hornquist Astrand & Zhu Expires September 2, 2006 [Page 3]
Internet-Draft PK-INIT algorithm agility March 2006
2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Hornquist Astrand & Zhu Expires September 2, 2006 [Page 4]
Internet-Draft PK-INIT algorithm agility March 2006
3. paChecksum agility
The paChecksum binds the PK-INIT part of the request to main body of
the Kerberos request (KDC-REQ-BODY). This is to makes sure an
attacker can not change the request from the client to the server.
The problem is that paChecksum is hardcoded to use SHA1-1, however,
there is a mechaism to provide algorithm agility for the paChecksum
within the PK-INIT prototcol. Newer clients can choose not send the
paChecksum field, but rather add some new fields after the existing
fields, older KDC will send back know failure-code so that newer
clients can fall back to the old protocol if local policy allows
that.
If the attacker can preserve the checksum in paChecksum, an attacker
can, for example, change the KDC-REQ-BODY is to downgrade the
encryption types used, expend the expiration time, etc, and then try
to brute-force the request.
In the Public Key Encryption case of PK-INIT the reply contains a
checksum over the whole request in the asChecksum field, in this case
the client will detect any modifications to the request. Since the
asChecksum is using the associated checksum of the session key
encryption type, asChecksum field is algorithm agile.
One way to solve this problem is to add the asChecksum to the Diffie-
Hellman case reply too, and just ignore the paCheckSum field. The
KDC should still not issue tickets that are too weak, since that
exposes the problem. This is regardless of the using PK-INIT or not.
Questions for wg: Wait for Kerberos Extensions that will solve this
problem (ignore the problem for how), or use add asChecksum to DH
case.
Hornquist Astrand & Zhu Expires September 2, 2006 [Page 5]
Internet-Draft PK-INIT algorithm agility March 2006
4. CMS Digest Algorithm agility
The client can tell KDC what the supported CMS types are in the
requset packet, but there are no equivalent for KDC to the the client
what the digest algorithm are support in an reply.
Have KDC send the CMS list of supported encryption types in the
e-data field of KRB-ERROR when returning the
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error.
DER encoded TS-SD-PARAMETERS specifies supported digest algorithms.
The list is in decreasing preference order.
TD-SD-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
Hornquist Astrand & Zhu Expires September 2, 2006 [Page 6]
Internet-Draft PK-INIT algorithm agility March 2006
5. Certificate Signer Algorithm Identifier agility
The KDC can reject a certificate based on the signers hash algorithm
with the error KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED, but doesn't tell
the client what algorithm are supported.
DER encoded TS-DC-PARAMETERS specifies supported certificate digest
algorithms. The AllowedAlgorithms is in decreasing preference order.
RejectedAlgorithm may be include my the KDC to tell what algorithm
was rejected in case the rejected certificate was part of a computed
chain.
TD-DC-PARAMETERS ::= SEQUENCE {
AllowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
RejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL
}
Hornquist Astrand & Zhu Expires September 2, 2006 [Page 7]
Internet-Draft PK-INIT algorithm agility March 2006
6. octetstring2key function agility
The PK-INIT standard uses a home-grown string 2 key function in the
DH case. The function uses SHA-1 to mix and stretch the DH shared
key.
Describe how the client announces that is supports the new String to
key function. Probably by stuffing it into the supportCMSTypes field
in the request.
Use NIST SP 800 56B when its published.
Hornquist Astrand & Zhu Expires September 2, 2006 [Page 8]
Internet-Draft PK-INIT algorithm agility March 2006
7. Security Considerations
This document describes negotiation of checksum types and other
cryptographic functions. Most of this negotiation is done
unauthenticated with no way to very
Hornquist Astrand & Zhu Expires September 2, 2006 [Page 9]
Internet-Draft PK-INIT algorithm agility March 2006
8. IANA Considerations
No IANA considerations.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Hornquist Astrand & Zhu Expires September 2, 2006 [Page 10]
Internet-Draft PK-INIT algorithm agility March 2006
Authors' Addresses
Love Hornquist Astrand
Stockholm University
SE-106 91 STOCKHOLM
SWEDEN
Email: lha@it.su.se
Larry Zhu
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
Email: lzhu@microsoft.com
Hornquist Astrand & Zhu Expires September 2, 2006 [Page 11]
Internet-Draft PK-INIT algorithm agility March 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hornquist Astrand & Zhu Expires September 2, 2006 [Page 12]

View File

@@ -0,0 +1,392 @@
Network Working Group S. Josefsson
Internet-Draft SJD
Updates: 4120 (if approved) May 10, 2006
Expires: November 11, 2006
Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over
TCP
draft-ietf-krb-wg-tcp-expansion-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 11, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes an extensibility mechanism for the Kerberos
v5 protocol when used over TCP transports.
Josefsson Expires November 11, 2006 [Page 1]
Internet-Draft Kerberos V5 TCP extension May 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . 3
3. Extension Mechanism for TCP transport . . . . . . . . . . . . . 3
4. Interoperability Consideration . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Copying conditions . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Josefsson Expires November 11, 2006 [Page 2]
Internet-Draft Kerberos V5 TCP extension May 2006
1. Introduction
The Kerberos 5 [3] specification, in section 7.2.2, reserve the high
order bit in the initial length field for TCP transport for future
expansion. This document update [3] to describe the behaviour when
that bit is set. This mechanism is intended for extensions that are
specific for the TCP transport.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
3. Extension Mechanism for TCP transport
The reserved high bit of the request length field is used to signal
the use of this extension mechanism. When the reserved high bit is
set, the remaining 31 bits of the initial 4 octets are interpreted as
a bitmap. Each bit in the bitmask can be used to request a
particular extension. The 31 bits form the "extension bitmask". It
is expected that other documents will describe the details associated
with particular bits.
A 4-octet value with only the high bit set, and thus the extension
bitmask all zeros, is called a PROBE. A client may send a probe to
find out which extensions a KDC support. A client may also set
particular bits in the extension bitmask directly, if it does not
need to query the KDC for available extensions before deciding which
extension to request.
If a KDC receive a PROBE, or if a KDC does not support all extensions
corresponding to set bits in the extension bitmask, the KDC MUST
return 4 octets with the high bit set, and with the remaining bitmask
indicate which extensions it supports. The KDC SHOULD NOT close the
connection, and SHOULD wait for the client to then send a second
4-octet value, with the high bit set and the remaining bits as the
bitmask, to request a particular extension. If the second 4-octet
value is a PROBE or an unsupported extension, the KDC MUST close the
connection. This is used by the client to shutdown a session when
the KDC did not support a, by the client, required extension.
Resource avaibility considerations may influence whether, and for how
long, the KDC will wait for the client to send requests.
The behaviour when more than one non-high bit is set depends on the
Josefsson Expires November 11, 2006 [Page 3]
Internet-Draft Kerberos V5 TCP extension May 2006
particular extension mechanisms. If a requested extension (bit X)
does not specify how it interact with another requested extensions
(bit Y), the KDC MUST treat the request as a PROBE or unsupported
extension, and proceed as above.
Each extension MUST describe the structure of protocol data beyond
the length field, and the behaviour of the client and KDC. If an
extension mechanism reserve multiple bits, it MUST describe how they
interact.
4. Interoperability Consideration
Implementations with support for TCP that do not claim to conform to
RFC 4120 may not handle the high bit correctly. Behaviour may
include closing the TCP connection without any response, and logging
an error message in the KDC log. When this was written, this problem
existed in modern versions of popular implementations.
Implementations experiencing trouble getting the expected responses
from a server SHOULD assume that it does not support this extension
mechanism. Clients MAY remember this semi-permanently, to avoid
excessive logging in the server. Care should be taken to avoid
unexpected behaviour for the user when the KDC is eventually
upgraded. Implementations MAY also provide a way to enable and
disable this extension on a per-realm basis. How to handle these
backwards compatibility quirks are in general left unspecified.
5. Security Considerations
Because the initial length field is not protected, it is possible for
an active attacker (i.e., one that is able to modify traffic between
the client and the KDC) to make it appear to the client that the
server does not support this extension mechanism. Client and KDC
policies can be used to reject connections that does not use any
expansion.
6. IANA Considerations
IANA needs to create a new registry for "Kerberos 5 TCP Extensions".
The initial contents of this registry should be:
[[RFC Editor: Replace xxxx below with the number of this RFC.]]
Bit # Meaning Reference
----- ------- ---------
0..29 AVAILABLE for registration.
Josefsson Expires November 11, 2006 [Page 4]
Internet-Draft Kerberos V5 TCP extension May 2006
30 RESERVED. RFC XXXX
IANA will register values 0 to 29 after IESG Approval, as defined in
BCP 64 [2]. Assigning value 30 requires a Standards Action that
update or obsolete this document.
7. Acknowledgements
Thanks to Andrew Bartlett who pointed out that some implementations
(MIT Kerberos and Heimdal) did not follow RFC 4120 properly with
regards to the high bit, which resulted in an Interoperability
Consideration.
Nicolas Williams and Jeffrey Hutzelman provided comments that
improved the document.
8. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
Network Authentication Service (V5)", RFC 4120, July 2005.
Appendix A. Copying conditions
Copyright (C) 2005, 2006 Simon Josefsson
Regarding this entire document or any portion of it, the author makes
no guarantees and is not responsible for any damage resulting from
its use. The author grants irrevocable permission to anyone to use,
modify, and distribute it in any way that does not diminish the
rights of anyone else to use, modify, and distribute it, provided
that redistributed derivative works do not contain misleading author
or version information. Derivative works need not be licensed under
similar terms.
Josefsson Expires November 11, 2006 [Page 5]
Internet-Draft Kerberos V5 TCP extension May 2006
Author's Address
Simon Josefsson
SJD
Email: simon@josefsson.org
Josefsson Expires November 11, 2006 [Page 6]
Internet-Draft Kerberos V5 TCP extension May 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Josefsson Expires November 11, 2006 [Page 7]

View File

@@ -0,0 +1,610 @@
NETWORK WORKING GROUP L. Zhu
Internet-Draft K. Jaganathan
Expires: March 17, 2006 K. Lauter
Microsoft Corporation
September 13, 2005
ECC Support for PKINIT
draft-zhu-pkinit-ecc-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the use of Elliptic Curve certificates,
Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman
(ECDH) key agreement within the framework of PKINIT - the Kerberos
Version 5 extension that provides for the use of public key
cryptography.
Zhu, et al. Expires March 17, 2006 [Page 1]
Internet-Draft ECC Support for PKINIT September 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Using Elliptic Curve Certificates and Elliptic Curve
Signature Schemes . . . . . . . . . . . . . . . . . . . . . . 3
4. Using ECDH Key Exchange . . . . . . . . . . . . . . . . . . . 4
5. Choosing the Domain Parameters and the Key Size . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Zhu, et al. Expires March 17, 2006 [Page 2]
Internet-Draft ECC Support for PKINIT September 2005
1. Introduction
Elliptic Curve Cryptography (ECC) is emerging as an attractive
public-key cryptosystem that provides security equivalent to
currently popular public-key mechanisms such as RSA and DSA with
smaller key sizes [LENSTRA] [NISTSP80057].
Currently [PKINIT] permits the use of ECC algorithms but it does not
specify how ECC parameters are chosen and how to derive the shared
key for key delivery using Elliptic Curve Diffie-Hellman (ECDH)
[IEEE1363].
This document describes how to use Elliptic Curve certificates,
Elliptic Curve signature schemes, and ECDH with [PKINIT]. However,
it should be noted that there is no syntactic or semantic change to
the existing [PKINIT] messages. Both the client and the KDC
contribute one ECDH key pair using the key agrement protocol
described in this document.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Using Elliptic Curve Certificates and Elliptic Curve Signature
Schemes
ECC certificates and signature schemes can be used in the
Cryptographic Message Syntax (CMS) [RFC3369] content type
'SignedData'.
X.509 certificates [RFC3280] containing ECC public keys or signed
using ECC signature schemes MUST comply with [RFC3279].
The elliptic curve domain parameters recommended in [X9.62],
[FIPS186-2], and [SECG] SHOULD be used.
The signatureAlgorithm field of the CMS data type SignerInfo can
contain one of the following ECC signature algorithm identifiers:
ecdsa-with-Sha1 [ECCPKALGS]
ecdsa-with-Sha256 [ECCPKALGS]
ecdsa-with-Sha384 [ECCPKALGS]
ecdsa-with-Sha512 [ECCPKALGS]
Zhu, et al. Expires March 17, 2006 [Page 3]
Internet-Draft ECC Support for PKINIT September 2005
The corresponding digestAlgorithm field contains one of the following
hash algorithm identifiers respectively:
id-sha1 [RFC3279]
id-sha256 [ECCPKALGS]
id-sha384 [ECCPKALGS]
id-sha512 [ECCPKALGS]
Namely id-sha1 MUST be used in conjunction with ecdsa-with-Sha1, id-
sha256 MUST be used in conjunction with ecdsa-with-Sha256, id-sha384
MUST be used in conjunction with ecdsa-with-Sha384, and id-sha512
MUST be used in conjunction with ecdsa-with-Sha512.
Implementations of this specfication MUST support ecdsa-with-Sha256
and SHOULD support ecdsa-with-Sha1.
4. Using ECDH Key Exchange
This section describes how ECDH can be used as the AS reply key
delivery method [PKINIT]. Note that the protocol description is
similar to that of Modular Exponential Diffie-Hellman (MODP DH), as
described in [PKINIT].
If the client wishes to use ECDH key agreement method, it encodes its
ECDH public key value and the domain parameters [IEEE1363] for its
ECDH public key in clientPublicValue of the PA-PK-AS-REQ message
[PKINIT].
As described in [PKINIT], the ECDH domain parameters for the client's
public key are specified in the algorithm field of the type
SubjectPublicKeyInfo [RFC3279] and the client's ECDH public key value
is mapped to a subjectPublicKey (a BIT STRING) according to
[RFC3279].
The following algorithm identifier is used to identify the client's
choice of the ECDH key agreement method for key delivery.
id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
If the domain parameters are not accepted by the KDC, the KDC sends
back an error message [RFC4120] with the code
KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED [PKINIT]. This error message
contains the list of domain parameters acceptable to the KDC. This
list is encoded as TD-DH-PARAMETERS [PKINIT], and it is in the KDC's
decreasing preference order. The client can then pick a set of
domain parameters from the list and retry the authentication.
Zhu, et al. Expires March 17, 2006 [Page 4]
Internet-Draft ECC Support for PKINIT September 2005
Both the client and the KDC MUST have local policy that specifies
which set of domain parameters are acceptable if they do not have a
priori knowledge of the chosen domain parameters. The need for such
local policy is explained in Section 6.
If the ECDH domain parameters are accepted by the KDC, the KDC sends
back its ECDH public key value in the subjectPublicKey field of the
PA-PK-AS-REP message [PKINIT].
As described in [PKINIT], the KDC's ECDH public key value is encoded
as a BIT STRING according to [RFC3279].
Note that in the steps above, the client can indicate to the KDC that
it wishes to reuse ECDH keys or to allow the KDC to do so, by
including the clientDHNonce field in the request [PKINIT], and the
KDC can then reuse the ECDH keys and include serverDHNonce field in
the reply [PKINIT]. This logic is the same as that of the Modular
Exponential Diffie-Hellman key agreement method [PKINIT].
If ECDH is negotiated as the key delivery method, both the KDC and
the client calculate the shared secret value and derive the reply key
as follows:
1) Let DHSharedSecret be the x-coordinate of the shared secret value
(an elliptic curve point). DHSharedSecret is the output of
operation ECSVDP-DH as described in Section 7.2.1 of [IEEE1363].
2) DHSharedSecret is first padded with leading zeros such that the
size of DHSharedSecret in octets is the same as that of the
modulus, then represented as a string of octets in big-endian
order.
3) The DHSharedSecret value derived above is used as input to the
octetstring2key() function to derive the AS reply key k, as
described in Section 3.2.3.1 of [PKINIT].
Both the client and KDC then proceed as described in [PKINIT] and
[RFC4120].
Lastly it should be noted that ECDH can be used with any certificates
and signature schemes. However, a significant advantage of using
ECDH together with ECC certificates and signature schemes is that the
ECC domain parameters in the client or KDC certificates can be used.
This obviates the need of locally preconfigured domain parameters as
described in Section 6.
Zhu, et al. Expires March 17, 2006 [Page 5]
Internet-Draft ECC Support for PKINIT September 2005
5. Choosing the Domain Parameters and the Key Size
The domain parameters and the key size should be chosen so as to
provide sufficient cryptographic security [RFC3766]. The following
table, based on table 2 on page 63 of NIST SP800-57 part 1
[NISTSP80057], gives approximate comparable key sizes for symmetric-
and asymmetric-key cryptosystems based on the best-known algorithms
for attacking them.
Symmetric | ECC | RSA
-------------+----------- +------------
80 | 160 - 223 | 1024
112 | 224 - 255 | 2048
128 | 256 - 383 | 3072
192 | 384 - 511 | 7680
256 | 512+ | 15360
Table 1: Comparable key sizes (in bits)
Thus, for example, when securing a 128-bit symmetric key, it is
prudent to use 256-bit Elliptic Curve Cryptography (ECC), e.g. group
P-256 (secp256r1) as described below.
A set of ECDH domain parameters is also known as a curve. A curve is
a named curve if the domain paratmeters are well known and can be
identified by an Object Identifier, otherwise it is called a custom
curve. [PKINIT] supports both named curves and custom curves, see
Section 6 on the tradeoff of choosing between named curves and custom
curves.
The named curves recommended in this document are also recommended by
NIST [FIPS186-2]. These fifteen ECC curves are given in the
following table [FIPS186-2] [SECG].
Zhu, et al. Expires March 17, 2006 [Page 6]
Internet-Draft ECC Support for PKINIT September 2005
Description SEC 2 OID
----------------- ---------
ECPRGF192Random group P-192 secp192r1
EC2NGF163Random group B-163 sect163r2
EC2NGF163Koblitz group K-163 sect163k1
ECPRGF224Random group P-224 secp224r1
EC2NGF233Random group B-233 sect233r1
EC2NGF233Koblitz group K-233 sect233k1
ECPRGF256Random group P-256 secp256r1
EC2NGF283Random group B-283 sect283r1
EC2NGF283Koblitz group K-283 sect283k1
ECPRGF384Random group P-384 secp384r1
EC2NGF409Random group B-409 sect409r1
EC2NGF409Koblitz group K-409 sect409k1
ECPRGF521Random group P-521 secp521r1
EC2NGF571Random group B-571 sect571r1
EC2NGF571Koblitz group K-571 sect571k1
6. Security Considerations
Kerberos error messages are not integrity protected, as a result, the
domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
with by an attacker so that the set of domain parameters selected
could be either weaker or not mutually preferred. Local policy can
configure sets of domain parameters acceptable locally, or disallow
the negotiation of ECDH domain parameters.
Beyond elliptic curve size, the main issue is elliptic curve
structure. As a general principle, it is more conservative to use
elliptic curves with as little algebraic structure as possible - thus
random curves are more conservative than special curves such as
Koblitz curves, and curves over F_p with p random are more
conservative than curves over F_p with p of a special form (and
curves over F_p with p random might be considered more conservative
than curves over F_2^m as there is no choice between multiple fields
of similar size for characteristic 2). Note, however, that algebraic
structure can also lead to implementation efficiencies and
implementors and users may, therefore, need to balance conservatism
against a need for efficiency. Concrete attacks are known against
only very few special classes of curves, such as supersingular
curves, and these classes are excluded from the ECC standards such as
[IEEE1363] and [X9.62].
Zhu, et al. Expires March 17, 2006 [Page 7]
Internet-Draft ECC Support for PKINIT September 2005
Another issue is the potential for catastrophic failures when a
single elliptic curve is widely used. In this case, an attack on the
elliptic curve might result in the compromise of a large number of
keys. Again, this concern may need to be balanced against efficiency
and interoperability improvements associated with widely-used curves.
Substantial additional information on elliptic curve choice can be
found in [IEEE1363], [X9.62] and [FIPS186-2].
7. IANA Considerations
No IANA actions are required for this document.
8. Acknowledgements
The following people have made significant contributions to this
draft: Paul Leach, Dan Simon, Kelvin Yiu, David Cross and Sam
Hartman.
9. References
9.1. Normative References
[ECCPKALGS]
RFC-Editor: To be replaced by RFC number for draft-ietf-
pkix-ecc-pkalgs. Work in Progress.
[FIPS186-2]
NIST, "Digital Signature Standard", FIPS 186-2, 2000.
[IEEE1363]
IEEE, "Standard Specifications for Public Key Cryptography",
IEEE 1363, 2000.
[NISTSP80057]
NIST, "Recommendation on Key Management",
http://csrc.nist.gov/publications/nistpubs/, SP 800-57,
August 2005.
[PKINIT] RFC-Editor: To be replaced by RFC number for draft-ietf-
cat-kerberos-pk-init. Work in Progress.
Zhu, et al. Expires March 17, 2006 [Page 8]
Internet-Draft ECC Support for PKINIT September 2005
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3369] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3369, August 2002.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[X9.62] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 1998.
9.2. Informative References
[LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
Sizes", Journal of Cryptology 14 (2001) 255-293.
[SECG] SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
<http://www.secg.org/>.
Zhu, et al. Expires March 17, 2006 [Page 9]
Internet-Draft ECC Support for PKINIT September 2005
Authors' Addresses
Larry Zhu
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
Email: lzhu@microsoft.com
Karthik Jaganathan
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
Email: karthikj@microsoft.com
Kristin Lauter
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
Email: klauter@microsoft.com
Zhu, et al. Expires March 17, 2006 [Page 10]
Internet-Draft ECC Support for PKINIT September 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhu, et al. Expires March 17, 2006 [Page 11]

View File

@@ -0,0 +1,611 @@
NETWORK WORKING GROUP L. Zhu
Internet-Draft K. Jaganathan
Expires: September 3, 2006 K. Lauter
Microsoft Corporation
March 2, 2006
ECC Support for PKINIT
draft-zhu-pkinit-ecc-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 3, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the use of Elliptic Curve certificates,
Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman
(ECDH) key agreement within the framework of PKINIT - the Kerberos
Version 5 extension that provides for the use of public key
cryptography.
Zhu, et al. Expires September 3, 2006 [Page 1]
Internet-Draft ECC Support for PKINIT March 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Using Elliptic Curve Certificates and Elliptic Curve
Signature Schemes . . . . . . . . . . . . . . . . . . . . . . 3
4. Using ECDH Key Exchange . . . . . . . . . . . . . . . . . . . 4
5. Choosing the Domain Parameters and the Key Size . . . . . . . 5
6. Interoperability Requirements . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Zhu, et al. Expires September 3, 2006 [Page 2]
Internet-Draft ECC Support for PKINIT March 2006
1. Introduction
Elliptic Curve Cryptography (ECC) is emerging as an attractive
public-key cryptosystem that provides security equivalent to
currently popular public-key mechanisms such as RSA and DSA with
smaller key sizes [LENSTRA] [NISTSP80057].
Currently [PKINIT] permits the use of ECC algorithms but it does not
specify how ECC parameters are chosen and how to derive the shared
key for key delivery using Elliptic Curve Diffie-Hellman (ECDH)
[IEEE1363] [X9.63].
This document describes how to use Elliptic Curve certificates,
Elliptic Curve signature schemes, and ECDH with [PKINIT]. However,
it should be noted that there is no syntactic or semantic change to
the existing [PKINIT] messages. Both the client and the KDC
contribute one ECDH key pair using the key agrement protocol
described in this document.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Using Elliptic Curve Certificates and Elliptic Curve Signature
Schemes
ECC certificates and signature schemes can be used in the
Cryptographic Message Syntax (CMS) [RFC3369] content type
'SignedData'.
X.509 certificates [RFC3280] containing ECC public keys or signed
using ECC signature schemes MUST comply with [RFC3279].
The elliptic curve domain parameters recommended in [X9.62],
[FIPS186-2], and [SECG] SHOULD be used.
The signatureAlgorithm field of the CMS data type SignerInfo can
contain one of the following ECC signature algorithm identifiers:
ecdsa-with-Sha1 [ECCPKALGS]
ecdsa-with-Sha256 [ECCPKALGS]
ecdsa-with-Sha384 [ECCPKALGS]
ecdsa-with-Sha512 [ECCPKALGS]
Zhu, et al. Expires September 3, 2006 [Page 3]
Internet-Draft ECC Support for PKINIT March 2006
The corresponding digestAlgorithm field contains one of the following
hash algorithm identifiers respectively:
id-sha1 [RFC3279]
id-sha256 [ECCPKALGS]
id-sha384 [ECCPKALGS]
id-sha512 [ECCPKALGS]
Namely id-sha1 MUST be used in conjunction with ecdsa-with-Sha1, id-
sha256 MUST be used in conjunction with ecdsa-with-Sha256, id-sha384
MUST be used in conjunction with ecdsa-with-Sha384, and id-sha512
MUST be used in conjunction with ecdsa-with-Sha512.
Implementations of this specfication MUST support ecdsa-with-Sha256
and SHOULD support ecdsa-with-Sha1.
4. Using ECDH Key Exchange
This section describes how ECDH can be used as the AS reply key
delivery method [PKINIT]. Note that the protocol description here is
similar to that of Modular Exponential Diffie-Hellman (MODP DH), as
described in [PKINIT].
If the client wishes to use ECDH key agreement method, it encodes its
ECDH public key value and the domain parameters [IEEE1363] [X9.63]
for its ECDH public key in clientPublicValue of the PA-PK-AS-REQ
message [PKINIT].
As described in [PKINIT], the ECDH domain parameters for the client's
public key are specified in the algorithm field of the type
SubjectPublicKeyInfo [RFC3279] and the client's ECDH public key value
is mapped to a subjectPublicKey (a BIT STRING) according to
[RFC3279].
The following algorithm identifier is used to identify the client's
choice of the ECDH key agreement method for key delivery.
id-ecPublicKey (Elliptic Curve Diffie-Hellman [ECCPKALGS])
If the domain parameters are not accepted by the KDC, the KDC sends
back an error message [RFC4120] with the code
KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED [PKINIT]. This error message
contains the list of domain parameters acceptable to the KDC. This
list is encoded as TD-DH-PARAMETERS [PKINIT], and it is in the KDC's
decreasing preference order. The client can then pick a set of
domain parameters from the list and retry the authentication.
Zhu, et al. Expires September 3, 2006 [Page 4]
Internet-Draft ECC Support for PKINIT March 2006
Both the client and the KDC MUST have local policy that specifies
which set of domain parameters are acceptable if they do not have a
priori knowledge of the chosen domain parameters. The need for such
local policy is explained in Section 7.
If the ECDH domain parameters are accepted by the KDC, the KDC sends
back its ECDH public key value in the subjectPublicKey field of the
PA-PK-AS-REP message [PKINIT].
As described in [PKINIT], the KDC's ECDH public key value is encoded
as a BIT STRING according to [RFC3279].
Note that in the steps above, the client can indicate to the KDC that
it wishes to reuse ECDH keys or to allow the KDC to do so, by
including the clientDHNonce field in the request [PKINIT], and the
KDC can then reuse the ECDH keys and include serverDHNonce field in
the reply [PKINIT]. This logic is the same as that of the Modular
Exponential Diffie-Hellman key agreement method [PKINIT].
If ECDH is negotiated as the key delivery method, then the PA-PK-AS-
REP and AS reply key are generated as in Section 3.2.3.1 of [PKINIT]
with the following difference: The DHSharedSecret is the x-coordinate
of the shared secret value (an elliptic curve point); DHSharedSecret
is the output of operation ECSVDP-DH as described in Section 7.2.1 of
[IEEE1363].
Both the client and KDC then proceed as described in [PKINIT] and
[RFC4120].
Lastly it should be noted that ECDH can be used with any certificates
and signature schemes. However, a significant advantage of using
ECDH together with ECC certificates and signature schemes is that the
ECC domain parameters in the client or KDC certificates can be used.
This obviates the need of locally preconfigured domain parameters as
described in Section 7.
5. Choosing the Domain Parameters and the Key Size
The domain parameters and the key size should be chosen so as to
provide sufficient cryptographic security [RFC3766]. The following
table, based on table 2 on page 63 of NIST SP800-57 part 1
[NISTSP80057], gives approximate comparable key sizes for symmetric-
and asymmetric-key cryptosystems based on the best-known algorithms
for attacking them.
Zhu, et al. Expires September 3, 2006 [Page 5]
Internet-Draft ECC Support for PKINIT March 2006
Symmetric | ECC | RSA
-------------+----------- +------------
80 | 160 - 223 | 1024
112 | 224 - 255 | 2048
128 | 256 - 383 | 3072
192 | 384 - 511 | 7680
256 | 512+ | 15360
Table 1: Comparable key sizes (in bits)
Thus, for example, when securing a 128-bit symmetric key, it is
prudent to use 256-bit Elliptic Curve Cryptography (ECC), e.g. group
P-256 (secp256r1) as described below.
A set of ECDH domain parameters is also known as a curve. A curve is
a named curve if the domain paratmeters are well known and can be
identified by an Object Identifier, otherwise it is called a custom
curve. [PKINIT] supports both named curves and custom curves, see
Section 7 on the tradeoff of choosing between named curves and custom
curves.
The named curves recommended in this document are also recommended by
NIST [FIPS186-2]. These fifteen ECC curves are given in the
following table [FIPS186-2] [SECG].
Description SEC 2 OID
----------------- ---------
ECPRGF192Random group P-192 secp192r1
EC2NGF163Random group B-163 sect163r2
EC2NGF163Koblitz group K-163 sect163k1
ECPRGF224Random group P-224 secp224r1
EC2NGF233Random group B-233 sect233r1
EC2NGF233Koblitz group K-233 sect233k1
ECPRGF256Random group P-256 secp256r1
EC2NGF283Random group B-283 sect283r1
EC2NGF283Koblitz group K-283 sect283k1
ECPRGF384Random group P-384 secp384r1
EC2NGF409Random group B-409 sect409r1
EC2NGF409Koblitz group K-409 sect409k1
ECPRGF521Random group P-521 secp521r1
EC2NGF571Random group B-571 sect571r1
EC2NGF571Koblitz group K-571 sect571k1
Zhu, et al. Expires September 3, 2006 [Page 6]
Internet-Draft ECC Support for PKINIT March 2006
6. Interoperability Requirements
Implementations conforming to this specification MUST support curve
P-256 and P-384.
7. Security Considerations
Kerberos error messages are not integrity protected, as a result, the
domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
with by an attacker so that the set of domain parameters selected
could be either weaker or not mutually preferred. Local policy can
configure sets of domain parameters acceptable locally, or disallow
the negotiation of ECDH domain parameters.
Beyond elliptic curve size, the main issue is elliptic curve
structure. As a general principle, it is more conservative to use
elliptic curves with as little algebraic structure as possible - thus
random curves are more conservative than special curves such as
Koblitz curves, and curves over F_p with p random are more
conservative than curves over F_p with p of a special form (and
curves over F_p with p random might be considered more conservative
than curves over F_2^m as there is no choice between multiple fields
of similar size for characteristic 2). Note, however, that algebraic
structure can also lead to implementation efficiencies and
implementors and users may, therefore, need to balance conservatism
against a need for efficiency. Concrete attacks are known against
only very few special classes of curves, such as supersingular
curves, and these classes are excluded from the ECC standards such as
[IEEE1363] and [X9.62].
Another issue is the potential for catastrophic failures when a
single elliptic curve is widely used. In this case, an attack on the
elliptic curve might result in the compromise of a large number of
keys. Again, this concern may need to be balanced against efficiency
and interoperability improvements associated with widely-used curves.
Substantial additional information on elliptic curve choice can be
found in [IEEE1363], [X9.62] and [FIPS186-2].
8. IANA Considerations
No IANA actions are required for this document.
9. Acknowledgements
The following people have made significant contributions to this
Zhu, et al. Expires September 3, 2006 [Page 7]
Internet-Draft ECC Support for PKINIT March 2006
draft: Paul Leach, Dan Simon, Kelvin Yiu, David Cross, Sam Hartman,
Tolga Acar, and Stefan Santesson.
10. References
10.1. Normative References
[ECCPKALGS]
RFC-Editor: To be replaced by RFC number for draft-ietf-
pkix-ecc-pkalgs. Work in Progress.
[FIPS186-2]
NIST, "Digital Signature Standard", FIPS 186-2, 2000.
[IEEE1363]
IEEE, "Standard Specifications for Public Key Cryptography",
IEEE 1363, 2000.
[NISTSP80057]
NIST, "Recommendation on Key Management",
http://csrc.nist.gov/publications/nistpubs/, SP 800-57,
August 2005.
Zhu, et al. Expires September 3, 2006 [Page 8]
Internet-Draft ECC Support for PKINIT March 2006
[PKINIT] RFC-Editor: To be replaced by RFC number for draft-ietf-
cat-kerberos-pk-init. Work in Progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3369] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3369, August 2002.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[X9.62] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 1998.
[X9.63] ANSI, "Public Key Cryptography for the Financial Services
Industry: Key Agreement and Key Transport using Elliptic
Curve Cryptography", ANSI X9.63, 2001.
9.2. Informative References
[LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
Sizes", Journal of Cryptology 14 (2001) 255-293.
[SECG] SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
<http://www.secg.org/>.
Zhu, et al. Expires September 3, 2006 [Page 9]
Internet-Draft ECC Support for PKINIT March 2006
Authors' Addresses
Larry Zhu
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
Email: lzhu@microsoft.com
Karthik Jaganathan
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
Email: karthikj@microsoft.com
Kristin Lauter
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
Email: klauter@microsoft.com
Zhu, et al. Expires September 3, 2006 [Page 10]
Internet-Draft ECC Support for PKINIT March 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhu, et al. Expires September 3, 2006 [Page 11]