8 .ds RF FORMFEED[Page %]
17 Network Working Group P. Riikonen
19 draft-riikonen-silc-ke-auth-09.txt XXX
25 SILC Key Exchange and Authentication Protocols
26 <draft-riikonen-silc-ke-auth-09.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.
62 The second protocol, SILC Connection Authentication protocol provides
63 user level authentication used when creating connections in SILC
64 network. The protocol is transparent to the authentication data
65 which means that it can be used to authenticate the connection with, for
66 example, passphrase (pre-shared secret) or public key (and certificate)
67 based on digital signatures.
75 1 Introduction .................................................. 2
76 1.1 Requirements Terminology .................................. 3
77 2 SILC Key Exchange Protocol .................................... 3
78 2.1 Key Exchange Payloads ..................................... 4
79 2.1.1 Key Exchange Start Payload .......................... 4
80 2.1.2 Key Exchange Payload ................................ 8
81 2.2 Key Exchange Procedure .................................... 11
82 2.3 Processing the Key Material ............................... 12
83 2.4 SILC Key Exchange Groups .................................. 14
84 2.4.1 diffie-hellman-group1 ............................... 14
85 2.4.2 diffie-hellman-group2 ............................... 15
86 2.4.3 diffie-hellman-group3 ............................... 15
87 2.5 Key Exchange Status Types ................................. 16
88 3 SILC Connection Authentication Protocol ....................... 17
89 3.1 Connection Auth Payload ................................... 18
90 3.2 Connection Authentication Types ........................... 19
91 3.2.1 Passphrase Authentication ........................... 19
92 3.2.2 Public Key Authentication ........................... 20
93 3.3 Connection Authentication Status Types .................... 21
94 4 Security Considerations ....................................... 21
95 5 References .................................................... 21
96 6 Author's Address .............................................. 23
97 7 Full Copyright Statement ...................................... 23
104 Figure 1: Key Exchange Start Payload
105 Figure 2: Key Exchange Payload
106 Figure 3: Connection Auth Payload
112 This memo describes two protocols used in the Secure Internet Live
113 Conferencing (SILC) protocol specified in the Secure Internet Live
114 Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange
115 (SKE) protocol provides secure key exchange between two parties
116 resulting into shared secret key material. The protocol is based on
117 Diffie-Hellman key exchange algorithm and its functionality is derived
118 from several key exchange protocols, such as SSH2 Key Exchange protocol,
119 Station-To-Station (STS) protocol and the OAKLEY Key Determination
122 The second protocol, SILC Connection Authentication protocol provides
123 user level authentication used when creating connections in SILC
124 network. The protocol is transparent to the authentication data which
125 means that it can be used to authenticate the connection with, for example,
126 passphrase (pre-shared secret) or public key (and certificate) based
127 on digital signatures.
129 The basis of secure SILC session requires strong and secure key exchange
130 protocol and authentication. The authentication protocol is secured and
131 no authentication data is ever sent in the network without encrypting
132 and authenticating it first. Thus, authentication protocol may be used
133 only after the key exchange protocol has been successfully completed.
135 This document constantly refers to other SILC protocol specifications
136 that should be read to be able to fully understand the functionality
137 and purpose of these protocols. The most important references are
138 the Secure Internet Live Conferencing, Protocol Specification [SILC1]
139 and the SILC Packet Protocol [SILC2].
141 The protocol is intended to be used with the SILC protocol thus it
142 does not define own framework that could be used. The framework is
143 provided by the SILC protocol.
147 1.1 Requirements Terminology
149 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
150 MAY, and OPTIONAL, when they appear in this document, are to be
151 interpreted as described in [RFC2119].
155 2 SILC Key Exchange Protocol
157 SILC Key Exchange Protocol (SKE) is used to exchange shared secret
158 material used to secure the communication channel. The protocol use
159 Diffie-Hellman key exchange algorithm and its functionality is derived
160 from several key exchange protocols, such as SSH2 Key Exchange protocol,
161 Station-To-Station (STS) protocol and the OAKLEY Key Determination
162 protocol [OAKLEY]. The protocol does not claim any conformance
163 to any of these protocols, they were only used as a reference when
164 designing this protocol. The protocol can mutually authenticate the
165 negotiating parties during the key exchange.
167 The purpose of SILC Key Exchange protocol is to create session keys to
168 be used in current SILC session. The keys are valid only for some period
169 of time (usually an hour) or at most until the session ends. These keys
170 are used to protect packets traveling between the two entities.
171 Usually all traffic is secured with the key material derived from this
174 The Diffie-Hellman implementation used in the SILC SHOULD be compliant
179 2.1 Key Exchange Payloads
181 During the key exchange procedure public data is sent between initiator
182 and responder. This data is later used in the key exchange procedure.
183 There are several payloads used in the key exchange. As for all SILC
184 packets, SILC Packet Header, described in [SILC2], is at the beginning
185 of all packets sent in during this protocol. All the fields in the
186 following payloads are in MSB (most significant byte first) order.
187 Following descriptions of these payloads.
191 2.1.1 Key Exchange Start Payload
193 The key exchange between two entities MUST be started by sending the
194 SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
195 Initiator sends the Key Exchange Start Payload to the responder filled
196 with all security properties it supports. The responder then checks
197 whether it supports the security properties.
199 It then sends a Key Exchange Start Payload to the initiator filled with
200 security properties it selected from the original payload. The payload
201 sent by responder MUST include only one chosen property per list. The
202 character encoding for the security property values as defined in [SILC1]
203 SHOULD be UTF-8 [RFC2279] in Key Exchange Start Payload.
205 The Key Exchange Start Payload is used to tell connecting entities what
206 security properties and algorithms should be used in the communication.
207 The Key Exchange Start Payload is sent only once per session. Even if
208 the PFS (Perfect Forward Secrecy) flag is set the Key Exchange Start
209 Payload is not re-sent. When PFS is desired the Key Exchange Payloads
210 are sent to negotiate new key material. The procedure is equivalent to
211 the very first negotiation except that the Key Exchange Start Payload
214 As this payload is used only with the very first key exchange the payload
215 is never encrypted, as there are no keys to encrypt it with.
217 A cookie is also sent in this payload. A cookie is used to randomize the
218 payload so that none of the key exchange parties can determine this
219 payload before the key exchange procedure starts. The cookie MUST be
220 returned to the original sender unmodified by the responder.
222 Following diagram represents the Key Exchange Start Payload. The lists
223 mentioned below are always comma (`,') separated and the list MUST NOT
224 include white spaces (` ').
230 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
231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
232 | RESERVED | Flags | Payload Length |
233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
242 | Version String Length | |
243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
248 | Key Exchange Grp Length | |
249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
251 ~ Key Exchange Groups ~
253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
254 | PKCS Alg Length | |
255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
260 | Encryption Alg Length | |
261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
263 ~ Encryption Algorithms ~
265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
266 | Hash Alg Length | |
267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
278 | Compression Alg Length | |
279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
281 ~ Compression Algorithms ~
283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
287 Figure 1: Key Exchange Start Payload
291 o RESERVED (1 byte) - Reserved field. Sender fills this with
294 o Flags (1 byte) - Indicates flags to be used in the key
295 exchange. Several flags can be set at once by ORing the
296 flags together. The following flags are reserved for this
301 In this case the field is ignored.
305 This flag is used to indicate that Initialization
306 Vector (IV) in encryption will be included in the
307 ciphertext which the recipient must use in decryption.
308 At the beginning of the SILC packet, before the SILC
309 Packet header an 8-bit Security ID (SID) MUST be
310 placed. After the SID, the IV MUST be placed. After
311 the IV, a 32-bit MSB first ordered packet sequence
312 number MUST be placed. The SID and IV MUST NOT be
313 encrypted, but the sequence number MUST be included
314 in encryption. The recipient MUST use the sequence
315 number during MAC verification [SILC2]. All fields
316 however are authenticated with MAC.
318 The Security ID is set to value 0 when the key
319 exchange is performed for the first time. It is
320 monotonically increased after each re-key, wrapping
321 eventually. The SID in combination with the current
322 session can be used to identify which key has been
323 used to encrypt an incoming packet. This is especially
324 important after rekey when using UDP/IP protocol,
325 where packets may be lost or reordered. A packet with
326 unknown SID will result into discarding the packet as
327 it cannot be decrypted. After rekey, implementation
328 should understand that it may still receive packets
329 with old SID and be prepared to decrypt them with the
332 With this flag it is possible to use SILC protocol on
333 unreliable transport such as UDP/IP which may cause
334 packet reordering and packet losses. By default,
335 this flag is not set and thus IV is not included
336 in the ciphertext. Setting this flag increases the
337 packet length by one ciphertext block plus 1 byte for
338 the Security ID and 32 bits for the sequence number.
339 Responder MAY override this flag for the initiator,
340 however without this flag UDP connection cannot be
341 used. The flag MAY also be used in TCP connection.
345 Perfect Forward Secrecy (PFS) to be used in the
346 key exchange protocol. If not set, re-keying
347 is performed using the old key. See the [SILC1]
348 for more information on this issue. When PFS is
349 used, re-keying and creating new keys for any
350 particular purpose MUST cause new key exchange with
351 new Diffie-Hellman exponent values. In this key
352 exchange only the Key Exchange Payload is sent and
353 the Key Exchange Start Payload MUST NOT be sent.
354 When doing PFS the Key Exchange Payloads are
355 encrypted with the old keys.
357 Mutual Authentication 0x04
359 Both of the parties will perform authentication
360 by providing signed data for the other party to
361 verify. By default, only responder will provide
362 the signature data. If this is set then the
363 initiator must also provide it. Initiator MAY
364 set this but also responder MAY set this even if
365 initiator did not set it.
367 Rest of the flags are reserved for the future and
370 o Payload Length (2 bytes) - Length of the entire Key Exchange
371 Start payload, not including any other field.
373 o Cookie (16 bytes) - Cookie that randomize this payload so
374 that each of the party cannot determine the payload before
375 hand. This field MUST be present.
377 o Version String Length (2 bytes) - The length of the Version
378 String field, not including any other field.
380 o Version String (variable length) - Indicates the version of
381 the sender of this payload. Initiator sets this when sending
382 the payload and responder sets this when it replies by sending
383 this payload. See [SILC1] for definition for the version
384 string format. This field MUST be present and include valid
387 o Key Exchange Grp Length (2 bytes) - The length of the
388 key exchange group list, not including any other field.
390 o Key Exchange Group (variable length) - The list of
391 key exchange groups. See the section 2.4 SILC Key Exchange
392 Groups for definitions of these groups. This field MUST
395 o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms
396 list, not including any other field.
398 o PKCS Algorithms (variable length) - The list of PKCS
399 algorithms. This field MUST be present.
401 o Encryption Alg Length (2 bytes) - The length of the encryption
402 algorithms list, not including any other field.
404 o Encryption Algorithms (variable length) - The list of
405 encryption algorithms. This field MUST be present.
407 o Hash Alg Length (2 bytes) - The length of the Hash algorithm
408 list, not including any other field.
410 o Hash Algorithms (variable length) - The list of Hash
411 algorithms. The hash algorithms are mainly used in the
412 SKE protocol. This field MUST be present.
414 o HMAC Length (2 bytes) - The length of the HMAC list, not
415 including any other field.
417 o HMACs (variable length) - The list of HMACs. The HMAC's
418 are used to compute the Message Authentication Code (MAC)
419 of the SILC packets. This field MUST be present.
421 o Compression Alg Length (2 bytes) - The length of the
422 compression algorithms list, not including any other field.
424 o Compression Algorithms (variable length) - The list of
425 compression algorithms. This field MAY be omitted.
430 2.1.2 Key Exchange Payload
432 Key Exchange payload is used to deliver the public key (or certificate),
433 the computed Diffie-Hellman public value and possibly signature data
434 from one party to the other. When initiator is using this payload
435 and the Mutual Authentication flag is not set then the initiator MUST
436 NOT provide the signature data. If the flag is set then the initiator
437 MUST provide the signature data so that the responder can verify it.
439 The Mutual Authentication flag is usually used when a separate
440 authentication protocol will not be executed for the initiator of the
441 protocol. This is case for example when the SKE is performed between
442 two SILC clients. In normal case, where client is connecting to a
443 server, or server is connecting to a router the Mutual Authentication
444 flag MAY be omitted. However, if the connection authentication protocol
445 for the connecting entity is not based on digital signatures (it is
446 based on pre-shared key) then the Mutual Authentication flag SHOULD be
447 enabled. This way the connecting entity has to provide proof of
448 possession of the private key for the public key it will provide in
451 When performing re-key with PFS selected this is the only payload that
452 is sent in the SKE protocol. The Key Exchange Start Payload MUST NOT
453 be sent at all. However, this payload does not have all the fields
454 present. In the re-key with PFS the public key and a possible signature
455 data SHOULD NOT be present. If they are present they MUST be ignored.
456 The only field that is present is the Public Data that is used to create
457 the new key material. In the re-key the Mutual Authentication flag, that
458 may be set in the initial negotiation, MUST also be ignored.
460 This payload is sent inside SILC_PACKET_KEY_EXCHANGE_1 and inside
461 SILC_PACKET_KEY_EXCHANGE_2 packet types. The initiator uses the
462 SILC_PACKET_KEY_EXCHANGE_1 and the responder the latter.
464 The following diagram represent the Key Exchange Payload.
470 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
471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
472 | Public Key Length | Public Key Type |
473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
475 ~ Public Key of the party (or certificate) ~
477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
478 | Public Data Length | |
479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
484 | Signature Length | |
485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
493 Figure 2: Key Exchange Payload
497 o Public Key Length (2 bytes) - The length of the Public Key
498 (or certificate) field, not including any other field.
500 o Public Key Type (2 bytes) - The public key (or certificate)
501 type. This field indicates the type of the public key in
502 the packet. Following types are defined:
504 1 SILC style public key (mandatory)
505 2 SSH2 style public key (optional)
506 3 X.509 Version 3 certificate (optional)
507 4 OpenPGP certificate (optional)
508 5 SPKI certificate (optional)
510 The only required type to support is type number 1. See
511 [SILC1] for the SILC public key specification. See
512 SSH2 public key specification in [SSH-TRANS]. See X.509v3
513 certificate specification in [PKIX-Part1]. See OpenPGP
514 certificate specification in [PGP]. See SPKI certificate
515 specification in [SPKI]. If this field includes zero (0)
516 or unsupported type number the protocol MUST be aborted
517 sending SILC_PACKET_FAILURE message and the connection SHOULD
518 be closed immediately.
520 o Public Key (or certificate) (variable length) - The
521 public key or certificate of the party. This public key
522 is used to verify the digital signature. The public key
523 or certificate in this field is encoded in the manner as
524 defined in their respective definitions; see previous field.
526 o Public Data Length (2 bytes) - The length of the Public Data
527 field, not including any other field.
529 o Public Data (variable length) - The public data to be
530 sent to the receiver (computed Diffie-Hellman public values).
531 See section 2.2 Key Exchange Procedure for detailed description
532 how this field is computed. This field is MP integer and is
533 encoded as defined in [SILC1].
535 o Signature Length (2 bytes) - The length of the signature,
536 not including any other field.
538 o Signature Data (variable length) - The signature signed
539 by the sender. The receiver of this signature MUST
540 verify it. The verification is done using the sender's
541 public key. See section 2.2 Key Exchange Procedure for
542 detailed description how to produce the signature. If
543 the Mutual Authentication flag is not set then initiator
544 MUST NOT provide this field and the Signature Length field
545 MUST be set to zero (0) value. If the flag is set then
546 also the initiator MUST provide this field. The responder
547 always MUST provide this field. The encoding for signature
548 is defined in [SILC1].
554 2.2 Key Exchange Procedure
556 The key exchange begins by sending SILC_PACKET_KEY_EXCHANGE packet with
557 Key Exchange Start Payload to select the security properties to be used
558 in the key exchange and later in the communication.
560 After Key Exchange Start Payload has been processed by both of the
561 parties the protocol proceeds as follows:
564 Setup: p is a large and public safe prime. This is one of the
565 Diffie Hellman groups. q is order of subgroup (largest
566 prime factor of p). g is a generator and is defined
567 along with the Diffie Hellman group.
569 1. Initiator generates a random number x, where 1 < x < q,
570 and computes e = g ^ x mod p. The result e is then
571 encoded into Key Exchange Payload, with the public key
572 (or certificate) and sent to the responder.
574 If the Mutual Authentication flag is set then initiator
575 MUST also produce signature data SIGN_i which the responder
576 will verify. The initiator MUST compute a hash value
577 HASH_i = hash(Initiator's Key Exchange Start Payload |
578 public key (or certificate) | e). The '|' stands for
579 concatenation. It then signs the HASH_i value with its
580 private key resulting a signature SIGN_i.
582 2. Responder generates a random number y, where 1 < y < q,
583 and computes f = g ^ y mod p. It then computes the
584 shared secret KEY = e ^ y mod p, and, a hash value
585 HASH = hash(Initiator's Key Exchange Start Payload |
586 public key (or certificate) | Initiator's public key
587 (or certificate) | e | f | KEY). It then signs
588 the HASH value with its private key resulting a signature
591 It then encodes its public key (or certificate), f and
592 SIGN into Key Exchange Payload and sends it to the
595 If the Mutual Authentication flag is set then the responder
596 SHOULD verify that the public key provided in the payload
597 is authentic, or if certificates are used it verifies the
598 certificate. The responder MAY accept the public key without
599 verifying it, however, doing so may result to insecure key
600 exchange (accepting the public key without verifying may be
601 desirable for practical reasons on many environments. For
602 long term use this is never desirable, in which case
603 certificates would be the preferred method to use). It then
604 computes the HASH_i value the same way initiator did in the
605 phase 1. It then verifies the signature SIGN_i from the
606 payload with the hash value HASH_i using the received public
609 3. Initiator verifies that the public key provided in
610 the payload is authentic, or if certificates are used
611 it verifies the certificate. The initiator MAY accept
612 the public key without verifying it, however, doing
613 so may result to insecure key exchange (accepting the
614 public key without verifying may be desirable for
615 practical reasons on many environments. For long term
616 use this is never desirable, in which case certificates
617 would be the preferred method to use).
619 Initiator then computes the shared secret KEY =
620 f ^ x mod p, and, a hash value HASH in the same way as
621 responder did in phase 2. It then verifies the
622 signature SIGN from the payload with the hash value
623 HASH using the received public key.
626 If any of these phases is to fail the SILC_PACKET_FAILURE MUST be sent
627 to indicate that the key exchange protocol has failed, and the connection
628 SHOULD be closed immediately. Any other packets MUST NOT be sent or
629 accepted during the key exchange except the SILC_PACKET_KEY_EXCHANGE_*,
630 SILC_PACKET_FAILURE and SILC_PACKET_SUCCESS packets.
632 The result of this protocol is a shared secret key material KEY and
633 a hash value HASH. The key material itself is not fit to be used as
634 a key, it needs to be processed further to derive the actual keys to be
635 used. The key material is also used to produce other security parameters
636 later used in the communication. See section 2.3 Processing the Key
637 Material for detailed description how to process the key material.
639 If the Mutual Authentication flag was set the protocol produces also
640 a hash value HASH_i. This value, however, must be discarded.
642 After the keys are processed the protocol is ended by sending the
643 SILC_PACKET_SUCCESS packet. Both entities send this packet to
644 each other. After this both parties MUST start using the new keys.
648 2.3 Processing the Key Material
650 Key Exchange protocol produces secret shared key material KEY. This
651 key material is used to derive the actual keys used in the encryption
652 of the communication channel. The key material is also used to derive
653 other security parameters used in the communication. Key Exchange
654 protocol produces a hash value HASH as well.
656 The keys MUST be derived from the key material as follows:
659 Sending Initial Vector (IV) = hash(0x0 | KEY | HASH)
660 Receiving Initial Vector (IV) = hash(0x1 | KEY | HASH)
661 Sending Encryption Key = hash(0x2 | KEY | HASH)
662 Receiving Encryption Key = hash(0x3 | KEY | HASH)
663 Sending HMAC Key = hash(0x4 | KEY | HASH)
664 Receiving HMAC Key = hash(0x5 | KEY | HASH)
668 The Initial Vector (IV) is used in the encryption when doing for
669 example CBC mode. As many bytes as needed are taken from the start of
670 the hash output for IV. Sending IV is for sending key and receiving IV
671 is for receiving key. For receiving party, the receiving IV is actually
672 sender's sending IV, and, the sending IV is actually sender's receiving
673 IV. Initiator uses IV's as they are (sending IV for sending and
674 receiving IV for receiving).
676 The Encryption Keys are derived as well from the hash(). If the hash()
677 output is too short for the encryption algorithm more key material MUST
678 be produced in the following manner:
681 K1 = hash(0x2 | KEY | HASH)
682 K2 = hash(KEY | HASH | K1)
683 K3 = hash(KEY | HASH | K1 | K2) ...
685 Sending Encryption Key = K1 | K2 | K3 ...
688 K1 = hash(0x3 | KEY | HASH)
689 K2 = hash(KEY | HASH | K1)
690 K3 = hash(KEY | HASH | K1 | K2) ...
692 Receiving Encryption Key = K1 | K2 | K3 ...
696 The key is distributed by hashing the previous hash with the original
697 key material. The final key is a concatenation of the hash values.
698 For Receiving Encryption Key the procedure is equivalent. Sending key
699 is used only for encrypting data to be sent. The receiving key is used
700 only to decrypt received data. For receiving party, the receive key is
701 actually sender's sending key, and, the sending key is actually sender's
702 receiving key. Initiator uses generated keys as they are (sending key
703 for sending and receiving key for receiving).
705 The HMAC keys are used to create MAC values to packets in the
706 communication channel. As many bytes as needed are taken from the start
707 of the hash output to generate the MAC keys.
709 These procedures are performed by all parties of the key exchange
710 protocol. This MUST be done before the protocol has been ended by
711 sending the SILC_PACKET_SUCCESS packet, to assure that parties can
712 successfully process the key material.
714 This same key processing procedure MAY be used in the SILC in some
715 other circumstances as well. Any changes to this procedure is defined
716 separately when this procedure is needed. See the [SILC1] and the
717 [SILC2] for these circumstances.
721 2.4 SILC Key Exchange Groups
723 The Following groups may be used in the SILC Key Exchange protocol.
724 The first group diffie-hellman-group1 is REQUIRED, other groups MAY be
725 negotiated to be used in the connection with Key Exchange Start Payload
726 and SILC_PACKET_KEY_EXCHANGE packet. However, the first group MUST be
727 proposed in the Key Exchange Start Payload regardless of any other
728 requested group (however, it does not have to be the first in the list).
732 2.4.1 diffie-hellman-group1
734 The length of this group is 1024 bits. This is REQUIRED group.
735 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
737 Its hexadecimal value is
740 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
741 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
742 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
743 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
744 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
749 The generator used with this prime is g = 2. The group order q is
752 This group was taken from RFC 2412.
756 2.4.2 diffie-hellman-group2
758 The length of this group is 1536 bits. This is OPTIONAL group.
759 The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
761 Its hexadecimal value is
764 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
765 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
766 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
767 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
768 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
769 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
770 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
771 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
774 The generator used with this prime is g = 2. The group order q is
777 This group was taken from RFC 3526.
781 2.4.3 diffie-hellman-group3
783 The length of this group is 2048 bits. This is OPTIONAL group.
784 This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }.
786 Its hexadecimal value is
789 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
790 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
791 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
792 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
793 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
794 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
795 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
796 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
797 E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
798 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
799 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
802 The generator used with this prime is g = 2. The group order q is
805 This group was taken from RFC 3526.
807 Additional larger groups are defined in RFC 3526 and may be used in SKE
808 by defining name for them using the above name format.
812 2.5 Key Exchange Status Types
814 This section defines all key exchange protocol status types that may
815 be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
816 to indicate the status of the protocol. Implementations may map the
817 status types to human readable error message. All types except the
818 SILC_SKE_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
819 The length of status is 32 bits (4 bytes). The following status types
825 Protocol were executed successfully.
828 1 SILC_SKE_STATUS_ERROR
830 Unknown error occurred. No specific error type is defined.
833 2 SILC_SKE_STATUS_BAD_PAYLOAD
835 Provided KE payload were malformed or included bad fields.
838 3 SILC_SKE_STATUS_UNSUPPORTED_GROUP
840 None of the provided groups were supported.
843 4 SILC_SKE_STATUS_UNSUPPORTED_CIPHER
845 None of the provided ciphers were supported.
848 5 SILC_SKE_STATUS_UNSUPPORTED_PKCS
850 None of the provided public key algorithms were supported.
853 6 SILC_SKE_STATUS_UNSUPPORTED_HASH_FUNCTION
855 None of the provided hash functions were supported.
858 7 SILC_SKE_STATUS_UNSUPPORTED_HMAC
860 None of the provided HMACs were supported.
863 8 SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY
865 Provided public key type is not supported.
868 9 SILC_SKE_STATUS_INCORRECT_SIGNATURE
870 Provided signature was incorrect.
873 10 SILC_SKE_STATUS_BAD_VERSION
875 Provided version string was not acceptable.
878 11 SILC_SKE_STATUS_INVALID_COOKIE
880 The cookie in the Key Exchange Start Payload was malformed,
881 because responder modified the cookie.
886 3 SILC Connection Authentication Protocol
888 Purpose of Connection Authentication protocol is to authenticate the
889 connecting party with server. Usually connecting party is client but
890 server may connect to router server as well. Its other purpose is to
891 provide information for the server about which type of entity the
892 connection is. The type defines whether the connection is client,
893 server or router connection. Server use this information to create the
894 ID for the connection.
896 Server MUST verify the authentication data received and if it is to fail
897 the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
898 If authentication is successful the protocol is ended by server by sending
899 SILC_PACKET_SUCCESS packet.
901 The protocol is executed after the SILC Key Exchange protocol. It MUST
902 NOT be executed in any other time. As it is performed after key exchange
903 protocol all traffic in the connection authentication protocol is
904 encrypted with the exchanged keys.
906 The protocol MUST be started by the connecting party by sending the
907 SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload,
908 described in the next section. This payload MUST include the
909 authentication data. The authentication data is set according
910 authentication method that MUST be known by both parties. If connecting
911 party does not know what is the mandatory authentication method it MAY
912 request it from the server by sending SILC_PACKET_CONNECTION_AUTH_REQUEST
913 packet. This packet is not part of this protocol and is described in
914 section Connection Auth Request Payload in [SILC2]. However, if
915 connecting party already knows the mandatory authentication method
916 sending the request is not necessary.
918 See [SILC1] and section Connection Auth Request Payload in [SILC2] also
919 for the list of different authentication methods. Authentication method
920 MAY also be NONE, in which case the server does not require
921 authentication. However, in this case the protocol still MUST be
922 executed; the authentication data is empty indicating no authentication
925 If authentication method is passphrase the authentication data is
926 plaintext passphrase. As the payload is encrypted it is safe to have
927 plaintext passphrase. It is also provided as plaintext passphrase
928 because the receiver may need to pass the entire passphrase into a
929 passphrase verifier, and a message digest of the passphrase would
930 prevent this. See the section 3.2.1 Passphrase Authentication for
933 If authentication method is public key authentication the authentication
934 data is a digital signature of the hash value of hash HASH and Key
935 Exchange Start Payload, established by the SILC Key Exchange protocol.
936 This signature MUST then be verified by the server. See the section
937 3.2.2 Public Key Authentication for more information.
939 See the section 4 SILC Procedures in [SILC1] for more information about
940 client creating connection to server, and server creating connection
941 to router, and how to register the session in the SILC Network after
942 successful Connection Authentication protocol.
946 3.1 Connection Auth Payload
948 Client sends this payload to authenticate itself to the server. Server
949 connecting to another server also sends this payload. Server receiving
950 this payload MUST verify all the data in it and if something is to fail
951 the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
953 The payload may only be sent with SILC_PACKET_CONNECTION_AUTH packet.
954 It MUST NOT be sent in any other packet type. The following diagram
955 represent the Connection Auth Payload.
966 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
967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
968 | Payload Length | Connection Type |
969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
971 ~ Authentication Data ~
973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
977 Figure 3: Connection Auth Payload
981 o Payload Length (2 bytes) - Length of the entire Connection
984 o Connection Type (2 bytes) - Indicates the type of the
985 connection. See section Connection Auth Request Payload
986 in [SILC2] for the list of connection types. This field MUST
987 include valid connection type or the packet MUST be discarded
988 and authentication MUST be failed.
990 o Authentication Data (variable length) - The actual
991 authentication data. Contents of this depends on the
992 authentication method known by both parties. If no
993 authentication is required this field does not exist.
998 3.2 Connection Authentication Types
1000 SILC supports two authentication types to be used in the connection
1001 authentication protocol; passphrase authentication or public key
1002 authentication based on digital signatures. The following sections
1003 defines the authentication methods. See [SILC2] for defined numerical
1004 authentication method types.
1008 3.2.1 Passphrase Authentication
1010 Passphrase authentication or pre-shared key based authentication is
1011 simply an authentication where the party that wants to authenticate
1012 itself to the other end sends the passphrase that is required by
1013 the other end, for example server. The plaintext passphrase is put
1014 to the payload, that is then encrypted. The plaintext passphrase
1015 MUST be in UTF-8 [RFC2279] encoding. If the passphrase is in the
1016 sender's system in some other encoding it MUST be UTF-8 encoded
1017 before transmitted. The receiver MAY change the encoding of the
1018 passphrase to its system's default character encoding before verifying
1021 If the passphrase matches with the one in the server's end the
1022 authentication is successful. Otherwise SILC_PACKET_FAILURE MUST be
1023 sent to the sender and the protocol execution fails.
1025 This is REQUIRED authentication method to be supported by all SILC
1028 When password authentication is used it is RECOMMENDED that maximum
1029 amount of padding is applied to the SILC packet. This way it is not
1030 possible to approximate the length of the password from the encrypted
1036 3.2.2 Public Key Authentication
1038 Public key authentication may be used if passphrase based authentication
1039 is not desired. The public key authentication works by sending a
1040 digital signature as authentication data to the other end, say, server.
1041 The server MUST then verify the signature by the public key of the sender,
1042 which the server has received earlier in SKE protocol.
1044 The signature is computed using the private key of the sender by signing
1045 the HASH value provided by the SKE protocol previously, and the Key
1046 Exchange Start Payload from SKE protocol that was sent to the server.
1047 These are concatenated and hash function is used to compute a hash value
1048 which is then signed.
1050 auth_hash = hash(HASH | Key Exchange Start Payload);
1051 signature = sign(auth_hash);
1053 The hash() function used to compute the value is the hash function
1054 negotiated in the SKE protocol. The server MUST verify the data, thus
1055 it must keep the HASH and the Key Exchange Start Payload saved during
1056 SKE and authentication protocols. These values can be discarded after
1057 Connection Authentication protocol is completed.
1059 If the verified signature matches the sent signature, the authentication
1060 were successful and SILC_PACKET_SUCCESS is sent. If it failed the
1061 protocol execution is stopped and SILC_PACKET_FAILURE is sent.
1063 This is REQUIRED authentication method to be supported by all SILC
1069 3.3 Connection Authentication Status Types
1071 This section defines all connection authentication status types that
1072 may be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
1073 to indicate the status of the protocol. Implementations may map the
1074 status types to human readable error message. All types except the
1075 SILC_AUTH_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
1076 The length of status is 32 bits (4 bytes). The following status types
1081 Protocol was executed successfully.
1086 Authentication failed.
1090 4 Security Considerations
1092 Security is central to the design of this protocol, and these security
1093 considerations permeate the specification. Common security considerations
1094 such as keeping private keys truly private and using adequate lengths for
1095 symmetric and asymmetric keys must be followed in order to maintain the
1096 security of this protocol.
1102 [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
1103 Protocol Specification", Internet Draft, June 2003.
1105 [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
1108 [SILC4] Riikonen, P., "SILC Commands", Internet Draft, June 2003.
1110 [IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
1113 [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
1116 [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
1119 [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
1122 [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
1125 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
1128 [PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
1131 [SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
1134 [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
1135 Infrastructure, Certificate and CRL Profile", RFC 2459,
1138 [Schneier] Schneier, B., "Applied Cryptography Second Edition",
1139 John Wiley & Sons, New York, NY, 1996.
1141 [Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
1144 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
1145 RFC 2412, November 1998.
1147 [ISAKMP] Maughan D., et al, "Internet Security Association and
1148 Key Management Protocol (ISAKMP)", RFC 2408, November
1151 [IKE] Harkins D., and Carrel D., "The Internet Key Exchange
1152 (IKE)", RFC 2409, November 1998.
1154 [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
1155 Authentication", RFC 2104, February 1997.
1157 [PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
1158 Specifications, Version 2.0", RFC 2437, October 1998.
1160 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
1161 Requirement Levels", BCP 14, RFC 2119, March 1997.
1163 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
1164 10646", RFC 2279, January 1998.
1172 Snellmaninkatu 34 A 15
1176 EMail: priikone@iki.fi
1180 7 Full Copyright Statement
1182 Copyright (C) The Internet Society (2003). All Rights Reserved.
1184 This document and translations of it may be copied and furnished to
1185 others, and derivative works that comment on or otherwise explain it
1186 or assist in its implementation may be prepared, copied, published
1187 and distributed, in whole or in part, without restriction of any
1188 kind, provided that the above copyright notice and this paragraph are
1189 included on all such copies and derivative works. However, this
1190 document itself may not be modified in any way, such as by removing
1191 the copyright notice or references to the Internet Society or other
1192 Internet organizations, except as needed for the purpose of
1193 developing Internet standards in which case the procedures for
1194 copyrights defined in the Internet Standards process must be
1195 followed, or as required to translate it into languages other than
1198 The limited permissions granted above are perpetual and will not be
1199 revoked by the Internet Society or its successors or assigns.
1201 This document and the information contained herein is provided on an
1202 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1203 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1204 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1205 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1206 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.