X-Git-Url: http://git.silcnet.org/gitweb/?a=blobdiff_plain;f=doc%2Fdraft-riikonen-silc-ke-auth-09.nroff;fp=doc%2Fdraft-riikonen-silc-ke-auth-09.nroff;h=0000000000000000000000000000000000000000;hb=f9d9c92fcc179ff82ae7aa5f724440215f194827;hp=385003420a290afc1fa78e11db67a293144b06db;hpb=e7b6c157b80152bf9fb9266e6bdd93f9fb0db776;p=crypto.git diff --git a/doc/draft-riikonen-silc-ke-auth-09.nroff b/doc/draft-riikonen-silc-ke-auth-09.nroff deleted file mode 100644 index 38500342..00000000 --- a/doc/draft-riikonen-silc-ke-auth-09.nroff +++ /dev/null @@ -1,1204 +0,0 @@ -.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 15 January 2007 -.ds CH -.na -.hy 0 -.in 0 -.nf -Network Working Group P. Riikonen -Internet-Draft -draft-riikonen-silc-ke-auth-09.txt 15 January 2007 -Expires: 15 July 2007 - -.in 3 - -.ce 2 -SILC Key Exchange and Authentication Protocols - - -.ti 0 -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. - - -.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. - -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. - - - -.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 ................................ 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 - - -.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, 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 -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. - - -.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 -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 -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 beginning -of all packets sent in during this protocol. All the fields in the -following payloads are in MSB (most significant byte first) order. - - -.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 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 - 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 - 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 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. - - -.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 - 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]. -.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 MUST 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 RFC 2412. - - -.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 RFC 3526. - - -.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. - -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. - - -.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 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 -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, 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. - - - -.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, 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. - -[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. - - -.ti 0 -6 Author's Address - -.nf -Pekka Riikonen -Helsinki -Finland - -EMail: priikone@iki.fi - - -.ti 0 -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.