+++ /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 25 November 2002
-.ds CH
-.na
-.hy 0
-.in 0
-.nf
-Network Working Group P. Riikonen
-Internet-Draft
-draft-riikonen-silc-ke-auth-06.txt 25 November 2002
-Expires: 25 April 2003
-
-.in 3
-
-.ce 2
-SILC Key Exchange and Authentication Protocols
-<draft-riikonen-silc-ke-auth-06.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 [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 use best parts
-of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol
-and the OAKLEY Key Determination protocol [OAKLEY].
-
-The second protocol, 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)
-based on digital signatures.
-
-
-
-.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 .................................... 11
- 2.3 Processing the Key Material ............................... 12
- 2.4 SILC Key Exchange Groups .................................. 14
- 2.4.1 diffie-hellman-group1 ............................... 14
- 2.4.2 diffie-hellman-group2 ............................... 15
- 2.4.3 diffie-hellman-group3 ............................... 15
- 2.5 Key Exchange Status Types ................................. 16
-3 SILC Connection Authentication Protocol ....................... 17
- 3.1 Connection Auth Payload ................................... 18
- 3.2 Connection Authentication Types ........................... 19
- 3.2.1 Passphrase Authentication ........................... 19
- 3.2.2 Public Key Authentication ........................... 20
- 3.3 Connection Authentication Status Types .................... 21
-4 Security Considerations ....................................... 21
-5 References .................................................... 21
-6 Author's Address .............................................. 23
-
-
-.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 [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 use best parts of the SSH2
-Key Exchange protocol, Station-To-Station (STS) protocol and the
-OAKLEY Key Determination protocol [OAKLEY].
-
-The second protocol, 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) based
-on digital signatures.
-
-The basis of secure SILC session requires strong and secure key exchange
-protocol and authentication. The authentication protocol is 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 constantly refers to other SILC protocol specifications
-that should be read to be able to fully understand the functionality
-and purpose of these protocols. The most important references are
-the Secure Internet Live Conferencing, Protocol Specification [SILC1]
-and the SILC Packet Protocol [SILC2].
-
-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 use
-Diffie-Hellman key exchange algorithm and its functionality is derived
-from several key exchange protocols. SKE use 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 only 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 traveling between the two entities.
-Usually all traffic is secured with the key material derived from 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 sent in during this protocol. All the fields in the
-following payloads are 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
-character encoding for the security property values as defined in [SILC1]
-SHOULD be UTF-8 [RFC2279] in Key Exchange Start Payload.
-
-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 unmodified 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 white 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.
-
- IV Included 0x01
-
- This flag is used to indicate that Initial Vector (IV)
- in encryption will be included in the ciphertext
- which the recipient must use in decryption. The IV
- MUST be set after the last ciphertext block. With
- this flag it is possible to use SILC protocol on
- unreliable transport such as UDP/IP which may cause
- packet reordering and packet losses. By default,
- this flag is not set and thus IV is not included
- in the ciphertext. Setting this flag increases the
- ciphertext size by one ciphertext block. Responder
- MAY override this flag for the initiator.
-
- 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. This field MUST be present.
-
-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 for the version
- string format. This field MUST be present and include valid
- version string.
-
-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. This field MUST
- be present.
-
-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. This field MUST be present.
-
-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. This field MUST be present.
-
-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. This field MUST be present.
-
-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 Code (MAC)
- of the SILC packets. This field MUST be present.
-
-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. This field MAY be omitted.
-.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 digital signatures (it is
-based on pre-shared key) then the Mutual Authentication flag SHOULD be
-enabled. This way the connecting entity has to provide proof of
-possession of the private key for the public key it will provide in
-this 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
- SSH2 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 of the party. This public key
- is used to verify the digital signature. The public key
- or certificate in this field is encoded in the manner as
- defined in their respective definitions; see previous field.
-
-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 (Diffie-Hellman public values). 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
- always MUST 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(Initiator's Key Exchange Start Payload |
- public key (or certificate) | e). The '|' stands for
- concatenation. 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(Initiator's Key Exchange Start Payload |
- 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(0x0 | KEY | HASH)
-Receiving Initial Vector (IV) = hash(0x1 | KEY | HASH)
-Sending Encryption Key = hash(0x2 | KEY | HASH)
-Receiving Encryption Key = hash(0x3 | KEY | HASH)
-Sending HMAC Key = hash(0x4 | KEY | HASH)
-Receiving HMAC Key = hash(0x5 | 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(0x2 | KEY | HASH)
-K2 = hash(KEY | HASH | K1)
-K3 = hash(KEY | HASH | K1 | K2) ...
-
-Sending Encryption Key = K1 | K2 | K3 ...
-
-
-K1 = hash(0x3 | 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, to assure that parties can
-successfully process the key material.
-
-This same key processing procedure MAY be used in the SILC in some
-other circumstances as well. Any changes to this procedure is defined
-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 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 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.4.3 diffie-hellman-group3
-
-The length of this group is 2048 bits. This is OPTIONAL group.
-This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }.
-
-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 CA18217C 32905E46 2E36CE3B
-E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
-DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
-15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
-.in 3
-
-The generator used with this prime is g = 2. The group order q is
-(p - 1) / 2.
-
-
-
-
-
-.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 use this information to create the ID for the
-connection.
-
-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 authentication is successful 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. However, in this case the protocol still MUST be
-executed; the authentication data is empty indicating no authentication
-is required.
-
-If authentication method is passphrase the authentication data is
-plaintext passphrase. As the payload is encrypted it is safe to have
-plaintext passphrase. It is also provided as plaintext passphrase
-because the receiver may need to pass the entire passphrase into a
-passphrase verifier, and a message digest of the passphrase would
-prevent this. See the section 3.2.1 Passphrase Authentication for
-more information.
-
-If authentication method is public key authentication the authentication
-data is a digital signature of the hash value of hash HASH and 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.
-
-See the section 4 SILC Procedures in [SILC1] for more information about
-client creating connection to server, and server creating connection
-to router, and how to register the session in the SILC Network after
-successful Connection Authentication protocol.
-
-
-.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 authentication or public key
-authentication based on digital signatures. 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. The plaintext passphrase is put
-to the payload, that is then encrypted. The plaintext passphrase
-MUST be in UTF-8 [RFC2279] encoding. If the passphrase is in the
-sender's system in some other encoding it MUST be UTF-8 encoded
-before transmitted. The receiver MAY change the encoding of the
-passphrase to its system's default character encoding before verifying
-the passphrase.
-
-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
-digital 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. These values can be discarded after
-Connection Authentication protocol is completed.
-
-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, May 2002.
-
-[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
- May 2002.
-
-[SILC4] Riikonen, P., "SILC Commands", Internet Draft, May 2002.
-
-[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,
- 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 Exchange
- (IKE)", RFC 2409, November 1998.
-
-[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
- Authentication", RFC 2104, February 1997.
-
-[PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
- Specifications, Version 2.0", RFC 2437, October 1998.
-
-[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
-
-
-.ti 0
-6 Author's Address
-
-.nf
-Pekka Riikonen
-Snellmaninkatu 34 A 15
-70100 Kuopio
-Finland
-
-EMail: priikone@iki.fi
-
-This Internet-Draft expires 25 April 2003
projects / runtime.git / blobdiff