7 Network Working Group P. Riikonen
9 draft-riikonen-silc-ke-auth-09.txt 15 January 2007
13 SILC Key Exchange and Authentication Protocols
14 <draft-riikonen-silc-ke-auth-09.txt>
18 By submitting this Internet-Draft, each author represents that any
19 applicable patent or other IPR claims of which he or she is aware
20 have been or will be disclosed, and any of which he or she becomes
21 aware will be disclosed, in accordance with Section 6 of BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that
25 other groups may also distribute working documents as Internet-
26 Drafts. Internet-Drafts are draft documents valid for a maximum of
27 six months and may be updated, replaced, or obsoleted by other
28 documents at any time. It is inappropriate to use Internet-Drafts as
29 reference material or to cite them other than as "work in progress".
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/1id-abstracts.html
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
39 This memo describes two protocols used in the Secure Internet Live
40 Conferencing (SILC) protocol, specified in the Secure Internet Live
41 Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange
42 (SKE) protocol provides secure key exchange between two parties
43 resulting into shared secret key material. The protocol is based
44 on Diffie-Hellman key exchange algorithm and its functionality is
45 derived from several key exchange protocols.
47 The second protocol, SILC Connection Authentication protocol provides
48 user level authentication used when creating connections in SILC
49 network. The protocol supports passphrase (pre-shared secret)
50 authentication and public key (and certificate) authentication based
51 on digital signatures.
60 Internet-Draft 15 January 2007
65 1 Introduction .................................................. 2
66 1.1 Requirements Terminology .................................. 3
67 2 SILC Key Exchange Protocol .................................... 3
68 2.1 Key Exchange Payloads ..................................... 4
69 2.1.1 Key Exchange Start Payload .......................... 4
70 2.1.2 Key Exchange Payload ................................ 9
71 2.2 Key Exchange Procedure .................................... 11
72 2.3 Processing the Key Material ............................... 13
73 2.4 SILC Key Exchange Groups .................................. 15
74 2.4.1 diffie-hellman-group1 ............................... 15
75 2.4.2 diffie-hellman-group2 ............................... 15
76 2.4.3 diffie-hellman-group3 ............................... 16
77 2.5 Key Exchange Status Types ................................. 16
78 3 SILC Connection Authentication Protocol ....................... 18
79 3.1 Connection Auth Payload ................................... 19
80 3.2 Connection Authentication Types ........................... 20
81 3.2.1 Passphrase Authentication ........................... 20
82 3.2.2 Public Key Authentication ........................... 21
83 3.3 Connection Authentication Status Types .................... 21
84 4 Security Considerations ....................................... 22
85 5 References .................................................... 22
86 6 Author's Address .............................................. 23
87 7 Full Copyright Statement ...................................... 24
92 Figure 1: Key Exchange Start Payload
93 Figure 2: Key Exchange Payload
94 Figure 3: Connection Auth Payload
99 This memo describes two protocols used in the Secure Internet Live
100 Conferencing (SILC) protocol specified in the Secure Internet Live
101 Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange
102 (SKE) protocol provides secure key exchange between two parties
103 resulting into shared secret key material. The protocol is based on
104 Diffie-Hellman key exchange algorithm and its functionality is derived
105 from several key exchange protocols, such as SSH2 Key Exchange protocol,
106 Station-To-Station (STS) protocol and the OAKLEY Key Determination
109 The second protocol, SILC Connection Authentication protocol provides
110 user level authentication used when creating connections in SILC
116 Internet-Draft 15 January 2007
119 network. The protocol supports passphrase (pre-shared secret)
120 authentication and public key (and certificate) authentication based
121 on digital signatures.
123 The basis of secure SILC session requires strong and secure key exchange
124 protocol and authentication. The authentication protocol is secured and
125 no authentication data is ever sent in the network without encrypting
126 and authenticating it first. Thus, authentication protocol may be used
127 only after the key exchange protocol has been successfully completed.
129 This document constantly refers to other SILC protocol specifications
130 that should be read to be able to fully understand the functionality
131 and purpose of these protocols. The most important references are
132 the Secure Internet Live Conferencing, Protocol Specification [SILC1]
133 and the SILC Packet Protocol [SILC2].
135 The protocol is intended to be used with the SILC protocol thus it
136 does not define own framework that could be used. The framework is
137 provided by the SILC protocol.
140 1.1 Requirements Terminology
142 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
143 MAY, and OPTIONAL, when they appear in this document, are to be
144 interpreted as described in [RFC2119].
147 2 SILC Key Exchange Protocol
149 SILC Key Exchange Protocol (SKE) is used to exchange shared secret
150 material used to secure the communication channel. The protocol use
151 Diffie-Hellman key exchange algorithm and its functionality is derived
152 from several key exchange protocols, such as SSH2 Key Exchange protocol,
153 Station-To-Station (STS) protocol and the OAKLEY Key Determination
154 protocol [OAKLEY]. The protocol does not claim any conformance
155 to any of these protocols, they were only used as a reference when
156 designing this protocol. The protocol can mutually authenticate the
157 negotiating parties during the key exchange.
159 The purpose of SILC Key Exchange protocol is to create session keys to
160 be used in current SILC session. The keys are valid only for some period
161 of time (usually an hour) or at most until the session ends. These keys
162 are used to protect packets traveling between the two entities.
163 Usually all traffic is secured with the key material derived from this
166 The Diffie-Hellman implementation used in the SILC SHOULD be compliant
172 Internet-Draft 15 January 2007
178 2.1 Key Exchange Payloads
180 During the key exchange procedure public data is sent between initiator
181 and responder. This data is later used in the key exchange procedure.
182 There are several payloads used in the key exchange. As for all SILC
183 packets, SILC Packet Header, described in [SILC2], is at the beginning
184 of all packets sent in during this protocol. All the fields in the
185 following payloads are in MSB (most significant byte first) order.
188 2.1.1 Key Exchange Start Payload
190 The key exchange between two entities MUST be started by sending the
191 SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
192 Initiator sends the Key Exchange Start Payload to the responder filled
193 with all security properties it supports. The responder then checks
194 whether it supports the security properties.
196 It then sends a Key Exchange Start Payload to the initiator filled with
197 security properties it selected from the original payload. The payload
198 sent by responder MUST include only one chosen property per list. The
199 character encoding for the security property values as defined in [SILC1]
200 SHOULD be UTF-8 [RFC2279] in Key Exchange Start Payload.
202 The Key Exchange Start Payload is used to tell connecting entities what
203 security properties and algorithms should be used in the communication.
204 The Key Exchange Start Payload is sent only once per session. Even if
205 the PFS (Perfect Forward Secrecy) flag is set the Key Exchange Start
206 Payload is not re-sent. When PFS is desired the Key Exchange Payloads
207 are sent to negotiate new key material. The procedure is equivalent to
208 the very first negotiation except that the Key Exchange Start Payload
211 As this payload is used only with the very first key exchange the payload
212 is never encrypted, as there are no keys to encrypt it with.
214 A cookie is also sent in this payload. A cookie is used to randomize the
215 payload so that none of the key exchange parties can determine this
216 payload before the key exchange procedure starts. The cookie MUST be
217 returned to the original sender unmodified by the responder.
219 Following diagram represents the Key Exchange Start Payload. The lists
220 mentioned below are always comma (`,') separated and the list MUST NOT
221 include white spaces (` ').
228 Internet-Draft 15 January 2007
232 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
233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
234 | RESERVED | Flags | Payload Length |
235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
244 | Version String Length | |
245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
250 | Key Exchange Grp Length | |
251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
253 ~ Key Exchange Groups ~
255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
256 | PKCS Alg Length | |
257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
262 | Encryption Alg Length | |
263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
265 ~ Encryption Algorithms ~
267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
268 | Hash Alg Length | |
269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
284 Internet-Draft 15 January 2007
287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
288 | Compression Alg Length | |
289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
291 ~ Compression Algorithms ~
293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
295 Figure 1: Key Exchange Start Payload
298 o RESERVED (1 byte) - Reserved field. Sender fills this with
301 o Flags (1 byte) - Indicates flags to be used in the key
302 exchange. Several flags can be set at once by ORing the
303 flags together. The following flags are reserved for this
308 In this case the field is ignored.
312 This flag is used to indicate that Initialization
313 Vector (IV) in encryption will be included in the
314 ciphertext which the recipient must use in decryption.
315 At the beginning of the SILC packet, before the SILC
316 Packet header an 8-bit Security ID (SID) MUST be
317 placed. After the SID, the IV MUST be placed. After
318 the IV, a 32-bit MSB first ordered packet sequence
319 number MUST be placed. The SID and IV MUST NOT be
320 encrypted, but the sequence number MUST be included
321 in encryption. The recipient MUST use the sequence
322 number during MAC verification [SILC2]. All fields
323 however are authenticated with MAC.
325 The Security ID is set to value 0 when the key
326 exchange is performed for the first time. It is
327 monotonically increased after each re-key, wrapping
328 eventually. The SID in combination with the current
329 session can be used to identify which key has been
330 used to encrypt an incoming packet. This is especially
331 important after rekey when using UDP/IP protocol,
332 where packets may be lost or reordered. A packet with
333 unknown SID will result into discarding the packet as
334 it cannot be decrypted. After rekey, implementation
340 Internet-Draft 15 January 2007
343 should understand that it may still receive packets
344 with old SID and be prepared to decrypt them with the
347 With this flag it is possible to use SILC protocol on
348 unreliable transport such as UDP/IP which may cause
349 packet reordering and packet losses. By default,
350 this flag is not set and thus IV is not included
351 in the ciphertext. Setting this flag increases the
352 packet length by one ciphertext block plus 1 byte for
353 the Security ID and 32 bits for the sequence number.
354 Responder MAY override this flag for the initiator,
355 however without this flag UDP connection cannot be
356 used. The flag MAY also be used in TCP connection.
358 When using with UDP/IP implementations SHOULD use
359 anti-replay methods where an anti-replay window
360 defines what packets are replays. An example of
361 anti-window protocol is in [RFC2406] Section 3.4.2
362 with example source code in [RFC2401] Appendix C.
363 While [RFC2401] and [RFC2406] does not relate to SILC,
364 the anti-replay method used is applicable in SILC.
368 Perfect Forward Secrecy (PFS) to be used in the
369 key exchange protocol. If not set, re-keying
370 is performed using the old key. See the [SILC1]
371 for more information on this issue. When PFS is
372 used, re-keying and creating new keys for any
373 particular purpose MUST cause new key exchange with
374 new Diffie-Hellman exponent values. In this key
375 exchange only the Key Exchange Payload is sent and
376 the Key Exchange Start Payload MUST NOT be sent.
377 When doing PFS the Key Exchange Payloads are
378 encrypted with the old keys.
380 Mutual Authentication 0x04
382 Both of the parties will perform authentication
383 by providing signed data for the other party to
384 verify. By default, only responder will provide
385 the signature data. If this is set then the
386 initiator must also provide it. Initiator MAY
387 set this but also responder MAY set this even if
388 initiator did not set it.
390 Rest of the flags are reserved for the future and
396 Internet-Draft 15 January 2007
401 o Payload Length (2 bytes) - Length of the entire Key Exchange
402 Start payload, not including any other field.
404 o Cookie (16 bytes) - Cookie that randomize this payload so
405 that each of the party cannot determine the payload before
406 hand. This field MUST be present.
408 o Version String Length (2 bytes) - The length of the Version
409 String field, not including any other field.
411 o Version String (variable length) - Indicates the version of
412 the sender of this payload. Initiator sets this when sending
413 the payload and responder sets this when it replies by sending
414 this payload. See [SILC1] for definition for the version
415 string format. This field MUST be present and include valid
418 o Key Exchange Grp Length (2 bytes) - The length of the
419 key exchange group list, not including any other field.
421 o Key Exchange Group (variable length) - The list of
422 key exchange groups. See the section 2.4 SILC Key Exchange
423 Groups for definitions of these groups. This field MUST
426 o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms
427 list, not including any other field.
429 o PKCS Algorithms (variable length) - The list of PKCS
430 algorithms. This field MUST be present.
432 o Encryption Alg Length (2 bytes) - The length of the encryption
433 algorithms list, not including any other field.
435 o Encryption Algorithms (variable length) - The list of
436 encryption algorithms. This field MUST be present.
438 o Hash Alg Length (2 bytes) - The length of the Hash algorithm
439 list, not including any other field.
441 o Hash Algorithms (variable length) - The list of Hash
442 algorithms. The hash algorithms are mainly used in the
443 SKE protocol. This field MUST be present.
445 o HMAC Length (2 bytes) - The length of the HMAC list, not
446 including any other field.
452 Internet-Draft 15 January 2007
455 o HMACs (variable length) - The list of HMACs. The HMAC's
456 are used to compute the Message Authentication Code (MAC)
457 of the SILC packets. This field MUST be present.
459 o Compression Alg Length (2 bytes) - The length of the
460 compression algorithms list, not including any other field.
462 o Compression Algorithms (variable length) - The list of
463 compression algorithms. This field MAY be omitted.
466 2.1.2 Key Exchange Payload
468 Key Exchange payload is used to deliver the public key (or certificate),
469 the computed Diffie-Hellman public value and possibly signature data
470 from one party to the other. When initiator is using this payload
471 and the Mutual Authentication flag is not set then the initiator MUST
472 NOT provide the signature data. If the flag is set then the initiator
473 MUST provide the signature data so that the responder can verify it.
475 The Mutual Authentication flag is usually used when a separate
476 authentication protocol will not be executed for the initiator of the
477 protocol. This is case for example when the SKE is performed between
478 two SILC clients. In normal case, where client is connecting to a
479 server, or server is connecting to a router the Mutual Authentication
480 flag MAY be omitted. However, if the connection authentication protocol
481 for the connecting entity is not based on digital signatures (it is
482 based on pre-shared key or there is no authentication) then the Mutual
483 Authentication flag SHOULD be enabled. This way the connecting entity
484 has to provide proof of possession of the private key for the public key
485 it will provide in this protocol.
487 When performing re-key with PFS selected this is the only payload that
488 is sent in the SKE protocol. The Key Exchange Start Payload MUST NOT
489 be sent at all. However, this payload does not have all the fields
490 present. In the re-key with PFS the public key and a possible signature
491 data SHOULD NOT be present. If they are present they MUST be ignored.
492 The only field that is present is the Public Data that is used to create
493 the new key material. In the re-key the Mutual Authentication flag, that
494 may be set in the initial negotiation, MUST also be ignored.
496 This payload is sent inside SILC_PACKET_KEY_EXCHANGE_1 and inside
497 SILC_PACKET_KEY_EXCHANGE_2 packet types. The initiator uses the
498 SILC_PACKET_KEY_EXCHANGE_1 and the responder the latter.
500 The following diagram represent the Key Exchange Payload.
508 Internet-Draft 15 January 2007
512 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
513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
514 | Public Key Length | Public Key Type |
515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
517 ~ Public Key of the party (or certificate) ~
519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
520 | Public Data Length | |
521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
526 | Signature Length | |
527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
533 Figure 2: Key Exchange Payload
536 o Public Key Length (2 bytes) - The length of the Public Key
537 (or certificate) field, not including any other field.
539 o Public Key Type (2 bytes) - The public key (or certificate)
540 type. This field indicates the type of the public key in
541 the packet. Following types are defined:
543 1 SILC style public key (mandatory)
544 2 SSH2 style public key (optional)
545 3 X.509 Version 3 certificate (optional)
546 4 OpenPGP certificate (optional)
547 5 SPKI certificate (optional)
549 The only required type to support is type number 1. See
550 [SILC1] for the SILC public key specification. See
551 SSH2 public key specification in [SSH-TRANS]. See X.509v3
552 certificate specification in [PKIX-Part1]. See OpenPGP
553 certificate specification in [PGP]. See SPKI certificate
554 specification in [SPKI]. If this field includes zero (0)
555 or unsupported type number the protocol MUST be aborted
556 sending SILC_PACKET_FAILURE message and the connection SHOULD
557 be closed immediately.
564 Internet-Draft 15 January 2007
567 o Public Key (or certificate) (variable length) - The
568 public key or certificate of the party. This public key
569 may be used to verify the digital signature. The public key
570 or certificate in this field is encoded in the manner as
571 defined in their respective definitions; see previous field.
573 o Public Data Length (2 bytes) - The length of the Public Data
574 field, not including any other field.
576 o Public Data (variable length) - The public data to be
577 sent to the receiver (computed Diffie-Hellman public values).
578 See section 2.2 Key Exchange Procedure for detailed description
579 how this field is computed. This field is MP integer and is
580 encoded as defined in [SILC1].
582 o Signature Length (2 bytes) - The length of the signature,
583 not including any other field.
585 o Signature Data (variable length) - The signature signed
586 by the sender. The receiver of this signature MUST
587 verify it. The verification is done using the sender's
588 public key. See section 2.2 Key Exchange Procedure for
589 detailed description how to produce the signature. If
590 the Mutual Authentication flag is not set then initiator
591 MUST NOT provide this field and the Signature Length field
592 MUST be set to zero (0) value. If the flag is set then
593 also the initiator MUST provide this field. The responder
594 always MUST provide this field. The encoding for signature
595 is defined in [SILC1].
599 2.2 Key Exchange Procedure
601 The key exchange begins by sending SILC_PACKET_KEY_EXCHANGE packet with
602 Key Exchange Start Payload to select the security properties to be used
603 in the key exchange and later in the communication.
605 After Key Exchange Start Payload has been processed by both of the
606 parties the protocol proceeds as follows:
609 Setup: p is a large and public safe prime. This is one of the
610 Diffie Hellman groups. q is order of subgroup (largest
611 prime factor of p). g is a generator and is defined
612 along with the Diffie Hellman group.
614 1. Initiator generates a random number x, where 1 < x < q,
620 Internet-Draft 15 January 2007
623 and computes e = g ^ x mod p. The result e is then
624 encoded into Key Exchange Payload, with the public key
625 (or certificate) and sent to the responder.
627 If the Mutual Authentication flag is set then initiator
628 MUST also produce signature data SIGN_i which the responder
629 will verify. The initiator MUST compute a hash value
630 HASH_i = hash(Initiator's Key Exchange Start Payload |
631 public key (or certificate) | e). The '|' stands for
632 concatenation. It then signs the HASH_i value with its
633 private key resulting a signature SIGN_i.
635 2. Responder generates a random number y, where 1 < y < q,
636 and computes f = g ^ y mod p. It then computes the
637 shared secret KEY = e ^ y mod p, and, a hash value
638 HASH = hash(Initiator's Key Exchange Start Payload |
639 public key (or certificate) | Initiator's public key
640 (or certificate) | e | f | KEY). It then signs
641 the HASH value with its private key resulting a signature
644 It then encodes its public key (or certificate), f and
645 SIGN into Key Exchange Payload and sends it to the
648 If the Mutual Authentication flag is set then the responder
649 SHOULD verify that the public key provided in the payload
650 is authentic, or if certificates are used it verifies the
651 certificate. The responder MAY accept the public key without
652 verifying it, however, doing so may result to insecure key
653 exchange (accepting the public key without verifying may be
654 desirable for practical reasons on many environments. For
655 long term use this is never desirable, in which case
656 certificates would be the preferred method to use). It then
657 computes the HASH_i value the same way initiator did in the
658 phase 1. It then verifies the signature SIGN_i from the
659 payload with the hash value HASH_i using the received public
662 3. Initiator verifies that the public key provided in
663 the payload is authentic, or if certificates are used
664 it verifies the certificate. The initiator MAY accept
665 the public key without verifying it, however, doing
666 so may result to insecure key exchange (accepting the
667 public key without verifying may be desirable for
668 practical reasons on many environments. For long term
669 use this is never desirable, in which case certificates
670 would be the preferred method to use).
676 Internet-Draft 15 January 2007
679 Initiator then computes the shared secret KEY =
680 f ^ x mod p, and, a hash value HASH in the same way as
681 responder did in phase 2. It then verifies the
682 signature SIGN from the payload with the hash value
683 HASH using the received public key.
686 If any of these phases is to fail the SILC_PACKET_FAILURE MUST be sent
687 to indicate that the key exchange protocol has failed, and the connection
688 SHOULD be closed immediately. Any other packets MUST NOT be sent or
689 accepted during the key exchange except the SILC_PACKET_KEY_EXCHANGE_*,
690 SILC_PACKET_FAILURE and SILC_PACKET_SUCCESS packets.
692 The result of this protocol is a shared secret key material KEY and
693 a hash value HASH. The key material itself is not fit to be used as
694 a key, it needs to be processed further to derive the actual keys to be
695 used. The key material is also used to produce other security parameters
696 later used in the communication. See section 2.3 Processing the Key
697 Material for detailed description how to process the key material.
699 If the Mutual Authentication flag was set the protocol produces also
700 a hash value HASH_i. This value, however, must be discarded.
702 After the keys are processed the protocol is ended by sending the
703 SILC_PACKET_SUCCESS packet. Both entities send this packet to
704 each other. After this both parties MUST start using the new keys.
707 2.3 Processing the Key Material
709 Key Exchange protocol produces secret shared key material KEY. This
710 key material is used to derive the actual keys used in the encryption
711 of the communication channel. The key material is also used to derive
712 other security parameters used in the communication. Key Exchange
713 protocol produces a hash value HASH as well.
715 The keys MUST be derived from the key material as follows:
717 Sending Initial Vector (IV) = hash(0x0 | KEY | HASH)
718 Receiving Initial Vector (IV) = hash(0x1 | KEY | HASH)
719 Sending Encryption Key = hash(0x2 | KEY | HASH)
720 Receiving Encryption Key = hash(0x3 | KEY | HASH)
721 Sending HMAC Key = hash(0x4 | KEY | HASH)
722 Receiving HMAC Key = hash(0x5 | KEY | HASH)
725 The Initial Vector (IV) is used in the encryption when doing for
726 example CBC mode. As many bytes as needed are taken from the start of
732 Internet-Draft 15 January 2007
735 the hash output for IV. Sending IV is for sending key and receiving IV
736 is for receiving key. For receiving party, the receiving IV is actually
737 sender's sending IV, and, the sending IV is actually sender's receiving
738 IV. Initiator uses IV's as they are (sending IV for sending and
739 receiving IV for receiving).
741 The Encryption Keys are derived as well from the hash(). If the hash()
742 output is too short for the encryption algorithm more key material MUST
743 be produced in the following manner:
745 K1 = hash(0x2 | KEY | HASH)
746 K2 = hash(KEY | HASH | K1)
747 K3 = hash(KEY | HASH | K1 | K2) ...
749 Sending Encryption Key = K1 | K2 | K3 ...
752 K1 = hash(0x3 | KEY | HASH)
753 K2 = hash(KEY | HASH | K1)
754 K3 = hash(KEY | HASH | K1 | K2) ...
756 Receiving Encryption Key = K1 | K2 | K3 ...
759 The key is distributed by hashing the previous hash with the original
760 key material. The final key is a concatenation of the hash values.
761 For Receiving Encryption Key the procedure is equivalent. Sending key
762 is used only for encrypting data to be sent. The receiving key is used
763 only to decrypt received data. For receiving party, the receive key is
764 actually sender's sending key, and, the sending key is actually sender's
765 receiving key. Initiator uses generated keys as they are (sending key
766 for sending and receiving key for receiving).
768 The HMAC keys are used to create MAC values to packets in the
769 communication channel. As many bytes as needed are taken from the start
770 of the hash output to generate the MAC keys.
772 These procedures are performed by all parties of the key exchange
773 protocol. This MUST be done before the protocol has been ended by
774 sending the SILC_PACKET_SUCCESS packet, to assure that parties can
775 successfully process the key material.
777 This same key processing procedure MAY be used in the SILC in some
778 other circumstances as well. Any changes to this procedure is defined
779 separately when this procedure is needed. See the [SILC1] and the
780 [SILC2] for these circumstances.
788 Internet-Draft 15 January 2007
791 2.4 SILC Key Exchange Groups
793 The Following groups may be used in the SILC Key Exchange protocol.
794 The first group diffie-hellman-group1 is REQUIRED, other groups MAY be
795 negotiated to be used in the connection with Key Exchange Start Payload
796 and SILC_PACKET_KEY_EXCHANGE packet. However, the first group MUST be
797 proposed in the Key Exchange Start Payload regardless of any other
798 requested group (however, it does not have to be the first in the list).
801 2.4.1 diffie-hellman-group1
803 The length of this group is 1024 bits. This is REQUIRED group.
804 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
806 Its hexadecimal value is
808 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
809 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
810 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
811 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
812 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
816 The generator used with this prime is g = 2. The group order q is
819 This group was taken from RFC 2412.
822 2.4.2 diffie-hellman-group2
824 The length of this group is 1536 bits. This is OPTIONAL group.
825 The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
827 Its hexadecimal value is
829 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
830 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
831 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
832 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
833 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
834 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
835 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
836 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
838 The generator used with this prime is g = 2. The group order q is
844 Internet-Draft 15 January 2007
849 This group was taken from RFC 3526.
852 2.4.3 diffie-hellman-group3
854 The length of this group is 2048 bits. This is OPTIONAL group.
855 This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }.
857 Its hexadecimal value is
859 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
860 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
861 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
862 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
863 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
864 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
865 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
866 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
867 E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
868 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
869 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
871 The generator used with this prime is g = 2. The group order q is
874 This group was taken from RFC 3526.
876 Additional larger groups are defined in RFC 3526 and may be used in SKE
877 by defining name for them using the above name format.
880 2.5 Key Exchange Status Types
882 This section defines all key exchange protocol status types that may
883 be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
884 to indicate the status of the protocol. Implementations may map the
885 status types to human readable error message. All types except the
886 SILC_SKE_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
887 The length of status is 32 bits (4 bytes). The following status types
892 Protocol were executed successfully.
900 Internet-Draft 15 January 2007
903 1 SILC_SKE_STATUS_ERROR
905 Unknown error occurred. No specific error type is defined.
908 2 SILC_SKE_STATUS_BAD_PAYLOAD
910 Provided KE payload were malformed or included bad fields.
913 3 SILC_SKE_STATUS_UNSUPPORTED_GROUP
915 None of the provided groups were supported.
918 4 SILC_SKE_STATUS_UNSUPPORTED_CIPHER
920 None of the provided ciphers were supported.
923 5 SILC_SKE_STATUS_UNSUPPORTED_PKCS
925 None of the provided public key algorithms were supported.
928 6 SILC_SKE_STATUS_UNSUPPORTED_HASH_FUNCTION
930 None of the provided hash functions were supported.
933 7 SILC_SKE_STATUS_UNSUPPORTED_HMAC
935 None of the provided HMACs were supported.
938 8 SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY
940 Provided public key type is not supported.
943 9 SILC_SKE_STATUS_INCORRECT_SIGNATURE
945 Provided signature was incorrect.
948 10 SILC_SKE_STATUS_BAD_VERSION
950 Provided version string was not acceptable.
956 Internet-Draft 15 January 2007
959 11 SILC_SKE_STATUS_INVALID_COOKIE
961 The cookie in the Key Exchange Start Payload was malformed,
962 because responder modified the cookie.
965 3 SILC Connection Authentication Protocol
967 Purpose of Connection Authentication protocol is to authenticate the
968 connecting party with server. Usually connecting party is client but
969 server may connect to router server as well. Its other purpose is to
970 provide information for the server about which type of entity the
971 connection is. The type defines whether the connection is client,
972 server or router connection. Server use this information to create the
973 ID for the connection.
975 Server MUST verify the authentication data received and if it is to fail
976 the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
977 If authentication is successful the protocol is ended by server by sending
978 SILC_PACKET_SUCCESS packet.
980 The protocol is executed after the SILC Key Exchange protocol. It MUST
981 NOT be executed in any other time. As it is performed after key exchange
982 protocol all traffic in the connection authentication protocol is
983 encrypted with the exchanged keys.
985 The protocol MUST be started by the connecting party by sending the
986 SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload,
987 described in the next section. This payload MUST include the
988 authentication data. The authentication data is set according
989 authentication method that MUST be known by both parties. If connecting
990 party does not know what is the mandatory authentication method it MAY
991 request it from the server by sending SILC_PACKET_CONNECTION_AUTH_REQUEST
992 packet. This packet is not part of this protocol and is described in
993 section Connection Auth Request Payload in [SILC2]. However, if
994 connecting party already knows the mandatory authentication method
995 sending the request is not necessary.
997 See [SILC1] and section Connection Auth Request Payload in [SILC2] also
998 for the list of different authentication methods. Authentication method
999 MAY also be NONE, in which case the server does not require
1000 authentication. However, in this case the protocol still MUST be
1001 executed; the authentication data is empty indicating no authentication
1004 If authentication method is passphrase the authentication data is
1005 plaintext passphrase. As the payload is encrypted it is safe to have
1006 plaintext passphrase. It is also provided as plaintext passphrase
1012 Internet-Draft 15 January 2007
1015 because the receiver may need to pass the entire passphrase into a
1016 passphrase verifier, and a message digest of the passphrase would
1017 prevent this. See the section 3.2.1 Passphrase Authentication for
1020 If authentication method is public key authentication the authentication
1021 data is a digital signature of the hash value of hash HASH and Key
1022 Exchange Start Payload, established by the SILC Key Exchange protocol.
1023 This signature MUST then be verified by the server. See the section
1024 3.2.2 Public Key Authentication for more information.
1026 See the section 4 SILC Procedures in [SILC1] for more information about
1027 client creating connection to server, and server creating connection
1028 to router, and how to register the session in the SILC Network after
1029 successful Connection Authentication protocol.
1032 3.1 Connection Auth Payload
1034 Client sends this payload to authenticate itself to the server. Server
1035 connecting to another server also sends this payload. Server receiving
1036 this payload MUST verify all the data in it and if something is to fail
1037 the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
1039 The payload may only be sent with SILC_PACKET_CONNECTION_AUTH packet.
1040 It MUST NOT be sent in any other packet type. The following diagram
1041 represent the Connection Auth Payload.
1050 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
1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1052 | Payload Length | Connection Type |
1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1055 ~ Authentication Data ~
1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1059 Figure 3: Connection Auth Payload
1062 o Payload Length (2 bytes) - Length of the entire Connection
1068 Internet-Draft 15 January 2007
1073 o Connection Type (2 bytes) - Indicates the type of the
1074 connection. See section Connection Auth Request Payload
1075 in [SILC2] for the list of connection types. This field MUST
1076 include valid connection type or the packet MUST be discarded
1077 and authentication MUST be failed.
1079 o Authentication Data (variable length) - The actual
1080 authentication data. Contents of this depends on the
1081 authentication method known by both parties. If no
1082 authentication is required this field does not exist.
1085 3.2 Connection Authentication Types
1087 SILC supports two authentication types to be used in the connection
1088 authentication protocol; passphrase authentication or public key
1089 authentication based on digital signatures. The following sections
1090 defines the authentication methods. See [SILC2] for defined numerical
1091 authentication method types.
1094 3.2.1 Passphrase Authentication
1096 Passphrase authentication or pre-shared key based authentication is
1097 simply an authentication where the party that wants to authenticate
1098 itself to the other end sends the passphrase that is required by
1099 the other end, for example server. The plaintext passphrase is put
1100 to the payload, that is then encrypted. The plaintext passphrase
1101 MUST be in UTF-8 [RFC2279] encoding. If the passphrase is in the
1102 sender's system in some other encoding it MUST be UTF-8 encoded
1103 before transmitted. The receiver MAY change the encoding of the
1104 passphrase to its system's default character encoding before verifying
1107 If the passphrase matches with the one in the server's end the
1108 authentication is successful. Otherwise SILC_PACKET_FAILURE MUST be
1109 sent to the sender and the protocol execution fails.
1111 This is REQUIRED authentication method to be supported by all SILC
1114 When password authentication is used it is RECOMMENDED that maximum
1115 amount of padding is applied to the SILC packet. This way it is not
1116 possible to approximate the length of the password from the encrypted
1124 Internet-Draft 15 January 2007
1127 3.2.2 Public Key Authentication
1129 Public key authentication may be used if passphrase based authentication
1130 is not desired. The public key authentication works by sending a
1131 digital signature as authentication data to the other end, say, server.
1132 The server MUST then verify the signature by the public key of the sender,
1133 which the server has received earlier in SKE protocol, or which the
1134 server has cached locally at some previous time.
1136 The signature is computed using the private key of the sender by signing
1137 the HASH value provided by the SKE protocol previously, and the Key
1138 Exchange Start Payload from SKE protocol that was sent to the server.
1139 These are concatenated and hash function is used to compute a hash value
1140 which is then signed.
1142 auth_hash = hash(HASH | Key Exchange Start Payload);
1143 signature = sign(auth_hash);
1145 The hash() function used to compute the value is the hash function
1146 negotiated in the SKE protocol. The server MUST verify the data, thus
1147 it must keep the HASH and the Key Exchange Start Payload saved during
1148 SKE and authentication protocols. These values can be discarded after
1149 Connection Authentication protocol is completed.
1151 If the verified signature matches the sent signature, the authentication
1152 were successful and SILC_PACKET_SUCCESS is sent. If it failed the
1153 protocol execution is stopped and SILC_PACKET_FAILURE is sent.
1155 This is REQUIRED authentication method to be supported by all SILC
1160 3.3 Connection Authentication Status Types
1162 This section defines all connection authentication status types that
1163 may be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
1164 to indicate the status of the protocol. Implementations may map the
1165 status types to human readable error message. All types except the
1166 SILC_AUTH_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
1167 The length of status is 32 bits (4 bytes). The following status types
1172 Protocol was executed successfully.
1180 Internet-Draft 15 January 2007
1185 Authentication failed.
1188 4 Security Considerations
1190 Security is central to the design of this protocol, and these security
1191 considerations permeate the specification. Common security considerations
1192 such as keeping private keys truly private and using adequate lengths for
1193 symmetric and asymmetric keys must be followed in order to maintain the
1194 security of this protocol.
1199 [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
1200 Protocol Specification", Internet Draft, January 2007.
1202 [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
1205 [SILC4] Riikonen, P., "SILC Commands", Internet Draft, January 2007.
1207 [IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
1210 [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
1213 [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
1216 [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
1219 [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
1222 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
1225 [PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
1228 [SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
1236 Internet-Draft 15 January 2007
1239 [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
1240 Infrastructure, Certificate and CRL Profile", RFC 2459,
1243 [Schneier] Schneier, B., "Applied Cryptography Second Edition",
1244 John Wiley & Sons, New York, NY, 1996.
1246 [Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
1249 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
1250 RFC 2412, November 1998.
1252 [ISAKMP] Maughan D., et al, "Internet Security Association and
1253 Key Management Protocol (ISAKMP)", RFC 2408, November
1256 [IKE] Harkins D., and Carrel D., "The Internet Key Exchange
1257 (IKE)", RFC 2409, November 1998.
1259 [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
1260 Authentication", RFC 2104, February 1997.
1262 [PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
1263 Specifications, Version 2.0", RFC 2437, October 1998.
1265 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
1266 Requirement Levels", BCP 14, RFC 2119, March 1997.
1268 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
1269 10646", RFC 2279, January 1998.
1271 [RFC2401] Kent, S., et al, "Security Architecture for the Internet
1272 Protocol", RFC 2401, November 1998.
1274 [RFC2406] Kent, S., et al, "Security Architecture for the Internet
1275 Protocol", RFC 2406, November 1998.
1284 EMail: priikone@iki.fi
1292 Internet-Draft 15 January 2007
1295 7 Full Copyright Statement
1297 Copyright (C) The Internet Society (2007).
1299 This document is subject to the rights, licenses and restrictions
1300 contained in BCP 78, and except as set forth therein, the authors
1301 retain all their rights.
1303 This document and the information contained herein are provided on an
1304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1306 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1307 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1308 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.