+++ /dev/null
-.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 September 2000
-.ds CH
-.na
-.hy 0
-.in 0
-.nf
-Network Working Group P. Riikonen
-INTERNET-DRAFT
-draft-riikonen-silc-ke-auth-00.txt 13 September 2000
-Expires: 13 May 2001
-
-.in 3
-
-.ce 2
-SILC Key Exchange and Authentication Protocols
-<draft-riikonen-silc-ke-auth-00.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
-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
-
-
-.ti 0
-List of Figures
-
-.nf
-Figure 1: Key Exchange Start Payload
-Figure 2: Key Exchange 1 Payload
-Figure 3: Key Exchange 2 Payload
-Figure 4: 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, 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.
-
-
-.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 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.
-
-
-.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 fields in
-all payloads are always in MSB (most significant byte first) order.
-Following descriptions of these payloads.
-
-
-.ti 0
-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 (` ').
-
-
-
-
-
-
-
-.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 ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| 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
- 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, not including any other field.
-
-o Cookie (16 bytes) - Cookie that uniforms 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.1.2 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 algorithms
- list, not including any other field.
-
-o Hash Algorithms (variable length) - The list of Hash algorithms.
-
-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 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-.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 Host (or certificate) ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Public Data Length | |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
-| |
-~ Public Data (e = g ^ x mod p) ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-.in 3
-
-.ce
-Figure 2: Key Exchange 1 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.
-
-o Public Data Length (2 bytes) - The length of the public
- data computed by the responder, not including any other
- field.
-
-o Public Data (variable length) - The public data to be
- sent to the responder. See section 2.2 Key Exchange
- Procedure for detailed description how this field is
- computed. This value is binary encoded.
-.in 3
-
-
-.ti 0
-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.
-
-
-
-.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 Host (or certificate) ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Public Data Length | |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
-| |
-~ Public Data (f = g ^ y mod p) ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Signature Length | |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
-| |
-~ Signature Data ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-.in 3
-
-.ce
-Figure 3: Key Exchange 2 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. 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, not including any other
- field.
-
-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,
- not including any other field.
-
-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.
-
-
-.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 1 Payload and sent
- to the responder.
-
-
- 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.
-
-
-
-.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. This is used in the key
-deriving process as a session identifier.
-
-Keys are 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)
-HMAC Key = hash(4 | 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 is
-produced in following manner:
-
-.in 6
-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 ...
-.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 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.
-
-
-.ti 0
-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).
-
-
-.ti 0
-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
-
-.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.
-Following status types are defined:
-
-.in 6
-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.
-.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 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.
-
-
-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.
-
-
-
-.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. 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 4: 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.
-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 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.
-
-
-.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.
-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.
-Following status types are defined:
-
-0 SILC_AUTH_OK
-
- Protocol was executed succesfully.
-
-
-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.
-
-
-.ti 0
-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.
-
-[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.
-
-
-.ti 0
-6 Author's Address
-
-.nf
-Pekka Riikonen
-Kasarmikatu 11 A4
-70110 Kuopio
-Finland
-
-EMail: priikone@poseidon.pspt.fi
-
-This Internet-Draft expires 13 May 2001
-
projects / crypto.git / blobdiff