x
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@17742 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
672
doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-00.txt
Normal file
672
doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-00.txt
Normal 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]
|
||||
|
392
doc/standardisation/draft-ietf-krb-wg-tcp-expansion-00.txt
Normal file
392
doc/standardisation/draft-ietf-krb-wg-tcp-expansion-00.txt
Normal 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]
|
||||
|
610
doc/standardisation/draft-zhu-pkinit-ecc-00.txt
Normal file
610
doc/standardisation/draft-zhu-pkinit-ecc-00.txt
Normal 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]
|
||||
|
||||
|
611
doc/standardisation/draft-zhu-pkinit-ecc-01.txt
Normal file
611
doc/standardisation/draft-zhu-pkinit-ecc-01.txt
Normal 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]
|
||||
|
||||
|
Reference in New Issue
Block a user