Update gnulib files.

[shishi.git] / doc / specifications / draft-ietf-krb-wg-pkinit-alg-agility-01.txt

Network Working Group                               L. Hornquist Astrand
Internet-Draft                                      Stockholm University
Expires: April 26, 2007                                           L. Zhu
                                                   Microsoft Corporation
                                                        October 23, 2006


                       PK-INIT algorithm agility
                draft-ietf-krb-wg-pkinit-alg-agility-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 April 26, 2007.

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 April 26, 2007                 [Page 1]
\f
Internet-Draft          PK-INIT algorithm agility           October 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  . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13






































Hornquist Astrand & Zhu  Expires April 26, 2007                 [Page 2]
\f
Internet-Draft          PK-INIT algorithm agility           October 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 April 26, 2007                 [Page 3]
\f
Internet-Draft          PK-INIT algorithm agility           October 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 April 26, 2007                 [Page 4]
\f
Internet-Draft          PK-INIT algorithm agility           October 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 April 26, 2007                 [Page 5]
\f
Internet-Draft          PK-INIT algorithm agility           October 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 April 26, 2007                 [Page 6]
\f
Internet-Draft          PK-INIT algorithm agility           October 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 April 26, 2007                 [Page 7]
\f
Internet-Draft          PK-INIT algorithm agility           October 2006


6.  octetstring2key function agility

   The PK-INIT standard uses a home-grown string to key function to
   convert the DH key to a kerberos protocol key.  The function uses
   SHA-1 to mix and stretch the DH shared key.  This is replaced by the
   specification defined in [SP80056A] to convert a DH key to a
   symmetric key.

   The client annouces it supports by inserting the id-Pkinit-SP800-56A
   oid into the supportedCMSTypes in the request packet.  The KDC
   confirms this by setting the string2keyAlg in the updated DHRepInfo.

   The replacement string to key function is using [draft-dang-nistkdf]
   ASN.1 specification.

   SV is the concatenation of SVLen and SVData.  Where SVLen is a 4 byte
   big endian encoded length of SVData and SVData is the DH shared
   secret Z.

   OtherInfo is DER encoded and filled out as follows. algorithmID is
   set to id-PkInit-S2kFunction.  The two fields partyUInfo and
   partyVInfo is filled with DER encoded KRB5PrincipalName using the
   client and the KDC principal. suppPubInfo is filled by the DER encode
   pKinitSuppPubInfo.  The enctype field is set to the enctype that
   string to key function is supposed to produce.  The clientDHNonce and
   serverDHNonce elements of pKinitSuppPubInfo is filled in with
   clientDHNonce and serverDHNonce from th PK-INIT request if they where
   sent by the client or KDC.  The field suppPrivInfo is not used.























Hornquist Astrand & Zhu  Expires April 26, 2007                 [Page 8]
\f
Internet-Draft          PK-INIT algorithm agility           October 2006


   id-Pkinit-SP800-56A ::= OBJECT IDENTIFIER { ... TBD ... }
   id-PkInit-S2kFunction ::= OBJECT IDENTIFIER { ... TBD ... }

   pKinitSuppPubInfo ::= SEQUENCE {
           enctype       [0] ENCTYPE,
           clientDHNonce [1] OCTET STRING OPTIONAL
           serverDHNonce [2] OCTET STRING OPTIONAL
   }

   OtherInfo ::= SEQUENCE {
           algorithmID   AlgorithmIdentifier,
           partyUInfo     [0] OCTET STRING CONTAINS (KRB5PrincipalName),
           partyVInfo     [1] OCTET STRING CONTAINS (KRB5PrincipalName),
           suppPubInfo    [2] OCTET STRING OPTIONAL,
           suppPrivInfo   [3] OCTET STRING OPTIONAL
   }

   DHRepInfo ::= SEQUENCE {
           dhSignedData            [0] IMPLICIT OCTET STRING,
           serverDHNonce           [1] DHNonce OPTIONAL,
           ...,
           string2keyAlg           [2] AlgorithmIdentifier
   }




























Hornquist Astrand & Zhu  Expires April 26, 2007                 [Page 9]
\f
Internet-Draft          PK-INIT algorithm agility           October 2006


7.  Security Considerations

   This document describes negotiation of checksum types and other
   cryptographic functions.  Most of this negotiation is done
   unauthenticated so care needs to be taken to accect resonable values.
   Implemetion must make it possible to change the what is resonable
   over time.












































Hornquist Astrand & Zhu  Expires April 26, 2007                [Page 10]
\f
Internet-Draft          PK-INIT algorithm agility           October 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.

   [SP80056A]
              Barker, E., Don, D., and M. Smid, "Recommendation for
              Pair-Wise Key Establishment Schemes Using Discrete
              Logarithm CryptographyMarch", March 2006.

   [draft-dang-nistkdf]
              Dang, Q. and P. Polk, "Hash-Based Key Derivation (HKD)",
              June 2006.


































Hornquist Astrand & Zhu  Expires April 26, 2007                [Page 11]
\f
Internet-Draft          PK-INIT algorithm agility           October 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 April 26, 2007                [Page 12]
\f
Internet-Draft          PK-INIT algorithm agility           October 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 April 26, 2007                [Page 13]
\f