--- /dev/null
+.pl 10.0i
+.po 0
+.ll 7.2i
+.lt 7.2i
+.nr LL 7.2i
+.nr LT 7.2i
+.ds LF Riikonen
+.ds RF FORMFEED[Page %]
+.ds CF
+.ds LH Internet-Draft
+.ds RH XXX
+.ds CH
+.na
+.hy 0
+.in 0
+.nf
+Network Working Group P. Riikonen
+Internet-Draft
+draft-riikonen-silc-ke-auth-09.txt XXX
+Expires: XXX
+
+.in 3
+
+.ce 2
+SILC Key Exchange and Authentication Protocols
+<draft-riikonen-silc-ke-auth-09.txt>
+
+.ti 0
+Status of this Memo
+
+This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC 2026. Internet-Drafts are
+working documents of the Internet Engineering Task Force (IETF), its
+areas, and its working groups. Note that other groups may also
+distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time. It is inappropriate to use Internet-Drafts as reference
+material or to cite them other than as "work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html
+
+The distribution of this memo is unlimited.
+
+
+.ti 0
+Abstract
+
+This memo describes two protocols used in the Secure Internet Live
+Conferencing (SILC) protocol, specified in the Secure Internet Live
+Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange
+(SKE) protocol provides secure key exchange between two parties
+resulting into shared secret key material. The protocol is based
+on Diffie-Hellman key exchange algorithm and its functionality is
+derived from several key exchange protocols.
+
+The second protocol, SILC Connection Authentication protocol provides
+user level authentication used when creating connections in SILC
+network. The protocol is transparent to the authentication data
+which means that it can be used to authenticate the connection with, for
+example, passphrase (pre-shared secret) or public key (and certificate)
+based on digital signatures.
+
+
+
+.ti 0
+Table of Contents
+
+.nf
+1 Introduction .................................................. 2
+ 1.1 Requirements Terminology .................................. 3
+2 SILC Key Exchange Protocol .................................... 3
+ 2.1 Key Exchange Payloads ..................................... 4
+ 2.1.1 Key Exchange Start Payload .......................... 4
+ 2.1.2 Key Exchange Payload ................................ 8
+ 2.2 Key Exchange Procedure .................................... 11
+ 2.3 Processing the Key Material ............................... 12
+ 2.4 SILC Key Exchange Groups .................................. 14
+ 2.4.1 diffie-hellman-group1 ............................... 14
+ 2.4.2 diffie-hellman-group2 ............................... 15
+ 2.4.3 diffie-hellman-group3 ............................... 15
+ 2.5 Key Exchange Status Types ................................. 16
+3 SILC Connection Authentication Protocol ....................... 17
+ 3.1 Connection Auth Payload ................................... 18
+ 3.2 Connection Authentication Types ........................... 19
+ 3.2.1 Passphrase Authentication ........................... 19
+ 3.2.2 Public Key Authentication ........................... 20
+ 3.3 Connection Authentication Status Types .................... 21
+4 Security Considerations ....................................... 21
+5 References .................................................... 21
+6 Author's Address .............................................. 23
+7 Full Copyright Statement ...................................... 23
+
+
+.ti 0
+List of Figures
+
+.nf
+Figure 1: Key Exchange Start Payload
+Figure 2: Key Exchange Payload
+Figure 3: Connection Auth Payload
+
+
+.ti 0
+1 Introduction
+
+This memo describes two protocols used in the Secure Internet Live
+Conferencing (SILC) protocol specified in the Secure Internet Live
+Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange
+(SKE) protocol provides secure key exchange between two parties
+resulting into shared secret key material. The protocol is based on
+Diffie-Hellman key exchange algorithm and its functionality is derived
+from several key exchange protocols, 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 is transparent to the authentication data which
+means that it can be used to authenticate the connection with, for example,
+passphrase (pre-shared secret) or public key (and certificate) based
+on digital signatures.
+
+The basis of secure SILC session requires strong and secure key exchange
+protocol and authentication. The authentication protocol is secured and
+no authentication data is ever sent in the network without encrypting
+and authenticating it first. Thus, authentication protocol may be used
+only after the key exchange protocol has been successfully completed.
+
+This document constantly refers to other SILC protocol specifications
+that should be read to be able to fully understand the functionality
+and purpose of these protocols. The most important references are
+the Secure Internet Live Conferencing, Protocol Specification [SILC1]
+and the SILC Packet Protocol [SILC2].
+
+The protocol is intended to be used with the SILC protocol thus it
+does not define own framework that could be used. The framework is
+provided by the SILC protocol.
+
+
+.ti 0
+1.1 Requirements Terminology
+
+The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+MAY, and OPTIONAL, when they appear in this document, are to be
+interpreted as described in [RFC2119].
+
+
+.ti 0
+2 SILC Key Exchange Protocol
+
+SILC Key Exchange Protocol (SKE) is used to exchange shared secret
+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.
+Following descriptions of these payloads.
+
+
+.ti 0
+2.1.1 Key Exchange Start Payload
+
+The key exchange between two entities MUST be started by sending the
+SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
+Initiator sends the Key Exchange Start Payload to the responder filled
+with all security properties it supports. The responder then checks
+whether it supports the security properties.
+
+It then sends a Key Exchange Start Payload to the initiator filled with
+security properties it selected from the original payload. The payload
+sent by responder MUST include only one chosen property per list. The
+character encoding for the security property values as defined in [SILC1]
+SHOULD be UTF-8 [RFC2279] in Key Exchange Start Payload.
+
+The Key Exchange Start Payload is used to tell connecting entities what
+security properties and algorithms should be used in the communication.
+The Key Exchange Start Payload is sent only once per session. Even if
+the PFS (Perfect Forward Secrecy) flag is set the Key Exchange Start
+Payload is not re-sent. When PFS is desired the Key Exchange Payloads
+are sent to negotiate new key material. The procedure is equivalent to
+the very first negotiation except that the Key Exchange Start Payload
+is not sent.
+
+As this payload is used only with the very first key exchange the payload
+is never encrypted, as there are no keys to encrypt it with.
+
+A cookie is also sent in this payload. A cookie is used to randomize the
+payload so that none of the key exchange parties can determine this
+payload before the key exchange procedure starts. The cookie MUST be
+returned to the original sender unmodified by the responder.
+
+Following diagram represents the Key Exchange Start Payload. The lists
+mentioned below are always comma (`,') separated and the list MUST NOT
+include white spaces (` ').
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| RESERVED | Flags | Payload Length |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
++ +
+| |
++ Cookie +
+| |
++ +
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Version String Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Version String ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Key Exchange Grp Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Key Exchange Groups ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| PKCS Alg Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ PKCS Algorithms ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Encryption Alg Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Encryption Algorithms ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Hash Alg Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Hash Algorithms ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| HMAC Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ HMACs ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Compression Alg Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Compression Algorithms ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 1: Key Exchange Start Payload
+
+
+.in 6
+o RESERVED (1 byte) - Reserved field. Sender fills this with
+ zero (0) value.
+
+o Flags (1 byte) - Indicates flags to be used in the key
+ exchange. Several flags can be set at once by ORing the
+ flags together. The following flags are reserved for this
+ field:
+
+ No flags 0x00
+
+ In this case the field is ignored.
+
+ IV Included 0x01
+
+ This flag is used to indicate that 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.
+
+ 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) then the Mutual Authentication flag SHOULD be
+enabled. This way the connecting entity has to provide proof of
+possession of the private key for the public key it will provide in
+this protocol.
+
+When performing re-key with PFS selected this is the only payload that
+is sent in the SKE protocol. The Key Exchange Start Payload MUST NOT
+be sent at all. However, this payload does not have all the fields
+present. In the re-key with PFS the public key and a possible signature
+data SHOULD NOT be present. If they are present they MUST be ignored.
+The only field that is present is the Public Data that is used to create
+the new key material. In the re-key the Mutual Authentication flag, that
+may be set in the initial negotiation, MUST also be ignored.
+
+This payload is sent inside SILC_PACKET_KEY_EXCHANGE_1 and inside
+SILC_PACKET_KEY_EXCHANGE_2 packet types. The initiator uses the
+SILC_PACKET_KEY_EXCHANGE_1 and the responder the latter.
+
+The following diagram represent the Key Exchange Payload.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Public Key Length | Public Key Type |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Public Key of the party (or certificate) ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Public Data Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Public Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Signature Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Signature Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 2: Key Exchange Payload
+
+
+.in 6
+o Public Key Length (2 bytes) - The length of the Public Key
+ (or certificate) field, not including any other field.
+
+o Public Key Type (2 bytes) - The public key (or certificate)
+ type. This field indicates the type of the public key in
+ the packet. Following types are defined:
+
+ 1 SILC style public key (mandatory)
+ 2 SSH2 style public key (optional)
+ 3 X.509 Version 3 certificate (optional)
+ 4 OpenPGP certificate (optional)
+ 5 SPKI certificate (optional)
+
+ The only required type to support is type number 1. See
+ [SILC1] for the SILC public key specification. See
+ SSH2 public key specification in [SSH-TRANS]. See X.509v3
+ certificate specification in [PKIX-Part1]. See OpenPGP
+ certificate specification in [PGP]. See SPKI certificate
+ specification in [SPKI]. If this field includes zero (0)
+ or unsupported type number the protocol MUST be aborted
+ sending SILC_PACKET_FAILURE message and the connection SHOULD
+ be closed immediately.
+
+o Public Key (or certificate) (variable length) - The
+ public key or certificate of the party. This public key
+ is used to verify the digital signature. The public key
+ or certificate in this field is encoded in the manner as
+ defined in their respective definitions; see previous field.
+
+o Public Data Length (2 bytes) - The length of the Public Data
+ field, not including any other field.
+
+o Public Data (variable length) - The public data to be
+ sent to the receiver (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.
+
+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, June 2003.
+
+[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
+ June 2003.
+
+[SILC4] Riikonen, P., "SILC Commands", Internet Draft, June 2003.
+
+[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
+ RFC 1459, May 1993.
+
+[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+ April 2000.
+
+[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
+ 2811, April 2000.
+
+[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+ 2812, April 2000.
+
+[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+ 2813, April 2000.
+
+[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
+ Internet Draft.
+
+[PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
+ November 1998.
+
+[SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
+ September 1999.
+
+[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
+ Infrastructure, Certificate and CRL Profile", RFC 2459,
+ January 1999.
+
+[Schneier] Schneier, B., "Applied Cryptography Second Edition",
+ John Wiley & Sons, New York, NY, 1996.
+
+[Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
+ CRC Press 1997.
+
+[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
+ RFC 2412, November 1998.
+
+[ISAKMP] Maughan D., et al, "Internet Security Association and
+ Key Management Protocol (ISAKMP)", RFC 2408, November
+ 1998.
+
+[IKE] Harkins D., and Carrel D., "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
+ Authentication", RFC 2104, February 1997.
+
+[PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
+ Specifications, Version 2.0", RFC 2437, October 1998.
+
+[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+.ti 0
+6 Author's Address
+
+.nf
+Pekka Riikonen
+Snellmaninkatu 34 A 15
+70100 Kuopio
+Finland
+
+EMail: priikone@iki.fi
+
+
+.ti 0
+7 Full Copyright Statement
+
+Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it
+or assist in its implementation may be prepared, copied, published
+and distributed, in whole or in part, without restriction of any
+kind, provided that the above copyright notice and this paragraph are
+included on all such copies and derivative works. However, this
+document itself may not be modified in any way, such as by removing
+the copyright notice or references to the Internet Society or other
+Internet organizations, except as needed for the purpose of
+developing Internet standards in which case the procedures for
+copyrights defined in the Internet Standards process must be
+followed, or as required to translate it into languages other than
+English.
+
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an
+"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+TASK FORCE DISCLAIMS 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.
4.9 Command Sending and Reception ............................. 46
4.10 Closing Connection ....................................... 47
4.11 Detaching and Resuming a Session ......................... 48
+ 4.12 UDP/IP Connections ...................................... XXX
5 Security Considerations ....................................... 49
6 References .................................................... 50
7 Author's Address .............................................. 52
Figure 4: Router Connections
Figure 5: SILC Public Key
Figure 6: Counter Block
+Figure 7: CTR Mode Initialization Vector
.ti 0
in [SILC3] along with connection authentication protocol and should
be read to fully comprehend this document and protocol.
-The SILC protocol has been developed to work on TCP/IP network
-protocol, although it could be made to work on other network protocols
-with only minor changes. However, it is recommended that TCP/IP
-protocol is used under SILC protocol. Typical implementation would
-be made in client-server model.
+The SILC protocol has been developed to work on both TCP/IP and UDP/IP
+network protocols. However, typical implementation would use only TCP/IP
+with SILC protocol. Typical implementation would be made in client-server
+model.
.ti 0
decryption operation is not needed since both encryption and decryption
process is simple XOR with the plaintext block and the key stream block.
-The counter block is used to create the key for the CTR mode. When
-SILC specifications refer to Initialization Vector (IV) in general cases,
-in case of CTR mode it refers to the counter block. The format of the
-128 bit counter block is as follows:
+The counter block is used to create the key for the CTR mode. The format
+of the 128 bit counter block is as follows:
.in 5
.nf
| Truncated HASH from SKE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending/Receiving IV from SKE |
-| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Packet Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
protocol. This acts as session identifier and each rekey MUST
produce a new HASH value.
-o Sending/Receiving IV from SKE (8 bytes) - This value is the
- first 8 bytes from the Sending IV or Receiving IV generated in
- the SKE protocol. When this mode is used to encrypt sending
- traffic the Sending IV is used, when used to decrypt receiving
- traffic the Receiving IV is used. This assures that two parties
- of the protocol use different IV for sending traffic. Each rekey
- MUST produce a new value.
-
-o Block Counter (4 bytes) - This is the counter value for the
- counter block and is MSB ordered number starting from one (1)
- value for first block and incrementing for subsequent blocks.
- The same value MUST NOT be used twice. The rekey MUST be
- performed before this counter value wraps.
+o Sending/Receiving IV from SKE (4 bytes) - If the CTR mode is fully
+ stateful this field MUST include the first 4 bytes from the Sending
+ IV or Receiving IV generated in SKE protocol. When this mode is
+ used to encrypt sending traffic the Sending IV is used, when used
+ to decrypt receiving traffic the Receiving IV is used. This assures
+ that two parties of the protocol use different IV for sending
+ traffic. Each rekey MUST produce a new value.
+
+ If the IV Included flag is negotiated in SKE or CTR mode is used
+ where the IV is included in the data payload, this field is the
+ Nonce field from the IV received in the packet, defined below.
+
+o Packet Counter (4 bytes) - This is MSB first ordered monotonically
+ increasing packet counter. It is set value 1 for first packet and
+ increases for subsequent packets. After rekey the counter MUST
+ restart from 1.
+
+ If the IV Included flag is negotiated in SKE or CTR mode is used
+ where the IV is included in the data payload, this field is the
+ Packet Counter field from the IV received in the packet, defined
+ below.
+
+o Block Counter (4 bytes) - This is an MSB first ordered block
+ counter starting from 1 for first block and increasing for
+ subsequent blocks. The counter is always set to value 1 for
+ a new packet.
.in 3
CTR mode MUST NOT be used with "none" MAC. Implementations also MUST
assure that the same counter block is not used to encrypt more than
-one block. Also, the key material used with CTR mode MUST be fresh
-key material. Static keys (pre-shared keys) MUST NOT be used with
-CTR mode. For this reason using CTR mode to encrypt for example
-channel messages or private messages with a pre-shared key is
-inappropriate. For private messages, the Key Agreement could be
-performed to produce fresh key material.
+one block. None of the counters must be allowed to wrap without rekey.
+Also, the key material used with CTR mode MUST be fresh key material.
+Static keys (pre-shared keys) MUST NOT be used with CTR mode. For this
+reason using CTR mode to encrypt for example channel messages or private
+messages with a pre-shared key is inappropriate. For private messages,
+the Key Agreement could be performed to produce fresh key material.
If the IV Included flag was negotiated in SKE, or CTR mode is used to
protect channel messages where the counter block will be included in the
-Message Payload, implementations SHOULD still use the same counter block
-format as defined above. However, implementations are RECOMMENDED to
-replace the Truncated HASH field with a 32 bit random value for each IV
-(counter block) per encrypted SILC packet. Also note, that in this case
-the decryption process is not stateful and receiver cannot precompute the
-key stream.
+Message Payload, the Initialization Vector (IV) to be used is a 64-bit
+block containing randomness and packet counter. Also note, that in this
+case the decryption process is not stateful and receiver cannot
+precompute the key stream. Hence, the Initialization Vector (IV) when
+CTR mode is used is as follows.
+
+.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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Nonce |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Packet Counter |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 7: CTR Mode Initialization Vector
+
+o Nonce (4 bytes) - This field should be random or otherwise not
+ easily determinable and SHOULD change for each packet.
+
+o Packet Counter (4 bytes) - This is MSB first ordered monotonically
+ increasing packet counter. It is set value 1 for first packet and
+ increases for subsequent packets. After rekey the counter MUST
+ restart from 1.
+
+When decrypting the packet the Counter Block is assembled by concatenating
+the truncated hash, with the received nonce and packet counter, and with
+the block counter. The Counter Block is then used to compute the key
+stream to perform the decryption.
.ti 0
Identifier strings are special strings in SILC protocol that require
more careful processing, than the general UTF-8 strings described in the
-previous section. These strings include the nicknames, server names,
-hostnames and some other identifier strings. These strings are prepared
-using the stringprep [RFC3454] standard. The Appendix A defines the
-stringprep profile for SILC identifier strings and conforming
+previous section. These strings include the nicknames, server names,
+hostnames and some other identifier strings. These strings are prepared
+using the stringprep [RFC3454] standard. The Appendix A defines the
+stringprep profile for SILC identifier strings and conforming
implementation MUST use the profile to prepare any identifier string.
The stringprep profile describes how identifier strings are prepared,
SILC_NOTIFY_TYPE_WATCH to the watcher.
-
-
.ti 0
4.2 Creating Server Connection
persistent as long as the server is running.
+.ti 0
+4.12 UDP/IP Connections
+
+SILC protocol allows the use of UDP/IP instead of TCP/IP. There may be
+many reasons to use UDP, such as video and audio conferencing might
+be more efficient with UDP.
+
+When UDP/IP is used, in the SILC Key Exchange protocol the IV Included
+flag MUST be set and the first 16-bits of the Cookie field in the Key
+Exchange Start Payload MUST include the port that the other end will use
+as the SILC session port. The port is in MSB first order. Both initiator
+and responder will set the port they are going to use and all packets
+after the SKE has been completed with the SILC_PACKET_SUCCESS packet MUST
+be sent to the specified port. Initiator will send them to the port
+responder specified and vice versa. When verifying the cookie for
+modifications the first two bytes are to be ignored in case IV Included
+flag has been set.
+
+The default SILC port or port where the SILC server is listenning for
+incoming packets is used only during initial key exchange protocol. After
+SKE has been completed all packets are sent to the specified ports,
+including connection authentication packets and rekey packets even when
+PFS is used in rekey.
+
+Changing the ports during SILC session is possible only by first detaching
+from the server (with client-server connections) and then performing the
+SILC Key Exchange protocol from the beginning and resuming the detached
+session.
+
+Since the UDP is unreliable transport the SKE packets may not arrive to
+the recipient. Implementation should support retransmission of SKE
+packets by using exponential backoff algorithm. Also other SILC packets
+such as messages may drop en route. With message packets only way to
+assure reliable delivery is to use message acking and retransmit the
+message by using for example exponential backoff algorithm. With SKE
+packets the initial timeout value should be no more than 1000
+milliseconds. With message packets the initial timeout value should be
+around 5000 milliseconds.
+
+
.ti 0
5 Security Considerations
profile defines the following as required by [RFC3454].
- Intended applicability of the profile: the following identifiers in
- the SILC Protocol; nicknames, usernames, server names, hostnames,
+ the SILC Protocol; nicknames, usernames, server names, hostnames,
service names, algorithm names and other security property names [SILC3],
and SILC Public Key name.
.ti 0
Appendix B
-This appendix defines the stringprep [RFC3454] profile for channel name
-strings in SILC protocol. Compliant implementation MUST use this profile
-to prepare the channel name strings in the SILC protocol. The profile
+This appendix defines the stringprep [RFC3454] profile for channel name
+strings in SILC protocol. Compliant implementation MUST use this profile
+to prepare the channel name strings in the SILC protocol. The profile
defines the following as required by [RFC3454].
- Intended applicability of the profile: channel names.
This appendix defines additional prohibited characters in the identifier
strings as defined in the stringprep profile in Appendix A and Appendix B.
Note that the prohibited character tables listed in the Appendix A and
-Appendix B may include some of the same characters listed in this
+Appendix B may include some of the same characters listed in this
appendix as well.
Symbol characters and other symbol like characters
projects / silc.git / commitdiff