[runtime.git] / public_html / docs / draft-riikonen-silc-ke-auth-00.txt

Network Working Group                                      P. Riikonen
Internet-Draft
draft-riikonen-silc-ke-auth-00.txt                        28 June 2000
Expires: 28 Jan 2001


              SILC Key Exchange and Authentication Protocols

Status of this Memo

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   The distribution of this memo is unlimited.


Abstract

   This memo describes two protocols used in the Secure Internet Live
   Conferencing (SILC) protocol specified in the Secure Internet Live
   Conferencing, Protocol Specification internet-draft [SILC1].  The
   SILC Key Exchange (SKE) protocol provides secure key exchange between
   two parties resulting into shared secret key material.  The protocol
   is based on Diffie Hellman key exchange algorithm and its functionality
   is derived from several key exchange protocols.  SKE uses best parts
   of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol
   and the OAKLEY Key Determination protocol [OAKLEY].

   The SILC Connection Authentication protocol provides user level
   authentication used when creating connections in SILC network.  The
   protocol is transparent to the authentication data which means that it
   can be used to authenticate the user with, for example, passphrase
   (pre-shared- secret) or public key (and certificate).




Riikonen                                                        [Page 1]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


Table of Contents

   1 Introduction ..................................................  2
   2 SILC Key Exchange Protocol ....................................  3
     2.1 Key Exchange Payloads .....................................  3
         2.1.1 Key Exchange Start Payload ..........................  4
         2.1.2 Key Exchange 1 Payload ..............................  7
         2.1.3 Key Exchange 2 Payload ..............................  9
     2.2 Key Exchange Procedure .................................... 10
     2.3 Processing the Key Material ............................... 12
     2.4 SILC Key Exchange Groups .................................. 13
         2.4.1 diffie-hellman-group1 ............................... 13
         2.4.2 diffie-hellman-group2 ............................... 14
     2.5 Key Exchange Status Types ................................. 14
   3 SILC Connection Authentication Protocol ....................... 16
     3.1 Connection Auth Payload ................................... 17
     3.2 Connection Authentication Types ........................... 18
         3.2.1 Passphrase Authentication ........................... 18
         3.2.2 Public Key Authentication ........................... 18
     3.3 Connection Authentication Status Types .................... 19
   4 Security Considerations ....................................... 19
   5 References .................................................... 19
   6 Author's Address .............................................. 20


List of Figures

   Figure 1:  Key Exchange Start Payload
   Figure 2:  Key Exchange 1 Payload
   Figure 3:  Key Exchange 2 Payload
   Figure 4:  Connection Auth Payload


1 Introduction

   This memo describes two protocols used in the Secure Internet Live
   Conferencing (SILC) protocol specified in the Secure Internet Live
   Conferencing, Protocol Specification internet-draft [SILC1].  The
   SILC Key Exchange (SKE) protocol provides secure key exchange between
   two parties resulting into shared secret key material.  The protocol
   is based on Diffie Hellman key exchange algorithm and its functionality
   is derived from several key exchange protocols.  SKE uses best parts
   of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol
   and the OAKLEY Key Determination protocol.

   The SILC Connection Authentication protocol provides user level
   authentication used when creating connections in SILC network.  The
   protocol is transparent to the authentication data which means that it



Riikonen                                                        [Page 2]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


   can be used to authenticate the user with, for example, passphrase
   (pre-shared- secret) or public key (and certificate).

   The basis of secure SILC session requires strong and secure key exchange
   protocol and authentication.  The authentication protocol is entirely
   secured and no authentication data is ever sent in the network without
   encrypting and authenticating it first.  Thus, authentication protocol
   may be used only after the key exchange protocol has been successfully
   completed.

   This document refers constantly to other SILC protocol specification
   Internet Drafts that are a must read for those who wants to understand
   the function of these protocols.  The most important references are
   the Secure Internet Live Conferencing, Protocol Specification [SILC1]
   and SILC Packet Protocol [SILC2] Internet Drafts.

   The protocol is intended to be used with the SILC protocol thus it
   does not define own framework that could be used.  The framework is
   provided by the SILC protocol.


2 SILC Key Exchange Protocol

   SILC Key Exchange Protocol (SKE) is used to exchange shared secret
   between connecting entities.  The result of this protocol is a key
   material used to secure the communication channel.  The protocol uses
   Diffie-Hellman key exchange algorithm and its functionality is derived
   from several key exchange protocols.  SKE uses best parts of the SSH2
   Key Exchange protocol, Station-To-Station (STS) protocol and the OAKLEY
   Key Determination protocol.  The protocol does not claim any conformance
   to any of these protocols, they were merely used as a reference when
   designing this protocol.

   The purpose of SILC Key Exchange protocol is to create session keys to
   be used in current SILC session.  The keys are valid only for some period
   of time (usually an hour) or at most until the session ends.  These keys
   are used to protect packets like commands, command replies and other
   communication between two entities.  If connection is server to server
   connection, the keys are used to protect all traffic between those
   servers.  In client connections usually all the packets are protected
   with this key except channel messages; channels has their own keys and
   they are not exchanged with this protocol.


2.1 Key Exchange Payloads

   During the key exchange procedure public data is sent between initiator
   and responder.  This data is later used in the key exchange procedure.



Riikonen                                                        [Page 3]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


   There are several payloads used in the key exchange.  As for all SILC
   packets, SILC Packet Header, described in [SILC2], is at the start of all
   packets, the same is done with these payloads as well.  All fields in
   all payloads are always in MSB (most significant byte first) order.
   Following descriptions of these payloads.


2.1.1 Key Exchange Start Payload

   Key exchange between two entities always begins with a
   SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
   When performing key exchange between client and server, the client sends
   Key Exchange Start Payload to server filled with all security properties
   that the client supports.  Server then checks if it supports the security
   properties.

   It then sends a Key Exchange Start Payload to client filled with security
   properties it selected from the payload client originally sent.  The
   payload sent by server must include only one chosen property per list.

   When performing key exchange between server and server, the server who
   is contacting sends the Key Exchange Start Payload with security property
   list it supports to the other server.  The contacted party then chooses
   the preferred properties same way as previously described.  It then
   replies with the properties it wanted same way as previously described.

   The Key Exchange Start Payload is used to tell connecting entities what
   security properties and algorithms should be used in the communication.
   If perfect forward secrecy (PFS) is not desired (PFS is undefined by
   default) Key Exchange Start Payload is sent only once per session, thus,
   for example, re-keying will not cause sending of a new payload.  If PFS
   is desired, re-keying will always cause new key exchange thus causes
   sending of a new Key Exchange Start Payload.

   When performing first key exchange this payload is never encrypted, as
   there are no existing keys to encrypt it with.  If performing re-keying
   (PFS was selected) this payload is encrypted with the existing key and
   encryption algorithm.

   Cookie is also send in this payload.  Cookie is used to uniform the
   payload so that none of the key exchange parties cannot determine this
   payload before hand.  The cookie must be returned to the original sender
   by the responder.

   Following diagram represents the Key Exchange Start Payload.  The lists
   mentioned below are always comma (`,') separated and the list must
   not include spaces (` ').




Riikonen                                                        [Page 4]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   RESERVED    |     Flags     |         Payload Length        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                            Cookie                             +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Key Exchange Grp Length     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     |                                                               |
     ~                      Key Exchange Groups                      ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        PKCS Alg Length        |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     |                                                               |
     ~                         PKCS Algorithms                       ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Encryption Alg Length     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     |                                                               |
     ~                      Encryption Algorithms                    ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Hash Alg Length         |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     |                                                               |
     ~                        Hash Algorithms                        ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Compression Alg Length     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     |                                                               |
     ~                     Compression Algorithms                    ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1:  Key Exchange Start Payload






Riikonen                                                        [Page 5]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


      o RESERVED (1 byte) - Reserved field.  Sender fills this with
        zeroes (0).

      o Flags (1 byte) - Indicates flags to be used in the key
        exchange.  Several flags can be set at once by ORing the
        flags together.  Following flags are reserved for this field.

           No flags              0x00

             In this case the field is ignored.

           No Reply              0x01

             If set the receiver of the payload does not reply to
             the packet.

           PFS                   0x02

             Perfect Forward Secrecy (PFS) to be used in the
             key exchange protocol.  If not set, re-keying
             is performed using the old key.  When PFS is used,
             re-keying and creating new keys for any particular
             purpose will cause new key exchange.

             Rest of the flags are reserved for the future and
             must not be set.

      o Payload Length (2 bytes) - Length of the entire Key Exchange
        Start payload.

      o Cookie (16 bytes) - Cookie that uniforms this payload so
        that each of the party cannot determine the payload before
        hand.

      o Key Exchange Grp Length (2 bytes) - The length of the
        key exchange group list, including this field as well.

      o Key Exchange Group (variable length) - The list of
        key exchange groups.  See the section 2.1.2 SILC Key Exchange
        Groups for definitions of these groups.

      o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms
        list, including this field as well.

      o PKCS Algorithms (variable length) - The list of PKCS
        algorithms.

      o Encryption Alg Length (2 bytes) - The length of the encryption



Riikonen                                                        [Page 6]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


        algorithms list, including this field as well.

      o Encryption Algorithms (variable length) - The list of
        encryption algorithms.

      o Hash Alg Length (2 bytes) - The length of the Hash algorithms
        list, including this field as well.

      o Hash Algorithms (variable length) - The list of Hash algorithms.

      o Compression Alg Length (2 bytes) - The length of the
        compression algorithms list, including this field as well.

      o Compression Algorithms (variable length) - The list of
        compression algorithms.


2.1.2 Key Exchange 1 Payload

   Key Exchange 1 Payload is used to deliver computed public data from
   initiator to responder.  This data is used to compute the shared secret,
   later by all parties.  Key Exchange 1 Payload is only sent after the
   SILC_PACKET_KEY_EXCHANGE packet and the Key Exchange Start Payload has
   been processed by all the parties.

   This payload sends the initiator's public key to the responder.  Responder
   may need the public key in which case it should be checked to be trusted
   by the responder.

   The payload may only be sent with SILC_PACKET_KEY_EXCHANGE_1 packet.
   It must not be sent in any other packet type.  Following diagram
   represent the Key Exchange 1 Payload.



















Riikonen                                                        [Page 7]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Public Key Length       |        Public Key Type        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~            Public Key of the Host (or certificate)            ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Public Data Length       |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     |                                                               |
     ~                 Public Data (e = g ^ x mod p)                 ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 2:  Key Exchange 1 Payload


      o Public Key Length (2 bytes) - The length of the public key
        (or certificate), including this field and public key type
        field as well.

      o Public Key Type (2 bytes) - The public key (or certificate)
        type.  This field indicates the type of the public key in
        the packet.  Following types are defined:

           1    SILC style public key (mandatory)
           2    SSH2 style public key (optional)
           3    X.509 Version 3 certificate (optional)
           4    OpenPGP certificate (optional)
           5    SPKI certificate (optional)

        The only required type to support is type number 1.  See
        [SILC1] for the SILC public key specification.  See
        SSH public key specification in [SSH-TRANS].  See X.509v3
        certificate specification in [PKIX-Part1].  See OpenPGP
        certificate specification in [PGP].  See SPKI certificate
        specification in [SPKI].  If this field includes zero (0)
        or unsupported type number the protocol must be aborted
        sending SILC_PACKET_FAILURE message.

      o Public Data Length (2 bytes) - The length of the public
        data computed by the responder, including this field
        as well.

      o Public Data (variable length) - The public data to be
        sent to the responder.  See section 2.2 Key Exchange



Riikonen                                                        [Page 8]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


        Procedure for detailed description how this field is
        computed.  This value is binary encoded.


2.1.3 Key Exchange 2 Payload

   Key Exchange 2 Payload is used to deliver public key, computed public
   data and signature from responder to initiator.  Initiator uses these
   public parts of the key exchange protocol to compute the shared secret.

   The payload may only be sent with SILC_PACKET_KEY_EXCHANGE_2 packet.
   It must not be sent in any other packet type.  Following diagram
   represent the Key Exchange 2 Payload.



                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Public Key Length       |        Public Key Type        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~            Public Key of the Host (or certificate)            ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Public Data Length      |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     |                                                               |
     ~                 Public Data (f = g ^ y mod p)                 ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Signature Length       |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     |                                                               |
     ~                        Signature Data                         ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3:  Key Exchange 2 Payload



      o Public Key Length (2 bytes) - The length of the public key
        (or certificate), including this field and public key type
        field as well.

      o Public Key Type (2 bytes) - The public key (or certificate)
        type.  This field indicates the type of the public key in



Riikonen                                                        [Page 9]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


        the packet.  See previous sections for defined public key
        types.

      o Public Key of the host (variable length) - The public
        key of the sender (or its certificate).  This is verified
        by the receiver of the packet.  The type of this field
        is indicated by previous Public Key Type field.

      o Public Data Length (2 bytes) - The length of the public
        data computed by the responder, including this field
        as well.

      o Public Data (variable length) - The public data computed
        by the responder.  See section 2.2 Key Exchange Procedure
        for detailed description how this field is computed.  This
        value is binary encoded.

      o Signature Length (2 bytes) - The length of the signature,
        including the length of this field as well.

      o Signature Data (variable length) - The signature signed
        by the responder.  The receiver of this signature must
        verify it.  The verification is done using the public
        key received in this same payload.  See section 2.2
        Key Exchange Procedure for detailed description how
        to produce the signature.


2.2 Key Exchange Procedure

      The key exchange begins by sending SILC_PACKET_KEY_EXCHANGE packet with
      Key Exchange Start Payload to select the security properties to be used
      in the key exchange and later in the  communication.

      After Key Exchange Start Payload has been processed by both of the
      parties the protocol proceeds as follows:


      Setup:  p is a large and public safe prime.  This is one of the
              Diffie Hellman groups.  q is order of subgroup (largest
              prime factor of p).  g is a generator and is defined
              along with the Diffie Hellman group.

          1.  Initiator generates a random number x, where 1 < x < q,
              and computes e = g ^ x mod p.  The result e is then
              encoded into Key Exchange 1 Payload and sent
              to the responder.




Riikonen                                                       [Page 10]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


          2.  Responder generates a random number y, where 1 < y < q,
              and computes f = g ^ y mod p.  It then computes the
              shared secret KEY = e ^ y mod p, and, a hash value
              HASH = hash(Key Exchange Start Payload data | Host public
              key (or certificate) | e | f | KEY).  It then signs
              the HASH value with its private key resulting a signature
              SIGN.

              It then encodes its public key (or certificate), f and
              SIGN into Key Exchange 2 Payload and sends it to the
              initiator.


          3.  Initiator verifies that the public key provided in
              the payload is authentic, or if certificates are used
              it verifies the certificate.  Initiator may accept
              the public key without verifying it, however, doing
              so may result to insecure key exchange (accepting the
              public key without verifying may be desirable for
              practical reasons on many environments.  For long term
              use this is never desirable, in which case certificates
              would be the preferred method to use).

              Initiator then computes the shared secret KEY =
              f ^ x mod p, and, a hash value HASH in the same way as
              responder did in phase 2.  It then verifies the
              signature SIGN from the payload with the hash value
              HASH using the received public key.


      If any of these phases is to fail SILC_PACKET_FAILURE is sent to
      indicate that the key exchange protocol failed.  Any other packets must
      not be sent or accepted during the key exchange except the
      SILC_PACKET_KEY_EXCHANGE_*, SILC_PACKET_DISCONNECT, SILC_PACKET_FAILURE
      and/or SILC_PACKET_SUCCESS packets.

      The result of this protocol is a shared secret key material KEY and
      a hash value HASH.  The key material itself is not fit to be used as
      a key, it needs to be processed further to derive the actual keys to be
      used.  The key material is also used to produce other security parameters
      later used in the communication.  See section 2.3 Processing the Key
      Material for detailed description how to process the key material.

      After the keys are processed the protocol is ended by sending the
      SILC_PACKET_SUCCESS packet.  Both entities send this packet to
      each other.  After this both parties will start using the new keys.





Riikonen                                                       [Page 11]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


2.3 Processing the Key Material

      Key Exchange protocol produces secret shared key material KEY.  This
      key material is used to derive the actual keys used in the encryption
      of the communication channel.  The key material is also used to derive
      other security parameters used in the communication.  Key Exchange
      protocol produces a hash value HASH as well.  This is used in the key
      deriving process as a session identifier.

      Keys are derived from the key material as follows:

      Sending Initial Vector (IV)     = hash(0 | KEY | HASH)
      Receiving Initial Vector (IV)   = hash(1 | KEY | HASH)
      Sending Encryption Key          = hash(2 | KEY | HASH)
      Receiving Encryption Key        = hash(3 | KEY | HASH)
      HMAC Key                        = hash(4 | KEY | HASH)


   The Initial Vector (IV) is used in the encryption when doing for
   example CBC mode.  As many bytes as needed are taken from the start of
   the hash output for IV.  Sending IV is for sending key and receiving IV
   is for receiving key.  For receiving party, the receiving IV is actually
   sender's sending IV, and, the sending IV is actually sender's receiving
   IV.  Initiator uses IV's as they are (sending IV for sending and
   receiving IV for receiving).

   The Encryption Keys are derived as well from the hash().  If the hash()
   output is too short for the encryption algorithm more key material is
   produced in following manner:

      K1 = hash(2 | KEY | HASH)
      K2 = hash(KEY | K1)
      K3 = hash(KEY | K1 | K2)  ...

      Sending Encryption Key = K1 | K2 | K3 ...


      K1 = hash(3 | KEY | HASH)
      K2 = hash(KEY | K1)
      K3 = hash(KEY | K1 | K2)  ...

      Receiving Encryption Key = K1 | K2 | K3 ...


   The key is distributed by hashing the previous hash with the original
   key material.  The final key is a concatenation of the hash values.
   For Receiving Encryption Key the procedure is equivalent.  Sending key
   is used only for encrypting data to be sent.  The receiving key is used



Riikonen                                                       [Page 12]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


   only to decrypt received data.  For receiving party, the receive key is
   actually sender's sending key, and, the sending key is actually sender's
   receiving key.  Initiator uses generated keys as they are (sending key
   for sending and receiving key for sending).

   The HMAC key is used to create MAC values to packets in the communication
   channel.  As many bytes as needed are taken from the start of the hash
   output.

   These procedures are performed by all parties of the key exchange
   protocol.  This must be done before the protocol has been ended by
   sending the SILC_PACKET_SUCCESS packet.


2.4 SILC Key Exchange Groups

   Following groups may be used in the SILC Key Exchange protocol.  The
   first group diffie-hellman-group1 is mandatory, other groups maybe
   negotiated to be used in the connection with Key Exchange Start Payload
   and SILC_PACKET_KEY_EXCHANGE packet.  However, the first group must be
   proposed in the Key Exchange Start Payload regardless of any other
   requested group (however, it doesn't have to be the first on the list).


2.4.1 diffie-hellman-group1

   The length of this group is 1024 bits.  This is mandatory group.
   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.

   Its decimal value is

      179769313486231590770839156793787453197860296048756011706444
      423684197180216158519368947833795864925541502180565485980503
      646440548199239100050792877003355816639229553136239076508735
      759914822574862575007425302077447712589550957937778424442426
      617334727629299387668709205606050270810842907692932019128194
      467627007

   Its hexadecimal value is

      FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
      29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
      EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
      E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
      EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
      FFFFFFFF FFFFFFFF





Riikonen                                                       [Page 13]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


   The generator used with this prime is g = 2. The group order q is
   (p - 1) / 2.

   This group was taken from the OAKLEY specification.


2.4.2 diffie-hellman-group2

   The length of this group is 1536 bits.  This is optional group.
   The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.

   Its decimal value is

      241031242692103258855207602219756607485695054850245994265411
      694195810883168261222889009385826134161467322714147790401219
      650364895705058263194273070680500922306273474534107340669624
      601458936165977404102716924945320037872943417032584377865919
      814376319377685986952408894019557734611984354530154704374720
      774996976375008430892633929555996888245787241299381012913029
      459299994792636526405928464720973038494721168143446471443848
      8520940127459844288859336526896320919633919

   Its hexadecimal value is

      FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
      29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
      EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
      E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
      EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
      C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
      83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
      670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF

   The generator used with this prime is g = 2. The group order q is
   (p - 1) / 2.

   This group was taken from the OAKLEY specification.


2.5 Key Exchange Status Types

   This section defines all key exchange protocol status types that may be
   returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets to
   indicate the status of the protocol.  Implementations may map the
   status types to human readable error message.  All types except the
   SILC_SKE_STATUS_OK type must be sent in SILC_PACKET_FAILURE packet.
   Following status types are defined:




Riikonen                                                       [Page 14]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


      0   SILC_SKE_STATUS_OK

          Protocol were exeucted succesfully.


      1   SILC_SKE_STATUS_ERROR

          Unknown error occured.  No specific error type is defined.


      2   SILC_SKE_STATUS_BAD_PAYLOAD

          Provided KE payload were malformed or included bad fields.


      3   SILC_SKE_STATUS_UNSUPPORTED_GROUP

          None of the provided groups were supported.


      4   SILC_SKE_STATUS_UNSUPPORTED_CIPHER

          None of the provided ciphers were supported.


      5   SILC_SKE_STATUS_UNSUPPORTED_PKCS

          None of the provided public key algorithms were supported.


      6   SILC_SKE_STATUS_UNSUPPORTED_HASH_FUNCTION

          None of the provided hash functions were supported.


      7   SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY

          Provided public key type is not supported.


      8   SILC_SKE_STATUS_INCORRECT_SIGNATURE

          Provided signature was incorrect.








Riikonen                                                       [Page 15]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


3 SILC Connection Authentication Protocol

   Purpose of Connection Authentication protocol is to authenticate the
   connecting party with server.  Usually connecting party is client but
   server may connect to server as well.  Its other purpose is to provide
   information for the server about which type of connection this is.
   The type defines whether this is client, server or router connection.
   Server uses this information to create the ID for the connection.  After
   the authentication protocol has been successfully completed
   SILC_PACKET_NEW_ID must be sent to the connecting party by the server.
   See section New ID Payload in [SILC2] for detailed description for this
   packet's payload.

   Server must verify the authentication data received and if it is to fail
   the authentication must be failed by sending SILC_PACKET_FAILURE packet.
   If everything checks out fine the protocol is ended by server by sending
   SILC_PACKET_SUCCESS packet.

   The protocol is executed after the SILC Key Exchange protocol.  It must
   not be executed in any other time.  As it is performed after key exchange
   protocol all traffic in the connection authentication protocol is
   encrypted with the exchanged keys.

   The protocol is started by the connecting party by sending
   SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload,
   described in the next section.  This payload must include the
   authentication data.  Authentication data is set according
   authentication method that must be known by both parties. If connecting
   party does not know what is the mandatory authentication method it must
   request it from the server by sending SILC_PACKET_CONNECTION_AUTH_REQUEST
   packet.  This packet is not part of this protocol and is described in
   section Connection Auth Request Payload in [SILC2].  However, if
   connecting party already knows the mandatory authentication method
   sending the request is not necessary.

   See [SILC1] and section Connection Auth Request Payload in [SILC2] also
   for the list of different authentication methods.  Authentication method
   may also be NONE, in which case the server does not require
   authentication at all.  However, in this case the protocol still must be
   executed; the authentication data just is empty indicating no
   authentication is required.

   If authentication method is passphrase the authentication data is
   plaintext passphrase.  As the payload is entirely encrypted it is safe
   to have plaintext passphrase.  3.2.1 Passphrase Authentication for
   more information.





Riikonen                                                       [Page 16]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


   If authentication method is public key authentication the authentication
   data is signature of the hash value HASH plus Key Exchange Start Payload,
   established by the SILC Key Exchange protocol.  This signature must then
   be verified by the server.  See section 3.2.2 Public Key Authentication
   for more information.

   The connecting party of this protocol must wait after successful execution
   of this protocol for the SILC_PACKET_NEW_ID packet where it will receive
   the ID it will be using in the SILC network.  Connecting party cannot
   start normal SILC session (sending messages or commands) until it has
   received its ID.  The ID's are always created by the server except
   for server to server connection where servers create their own ID's.



3.1 Connection Auth Payload

   Client sends this payload to authenticate itself to the server.  Server
   connecting to another server also sends this payload.  Server receiving
   this payload must verify all the data in it and if something is to fail
   the authentication must be failed by sending SILC_PACKET_FAILURE packet.

   The payload may only be sent with SILC_PACKET_CONNECTION_AUTH packet.
   It must not be sent in any other packet type.  Following diagram
   represent the Connection Auth Payload.


                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Payload Length         |        Connection Type        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                     Authentication Data                       ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 4:  Connection Auth Payload


      o Payload Length (2 bytes) - Length of the entire Connection
        Auth Payload.

      o Connection Type (2 bytes) - Indicates the type of the
        connection.  See section Connection Auth Request Payload
        in [SILC2] for the list of connection types.  This field must
        include valid connection type or the packet must be discarded
        and authentication must be failed.



Riikonen                                                       [Page 17]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


      o Authentication Data (variable length) - The actual
        authentication data.  Contents of this depends on the
        authentication method known by both parties.  If no
        authentication is required this field does not exist.


3.2 Connection Authentication Types

   SILC supports two authentication types to be used in the connection
   authentication protocol; passphrase or public key based authentication.
   Following sections defines the authentication methods.  See [SILC2]
   for defined numerical authentication method types.


3.2.1 Passphrase Authentication

   Passphrase authentication or pre-shared-key base authentication is
   simply an authentication where the party that wants to authenticate
   itself to the other end sends the passphrase that is required by
   the other end, for example server.

   If the passphrase matches with the one in the server's end the
   authentication is successful.  Otherwise SILC_PACKET_FAILURE must be
   sent to the sender and the protocol execution fails.

   This is required authentication method to be supported by all SILC
   implementations.


3.2.2 Public Key Authentication

   Public key authentication may be used if passphrase based authentication
   is not desired.  The public key authentication works by sending a
   signature as authentication data to the other end, say, server.  The
   server must then verify the signature by the public key of the sender,
   which the server has received earlier in SKE protocol.

   The signature is computed using the private key of the sender by signing
   the HASH value provided by the SKE protocol previously, and the Key
   Exchange Start Payload from SKE protocol that was sent to the server.
   The server must verify the data, thus it must keep the HASH and the
   Key Exchange Start Payload saved during SKE and authentication protocols.

   If the verified signature matches the sent signature, the authentication
   were successful and SILC_PACKET_SUCCESS is sent.  If it failed the protocol
   execution is stopped and SILC_PACKET_FAILURE is sent.

   This is required authentication method to be supported by all SILC



Riikonen                                                       [Page 18]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


   implementations.


3.3 Connection Authentication Status Types

   This section defines all connection authentication status types that
   may be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
   to indicate the status of the protocol.  Implementations may map the
   status types to human readable error message.  All types except the
   SILC_AUTH_STATUS_OK type must be sent in SILC_PACKET_FAILURE packet.
   Following status types are defined:

   0   SILC_AUTH_OK

       Protocol was executed succesfully.


   1   SILC_AUTH_FAILED

       Authentication failed.


4 Security Considerations

   Security is central to the design of this protocol, and these security
   considerations permeate the specification.


5 References

   [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
                Protocol Specification", Internet Draft, June 2000.

   [SILC2]      Riikonen, P., "SILC Packet Protocol", Internet Draft,
                June 2000.

   [IRC]        Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
                RFC 1459, May 1993.

   [SSH-TRANS]  Ylonen, T., et al, "SSH Transport Layer Protocol",
                Internet Draft.

   [PGP]        Callas, J., et al, "OpenPGP Message Format", RFC 2440,
                November 1998.

   [SPKI]       Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
                September 1999.




Riikonen                                                       [Page 19]
\f
Internet Draft       Key Exchange and Authentication        28 June 2000


   [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
                Infrastructure, Certificate and CRL Profile", RFC 2459,
                January 1999.

   [Schneier]   Schneier, B., "Applied Cryptography Second Edition",
                John Wiley & Sons, New York, NY, 1996.

   [Menezes]    Menezes, A., et al, "Handbook of Applied Cryptography",
                CRC Press 1997.

   [OAKLEY]     Orman, H., "The OAKLEY Key Determination Protocol",
                RFC 2412, November 1998.

   [ISAKMP]     Maughan D., et al, "Internet Security Association and
                Key Management Protocol (ISAKMP)", RFC 2408, November
                1998.

   [IKE]        Harkins D., and Carrel D., "The Internet Key Exhange
                (IKE)", RFC 2409, November 1998.

   [HMAC]       Krawczyk, H., "HMAC: Keyed-Hashing for Message
                Authentication", RFC 2104, February 1997.


6 Author's Address

   Pekka Riikonen
   Kasarmikatu 11 A4
   70110 Kuopio
   Finland

   EMail: priikone@poseidon.pspt.fi



















Riikonen                                                       [Page 20]
\f