.pl 10.0i
   .po 0
   .ll 7.2i
   .lt 7.2i
   .nr LL 7.2i
   .nr LT 7.2i
   .ds LF Riikonen
   .ds RF FORMFEED[Page %]
   .ds CF
  .ds LH Internet-Draft
  .ds RH 13 November 2001
  .ds CH
  .na
  .hy 0
  .in 0
  .nf
  Network Working Group                                        P. Riikonen
  Internet-Draft
  draft-riikonen-silc-ke-auth-04.txt                      13 November 2001
  Expires: 13 May 2002
  
  .in 3
  
  .ce 2
  SILC Key Exchange and Authentication Protocols
  <draft-riikonen-silc-ke-auth-04.txt>
  
  .ti 0
  Status of this Memo
  
  This document is an Internet-Draft and is in full conformance with
  all provisions of Section 10 of RFC 2026.  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
  
  The distribution of this memo is unlimited.
  
  
  .ti 0
  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).
  
  
  
  .ti 0
  Table of Contents
  
  .nf
  1 Introduction ..................................................  2
    1.1 Requirements Terminology ..................................  3
  2 SILC Key Exchange Protocol ....................................  3
    2.1 Key Exchange Payloads .....................................  4
        2.1.1 Key Exchange Start Payload ..........................  4
        2.1.2 Key Exchange Payload ................................  8
    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 ............................... 14
        2.4.2 diffie-hellman-group2 ............................... 14
    2.5 Key Exchange Status Types ................................. 15
  3 SILC Connection Authentication Protocol ....................... 16
    3.1 Connection Auth Payload ................................... 18
    3.2 Connection Authentication Types ........................... 19
        3.2.1 Passphrase Authentication ........................... 19
        3.2.2 Public Key Authentication ........................... 19
    3.3 Connection Authentication Status Types .................... 20
  4 Security Considerations ....................................... 20
  5 References .................................................... 20
  6 Author's Address .............................................. 22
  
  
  .ti 0
 List of Figures
 
 .nf
 Figure 1:  Key Exchange Start Payload
 Figure 2:  Key Exchange Payload
 Figure 3:  Connection Auth Payload
 
 
 .ti 0
 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
 can be used to authenticate the user with, for example, pass phrase
 (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 the 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.
 
 
 .ti 0
 1.1 Requirements Terminology
 
 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, 
 MAY, and OPTIONAL, when they appear in this document, are to be
 interpreted as described in [RFC2119].
 
 
 .ti 0
 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 router
 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.
 
 The Diffie-Hellman implementation used in the SILC SHOULD be compliant
 to the PKCS #3.
 
 
 .ti 0
 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.
 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 the
 fields in the payloads are always in MSB (most significant byte first)
 order.  Following descriptions of these payloads.
 
 
 .ti 0
 2.1.1 Key Exchange Start Payload
 
 The key exchange between two entities MUST be started by sending the
 SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
 Initiator sends the Key Exchange Start Payload to the responder filled
 with all security properties it supports.  The responder then checks
 whether it supports the security properties.
 
 It then sends a Key Exchange Start Payload to the initiator filled with
 security properties it selected from the original payload.  The payload
 sent by responder MUST include only one chosen property per list.
 
 The Key Exchange Start Payload is used to tell connecting entities what
 security properties and algorithms should be used in the communication.
 The Key Exchange Start Payload is sent only once per session.  Even if
 the PFS (Perfect Forward Secrecy) flag is set the Key Exchange Start
 Payload is not re-sent.  When PFS is desired the Key Exchange Payloads
 are sent to negotiate new key material.  The procedure is equivalent to
 the very first negotiation except that the Key Exchange Start Payload
 is not sent.
 
 As this payload is used only with the very first key exchange the payload
 is never encrypted, as there are no keys to encrypt it with.
 
 A cookie is also sent in this payload.  A cookie is used to randomize the
 payload so that none of the key exchange parties can determine this
 payload before the key exchange procedure starts.  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 (` ').
 
 
 .in 5
 .nf
                      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                             +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Version String Length     |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                         Version String                        ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Key Exchange Grp Length     |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                      Key Exchange Groups                      ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        PKCS Alg Length        |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                         PKCS Algorithms                       ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Encryption Alg Length     |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                      Encryption Algorithms                    ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       Hash Alg Length         |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                         Hash Algorithms                       ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         HMAC Length           |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                             HMACs                             ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Compression Alg Length     |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                     Compression Algorithms                    ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .in 3
 
 .ce
 Figure 1:  Key Exchange Start Payload
 
 
 
 .in 6
 o RESERVED (1 byte) - Reserved field.  Sender fills this with
   zero (0) value.
 
 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.  The 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.  See the [SILC1]
        for more information on this issue.  When PFS is
        used, re-keying and creating new keys for any
        particular purpose MUST cause new key exchange.
        In this key exchange only the Key Exchange Payload
        is sent and the Key Exchange Start Payload MUST
        NOT be sent.  When doing PFS the Key Exchange
        Payloads are encrypted with the old keys.
 
      Mutual Authentication    0x04
 
        Both of the parties will perform authentication
        by providing signed data for the other party to
        verify.  By default, only responder will provide
        the signature data.  If this is set then the
        initiator must also provide it.  Initiator MAY
        set this but also responder MAY set this even if
        initiator did not set it.
 
      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, not including any other field.
 
 o Cookie (16 bytes) - Cookie that randomize this payload so
   that each of the party cannot determine the payload before
   hand.
 
 o Version String Length (2 bytes) - The length of the Version
   String field, not including any other field.
 
 o Version String (variable length) - Indicates the version of
   the sender of this payload.  Initiator sets this when sending
   the payload and responder sets this when it replies by sending
   this payload.  See [SILC1] for definition of the version
   string format.
 
 o Key Exchange Grp Length (2 bytes) - The length of the
   key exchange group list, not including any other field.
 
 o Key Exchange Group (variable length) - The list of
   key exchange groups.  See the section 2.4 SILC Key Exchange
   Groups for definitions of these groups.
 
 o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms
   list, not including any other field.
 
 o PKCS Algorithms (variable length) - The list of PKCS 
   algorithms.
 
 o Encryption Alg Length (2 bytes) - The length of the encryption
   algorithms list, not including any other field.
 
 o Encryption Algorithms (variable length) - The list of
   encryption algorithms.
 
 o Hash Alg Length (2 bytes) - The length of the Hash algorithm
   list, not including any other field.
 
 o Hash Algorithms (variable length) - The list of Hash
   algorithms.  The hash algorithms are mainly used in the
   SKE protocol.
 
 o HMAC Length (2 bytes) - The length of the HMAC list, not
   including any other field.
 
 o HMACs (variable length) - The list of HMACs.  The HMAC's
   are used to compute the Message Authentication Codes (MAC)
   of the SILC packets.
 
 o Compression Alg Length (2 bytes) - The length of the
   compression algorithms list, not including any other field.
 
 o Compression Algorithms (variable length) - The list of 
   compression algorithms.
 .in 3
 
 
 .ti 0
 2.1.2 Key Exchange Payload
 
 Key Exchange payload is used to deliver the public key (or certificate),
 the computed Diffie-Hellman public value and possibly signature data
 from one party to the other.  When initiator is using this payload
 and the Mutual Authentication flag is not set then the initiator MUST
 NOT provide the signature data.  If the flag is set then the initiator
 MUST provide the signature data so that the responder can verify it.
 
 The Mutual Authentication flag is usually used when a separate 
 authentication protocol will not be executed for the initiator of the
 protocol.  This is case for example when the SKE is performed between
 two SILC clients.  In normal case, where client is connecting to a
 server, or server is connecting to a router the Mutual Authentication
 flag may be omitted.  However, if the connection authentication protocol 
 for the connecting entity is not based on public key authentication (it
 is based on passphrase) then the Mutual Authentication flag SHOULD be 
 enabled.  This way the connecting entity has to provide proof of
 posession of the private key for the public key it will provide in
 SILC Key Exchange protocol.
 
 When performing re-key with PFS selected this is the only payload that
 is sent in the SKE protocol.  The Key Exchange Start Payload MUST NOT
 be sent at all.  However, this payload does not have all the fields
 present.  In the re-key with PFS the public key and a possible signature
 data SHOULD NOT be present.  If they are present they MUST be ignored.
 The only field that is present is the Public Data that is used to create
 the new key material.  In the re-key the Mutual Authentication flag, that
 may be set in the initial negotiation, MUST also be ignored.
 
 This payload is sent inside SILC_PACKET_KEY_EXCHANGE_1 and inside
 SILC_PACKET_KEY_EXCHANGE_2 packet types.  The initiator uses the 
 SILC_PACKET_KEY_EXCHANGE_1 and the responder the latter.
 
 The following diagram represent the Key Exchange Payload.
 
 
 .in 5
 .nf
                      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 party (or certificate)           ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       Public Data Length      |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                          Public Data                          ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Signature Length       |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 ~                        Signature Data                         ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .in 3
 
 .ce
 Figure 2:  Key Exchange Payload
 
 
 .in 6
 o Public Key Length (2 bytes) - The length of the Public Key
   (or certificate) field, not including any other field.
 
 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 and the connection SHOULD
   be closed immediately.
 
 o Public Key (or certificate) (variable length) - The
   public key or certificate.
 
 o Public Data Length (2 bytes) - The length of the Public Data
   field, not including any other field.
 
 o Public Data (variable length) - The public data to be
   sent to the receiver.  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,
   not including any other field.
 
 o Signature Data (variable length) - The signature signed
   by the sender.  The receiver of this signature MUST
   verify it.  The verification is done using the sender's
   public key.  See section 2.2 Key Exchange Procedure for
   detailed description how to produce the signature.  If
   the Mutual Authentication flag is not set then initiator
   MUST NOT provide this field and the Signature Length field
   MUST be set to zero (0) value.  If the flag is set then
   also the initiator MUST provide this field.  The responder
   MUST always provide this field.
 .in 3
 
 
 .ti 0
 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 Payload, with the public key
         (or certificate) and sent to the responder.
 
         If the Mutual Authentication flag is set then initiator
         MUST also produce signature data SIGN_i which the responder
         will verify.  The initiator MUST compute a hash value
         HASH_i = hash(Key Exchange Start Payload | public key
         (or certificate) | e).  It then signs the HASH_i value with
         its private key resulting a signature SIGN_i.
 
     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 | public 
         key (or certificate) | Initiator's 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 Payload and sends it to the 
         initiator.
 
         If the Mutual Authentication flag is set then the responder
         SHOULD verify that the public key provided in the payload
         is authentic, or if certificates are used it verifies the
         certificate.  The responder 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).  It then
         computes the HASH_i value the same way initiator did in the
         phase 1.  It then verifies the signature SIGN_i from the
         payload with the hash value HASH_i using the received public
         key.
 
     3.  Initiator verifies that the public key provided in
         the payload is authentic, or if certificates are used
         it verifies the certificate.  The 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 the SILC_PACKET_FAILURE MUST be sent
 to indicate that the key exchange protocol has failed, and the connection
 SHOULD be closed immediately.  Any other packets MUST NOT be sent or
 accepted during the key exchange except the SILC_PACKET_KEY_EXCHANGE_*,
 SILC_PACKET_FAILURE and 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.
 
 If the Mutual Authentication flag was set the protocol produces also
 a hash value HASH_i.  This value, however, must be discarded.
 
 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.
 
 
 .ti 0
 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.
 
 The keys MUST be derived from the key material as follows:
 
 .in 6
 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)
 Sending HMAC Key                = hash(4 | KEY | HASH)
 Receiving HMAC Key              = hash(5 | KEY | HASH)
 .in 3
 
 
 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 MUST
 be produced in the following manner:
 
 .in 6
 K1 = hash(2 | KEY | HASH)
 K2 = hash(KEY | HASH | K1)
 K3 = hash(KEY | HASH | K1 | K2)  ...
 
 Sending Encryption Key = K1 | K2 | K3 ...
 
 
 K1 = hash(3 | KEY | HASH)
 K2 = hash(KEY | HASH | K1)
 K3 = hash(KEY | HASH | K1 | K2)  ...
 
 Receiving Encryption Key = K1 | K2 | K3 ...
 .in 3
 
 
 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
 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 receiving).
 
 The HMAC keys are 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 to generate the MAC keys.
 
 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.
 
 This same procedure is used in the SILC in some other circumstances
 as well.  Any changes to this procedure is mentioned separately when
 this procedure is needed.  See the [SILC1] and the [SILC2] for these
 circumstances.
 
 
 .ti 0
 2.4 SILC Key Exchange Groups
 
 The Following groups may be used in the SILC Key Exchange protocol.
 The first group diffie-hellman-group1 is REQUIRED, other groups MAY be 
 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 does not have to be the first in the list).
 
 
 .ti 0
 2.4.1 diffie-hellman-group1
 
 The length of this group is 1024 bits.  This is REQUIRED group.
 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
 
 Its decimal value is
 
 .in 6
 179769313486231590770839156793787453197860296048756011706444
 423684197180216158519368947833795864925541502180565485980503
 646440548199239100050792877003355816639229553136239076508735
 759914822574862575007425302077447712589550957937778424442426
 617334727629299387668709205606050270810842907692932019128194
 467627007
 .in 3
 
 Its hexadecimal value is
 
 .in 6
 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
 .in 3
 
 
 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.
 
 
 .ti 0
 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
 
 .in 6
 241031242692103258855207602219756607485695054850245994265411
 694195810883168261222889009385826134161467322714147790401219
 650364895705058263194273070680500922306273474534107340669624
 601458936165977404102716924945320037872943417032584377865919
 814376319377685986952408894019557734611984354530154704374720
 774996976375008430892633929555996888245787241299381012913029
 459299994792636526405928464720973038494721168143446471443848
 8520940127459844288859336526896320919633919
 .in 3
 
 Its hexadecimal value is
 
 .in 6
 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
 .in 3
 
 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.
 
 
 .ti 0
 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.
 The length of status is 32 bits (4 bytes).  The following status types
 are defined:
 
 .in 6
 0   SILC_SKE_STATUS_OK
 
     Protocol were executed successfully.
 
 
 1   SILC_SKE_STATUS_ERROR
 
     Unknown error occurred.  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_HMAC
 
     None of the provided HMACs were supported.
 
 
 8   SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY
 
     Provided public key type is not supported.
 
 
 9   SILC_SKE_STATUS_INCORRECT_SIGNATURE
 
     Provided signature was incorrect.
 
 
 10  SILC_SKE_STATUS_BAD_VERSION
 
     Provided version string was not acceptable.
 
 11  SILC_SKE_STATUS_INVALID_COOKIE
 
     The cookie in the Key Exchange Start Payload was malformed,
     because responder modified the cookie.
 .in 3
 
 
 .ti 0
 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 router 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 client by the server.
 See the [SILC1] for the details of the connecting procedure.
 
 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 MUST be started by the connecting party by sending the
 SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload,
 described in the next section.  This payload MUST include the
 authentication data.  The 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 MAY
 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.  See the section 3.2.1 Passphrase
 Authentication for more information.
 
 If authentication method is public key authentication the authentication
 data is a signature of the hash value of hash HASH plus Key Exchange
 Start Payload, established by the SILC Key Exchange protocol.  This
 signature MUST then be verified by the server.  See the section 3.2.2
 Public Key Authentication for more information.
 
 The connecting client 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.  The connecting client 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 router connection where servers create their own ID's.
 
 
 .ti 0
 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.  The following diagram 
 represent the Connection Auth Payload.
 
 
 .in 5
 .nf
                      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                       ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .in 3
  
 .ce
 Figure 3:  Connection Auth Payload
 
 
 .in 6
 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. 
 
 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.
 .in 3
 
 
 
 
 .ti 0
 3.2 Connection Authentication Types
 
 SILC supports two authentication types to be used in the connection
 authentication protocol; passphrase or public key based authentication.
 The following sections defines the authentication methods.  See [SILC2]
 for defined numerical authentication method types.
 
 
 .ti 0
 3.2.1 Passphrase Authentication
 
 Passphrase authentication or pre-shared-key based 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.
 
 When password authentication is used it is RECOMMENDED that maximum
 amount of padding is applied to the SILC packet.  This way it is not
 possible to approximate the length of the password from the encrypted
 packet.
 
 
 .ti 0
 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.
 These are concatenated and hash function is used to compute a hash value
 which is then signed.
 
   auth_hash = hash(HASH | Key Exchange Start Payload);
   signature = sign(auth_hash);
 
 The hash() function used to compute the value is the hash function
 negotiated in the SKE protocol.  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
 implementations.
 
 
 .ti 0
 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.
 The length of status is 32 bits (4 bytes).  The following status types
 are defined:
 
 
 
 0   SILC_AUTH_OK
 
     Protocol was executed successfully.
 
 
 1   SILC_AUTH_FAILED
 
     Authentication failed.
 
 
 .ti 0
 4 Security Considerations
 
 Security is central to the design of this protocol, and these security
 considerations permeate the specification.  Common security considerations
 such as keeping private keys truly private and using adequate lengths for 
 symmetric and asymmetric keys must be followed in order to maintain the   
 security of this protocol.
 
 
 .ti 0
 5 References
 
 [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
              Protocol Specification", Internet Draft, April 2001.
 
 [SILC2]      Riikonen, P., "SILC Packet Protocol", Internet Draft,
              April 2001.
 
 [SILC4]      Riikonen, P., "SILC Commands", Internet Draft, April 2001.
 
 [IRC]        Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
              RFC 1459, May 1993.
 
 [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
              April 2000.
 
 [IRC-CHAN]   Kalt, C., "Internet Relay Chat: Channel Management", RFC
              2811, April 2000.
 
 [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
              2812, April 2000.
 
 [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
              2813, April 2000.
 
 [SSH-TRANS]  Ylonen, T., et al, "SSH Transport Layer Protocol", 
              Internet Draft.
 
 [PGP]        Callas, J., et al, "OpenPGP Message Format", RFC 2440,