8 .ds RF FORMFEED[Page %]
11 .ds RH 25 November 2002
17 Network Working Group P. Riikonen
19 draft-riikonen-silc-ke-auth-06.txt 25 November 2002
20 Expires: 25 April 2003
25 SILC Key Exchange and Authentication Protocols
26 <draft-riikonen-silc-ke-auth-06.txt>
31 This document is an Internet-Draft and is in full conformance with
32 all provisions of Section 10 of RFC 2026. Internet-Drafts are
33 working documents of the Internet Engineering Task Force (IETF), its
34 areas, and its working groups. Note that other groups may also
35 distribute working documents as Internet-Drafts.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 The list of current Internet-Drafts can be accessed at
43 http://www.ietf.org/ietf/1id-abstracts.txt
45 The list of Internet-Draft Shadow Directories can be accessed at
46 http://www.ietf.org/shadow.html
48 The distribution of this memo is unlimited.
54 This memo describes two protocols used in the Secure Internet Live
55 Conferencing (SILC) protocol, specified in the Secure Internet Live
56 Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange
57 (SKE) protocol provides secure key exchange between two parties
58 resulting into shared secret key material. The protocol is based
59 on Diffie-Hellman key exchange algorithm and its functionality is
60 derived from several key exchange protocols. SKE use best parts
61 of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol
62 and the OAKLEY Key Determination protocol [OAKLEY].
64 The second protocol, SILC Connection Authentication protocol provides
65 user level authentication used when creating connections in SILC
66 network. The protocol is transparent to the authentication data
67 which means that it can be used to authenticate the user with, for
68 example, passphrase (pre-shared secret) or public key (and certificate)
69 based on digital signatures.
77 1 Introduction .................................................. 2
78 1.1 Requirements Terminology .................................. 3
79 2 SILC Key Exchange Protocol .................................... 3
80 2.1 Key Exchange Payloads ..................................... 4
81 2.1.1 Key Exchange Start Payload .......................... 4
82 2.1.2 Key Exchange Payload ................................ 8
83 2.2 Key Exchange Procedure .................................... 11
84 2.3 Processing the Key Material ............................... 12
85 2.4 SILC Key Exchange Groups .................................. 14
86 2.4.1 diffie-hellman-group1 ............................... 14
87 2.4.2 diffie-hellman-group2 ............................... 15
88 2.4.3 diffie-hellman-group3 ............................... 15
89 2.5 Key Exchange Status Types ................................. 16
90 3 SILC Connection Authentication Protocol ....................... 17
91 3.1 Connection Auth Payload ................................... 18
92 3.2 Connection Authentication Types ........................... 19
93 3.2.1 Passphrase Authentication ........................... 19
94 3.2.2 Public Key Authentication ........................... 20
95 3.3 Connection Authentication Status Types .................... 21
96 4 Security Considerations ....................................... 21
97 5 References .................................................... 21
98 6 Author's Address .............................................. 23
105 Figure 1: Key Exchange Start Payload
106 Figure 2: Key Exchange Payload
107 Figure 3: Connection Auth Payload
113 This memo describes two protocols used in the Secure Internet Live
114 Conferencing (SILC) protocol specified in the Secure Internet Live
115 Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange
116 (SKE) protocol provides secure key exchange between two parties
117 resulting into shared secret key material. The protocol is based on
118 Diffie-Hellman key exchange algorithm and its functionality is derived
119 from several key exchange protocols. SKE use best parts of the SSH2
120 Key Exchange protocol, Station-To-Station (STS) protocol and the
121 OAKLEY Key Determination protocol [OAKLEY].
123 The second protocol, SILC Connection Authentication protocol provides
124 user level authentication used when creating connections in SILC
125 network. The protocol is transparent to the authentication data which
126 means that it can be used to authenticate the user with, for example,
127 passphrase (pre-shared secret) or public key (and certificate) based
128 on digital signatures.
130 The basis of secure SILC session requires strong and secure key exchange
131 protocol and authentication. The authentication protocol is secured and
132 no authentication data is ever sent in the network without encrypting
133 and authenticating it first. Thus, authentication protocol may be used
134 only after the key exchange protocol has been successfully completed.
136 This document constantly refers to other SILC protocol specifications
137 that should be read to be able to fully understand the functionality
138 and purpose of these protocols. The most important references are
139 the Secure Internet Live Conferencing, Protocol Specification [SILC1]
140 and the SILC Packet Protocol [SILC2].
142 The protocol is intended to be used with the SILC protocol thus it
143 does not define own framework that could be used. The framework is
144 provided by the SILC protocol.
148 1.1 Requirements Terminology
150 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
151 MAY, and OPTIONAL, when they appear in this document, are to be
152 interpreted as described in [RFC2119].
156 2 SILC Key Exchange Protocol
158 SILC Key Exchange Protocol (SKE) is used to exchange shared secret
159 between connecting entities. The result of this protocol is a key
160 material used to secure the communication channel. The protocol use
161 Diffie-Hellman key exchange algorithm and its functionality is derived
162 from several key exchange protocols. SKE use best parts of the SSH2
163 Key Exchange protocol, Station-To-Station (STS) protocol and the OAKLEY
164 Key Determination protocol. The protocol does not claim any conformance
165 to any of these protocols, they were only used as a reference when
166 designing this protocol.
168 The purpose of SILC Key Exchange protocol is to create session keys to
169 be used in current SILC session. The keys are valid only for some period
170 of time (usually an hour) or at most until the session ends. These keys
171 are used to protect packets traveling between the two entities.
172 Usually all traffic is secured with the key material derived from this
175 The Diffie-Hellman implementation used in the SILC SHOULD be compliant
180 2.1 Key Exchange Payloads
182 During the key exchange procedure public data is sent between initiator
183 and responder. This data is later used in the key exchange procedure.
184 There are several payloads used in the key exchange. As for all SILC
185 packets, SILC Packet Header, described in [SILC2], is at the start of
186 all packets sent in during this protocol. All the fields in the
187 following payloads are in MSB (most significant byte first) order.
188 Following descriptions of these payloads.
192 2.1.1 Key Exchange Start Payload
194 The key exchange between two entities MUST be started by sending the
195 SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
196 Initiator sends the Key Exchange Start Payload to the responder filled
197 with all security properties it supports. The responder then checks
198 whether it supports the security properties.
200 It then sends a Key Exchange Start Payload to the initiator filled with
201 security properties it selected from the original payload. The payload
202 sent by responder MUST include only one chosen property per list. The
203 character encoding for the security property values as defined in [SILC1]
204 SHOULD be UTF-8 [RFC2279] in Key Exchange Start Payload.
206 The Key Exchange Start Payload is used to tell connecting entities what
207 security properties and algorithms should be used in the communication.
208 The Key Exchange Start Payload is sent only once per session. Even if
209 the PFS (Perfect Forward Secrecy) flag is set the Key Exchange Start
210 Payload is not re-sent. When PFS is desired the Key Exchange Payloads
211 are sent to negotiate new key material. The procedure is equivalent to
212 the very first negotiation except that the Key Exchange Start Payload
215 As this payload is used only with the very first key exchange the payload
216 is never encrypted, as there are no keys to encrypt it with.
218 A cookie is also sent in this payload. A cookie is used to randomize the
219 payload so that none of the key exchange parties can determine this
220 payload before the key exchange procedure starts. The cookie MUST be
221 returned to the original sender unmodified by the responder.
223 Following diagram represents the Key Exchange Start Payload. The lists
224 mentioned below are always comma (`,') separated and the list MUST NOT
225 include white spaces (` ').
231 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
232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
233 | RESERVED | Flags | Payload Length |
234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
243 | Version String Length | |
244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
249 | Key Exchange Grp Length | |
250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
252 ~ Key Exchange Groups ~
254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
255 | PKCS Alg Length | |
256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
261 | Encryption Alg Length | |
262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
264 ~ Encryption Algorithms ~
266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
267 | Hash Alg Length | |
268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
279 | Compression Alg Length | |
280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
282 ~ Compression Algorithms ~
284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
288 Figure 1: Key Exchange Start Payload
293 o RESERVED (1 byte) - Reserved field. Sender fills this with
296 o Flags (1 byte) - Indicates flags to be used in the key
297 exchange. Several flags can be set at once by ORing the
298 flags together. The following flags are reserved for this
303 In this case the field is ignored.
307 This flag is used to indicate that Initial Vector (IV)
308 in encryption will be included in the ciphertext
309 which the recipient must use in decryption. The IV
310 MUST be set after the last ciphertext block. With
311 this flag it is possible to use SILC protocol on
312 unreliable transport such as UDP/IP which may cause
313 packet reordering and packet losses. By default,
314 this flag is not set and thus IV is not included
315 in the ciphertext. Setting this flag increases the
316 ciphertext size by one ciphertext block. Responder
317 MAY override this flag for the initiator.
321 Perfect Forward Secrecy (PFS) to be used in the
322 key exchange protocol. If not set, re-keying
323 is performed using the old key. See the [SILC1]
324 for more information on this issue. When PFS is
325 used, re-keying and creating new keys for any
326 particular purpose MUST cause new key exchange.
327 In this key exchange only the Key Exchange Payload
328 is sent and the Key Exchange Start Payload MUST
329 NOT be sent. When doing PFS the Key Exchange
330 Payloads are encrypted with the old keys.
332 Mutual Authentication 0x04
334 Both of the parties will perform authentication
335 by providing signed data for the other party to
336 verify. By default, only responder will provide
337 the signature data. If this is set then the
338 initiator must also provide it. Initiator MAY
339 set this but also responder MAY set this even if
340 initiator did not set it.
342 Rest of the flags are reserved for the future and
345 o Payload Length (2 bytes) - Length of the entire Key Exchange
346 Start payload, not including any other field.
348 o Cookie (16 bytes) - Cookie that randomize this payload so
349 that each of the party cannot determine the payload before
350 hand. This field MUST be present.
352 o Version String Length (2 bytes) - The length of the Version
353 String field, not including any other field.
355 o Version String (variable length) - Indicates the version of
356 the sender of this payload. Initiator sets this when sending
357 the payload and responder sets this when it replies by sending
358 this payload. See [SILC1] for definition for the version
359 string format. This field MUST be present and include valid
362 o Key Exchange Grp Length (2 bytes) - The length of the
363 key exchange group list, not including any other field.
365 o Key Exchange Group (variable length) - The list of
366 key exchange groups. See the section 2.4 SILC Key Exchange
367 Groups for definitions of these groups. This field MUST
370 o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms
371 list, not including any other field.
373 o PKCS Algorithms (variable length) - The list of PKCS
374 algorithms. This field MUST be present.
376 o Encryption Alg Length (2 bytes) - The length of the encryption
377 algorithms list, not including any other field.
379 o Encryption Algorithms (variable length) - The list of
380 encryption algorithms. This field MUST be present.
382 o Hash Alg Length (2 bytes) - The length of the Hash algorithm
383 list, not including any other field.
385 o Hash Algorithms (variable length) - The list of Hash
386 algorithms. The hash algorithms are mainly used in the
387 SKE protocol. This field MUST be present.
389 o HMAC Length (2 bytes) - The length of the HMAC list, not
390 including any other field.
392 o HMACs (variable length) - The list of HMACs. The HMAC's
393 are used to compute the Message Authentication Code (MAC)
394 of the SILC packets. This field MUST be present.
396 o Compression Alg Length (2 bytes) - The length of the
397 compression algorithms list, not including any other field.
399 o Compression Algorithms (variable length) - The list of
400 compression algorithms. This field MAY be omitted.
405 2.1.2 Key Exchange Payload
407 Key Exchange payload is used to deliver the public key (or certificate),
408 the computed Diffie-Hellman public value and possibly signature data
409 from one party to the other. When initiator is using this payload
410 and the Mutual Authentication flag is not set then the initiator MUST
411 NOT provide the signature data. If the flag is set then the initiator
412 MUST provide the signature data so that the responder can verify it.
414 The Mutual Authentication flag is usually used when a separate
415 authentication protocol will not be executed for the initiator of the
416 protocol. This is case for example when the SKE is performed between
417 two SILC clients. In normal case, where client is connecting to a
418 server, or server is connecting to a router the Mutual Authentication
419 flag MAY be omitted. However, if the connection authentication protocol
420 for the connecting entity is not based on digital signatures (it is
421 based on pre-shared key) then the Mutual Authentication flag SHOULD be
422 enabled. This way the connecting entity has to provide proof of
423 possession of the private key for the public key it will provide in
426 When performing re-key with PFS selected this is the only payload that
427 is sent in the SKE protocol. The Key Exchange Start Payload MUST NOT
428 be sent at all. However, this payload does not have all the fields
429 present. In the re-key with PFS the public key and a possible signature
430 data SHOULD NOT be present. If they are present they MUST be ignored.
431 The only field that is present is the Public Data that is used to create
432 the new key material. In the re-key the Mutual Authentication flag, that
433 may be set in the initial negotiation, MUST also be ignored.
435 This payload is sent inside SILC_PACKET_KEY_EXCHANGE_1 and inside
436 SILC_PACKET_KEY_EXCHANGE_2 packet types. The initiator uses the
437 SILC_PACKET_KEY_EXCHANGE_1 and the responder the latter.
439 The following diagram represent the Key Exchange Payload.
445 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
446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
447 | Public Key Length | Public Key Type |
448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
450 ~ Public Key of the party (or certificate) ~
452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
453 | Public Data Length | |
454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
459 | Signature Length | |
460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
468 Figure 2: Key Exchange Payload
472 o Public Key Length (2 bytes) - The length of the Public Key
473 (or certificate) field, not including any other field.
475 o Public Key Type (2 bytes) - The public key (or certificate)
476 type. This field indicates the type of the public key in
477 the packet. Following types are defined:
479 1 SILC style public key (mandatory)
480 2 SSH2 style public key (optional)
481 3 X.509 Version 3 certificate (optional)
482 4 OpenPGP certificate (optional)
483 5 SPKI certificate (optional)
485 The only required type to support is type number 1. See
486 [SILC1] for the SILC public key specification. See
487 SSH2 public key specification in [SSH-TRANS]. See X.509v3
488 certificate specification in [PKIX-Part1]. See OpenPGP
489 certificate specification in [PGP]. See SPKI certificate
490 specification in [SPKI]. If this field includes zero (0)
491 or unsupported type number the protocol MUST be aborted
492 sending SILC_PACKET_FAILURE message and the connection SHOULD
493 be closed immediately.
495 o Public Key (or certificate) (variable length) - The
496 public key or certificate of the party. This public key
497 is used to verify the digital signature. The public key
498 or certificate in this field is encoded in the manner as
499 defined in their respective definitions; see previous field.
501 o Public Data Length (2 bytes) - The length of the Public Data
502 field, not including any other field.
504 o Public Data (variable length) - The public data to be
505 sent to the receiver (Diffie-Hellman public values). See
506 section 2.2 Key Exchange Procedure for detailed description
507 how this field is computed. This value is binary encoded.
509 o Signature Length (2 bytes) - The length of the signature,
510 not including any other field.
512 o Signature Data (variable length) - The signature signed
513 by the sender. The receiver of this signature MUST
514 verify it. The verification is done using the sender's
515 public key. See section 2.2 Key Exchange Procedure for
516 detailed description how to produce the signature. If
517 the Mutual Authentication flag is not set then initiator
518 MUST NOT provide this field and the Signature Length field
519 MUST be set to zero (0) value. If the flag is set then
520 also the initiator MUST provide this field. The responder
521 always MUST provide this field.
526 2.2 Key Exchange Procedure
528 The key exchange begins by sending SILC_PACKET_KEY_EXCHANGE packet with
529 Key Exchange Start Payload to select the security properties to be used
530 in the key exchange and later in the communication.
532 After Key Exchange Start Payload has been processed by both of the
533 parties the protocol proceeds as follows:
536 Setup: p is a large and public safe prime. This is one of the
537 Diffie Hellman groups. q is order of subgroup (largest
538 prime factor of p). g is a generator and is defined
539 along with the Diffie Hellman group.
541 1. Initiator generates a random number x, where 1 < x < q,
542 and computes e = g ^ x mod p. The result e is then
543 encoded into Key Exchange Payload, with the public key
544 (or certificate) and sent to the responder.
546 If the Mutual Authentication flag is set then initiator
547 MUST also produce signature data SIGN_i which the responder
548 will verify. The initiator MUST compute a hash value
549 HASH_i = hash(Initiator's Key Exchange Start Payload |
550 public key (or certificate) | e). The '|' stands for
551 concatenation. It then signs the HASH_i value with its
552 private key resulting a signature SIGN_i.
554 2. Responder generates a random number y, where 1 < y < q,
555 and computes f = g ^ y mod p. It then computes the
556 shared secret KEY = e ^ y mod p, and, a hash value
557 HASH = hash(Initiator's Key Exchange Start Payload |
558 public key (or certificate) | Initiator's public key
559 (or certificate) | e | f | KEY). It then signs
560 the HASH value with its private key resulting a signature
563 It then encodes its public key (or certificate), f and
564 SIGN into Key Exchange Payload and sends it to the
567 If the Mutual Authentication flag is set then the responder
568 SHOULD verify that the public key provided in the payload
569 is authentic, or if certificates are used it verifies the
570 certificate. The responder MAY accept the public key without
571 verifying it, however, doing so may result to insecure key
572 exchange (accepting the public key without verifying may be
573 desirable for practical reasons on many environments. For
574 long term use this is never desirable, in which case
575 certificates would be the preferred method to use). It then
576 computes the HASH_i value the same way initiator did in the
577 phase 1. It then verifies the signature SIGN_i from the
578 payload with the hash value HASH_i using the received public
581 3. Initiator verifies that the public key provided in
582 the payload is authentic, or if certificates are used
583 it verifies the certificate. The initiator MAY accept
584 the public key without verifying it, however, doing
585 so may result to insecure key exchange (accepting the
586 public key without verifying may be desirable for
587 practical reasons on many environments. For long term
588 use this is never desirable, in which case certificates
589 would be the preferred method to use).
591 Initiator then computes the shared secret KEY =
592 f ^ x mod p, and, a hash value HASH in the same way as
593 responder did in phase 2. It then verifies the
594 signature SIGN from the payload with the hash value
595 HASH using the received public key.
598 If any of these phases is to fail the SILC_PACKET_FAILURE MUST be sent
599 to indicate that the key exchange protocol has failed, and the connection
600 SHOULD be closed immediately. Any other packets MUST NOT be sent or
601 accepted during the key exchange except the SILC_PACKET_KEY_EXCHANGE_*,
602 SILC_PACKET_FAILURE and SILC_PACKET_SUCCESS packets.
604 The result of this protocol is a shared secret key material KEY and
605 a hash value HASH. The key material itself is not fit to be used as
606 a key, it needs to be processed further to derive the actual keys to be
607 used. The key material is also used to produce other security parameters
608 later used in the communication. See section 2.3 Processing the Key
609 Material for detailed description how to process the key material.
611 If the Mutual Authentication flag was set the protocol produces also
612 a hash value HASH_i. This value, however, must be discarded.
614 After the keys are processed the protocol is ended by sending the
615 SILC_PACKET_SUCCESS packet. Both entities send this packet to
616 each other. After this both parties will start using the new keys.
620 2.3 Processing the Key Material
622 Key Exchange protocol produces secret shared key material KEY. This
623 key material is used to derive the actual keys used in the encryption
624 of the communication channel. The key material is also used to derive
625 other security parameters used in the communication. Key Exchange
626 protocol produces a hash value HASH as well.
628 The keys MUST be derived from the key material as follows:
631 Sending Initial Vector (IV) = hash(0x0 | KEY | HASH)
632 Receiving Initial Vector (IV) = hash(0x1 | KEY | HASH)
633 Sending Encryption Key = hash(0x2 | KEY | HASH)
634 Receiving Encryption Key = hash(0x3 | KEY | HASH)
635 Sending HMAC Key = hash(0x4 | KEY | HASH)
636 Receiving HMAC Key = hash(0x5 | KEY | HASH)
640 The Initial Vector (IV) is used in the encryption when doing for
641 example CBC mode. As many bytes as needed are taken from the start of
642 the hash output for IV. Sending IV is for sending key and receiving IV
643 is for receiving key. For receiving party, the receiving IV is actually
644 sender's sending IV, and, the sending IV is actually sender's receiving
645 IV. Initiator uses IV's as they are (sending IV for sending and
646 receiving IV for receiving).
648 The Encryption Keys are derived as well from the hash(). If the hash()
649 output is too short for the encryption algorithm more key material MUST
650 be produced in the following manner:
653 K1 = hash(0x2 | KEY | HASH)
654 K2 = hash(KEY | HASH | K1)
655 K3 = hash(KEY | HASH | K1 | K2) ...
657 Sending Encryption Key = K1 | K2 | K3 ...
660 K1 = hash(0x3 | KEY | HASH)
661 K2 = hash(KEY | HASH | K1)
662 K3 = hash(KEY | HASH | K1 | K2) ...
664 Receiving Encryption Key = K1 | K2 | K3 ...
668 The key is distributed by hashing the previous hash with the original
669 key material. The final key is a concatenation of the hash values.
670 For Receiving Encryption Key the procedure is equivalent. Sending key
671 is used only for encrypting data to be sent. The receiving key is used
672 only to decrypt received data. For receiving party, the receive key is
673 actually sender's sending key, and, the sending key is actually sender's
674 receiving key. Initiator uses generated keys as they are (sending key
675 for sending and receiving key for receiving).
677 The HMAC keys are used to create MAC values to packets in the
678 communication channel. As many bytes as needed are taken from the start
679 of the hash output to generate the MAC keys.
681 These procedures are performed by all parties of the key exchange
682 protocol. This MUST be done before the protocol has been ended by
683 sending the SILC_PACKET_SUCCESS packet, to assure that parties can
684 successfully process the key material.
686 This same key processing procedure MAY be used in the SILC in some
687 other circumstances as well. Any changes to this procedure is defined
688 separately when this procedure is needed. See the [SILC1] and the
689 [SILC2] for these circumstances.
693 2.4 SILC Key Exchange Groups
695 The Following groups may be used in the SILC Key Exchange protocol.
696 The first group diffie-hellman-group1 is REQUIRED, other groups MAY be
697 negotiated to be used in the connection with Key Exchange Start Payload
698 and SILC_PACKET_KEY_EXCHANGE packet. However, the first group MUST be
699 proposed in the Key Exchange Start Payload regardless of any other
700 requested group (however, it does not have to be the first in the list).
704 2.4.1 diffie-hellman-group1
706 The length of this group is 1024 bits. This is REQUIRED group.
707 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
709 Its hexadecimal value is
712 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
713 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
714 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
715 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
716 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
721 The generator used with this prime is g = 2. The group order q is
724 This group was taken from the OAKLEY specification.
728 2.4.2 diffie-hellman-group2
730 The length of this group is 1536 bits. This is OPTIONAL group.
731 The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
733 Its hexadecimal value is
736 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
737 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
738 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
739 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
740 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
741 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
742 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
743 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
746 The generator used with this prime is g = 2. The group order q is
749 This group was taken from the OAKLEY specification.
753 2.4.3 diffie-hellman-group3
755 The length of this group is 2048 bits. This is OPTIONAL group.
756 This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }.
758 Its hexadecimal value is
761 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
762 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
763 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
764 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
765 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
766 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
767 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
768 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
769 E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
770 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
771 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
774 The generator used with this prime is g = 2. The group order q is
782 2.5 Key Exchange Status Types
784 This section defines all key exchange protocol status types that may
785 be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
786 to indicate the status of the protocol. Implementations may map the
787 status types to human readable error message. All types except the
788 SILC_SKE_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
789 The length of status is 32 bits (4 bytes). The following status types
795 Protocol were executed successfully.
798 1 SILC_SKE_STATUS_ERROR
800 Unknown error occurred. No specific error type is defined.
803 2 SILC_SKE_STATUS_BAD_PAYLOAD
805 Provided KE payload were malformed or included bad fields.
808 3 SILC_SKE_STATUS_UNSUPPORTED_GROUP
810 None of the provided groups were supported.
813 4 SILC_SKE_STATUS_UNSUPPORTED_CIPHER
815 None of the provided ciphers were supported.
818 5 SILC_SKE_STATUS_UNSUPPORTED_PKCS
820 None of the provided public key algorithms were supported.
823 6 SILC_SKE_STATUS_UNSUPPORTED_HASH_FUNCTION
825 None of the provided hash functions were supported.
828 7 SILC_SKE_STATUS_UNSUPPORTED_HMAC
830 None of the provided HMACs were supported.
833 8 SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY
835 Provided public key type is not supported.
838 9 SILC_SKE_STATUS_INCORRECT_SIGNATURE
840 Provided signature was incorrect.
843 10 SILC_SKE_STATUS_BAD_VERSION
845 Provided version string was not acceptable.
848 11 SILC_SKE_STATUS_INVALID_COOKIE
850 The cookie in the Key Exchange Start Payload was malformed,
851 because responder modified the cookie.
856 3 SILC Connection Authentication Protocol
858 Purpose of Connection Authentication protocol is to authenticate the
859 connecting party with server. Usually connecting party is client but
860 server may connect to router server as well. Its other purpose is to
861 provide information for the server about which type of connection this
862 is. The type defines whether this is client, server or router
863 connection. Server use this information to create the ID for the
866 Server MUST verify the authentication data received and if it is to fail
867 the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
868 If authentication is successful the protocol is ended by server by sending
869 SILC_PACKET_SUCCESS packet.
871 The protocol is executed after the SILC Key Exchange protocol. It MUST
872 NOT be executed in any other time. As it is performed after key exchange
873 protocol all traffic in the connection authentication protocol is
874 encrypted with the exchanged keys.
876 The protocol MUST be started by the connecting party by sending the
877 SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload,
878 described in the next section. This payload MUST include the
879 authentication data. The authentication data is set according
880 authentication method that MUST be known by both parties. If connecting
881 party does not know what is the mandatory authentication method it MAY
882 request it from the server by sending SILC_PACKET_CONNECTION_AUTH_REQUEST
883 packet. This packet is not part of this protocol and is described in
884 section Connection Auth Request Payload in [SILC2]. However, if
885 connecting party already knows the mandatory authentication method
886 sending the request is not necessary.
888 See [SILC1] and section Connection Auth Request Payload in [SILC2] also
889 for the list of different authentication methods. Authentication method
890 MAY also be NONE, in which case the server does not require
891 authentication. However, in this case the protocol still MUST be
892 executed; the authentication data is empty indicating no authentication
895 If authentication method is passphrase the authentication data is
896 plaintext passphrase. As the payload is encrypted it is safe to have
897 plaintext passphrase. It is also provided as plaintext passphrase
898 because the receiver may need to pass the entire passphrase into a
899 passphrase verifier, and a message digest of the passphrase would
900 prevent this. See the section 3.2.1 Passphrase Authentication for
903 If authentication method is public key authentication the authentication
904 data is a digital signature of the hash value of hash HASH and Key
905 Exchange Start Payload, established by the SILC Key Exchange protocol.
906 This signature MUST then be verified by the server. See the section
907 3.2.2 Public Key Authentication for more information.
909 See the section 4 SILC Procedures in [SILC1] for more information about
910 client creating connection to server, and server creating connection
911 to router, and how to register the session in the SILC Network after
912 successful Connection Authentication protocol.
916 3.1 Connection Auth Payload
918 Client sends this payload to authenticate itself to the server. Server
919 connecting to another server also sends this payload. Server receiving
920 this payload MUST verify all the data in it and if something is to fail
921 the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
923 The payload may only be sent with SILC_PACKET_CONNECTION_AUTH packet.
924 It MUST NOT be sent in any other packet type. The following diagram
925 represent the Connection Auth Payload.
936 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
937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
938 | Payload Length | Connection Type |
939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
941 ~ Authentication Data ~
943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
947 Figure 3: Connection Auth Payload
951 o Payload Length (2 bytes) - Length of the entire Connection
954 o Connection Type (2 bytes) - Indicates the type of the
955 connection. See section Connection Auth Request Payload
956 in [SILC2] for the list of connection types. This field MUST
957 include valid connection type or the packet MUST be discarded
958 and authentication MUST be failed.
960 o Authentication Data (variable length) - The actual
961 authentication data. Contents of this depends on the
962 authentication method known by both parties. If no
963 authentication is required this field does not exist.
968 3.2 Connection Authentication Types
970 SILC supports two authentication types to be used in the connection
971 authentication protocol; passphrase authentication or public key
972 authentication based on digital signatures. The following sections
973 defines the authentication methods. See [SILC2] for defined numerical
974 authentication method types.
978 3.2.1 Passphrase Authentication
980 Passphrase authentication or pre-shared key based authentication is
981 simply an authentication where the party that wants to authenticate
982 itself to the other end sends the passphrase that is required by
983 the other end, for example server. The plaintext passphrase is put
984 to the payload, that is then encrypted. The plaintext passphrase
985 MUST be in UTF-8 [RFC2279] encoding. If the passphrase is in the
986 sender's system in some other encoding it MUST be UTF-8 encoded
987 before transmitted. The receiver MAY change the encoding of the
988 passphrase to its system's default character encoding before verifying
991 If the passphrase matches with the one in the server's end the
992 authentication is successful. Otherwise SILC_PACKET_FAILURE MUST be
993 sent to the sender and the protocol execution fails.
995 This is REQUIRED authentication method to be supported by all SILC
998 When password authentication is used it is RECOMMENDED that maximum
999 amount of padding is applied to the SILC packet. This way it is not
1000 possible to approximate the length of the password from the encrypted
1006 3.2.2 Public Key Authentication
1008 Public key authentication may be used if passphrase based authentication
1009 is not desired. The public key authentication works by sending a
1010 digital signature as authentication data to the other end, say, server.
1011 The server MUST then verify the signature by the public key of the sender,
1012 which the server has received earlier in SKE protocol.
1014 The signature is computed using the private key of the sender by signing
1015 the HASH value provided by the SKE protocol previously, and the Key
1016 Exchange Start Payload from SKE protocol that was sent to the server.
1017 These are concatenated and hash function is used to compute a hash value
1018 which is then signed.
1020 auth_hash = hash(HASH | Key Exchange Start Payload);
1021 signature = sign(auth_hash);
1023 The hash() function used to compute the value is the hash function
1024 negotiated in the SKE protocol. The server MUST verify the data, thus
1025 it must keep the HASH and the Key Exchange Start Payload saved during
1026 SKE and authentication protocols. These values can be discarded after
1027 Connection Authentication protocol is completed.
1029 If the verified signature matches the sent signature, the authentication
1030 were successful and SILC_PACKET_SUCCESS is sent. If it failed the
1031 protocol execution is stopped and SILC_PACKET_FAILURE is sent.
1033 This is REQUIRED authentication method to be supported by all SILC
1039 3.3 Connection Authentication Status Types
1041 This section defines all connection authentication status types that
1042 may be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
1043 to indicate the status of the protocol. Implementations may map the
1044 status types to human readable error message. All types except the
1045 SILC_AUTH_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
1046 The length of status is 32 bits (4 bytes). The following status types
1051 Protocol was executed successfully.
1056 Authentication failed.
1060 4 Security Considerations
1062 Security is central to the design of this protocol, and these security
1063 considerations permeate the specification. Common security considerations
1064 such as keeping private keys truly private and using adequate lengths for
1065 symmetric and asymmetric keys must be followed in order to maintain the
1066 security of this protocol.
1072 [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
1073 Protocol Specification", Internet Draft, May 2002.
1075 [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
1078 [SILC4] Riikonen, P., "SILC Commands", Internet Draft, May 2002.
1080 [IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
1083 [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
1086 [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
1089 [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
1092 [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
1095 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
1098 [PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
1101 [SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
1104 [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
1105 Infrastructure, Certificate and CRL Profile", RFC 2459,
1108 [Schneier] Schneier, B., "Applied Cryptography Second Edition",
1109 John Wiley & Sons, New York, NY, 1996.
1111 [Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
1114 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
1115 RFC 2412, November 1998.
1117 [ISAKMP] Maughan D., et al, "Internet Security Association and
1118 Key Management Protocol (ISAKMP)", RFC 2408, November
1121 [IKE] Harkins D., and Carrel D., "The Internet Key Exchange
1122 (IKE)", RFC 2409, November 1998.
1124 [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
1125 Authentication", RFC 2104, February 1997.
1127 [PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
1128 Specifications, Version 2.0", RFC 2437, October 1998.
1130 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
1131 Requirement Levels", BCP 14, RFC 2119, March 1997.
1133 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
1134 10646", RFC 2279, January 1998.
1142 Snellmaninkatu 34 A 15
1146 EMail: priikone@iki.fi
1148 This Internet-Draft expires 25 April 2003