Internet DRAFT - draft-weber-secsh-pgp-sign

draft-weber-secsh-pgp-sign






INTERNET DRAFT                                         Joel N. Weber II
                                                        August 14, 2003
                                              Expires February 14, 2004

           Secure Shell ``pgp-sign-*'' Public Key Algorithms
                   draft-weber-secsh-pgp-sign-00.txt

   This document is an Internet-Draft and is subject to all the
   provisions of Section 10 of RFC2026.

   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   The distribution of this memo is unlimited.  It is filed as draft-
   weber-secsh-pgp-sign-00.txt, and expires 14 February 2004.  Please
   send comments to the author or to ietf-ssh@netbsd.org


ABSTRACT

   This document clarifies details of using OpenPGP keys as host keys
   and user authentication keys in the Secure Shell protocol.
   Preventing man in the middle attacks is an important part of
   security, and in many circumstances verifying the authenticity of an
   OpenPGP key will be easier than verifying the authenticity of an ssh-
   rsa or ssh-dss key.

INTRODUCTION

   The Secure Shell Transport protocol [TRANSPORT] defines the host key
   types pgp-sign-rsa and pgp-sign-dss, which allow the decentralized
   certification model of the OpenPGP standard [RFC2440] to be used in
   conjunction with the Secure Shell protocol.

   This has the potential to be more effective than the traditional ssh-



Weber                  Secure Shell ``pgp-sign-*''              [Page 1]






draft-weber-secsh-pgp-sign-00.txt                         August 14 2003


   rsa and ssh-dss keys with a local database on the client in
   preventing man in the middle attacks involving accepting an
   attacker's host key, because it is typically easier to determine
   whether a new OpenPGP key belongs to the real host than a new ssh-rsa
   or ssh-dss key.

   An OpenPGP key also can be used for public key user authentication.

   This document fills in details not adaquately explained by
   [TRANSPORT].

   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.

KEY/CERTIFICATE

   If a subkey is being used by the key exchange algorithm for the
   signature of the hash, the choice of ``pgp-sign-dss'' vs ``pgp-sign-
   rsa'' is made on the basis of the subkey being used.  If the top-
   level key is used for the signature, then the top-level's key is used
   to determine which Secure Shell key type identifier to use.

   The key/certificate consists of a single toplevel key, a self-
   signature of that key, zero or more subkeys with signatures binding
   them to the toplevel key, and zero or more certification packets, all
   in OpenPGP binary format.  The keys and signatures may use any
   algorithm supported by an OpenPGP implementation, as long as the
   subkey or toplevel key used for the actual signature is of a type
   which has a corresponding Secure Shell key format identifier.

USER ID VALUE

   Every OpenPGP format key has a user ID identifying it.  For use as a
   host key with the Secure Shell protocol, the section in angle
   brackets MUST be of the form <ssh@example.com> where example.com is
   the hostname of the Secure Shell server.  The hostname in the key's
   user ID MUST be fully qualified.  Clients SHOULD ignore user ID
   values which do not meet the requirements of this paragraph, unless
   they have been explicitly configured otherwise.

   The key SHOULD have a user ID for every name which is used as the
   hostname of the Secure Shell server where the OpenPGP key is used as
   the host key.

   DNS aliases for hostnames SHOULD NOT be trusted; if the goal is to
   trust DNSSEC, then it is RECOMMENDED that DNSSEC be used to
   distribute the host key fingerprint rather than using an OpenPGP host



Weber                  Secure Shell ``pgp-sign-*''              [Page 2]






draft-weber-secsh-pgp-sign-00.txt                         August 14 2003


   key.

   Clients SHOULD NOT treat an unqualified hostname as matching if doing
   so might involve trusting DNS in a way that it should not be trusted.
   For example, a DNS resolver which is configured to search multiple
   domain names could be tricked by an attacker into choosing a
   different domain names than the one the user intended.  If the domain
   name comes from unauthenticated DHCP, it also SHOULD NOT be used for
   canonicalization.

KEY VERIFICATION

   When verifying a signature during initial key exchange, an
   implementation SHOULD reject the signature if there is no trusted
   path through unexpired signatures, or if the key or subkey is
   expired.  An implementation SHOULD ignore any signatures on the key
   used to sign the hash which are made on user ID values that do not
   correspond to the hostname being used for the connection.

   An implementation MAY disregard the trust and expiration during
   rekeying if the key was used during initial key exchange or in a
   subsequent rekeying and was determined to be trusted at that time.

   An implementation MAY disregard trust information for user
   authentication, but MUST NOT disregard expiration.

   An implementation MAY prompt the user to collect information about
   which keys are trusted after recieving a key from a server before
   deciding whether an adaquate trust path exists.

   It is frequently the case that verifying the trust path will involve
   both RSA and DSS keys; therefore, it is RECOMMENDED that
   implementations support both.

KEYRING MANAGEMENT

   A client MAY unconditionally add any key recieved from an ssh server
   to the client's keyring at the begining of the connection.  If this
   is done, the end user documentation SHOULD warn that an attacker can
   add arbitrary keys to the keyring in this way.

   A client MAY choose to add a key to the keyring only when it can be
   determined that they will be trusted once they are added, or MAY add
   trusted keys unconditionally and prompt the user before adding an
   untrusted key to the keyring.

   It may be necessary to retrieve additional toplevel OpenPGP keys from
   a keyserver or by other means in order to establish a trust path.  A



Weber                  Secure Shell ``pgp-sign-*''              [Page 3]






draft-weber-secsh-pgp-sign-00.txt                         August 14 2003


   Secure Shell client MAY include facilities to support this, or MAY
   leave this as the responsibility of the OpenPGP implementation being
   used.

   A server doing public key user authentication using an OpenPGP key
   MUST NOT unconditionally add data provided by arbitrary
   unauthenticated clients to its keyring.

   However, it MAY add new subkeys which have valid binding signatures
   made by a toplevel key which is authorized, to facilitate the use of
   subkeys which periodically expire.  Such a server SHOULD NOT add new
   certifications to the keyring in this fashion, however.

REVOCATION

   Implementations of pgp-sign-* SHOULD support passing revocation
   certificates from the server to the client using SSH_MSG_HOSTKEYS, as
   described in [HOSTKEYS], in order to facilitate making stolen,
   revoked private keys become unusable.

CLOCK CONSIDERATIONS

   If the system clock can be manipulated by an attacker, expired keys
   may be mistakenly treated as unexpired.  End user documentation
   SHOULD warn of this.

LOCAL DATABASE CONSIDERATIONS

   Client implementations SHOULD make sure that once a host has been
   connected to using a ``pgp-sign-*'' key, a subsequent connection to a
   man-in-the-middle attacker which offers keys of other types which are
   not recognizable as trusted offers a different and stronger warning
   than when no previous host key information exists for a host.  This
   can either be done by checking the OpenPGP keyring before deciding
   that a host key is new, or by making an entry in the same database
   where ``ssh-rsa'' and ``ssh-dss'' keys are stored.  The latter
   approach may have some performance advantages, and may also allow for
   more code reuse, especially in implementations of the Secure Shell
   protocol which also support other key exchange algthorithms such as
   the GSSAPI family of key exchange algorithms.

SECURITY CONSIDERATIONS

   This entire document is about security considerations.

AUTHOR'S ADDRESS

   Joel N. Weber II



Weber                  Secure Shell ``pgp-sign-*''              [Page 4]






draft-weber-secsh-pgp-sign-00.txt                         August 14 2003


   185 Lowell St #2
   Somerville MA 02144-2629
   Email: weber@joelweber.com

NORMATIVE REFERENCES

   [RFC2026] S. Bradner, RFC2026, BCP 9:  "The Internet Standard Process
   - Revision 3," October 1996, Obsoletes - RFC 1602, Status: Best
   Current Practice.

   [RFC2119] S. Bradner, RFC 2119, BCP 14: "Key words for use in RFCs to
   Indicate Requirement Levels," March 1997.

   [RFC2440] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, RFC2440:
   "OpenPGP Message Format," November 1998.

   [TRANSPORT] RFC-Editor: To be replaced by RFC number for draft-ietf-
   secsh-transport

INFORMATIVE REFERENCES

   [HOSTKEYS] draft-weber-secsh-msg-hostkeys-00.txt, not yet submitted.

IPR NOTICES

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

COPYRIGHT NOTICE

   Copyright (C) The Internet Society 2003. All Rights Reserved.



Weber                  Secure Shell ``pgp-sign-*''              [Page 5]






draft-weber-secsh-pgp-sign-00.txt                         August 14 2003


   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.




























Weber                  Secure Shell ``pgp-sign-*''              [Page 6]