--- /dev/null
+
+
+
+
+
+
+Network Working Group P. Riikonen
+Internet-Draft
+draft-riikonen-silc-ke-auth-09.txt 15 January 2007
+Expires: 15 July 2007
+
+
+ SILC Key Exchange and Authentication Protocols
+ <draft-riikonen-silc-ke-auth-09.txt>
+
+Status of this Draft
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts. Internet-Drafts are draft documents valid for a maximum of
+ six months and may be updated, replaced, or obsoleted by other
+ documents at any time. It is inappropriate to use Internet-Drafts as
+ reference material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+ This memo describes two protocols used in the Secure Internet Live
+ Conferencing (SILC) protocol, specified in the Secure Internet Live
+ Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange
+ (SKE) protocol provides secure key exchange between two parties
+ resulting into shared secret key material. The protocol is based
+ on Diffie-Hellman key exchange algorithm and its functionality is
+ derived from several key exchange protocols.
+
+ The second protocol, SILC Connection Authentication protocol provides
+ user level authentication used when creating connections in SILC
+ network. The protocol supports passphrase (pre-shared secret)
+ authentication and public key (and certificate) authentication based
+ on digital signatures.
+
+
+
+
+
+
+Riikonen [Page 1]
+\f
+Internet-Draft 15 January 2007
+
+
+Table of Contents
+
+ 1 Introduction .................................................. 2
+ 1.1 Requirements Terminology .................................. 3
+ 2 SILC Key Exchange Protocol .................................... 3
+ 2.1 Key Exchange Payloads ..................................... 4
+ 2.1.1 Key Exchange Start Payload .......................... 4
+ 2.1.2 Key Exchange Payload ................................ 9
+ 2.2 Key Exchange Procedure .................................... 11
+ 2.3 Processing the Key Material ............................... 13
+ 2.4 SILC Key Exchange Groups .................................. 15
+ 2.4.1 diffie-hellman-group1 ............................... 15
+ 2.4.2 diffie-hellman-group2 ............................... 15
+ 2.4.3 diffie-hellman-group3 ............................... 16
+ 2.5 Key Exchange Status Types ................................. 16
+ 3 SILC Connection Authentication Protocol ....................... 18
+ 3.1 Connection Auth Payload ................................... 19
+ 3.2 Connection Authentication Types ........................... 20
+ 3.2.1 Passphrase Authentication ........................... 20
+ 3.2.2 Public Key Authentication ........................... 21
+ 3.3 Connection Authentication Status Types .................... 21
+ 4 Security Considerations ....................................... 22
+ 5 References .................................................... 22
+ 6 Author's Address .............................................. 23
+ 7 Full Copyright Statement ...................................... 24
+
+
+List of Figures
+
+ Figure 1: Key Exchange Start Payload
+ Figure 2: Key Exchange Payload
+ Figure 3: Connection Auth Payload
+
+
+1 Introduction
+
+ This memo describes two protocols used in the Secure Internet Live
+ Conferencing (SILC) protocol specified in the Secure Internet Live
+ Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange
+ (SKE) protocol provides secure key exchange between two parties
+ resulting into shared secret key material. The protocol is based on
+ Diffie-Hellman key exchange algorithm and its functionality is derived
+ from several key exchange protocols, such as SSH2 Key Exchange protocol,
+ Station-To-Station (STS) protocol and the OAKLEY Key Determination
+ protocol [OAKLEY].
+
+ The second protocol, SILC Connection Authentication protocol provides
+ user level authentication used when creating connections in SILC
+
+
+
+Riikonen [Page 2]
+\f
+Internet-Draft 15 January 2007
+
+
+ network. The protocol supports passphrase (pre-shared secret)
+ authentication and public key (and certificate) authentication based
+ on digital signatures.
+
+ The basis of secure SILC session requires strong and secure key exchange
+ protocol and authentication. The authentication protocol is secured and
+ no authentication data is ever sent in the network without encrypting
+ and authenticating it first. Thus, authentication protocol may be used
+ only after the key exchange protocol has been successfully completed.
+
+ This document constantly refers to other SILC protocol specifications
+ that should be read to be able to fully understand the functionality
+ and purpose of these protocols. The most important references are
+ the Secure Internet Live Conferencing, Protocol Specification [SILC1]
+ and the SILC Packet Protocol [SILC2].
+
+ The protocol is intended to be used with the SILC protocol thus it
+ does not define own framework that could be used. The framework is
+ provided by the SILC protocol.
+
+
+1.1 Requirements Terminology
+
+ The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+ MAY, and OPTIONAL, when they appear in this document, are to be
+ interpreted as described in [RFC2119].
+
+
+2 SILC Key Exchange Protocol
+
+ SILC Key Exchange Protocol (SKE) is used to exchange shared secret
+ material used to secure the communication channel. The protocol use
+ Diffie-Hellman key exchange algorithm and its functionality is derived
+ from several key exchange protocols, such as SSH2 Key Exchange protocol,
+ Station-To-Station (STS) protocol and the OAKLEY Key Determination
+ protocol [OAKLEY]. The protocol does not claim any conformance
+ to any of these protocols, they were only used as a reference when
+ designing this protocol. The protocol can mutually authenticate the
+ negotiating parties during the key exchange.
+
+ The purpose of SILC Key Exchange protocol is to create session keys to
+ be used in current SILC session. The keys are valid only for some period
+ of time (usually an hour) or at most until the session ends. These keys
+ are used to protect packets traveling between the two entities.
+ Usually all traffic is secured with the key material derived from this
+ protocol.
+
+ The Diffie-Hellman implementation used in the SILC SHOULD be compliant
+
+
+
+Riikonen [Page 3]
+\f
+Internet-Draft 15 January 2007
+
+
+ to the PKCS #3.
+
+
+2.1 Key Exchange Payloads
+
+ During the key exchange procedure public data is sent between initiator
+ and responder. This data is later used in the key exchange procedure.
+ There are several payloads used in the key exchange. As for all SILC
+ packets, SILC Packet Header, described in [SILC2], is at the beginning
+ of all packets sent in during this protocol. All the fields in the
+ following payloads are in MSB (most significant byte first) order.
+
+
+2.1.1 Key Exchange Start Payload
+
+ The key exchange between two entities MUST be started by sending the
+ SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
+ Initiator sends the Key Exchange Start Payload to the responder filled
+ with all security properties it supports. The responder then checks
+ whether it supports the security properties.
+
+ It then sends a Key Exchange Start Payload to the initiator filled with
+ security properties it selected from the original payload. The payload
+ sent by responder MUST include only one chosen property per list. The
+ character encoding for the security property values as defined in [SILC1]
+ SHOULD be UTF-8 [RFC2279] in Key Exchange Start Payload.
+
+ The Key Exchange Start Payload is used to tell connecting entities what
+ security properties and algorithms should be used in the communication.
+ The Key Exchange Start Payload is sent only once per session. Even if
+ the PFS (Perfect Forward Secrecy) flag is set the Key Exchange Start
+ Payload is not re-sent. When PFS is desired the Key Exchange Payloads
+ are sent to negotiate new key material. The procedure is equivalent to
+ the very first negotiation except that the Key Exchange Start Payload
+ is not sent.
+
+ As this payload is used only with the very first key exchange the payload
+ is never encrypted, as there are no keys to encrypt it with.
+
+ A cookie is also sent in this payload. A cookie is used to randomize the
+ payload so that none of the key exchange parties can determine this
+ payload before the key exchange procedure starts. The cookie MUST be
+ returned to the original sender unmodified by the responder.
+
+ Following diagram represents the Key Exchange Start Payload. The lists
+ mentioned below are always comma (`,') separated and the list MUST NOT
+ include white spaces (` ').
+
+
+
+
+Riikonen [Page 4]
+\f
+Internet-Draft 15 January 2007
+
+
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RESERVED | Flags | Payload Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Cookie +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Version String Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | |
+ ~ Version String ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Exchange Grp Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | |
+ ~ Key Exchange Groups ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PKCS Alg Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | |
+ ~ PKCS Algorithms ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Encryption Alg Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | |
+ ~ Encryption Algorithms ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Hash Alg Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | |
+ ~ Hash Algorithms ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | HMAC Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | |
+ ~ HMACs ~
+ | |
+
+
+
+Riikonen [Page 5]
+\f
+Internet-Draft 15 January 2007
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Compression Alg Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | |
+ ~ Compression Algorithms ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: Key Exchange Start Payload
+
+
+ o RESERVED (1 byte) - Reserved field. Sender fills this with
+ zero (0) value.
+
+ o Flags (1 byte) - Indicates flags to be used in the key
+ exchange. Several flags can be set at once by ORing the
+ flags together. The following flags are reserved for this
+ field:
+
+ No flags 0x00
+
+ In this case the field is ignored.
+
+ IV Included 0x01
+
+ This flag is used to indicate that Initialization
+ Vector (IV) in encryption will be included in the
+ ciphertext which the recipient must use in decryption.
+ At the beginning of the SILC packet, before the SILC
+ Packet header an 8-bit Security ID (SID) MUST be
+ placed. After the SID, the IV MUST be placed. After
+ the IV, a 32-bit MSB first ordered packet sequence
+ number MUST be placed. The SID and IV MUST NOT be
+ encrypted, but the sequence number MUST be included
+ in encryption. The recipient MUST use the sequence
+ number during MAC verification [SILC2]. All fields
+ however are authenticated with MAC.
+
+ The Security ID is set to value 0 when the key
+ exchange is performed for the first time. It is
+ monotonically increased after each re-key, wrapping
+ eventually. The SID in combination with the current
+ session can be used to identify which key has been
+ used to encrypt an incoming packet. This is especially
+ important after rekey when using UDP/IP protocol,
+ where packets may be lost or reordered. A packet with
+ unknown SID will result into discarding the packet as
+ it cannot be decrypted. After rekey, implementation
+
+
+
+Riikonen [Page 6]
+\f
+Internet-Draft 15 January 2007
+
+
+ should understand that it may still receive packets
+ with old SID and be prepared to decrypt them with the
+ old key.
+
+ With this flag it is possible to use SILC protocol on
+ unreliable transport such as UDP/IP which may cause
+ packet reordering and packet losses. By default,
+ this flag is not set and thus IV is not included
+ in the ciphertext. Setting this flag increases the
+ packet length by one ciphertext block plus 1 byte for
+ the Security ID and 32 bits for the sequence number.
+ Responder MAY override this flag for the initiator,
+ however without this flag UDP connection cannot be
+ used. The flag MAY also be used in TCP connection.
+
+ When using with UDP/IP implementations SHOULD use
+ anti-replay methods where an anti-replay window
+ defines what packets are replays. An example of
+ anti-window protocol is in [RFC2406] Section 3.4.2
+ with example source code in [RFC2401] Appendix C.
+ While [RFC2401] and [RFC2406] does not relate to SILC,
+ the anti-replay method used is applicable in SILC.
+
+ PFS 0x02
+
+ Perfect Forward Secrecy (PFS) to be used in the
+ key exchange protocol. If not set, re-keying
+ is performed using the old key. See the [SILC1]
+ for more information on this issue. When PFS is
+ used, re-keying and creating new keys for any
+ particular purpose MUST cause new key exchange with
+ new Diffie-Hellman exponent values. In this key
+ exchange only the Key Exchange Payload is sent and
+ the Key Exchange Start Payload MUST NOT be sent.
+ When doing PFS the Key Exchange Payloads are
+ encrypted with the old keys.
+
+ Mutual Authentication 0x04
+
+ Both of the parties will perform authentication
+ by providing signed data for the other party to
+ verify. By default, only responder will provide
+ the signature data. If this is set then the
+ initiator must also provide it. Initiator MAY
+ set this but also responder MAY set this even if
+ initiator did not set it.
+
+ Rest of the flags are reserved for the future and
+
+
+
+Riikonen [Page 7]
+\f
+Internet-Draft 15 January 2007
+
+
+ MUST NOT be set.
+
+ o Payload Length (2 bytes) - Length of the entire Key Exchange
+ Start payload, not including any other field.
+
+ o Cookie (16 bytes) - Cookie that randomize this payload so
+ that each of the party cannot determine the payload before
+ hand. This field MUST be present.
+
+ o Version String Length (2 bytes) - The length of the Version
+ String field, not including any other field.
+
+ o Version String (variable length) - Indicates the version of
+ the sender of this payload. Initiator sets this when sending
+ the payload and responder sets this when it replies by sending
+ this payload. See [SILC1] for definition for the version
+ string format. This field MUST be present and include valid
+ version string.
+
+ o Key Exchange Grp Length (2 bytes) - The length of the
+ key exchange group list, not including any other field.
+
+ o Key Exchange Group (variable length) - The list of
+ key exchange groups. See the section 2.4 SILC Key Exchange
+ Groups for definitions of these groups. This field MUST
+ be present.
+
+ o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms
+ list, not including any other field.
+
+ o PKCS Algorithms (variable length) - The list of PKCS
+ algorithms. This field MUST be present.
+
+ o Encryption Alg Length (2 bytes) - The length of the encryption
+ algorithms list, not including any other field.
+
+ o Encryption Algorithms (variable length) - The list of
+ encryption algorithms. This field MUST be present.
+
+ o Hash Alg Length (2 bytes) - The length of the Hash algorithm
+ list, not including any other field.
+
+ o Hash Algorithms (variable length) - The list of Hash
+ algorithms. The hash algorithms are mainly used in the
+ SKE protocol. This field MUST be present.
+
+ o HMAC Length (2 bytes) - The length of the HMAC list, not
+ including any other field.
+
+
+
+Riikonen [Page 8]
+\f
+Internet-Draft 15 January 2007
+
+
+ o HMACs (variable length) - The list of HMACs. The HMAC's
+ are used to compute the Message Authentication Code (MAC)
+ of the SILC packets. This field MUST be present.
+
+ o Compression Alg Length (2 bytes) - The length of the
+ compression algorithms list, not including any other field.
+
+ o Compression Algorithms (variable length) - The list of
+ compression algorithms. This field MAY be omitted.
+
+
+2.1.2 Key Exchange Payload
+
+ Key Exchange payload is used to deliver the public key (or certificate),
+ the computed Diffie-Hellman public value and possibly signature data
+ from one party to the other. When initiator is using this payload
+ and the Mutual Authentication flag is not set then the initiator MUST
+ NOT provide the signature data. If the flag is set then the initiator
+ MUST provide the signature data so that the responder can verify it.
+
+ The Mutual Authentication flag is usually used when a separate
+ authentication protocol will not be executed for the initiator of the
+ protocol. This is case for example when the SKE is performed between
+ two SILC clients. In normal case, where client is connecting to a
+ server, or server is connecting to a router the Mutual Authentication
+ flag MAY be omitted. However, if the connection authentication protocol
+ for the connecting entity is not based on digital signatures (it is
+ based on pre-shared key or there is no authentication) then the Mutual
+ Authentication flag SHOULD be enabled. This way the connecting entity
+ has to provide proof of possession of the private key for the public key
+ it will provide in this protocol.
+
+ When performing re-key with PFS selected this is the only payload that
+ is sent in the SKE protocol. The Key Exchange Start Payload MUST NOT
+ be sent at all. However, this payload does not have all the fields
+ present. In the re-key with PFS the public key and a possible signature
+ data SHOULD NOT be present. If they are present they MUST be ignored.
+ The only field that is present is the Public Data that is used to create
+ the new key material. In the re-key the Mutual Authentication flag, that
+ may be set in the initial negotiation, MUST also be ignored.
+
+ This payload is sent inside SILC_PACKET_KEY_EXCHANGE_1 and inside
+ SILC_PACKET_KEY_EXCHANGE_2 packet types. The initiator uses the
+ SILC_PACKET_KEY_EXCHANGE_1 and the responder the latter.
+
+ The following diagram represent the Key Exchange Payload.
+
+
+
+
+
+Riikonen [Page 9]
+\f
+Internet-Draft 15 January 2007
+
+
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Public Key Length | Public Key Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ ~ Public Key of the party (or certificate) ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Public Data Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | |
+ ~ Public Data ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Signature Length | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | |
+ ~ Signature Data ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 2: Key Exchange Payload
+
+
+ o Public Key Length (2 bytes) - The length of the Public Key
+ (or certificate) field, not including any other field.
+
+ o Public Key Type (2 bytes) - The public key (or certificate)
+ type. This field indicates the type of the public key in
+ the packet. Following types are defined:
+
+ 1 SILC style public key (mandatory)
+ 2 SSH2 style public key (optional)
+ 3 X.509 Version 3 certificate (optional)
+ 4 OpenPGP certificate (optional)
+ 5 SPKI certificate (optional)
+
+ The only required type to support is type number 1. See
+ [SILC1] for the SILC public key specification. See
+ SSH2 public key specification in [SSH-TRANS]. See X.509v3
+ certificate specification in [PKIX-Part1]. See OpenPGP
+ certificate specification in [PGP]. See SPKI certificate
+ specification in [SPKI]. If this field includes zero (0)
+ or unsupported type number the protocol MUST be aborted
+ sending SILC_PACKET_FAILURE message and the connection SHOULD
+ be closed immediately.
+
+
+
+
+Riikonen [Page 10]
+\f
+Internet-Draft 15 January 2007
+
+
+ o Public Key (or certificate) (variable length) - The
+ public key or certificate of the party. This public key
+ may be used to verify the digital signature. The public key
+ or certificate in this field is encoded in the manner as
+ defined in their respective definitions; see previous field.
+
+ o Public Data Length (2 bytes) - The length of the Public Data
+ field, not including any other field.
+
+ o Public Data (variable length) - The public data to be
+ sent to the receiver (computed Diffie-Hellman public values).
+ See section 2.2 Key Exchange Procedure for detailed description
+ how this field is computed. This field is MP integer and is
+ encoded as defined in [SILC1].
+
+ o Signature Length (2 bytes) - The length of the signature,
+ not including any other field.
+
+ o Signature Data (variable length) - The signature signed
+ by the sender. The receiver of this signature MUST
+ verify it. The verification is done using the sender's
+ public key. See section 2.2 Key Exchange Procedure for
+ detailed description how to produce the signature. If
+ the Mutual Authentication flag is not set then initiator
+ MUST NOT provide this field and the Signature Length field
+ MUST be set to zero (0) value. If the flag is set then
+ also the initiator MUST provide this field. The responder
+ always MUST provide this field. The encoding for signature
+ is defined in [SILC1].
+
+
+
+2.2 Key Exchange Procedure
+
+ The key exchange begins by sending SILC_PACKET_KEY_EXCHANGE packet with
+ Key Exchange Start Payload to select the security properties to be used
+ in the key exchange and later in the communication.
+
+ After Key Exchange Start Payload has been processed by both of the
+ parties the protocol proceeds as follows:
+
+
+ Setup: p is a large and public safe prime. This is one of the
+ Diffie Hellman groups. q is order of subgroup (largest
+ prime factor of p). g is a generator and is defined
+ along with the Diffie Hellman group.
+
+ 1. Initiator generates a random number x, where 1 < x < q,
+
+
+
+Riikonen [Page 11]
+\f
+Internet-Draft 15 January 2007
+
+
+ and computes e = g ^ x mod p. The result e is then
+ encoded into Key Exchange Payload, with the public key
+ (or certificate) and sent to the responder.
+
+ If the Mutual Authentication flag is set then initiator
+ MUST also produce signature data SIGN_i which the responder
+ will verify. The initiator MUST compute a hash value
+ HASH_i = hash(Initiator's Key Exchange Start Payload |
+ public key (or certificate) | e). The '|' stands for
+ concatenation. It then signs the HASH_i value with its
+ private key resulting a signature SIGN_i.
+
+ 2. Responder generates a random number y, where 1 < y < q,
+ and computes f = g ^ y mod p. It then computes the
+ shared secret KEY = e ^ y mod p, and, a hash value
+ HASH = hash(Initiator's Key Exchange Start Payload |
+ public key (or certificate) | Initiator's public key
+ (or certificate) | e | f | KEY). It then signs
+ the HASH value with its private key resulting a signature
+ SIGN.
+
+ It then encodes its public key (or certificate), f and
+ SIGN into Key Exchange Payload and sends it to the
+ initiator.
+
+ If the Mutual Authentication flag is set then the responder
+ SHOULD verify that the public key provided in the payload
+ is authentic, or if certificates are used it verifies the
+ certificate. The responder MAY accept the public key without
+ verifying it, however, doing so may result to insecure key
+ exchange (accepting the public key without verifying may be
+ desirable for practical reasons on many environments. For
+ long term use this is never desirable, in which case
+ certificates would be the preferred method to use). It then
+ computes the HASH_i value the same way initiator did in the
+ phase 1. It then verifies the signature SIGN_i from the
+ payload with the hash value HASH_i using the received public
+ key.
+
+ 3. Initiator verifies that the public key provided in
+ the payload is authentic, or if certificates are used
+ it verifies the certificate. The initiator MAY accept
+ the public key without verifying it, however, doing
+ so may result to insecure key exchange (accepting the
+ public key without verifying may be desirable for
+ practical reasons on many environments. For long term
+ use this is never desirable, in which case certificates
+ would be the preferred method to use).
+
+
+
+Riikonen [Page 12]
+\f
+Internet-Draft 15 January 2007
+
+
+ Initiator then computes the shared secret KEY =
+ f ^ x mod p, and, a hash value HASH in the same way as
+ responder did in phase 2. It then verifies the
+ signature SIGN from the payload with the hash value
+ HASH using the received public key.
+
+
+ If any of these phases is to fail the SILC_PACKET_FAILURE MUST be sent
+ to indicate that the key exchange protocol has failed, and the connection
+ SHOULD be closed immediately. Any other packets MUST NOT be sent or
+ accepted during the key exchange except the SILC_PACKET_KEY_EXCHANGE_*,
+ SILC_PACKET_FAILURE and SILC_PACKET_SUCCESS packets.
+
+ The result of this protocol is a shared secret key material KEY and
+ a hash value HASH. The key material itself is not fit to be used as
+ a key, it needs to be processed further to derive the actual keys to be
+ used. The key material is also used to produce other security parameters
+ later used in the communication. See section 2.3 Processing the Key
+ Material for detailed description how to process the key material.
+
+ If the Mutual Authentication flag was set the protocol produces also
+ a hash value HASH_i. This value, however, must be discarded.
+
+ After the keys are processed the protocol is ended by sending the
+ SILC_PACKET_SUCCESS packet. Both entities send this packet to
+ each other. After this both parties MUST start using the new keys.
+
+
+2.3 Processing the Key Material
+
+ Key Exchange protocol produces secret shared key material KEY. This
+ key material is used to derive the actual keys used in the encryption
+ of the communication channel. The key material is also used to derive
+ other security parameters used in the communication. Key Exchange
+ protocol produces a hash value HASH as well.
+
+ The keys MUST be derived from the key material as follows:
+
+ Sending Initial Vector (IV) = hash(0x0 | KEY | HASH)
+ Receiving Initial Vector (IV) = hash(0x1 | KEY | HASH)
+ Sending Encryption Key = hash(0x2 | KEY | HASH)
+ Receiving Encryption Key = hash(0x3 | KEY | HASH)
+ Sending HMAC Key = hash(0x4 | KEY | HASH)
+ Receiving HMAC Key = hash(0x5 | KEY | HASH)
+
+
+ The Initial Vector (IV) is used in the encryption when doing for
+ example CBC mode. As many bytes as needed are taken from the start of
+
+
+
+Riikonen [Page 13]
+\f
+Internet-Draft 15 January 2007
+
+
+ the hash output for IV. Sending IV is for sending key and receiving IV
+ is for receiving key. For receiving party, the receiving IV is actually
+ sender's sending IV, and, the sending IV is actually sender's receiving
+ IV. Initiator uses IV's as they are (sending IV for sending and
+ receiving IV for receiving).
+
+ The Encryption Keys are derived as well from the hash(). If the hash()
+ output is too short for the encryption algorithm more key material MUST
+ be produced in the following manner:
+
+ K1 = hash(0x2 | KEY | HASH)
+ K2 = hash(KEY | HASH | K1)
+ K3 = hash(KEY | HASH | K1 | K2) ...
+
+ Sending Encryption Key = K1 | K2 | K3 ...
+
+
+ K1 = hash(0x3 | KEY | HASH)
+ K2 = hash(KEY | HASH | K1)
+ K3 = hash(KEY | HASH | K1 | K2) ...
+
+ Receiving Encryption Key = K1 | K2 | K3 ...
+
+
+ The key is distributed by hashing the previous hash with the original
+ key material. The final key is a concatenation of the hash values.
+ For Receiving Encryption Key the procedure is equivalent. Sending key
+ is used only for encrypting data to be sent. The receiving key is used
+ only to decrypt received data. For receiving party, the receive key is
+ actually sender's sending key, and, the sending key is actually sender's
+ receiving key. Initiator uses generated keys as they are (sending key
+ for sending and receiving key for receiving).
+
+ The HMAC keys are used to create MAC values to packets in the
+ communication channel. As many bytes as needed are taken from the start
+ of the hash output to generate the MAC keys.
+
+ These procedures are performed by all parties of the key exchange
+ protocol. This MUST be done before the protocol has been ended by
+ sending the SILC_PACKET_SUCCESS packet, to assure that parties can
+ successfully process the key material.
+
+ This same key processing procedure MAY be used in the SILC in some
+ other circumstances as well. Any changes to this procedure is defined
+ separately when this procedure is needed. See the [SILC1] and the
+ [SILC2] for these circumstances.
+
+
+
+
+
+Riikonen [Page 14]
+\f
+Internet-Draft 15 January 2007
+
+
+2.4 SILC Key Exchange Groups
+
+ The Following groups may be used in the SILC Key Exchange protocol.
+ The first group diffie-hellman-group1 is REQUIRED, other groups MAY be
+ negotiated to be used in the connection with Key Exchange Start Payload
+ and SILC_PACKET_KEY_EXCHANGE packet. However, the first group MUST be
+ proposed in the Key Exchange Start Payload regardless of any other
+ requested group (however, it does not have to be the first in the list).
+
+
+2.4.1 diffie-hellman-group1
+
+ The length of this group is 1024 bits. This is REQUIRED group.
+ The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
+
+ Its hexadecimal value is
+
+ FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+ 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+ EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+ E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+ EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
+ FFFFFFFF FFFFFFFF
+
+
+ The generator used with this prime is g = 2. The group order q is
+ (p - 1) / 2.
+
+ This group was taken from RFC 2412.
+
+
+2.4.2 diffie-hellman-group2
+
+ The length of this group is 1536 bits. This is OPTIONAL group.
+ The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
+
+ Its hexadecimal value is
+
+ FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+ 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+ EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+ E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+ EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+ C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+ 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+ 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
+
+ The generator used with this prime is g = 2. The group order q is
+
+
+
+Riikonen [Page 15]
+\f
+Internet-Draft 15 January 2007
+
+
+ (p - 1) / 2.
+
+ This group was taken from RFC 3526.
+
+
+2.4.3 diffie-hellman-group3
+
+ The length of this group is 2048 bits. This is OPTIONAL group.
+ This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }.
+
+ Its hexadecimal value is
+
+ FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+ 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+ EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+ E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+ EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+ C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+ 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+ 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
+ E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
+ DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
+ 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
+
+ The generator used with this prime is g = 2. The group order q is
+ (p - 1) / 2.
+
+ This group was taken from RFC 3526.
+
+ Additional larger groups are defined in RFC 3526 and may be used in SKE
+ by defining name for them using the above name format.
+
+
+2.5 Key Exchange Status Types
+
+ This section defines all key exchange protocol status types that may
+ be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
+ to indicate the status of the protocol. Implementations may map the
+ status types to human readable error message. All types except the
+ SILC_SKE_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
+ The length of status is 32 bits (4 bytes). The following status types
+ are defined:
+
+ 0 SILC_SKE_STATUS_OK
+
+ Protocol were executed successfully.
+
+
+
+
+
+Riikonen [Page 16]
+\f
+Internet-Draft 15 January 2007
+
+
+ 1 SILC_SKE_STATUS_ERROR
+
+ Unknown error occurred. No specific error type is defined.
+
+
+ 2 SILC_SKE_STATUS_BAD_PAYLOAD
+
+ Provided KE payload were malformed or included bad fields.
+
+
+ 3 SILC_SKE_STATUS_UNSUPPORTED_GROUP
+
+ None of the provided groups were supported.
+
+
+ 4 SILC_SKE_STATUS_UNSUPPORTED_CIPHER
+
+ None of the provided ciphers were supported.
+
+
+ 5 SILC_SKE_STATUS_UNSUPPORTED_PKCS
+
+ None of the provided public key algorithms were supported.
+
+
+ 6 SILC_SKE_STATUS_UNSUPPORTED_HASH_FUNCTION
+
+ None of the provided hash functions were supported.
+
+
+ 7 SILC_SKE_STATUS_UNSUPPORTED_HMAC
+
+ None of the provided HMACs were supported.
+
+
+ 8 SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY
+
+ Provided public key type is not supported.
+
+
+ 9 SILC_SKE_STATUS_INCORRECT_SIGNATURE
+
+ Provided signature was incorrect.
+
+
+ 10 SILC_SKE_STATUS_BAD_VERSION
+
+ Provided version string was not acceptable.
+
+
+
+Riikonen [Page 17]
+\f
+Internet-Draft 15 January 2007
+
+
+ 11 SILC_SKE_STATUS_INVALID_COOKIE
+
+ The cookie in the Key Exchange Start Payload was malformed,
+ because responder modified the cookie.
+
+
+3 SILC Connection Authentication Protocol
+
+ Purpose of Connection Authentication protocol is to authenticate the
+ connecting party with server. Usually connecting party is client but
+ server may connect to router server as well. Its other purpose is to
+ provide information for the server about which type of entity the
+ connection is. The type defines whether the connection is client,
+ server or router connection. Server use this information to create the
+ ID for the connection.
+
+ Server MUST verify the authentication data received and if it is to fail
+ the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
+ If authentication is successful the protocol is ended by server by sending
+ SILC_PACKET_SUCCESS packet.
+
+ The protocol is executed after the SILC Key Exchange protocol. It MUST
+ NOT be executed in any other time. As it is performed after key exchange
+ protocol all traffic in the connection authentication protocol is
+ encrypted with the exchanged keys.
+
+ The protocol MUST be started by the connecting party by sending the
+ SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload,
+ described in the next section. This payload MUST include the
+ authentication data. The authentication data is set according
+ authentication method that MUST be known by both parties. If connecting
+ party does not know what is the mandatory authentication method it MAY
+ request it from the server by sending SILC_PACKET_CONNECTION_AUTH_REQUEST
+ packet. This packet is not part of this protocol and is described in
+ section Connection Auth Request Payload in [SILC2]. However, if
+ connecting party already knows the mandatory authentication method
+ sending the request is not necessary.
+
+ See [SILC1] and section Connection Auth Request Payload in [SILC2] also
+ for the list of different authentication methods. Authentication method
+ MAY also be NONE, in which case the server does not require
+ authentication. However, in this case the protocol still MUST be
+ executed; the authentication data is empty indicating no authentication
+ is required.
+
+ If authentication method is passphrase the authentication data is
+ plaintext passphrase. As the payload is encrypted it is safe to have
+ plaintext passphrase. It is also provided as plaintext passphrase
+
+
+
+Riikonen [Page 18]
+\f
+Internet-Draft 15 January 2007
+
+
+ because the receiver may need to pass the entire passphrase into a
+ passphrase verifier, and a message digest of the passphrase would
+ prevent this. See the section 3.2.1 Passphrase Authentication for
+ more information.
+
+ If authentication method is public key authentication the authentication
+ data is a digital signature of the hash value of hash HASH and Key
+ Exchange Start Payload, established by the SILC Key Exchange protocol.
+ This signature MUST then be verified by the server. See the section
+ 3.2.2 Public Key Authentication for more information.
+
+ See the section 4 SILC Procedures in [SILC1] for more information about
+ client creating connection to server, and server creating connection
+ to router, and how to register the session in the SILC Network after
+ successful Connection Authentication protocol.
+
+
+3.1 Connection Auth Payload
+
+ Client sends this payload to authenticate itself to the server. Server
+ connecting to another server also sends this payload. Server receiving
+ this payload MUST verify all the data in it and if something is to fail
+ the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
+
+ The payload may only be sent with SILC_PACKET_CONNECTION_AUTH packet.
+ It MUST NOT be sent in any other packet type. The following diagram
+ represent the Connection Auth Payload.
+
+
+
+
+
+
+
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Payload Length | Connection Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ ~ Authentication Data ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 3: Connection Auth Payload
+
+
+ o Payload Length (2 bytes) - Length of the entire Connection
+
+
+
+Riikonen [Page 19]
+\f
+Internet-Draft 15 January 2007
+
+
+ Auth Payload.
+
+ o Connection Type (2 bytes) - Indicates the type of the
+ connection. See section Connection Auth Request Payload
+ in [SILC2] for the list of connection types. This field MUST
+ include valid connection type or the packet MUST be discarded
+ and authentication MUST be failed.
+
+ o Authentication Data (variable length) - The actual
+ authentication data. Contents of this depends on the
+ authentication method known by both parties. If no
+ authentication is required this field does not exist.
+
+
+3.2 Connection Authentication Types
+
+ SILC supports two authentication types to be used in the connection
+ authentication protocol; passphrase authentication or public key
+ authentication based on digital signatures. The following sections
+ defines the authentication methods. See [SILC2] for defined numerical
+ authentication method types.
+
+
+3.2.1 Passphrase Authentication
+
+ Passphrase authentication or pre-shared key based authentication is
+ simply an authentication where the party that wants to authenticate
+ itself to the other end sends the passphrase that is required by
+ the other end, for example server. The plaintext passphrase is put
+ to the payload, that is then encrypted. The plaintext passphrase
+ MUST be in UTF-8 [RFC2279] encoding. If the passphrase is in the
+ sender's system in some other encoding it MUST be UTF-8 encoded
+ before transmitted. The receiver MAY change the encoding of the
+ passphrase to its system's default character encoding before verifying
+ the passphrase.
+
+ If the passphrase matches with the one in the server's end the
+ authentication is successful. Otherwise SILC_PACKET_FAILURE MUST be
+ sent to the sender and the protocol execution fails.
+
+ This is REQUIRED authentication method to be supported by all SILC
+ implementations.
+
+ When password authentication is used it is RECOMMENDED that maximum
+ amount of padding is applied to the SILC packet. This way it is not
+ possible to approximate the length of the password from the encrypted
+ packet.
+
+
+
+
+Riikonen [Page 20]
+\f
+Internet-Draft 15 January 2007
+
+
+3.2.2 Public Key Authentication
+
+ Public key authentication may be used if passphrase based authentication
+ is not desired. The public key authentication works by sending a
+ digital signature as authentication data to the other end, say, server.
+ The server MUST then verify the signature by the public key of the sender,
+ which the server has received earlier in SKE protocol, or which the
+ server has cached locally at some previous time.
+
+ The signature is computed using the private key of the sender by signing
+ the HASH value provided by the SKE protocol previously, and the Key
+ Exchange Start Payload from SKE protocol that was sent to the server.
+ These are concatenated and hash function is used to compute a hash value
+ which is then signed.
+
+ auth_hash = hash(HASH | Key Exchange Start Payload);
+ signature = sign(auth_hash);
+
+ The hash() function used to compute the value is the hash function
+ negotiated in the SKE protocol. The server MUST verify the data, thus
+ it must keep the HASH and the Key Exchange Start Payload saved during
+ SKE and authentication protocols. These values can be discarded after
+ Connection Authentication protocol is completed.
+
+ If the verified signature matches the sent signature, the authentication
+ were successful and SILC_PACKET_SUCCESS is sent. If it failed the
+ protocol execution is stopped and SILC_PACKET_FAILURE is sent.
+
+ This is REQUIRED authentication method to be supported by all SILC
+ implementations.
+
+
+
+3.3 Connection Authentication Status Types
+
+ This section defines all connection authentication status types that
+ may be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
+ to indicate the status of the protocol. Implementations may map the
+ status types to human readable error message. All types except the
+ SILC_AUTH_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
+ The length of status is 32 bits (4 bytes). The following status types
+ are defined:
+
+ 0 SILC_AUTH_OK
+
+ Protocol was executed successfully.
+
+
+
+
+
+Riikonen [Page 21]
+\f
+Internet-Draft 15 January 2007
+
+
+ 1 SILC_AUTH_FAILED
+
+ Authentication failed.
+
+
+4 Security Considerations
+
+ Security is central to the design of this protocol, and these security
+ considerations permeate the specification. Common security considerations
+ such as keeping private keys truly private and using adequate lengths for
+ symmetric and asymmetric keys must be followed in order to maintain the
+ security of this protocol.
+
+
+5 References
+
+ [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
+ Protocol Specification", Internet Draft, January 2007.
+
+ [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
+ January 2007.
+
+ [SILC4] Riikonen, P., "SILC Commands", Internet Draft, January 2007.
+
+ [IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
+ RFC 1459, May 1993.
+
+ [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+ April 2000.
+
+ [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
+ 2811, April 2000.
+
+ [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+ 2812, April 2000.
+
+ [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+ 2813, April 2000.
+
+ [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
+ Internet Draft.
+
+ [PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
+ November 1998.
+
+ [SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
+ September 1999.
+
+
+
+
+Riikonen [Page 22]
+\f
+Internet-Draft 15 January 2007
+
+
+ [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
+ Infrastructure, Certificate and CRL Profile", RFC 2459,
+ January 1999.
+
+ [Schneier] Schneier, B., "Applied Cryptography Second Edition",
+ John Wiley & Sons, New York, NY, 1996.
+
+ [Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
+ CRC Press 1997.
+
+ [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
+ RFC 2412, November 1998.
+
+ [ISAKMP] Maughan D., et al, "Internet Security Association and
+ Key Management Protocol (ISAKMP)", RFC 2408, November
+ 1998.
+
+ [IKE] Harkins D., and Carrel D., "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+ [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
+ Authentication", RFC 2104, February 1997.
+
+ [PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
+ Specifications, Version 2.0", RFC 2437, October 1998.
+
+ [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+ [RFC2401] Kent, S., et al, "Security Architecture for the Internet
+ Protocol", RFC 2401, November 1998.
+
+ [RFC2406] Kent, S., et al, "Security Architecture for the Internet
+ Protocol", RFC 2406, November 1998.
+
+
+6 Author's Address
+
+ Pekka Riikonen
+ Helsinki
+ Finland
+
+ EMail: priikone@iki.fi
+
+
+
+
+
+Riikonen [Page 23]
+\f
+Internet-Draft 15 January 2007
+
+
+7 Full Copyright Statement
+
+ Copyright (C) The Internet Society (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Riikonen [Page 24]
+\f
projects / website.git / blobdiff