X-Git-Url: http://git.silcnet.org/gitweb/?p=website.git;a=blobdiff_plain;f=docs%2Fprotocol%2Fdraft-riikonen-silc-ke-auth-09.txt;fp=docs%2Fprotocol%2Fdraft-riikonen-silc-ke-auth-09.txt;h=cb428684e7a628166e234c8669e1fd2d2c32ecb1;hp=0000000000000000000000000000000000000000;hb=4deb84ef17e789147fa9f7f35a302c5a38999817;hpb=4c0f02a06b6cd767a24041e0d37e95945e294623 diff --git a/docs/protocol/draft-riikonen-silc-ke-auth-09.txt b/docs/protocol/draft-riikonen-silc-ke-auth-09.txt new file mode 100644 index 0000000..cb42868 --- /dev/null +++ b/docs/protocol/draft-riikonen-silc-ke-auth-09.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group P. Riikonen +Internet-Draft +draft-riikonen-silc-ke-auth-09.txt 15 January 2007 +Expires: 15 July 2007 + + + SILC Key Exchange and Authentication Protocols + + +Status of this Draft + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of + six months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts as + reference material or to cite them other than as "work in progress". + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + +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. + + The second protocol, SILC Connection Authentication protocol provides + user level authentication used when creating connections in SILC + network. The protocol supports passphrase (pre-shared secret) + authentication and public key (and certificate) authentication based + on digital signatures. + + + + + + +Riikonen [Page 1] + +Internet-Draft 15 January 2007 + + +Table of Contents + + 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 ................................ 9 + 2.2 Key Exchange Procedure .................................... 11 + 2.3 Processing the Key Material ............................... 13 + 2.4 SILC Key Exchange Groups .................................. 15 + 2.4.1 diffie-hellman-group1 ............................... 15 + 2.4.2 diffie-hellman-group2 ............................... 15 + 2.4.3 diffie-hellman-group3 ............................... 16 + 2.5 Key Exchange Status Types ................................. 16 + 3 SILC Connection Authentication Protocol ....................... 18 + 3.1 Connection Auth Payload ................................... 19 + 3.2 Connection Authentication Types ........................... 20 + 3.2.1 Passphrase Authentication ........................... 20 + 3.2.2 Public Key Authentication ........................... 21 + 3.3 Connection Authentication Status Types .................... 21 + 4 Security Considerations ....................................... 22 + 5 References .................................................... 22 + 6 Author's Address .............................................. 23 + 7 Full Copyright Statement ...................................... 24 + + +List of Figures + + Figure 1: Key Exchange Start Payload + Figure 2: Key Exchange Payload + Figure 3: Connection Auth Payload + + +1 Introduction + + This memo describes two protocols used in the Secure Internet Live + Conferencing (SILC) protocol specified in the Secure Internet Live + Conferencing, Protocol Specification [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, such as 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 + + + +Riikonen [Page 2] + +Internet-Draft 15 January 2007 + + + network. The protocol supports passphrase (pre-shared secret) + authentication and public key (and certificate) authentication 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. + + +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]. + + +2 SILC Key Exchange Protocol + + SILC Key Exchange Protocol (SKE) is used to exchange shared secret + 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, such as SSH2 Key Exchange protocol, + Station-To-Station (STS) protocol and the OAKLEY Key Determination + protocol [OAKLEY]. The protocol does not claim any conformance + to any of these protocols, they were only used as a reference when + designing this protocol. The protocol can mutually authenticate the + negotiating parties during the key exchange. + + 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 + + + +Riikonen [Page 3] + +Internet-Draft 15 January 2007 + + + to the PKCS #3. + + +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 beginning + of all packets sent in during this protocol. All the fields in the + following payloads are in MSB (most significant byte first) order. + + +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 (` '). + + + + +Riikonen [Page 4] + +Internet-Draft 15 January 2007 + + + 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 ~ + | | + + + +Riikonen [Page 5] + +Internet-Draft 15 January 2007 + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Compression Alg Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Compression Algorithms ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Key Exchange Start Payload + + + 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 Initialization + Vector (IV) in encryption will be included in the + ciphertext which the recipient must use in decryption. + At the beginning of the SILC packet, before the SILC + Packet header an 8-bit Security ID (SID) MUST be + placed. After the SID, the IV MUST be placed. After + the IV, a 32-bit MSB first ordered packet sequence + number MUST be placed. The SID and IV MUST NOT be + encrypted, but the sequence number MUST be included + in encryption. The recipient MUST use the sequence + number during MAC verification [SILC2]. All fields + however are authenticated with MAC. + + The Security ID is set to value 0 when the key + exchange is performed for the first time. It is + monotonically increased after each re-key, wrapping + eventually. The SID in combination with the current + session can be used to identify which key has been + used to encrypt an incoming packet. This is especially + important after rekey when using UDP/IP protocol, + where packets may be lost or reordered. A packet with + unknown SID will result into discarding the packet as + it cannot be decrypted. After rekey, implementation + + + +Riikonen [Page 6] + +Internet-Draft 15 January 2007 + + + should understand that it may still receive packets + with old SID and be prepared to decrypt them with the + old key. + + 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 + packet length by one ciphertext block plus 1 byte for + the Security ID and 32 bits for the sequence number. + Responder MAY override this flag for the initiator, + however without this flag UDP connection cannot be + used. The flag MAY also be used in TCP connection. + + When using with UDP/IP implementations SHOULD use + anti-replay methods where an anti-replay window + defines what packets are replays. An example of + anti-window protocol is in [RFC2406] Section 3.4.2 + with example source code in [RFC2401] Appendix C. + While [RFC2401] and [RFC2406] does not relate to SILC, + the anti-replay method used is applicable in SILC. + + 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 with + new Diffie-Hellman exponent values. 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 + + + +Riikonen [Page 7] + +Internet-Draft 15 January 2007 + + + 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. + + + +Riikonen [Page 8] + +Internet-Draft 15 January 2007 + + + 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. + + +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 or there is no authentication) 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. + + + + + +Riikonen [Page 9] + +Internet-Draft 15 January 2007 + + + 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 ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: Key Exchange Payload + + + 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. + + + + +Riikonen [Page 10] + +Internet-Draft 15 January 2007 + + + o Public Key (or certificate) (variable length) - The + public key or certificate of the party. This public key + may be 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 (computed Diffie-Hellman public values). + See section 2.2 Key Exchange Procedure for detailed description + how this field is computed. This field is MP integer and is + encoded as defined in [SILC1]. + + 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. The encoding for signature + is defined in [SILC1]. + + + +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, + + + +Riikonen [Page 11] + +Internet-Draft 15 January 2007 + + + 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). + + + +Riikonen [Page 12] + +Internet-Draft 15 January 2007 + + + 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 MUST start using the new keys. + + +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: + + 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) + + + 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 + + + +Riikonen [Page 13] + +Internet-Draft 15 January 2007 + + + 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: + + 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 ... + + + 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. + + + + + +Riikonen [Page 14] + +Internet-Draft 15 January 2007 + + +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). + + +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 + + 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 + + + The generator used with this prime is g = 2. The group order q is + (p - 1) / 2. + + This group was taken from RFC 2412. + + +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 + + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED + EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D + C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F + 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D + 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF + + The generator used with this prime is g = 2. The group order q is + + + +Riikonen [Page 15] + +Internet-Draft 15 January 2007 + + + (p - 1) / 2. + + This group was taken from RFC 3526. + + +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 + + 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 + + The generator used with this prime is g = 2. The group order q is + (p - 1) / 2. + + This group was taken from RFC 3526. + + Additional larger groups are defined in RFC 3526 and may be used in SKE + by defining name for them using the above name format. + + +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: + + 0 SILC_SKE_STATUS_OK + + Protocol were executed successfully. + + + + + +Riikonen [Page 16] + +Internet-Draft 15 January 2007 + + + 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. + + + +Riikonen [Page 17] + +Internet-Draft 15 January 2007 + + + 11 SILC_SKE_STATUS_INVALID_COOKIE + + The cookie in the Key Exchange Start Payload was malformed, + because responder modified the cookie. + + +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 entity the + connection is. The type defines whether the connection 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 + + + +Riikonen [Page 18] + +Internet-Draft 15 January 2007 + + + 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. + + +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. + + + + + + + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Payload Length | Connection Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Authentication Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Connection Auth Payload + + + o Payload Length (2 bytes) - Length of the entire Connection + + + +Riikonen [Page 19] + +Internet-Draft 15 January 2007 + + + 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. + + +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. + + +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. + + + + +Riikonen [Page 20] + +Internet-Draft 15 January 2007 + + +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, or which the + server has cached locally at some previous time. + + 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. + + + +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. + + + + + +Riikonen [Page 21] + +Internet-Draft 15 January 2007 + + + 1 SILC_AUTH_FAILED + + Authentication failed. + + +4 Security Considerations + + Security is central to the design of this protocol, and these security + considerations permeate the specification. 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. + + +5 References + + [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC), + Protocol Specification", Internet Draft, January 2007. + + [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft, + January 2007. + + [SILC4] Riikonen, P., "SILC Commands", Internet Draft, January 2007. + + [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. + + + + +Riikonen [Page 22] + +Internet-Draft 15 January 2007 + + + [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. + + [RFC2401] Kent, S., et al, "Security Architecture for the Internet + Protocol", RFC 2401, November 1998. + + [RFC2406] Kent, S., et al, "Security Architecture for the Internet + Protocol", RFC 2406, November 1998. + + +6 Author's Address + + Pekka Riikonen + Helsinki + Finland + + EMail: priikone@iki.fi + + + + + +Riikonen [Page 23] + +Internet-Draft 15 January 2007 + + +7 Full Copyright Statement + + Copyright (C) The Internet Society (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Riikonen [Page 24] +