8 .ds RF FORMFEED[Page %]
17 Network Working Group P. Riikonen
19 draft-riikonen-silc-ke-auth-05.txt 15 May 2002
20 Expires: 15 November 2002
25 SILC Key Exchange and Authentication Protocols
26 <draft-riikonen-silc-ke-auth-05.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 internet-draft [SILC1]. The
57 SILC Key Exchange (SKE) protocol provides secure key exchange between
58 two parties resulting into shared secret key material. The protocol
59 is based on Diffie-Hellman key exchange algorithm and its functionality
60 is derived from several key exchange protocols. SKE uses best parts
61 of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol
62 and the OAKLEY Key Determination protocol [OAKLEY].
64 The SILC Connection Authentication protocol provides user level
65 authentication used when creating connections in SILC network. The
66 protocol is transparent to the authentication data which means that it
67 can be used to authenticate the user with, for example, passphrase
68 (pre-shared-secret) or public key (and certificate).
76 1 Introduction .................................................. 2
77 1.1 Requirements Terminology .................................. 3
78 2 SILC Key Exchange Protocol .................................... 3
79 2.1 Key Exchange Payloads ..................................... 4
80 2.1.1 Key Exchange Start Payload .......................... 4
81 2.1.2 Key Exchange Payload ................................ 8
82 2.2 Key Exchange Procedure .................................... 10
83 2.3 Processing the Key Material ............................... 12
84 2.4 SILC Key Exchange Groups .................................. 14
85 2.4.1 diffie-hellman-group1 ............................... 14
86 2.4.2 diffie-hellman-group2 ............................... 14
87 2.5 Key Exchange Status Types ................................. 15
88 3 SILC Connection Authentication Protocol ....................... 16
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 .................... 20
94 4 Security Considerations ....................................... 21
95 5 References .................................................... 21
96 6 Author's Address .............................................. 22
103 Figure 1: Key Exchange Start Payload
104 Figure 2: Key Exchange Payload
105 Figure 3: Connection Auth Payload
111 This memo describes two protocols used in the Secure Internet Live
112 Conferencing (SILC) protocol specified in the Secure Internet Live
113 Conferencing, Protocol Specification Internet-Draft [SILC1]. The
114 SILC Key Exchange (SKE) protocol provides secure key exchange between
115 two parties resulting into shared secret key material. The protocol
116 is based on Diffie-Hellman key exchange algorithm and its functionality
117 is derived from several key exchange protocols. SKE uses best parts
118 of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol
119 and the OAKLEY Key Determination protocol.
121 The SILC Connection Authentication protocol provides user level
122 authentication used when creating connections in SILC network. The
123 protocol is transparent to the authentication data which means that it
124 can be used to authenticate the user with, for example, passphrase
125 (pre-shared- secret) or public key (and certificate).
127 The basis of secure SILC session requires strong and secure key exchange
128 protocol and authentication. The authentication protocol is entirely
129 secured and no authentication data is ever sent in the network without
130 encrypting and authenticating it first. Thus, authentication protocol
131 may be used only after the key exchange protocol has been successfully
134 This document refers constantly to other SILC protocol specification
135 Internet Drafts that are a must read for those who wants to understand
136 the function of these protocols. The most important references are
137 the Secure Internet Live Conferencing, Protocol Specification [SILC1]
138 and the SILC Packet Protocol [SILC2] Internet Drafts.
140 The protocol is intended to be used with the SILC protocol thus it
141 does not define own framework that could be used. The framework is
142 provided by the SILC protocol.
146 1.1 Requirements Terminology
148 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
149 MAY, and OPTIONAL, when they appear in this document, are to be
150 interpreted as described in [RFC2119].
154 2 SILC Key Exchange Protocol
156 SILC Key Exchange Protocol (SKE) is used to exchange shared secret
157 between connecting entities. The result of this protocol is a key
158 material used to secure the communication channel. The protocol uses
159 Diffie-Hellman key exchange algorithm and its functionality is derived
160 from several key exchange protocols. SKE uses best parts of the SSH2
161 Key Exchange protocol, Station-To-Station (STS) protocol and the OAKLEY
162 Key Determination protocol. The protocol does not claim any conformance
163 to any of these protocols, they were merely used as a reference when
164 designing this protocol.
166 The purpose of SILC Key Exchange protocol is to create session keys to
167 be used in current SILC session. The keys are valid only for some period
168 of time (usually an hour) or at most until the session ends. These keys
169 are used to protect packets like commands, command replies and other
170 communication between two entities. If connection is server to router
171 connection, the keys are used to protect all traffic between those
172 servers. In client connections usually all the packets are protected
173 with this key except channel messages; channels has their own keys and
174 they are not exchanged with this protocol.
176 The Diffie-Hellman implementation used in the SILC SHOULD be compliant
181 2.1 Key Exchange Payloads
183 During the key exchange procedure public data is sent between initiator
184 and responder. This data is later used in the key exchange procedure.
185 There are several payloads used in the key exchange. As for all SILC
186 packets, SILC Packet Header, described in [SILC2], is at the start of
187 all packets. The same is done with these payloads as well. All the
188 fields in the payloads are always in MSB (most significant byte first)
189 order. Following descriptions of these payloads.
193 2.1.1 Key Exchange Start Payload
195 The key exchange between two entities MUST be started by sending the
196 SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
197 Initiator sends the Key Exchange Start Payload to the responder filled
198 with all security properties it supports. The responder then checks
199 whether it supports the security properties.
201 It then sends a Key Exchange Start Payload to the initiator filled with
202 security properties it selected from the original payload. The payload
203 sent by responder MUST include only one chosen property per list. The
204 character encoding for the security property values as defined in [SILC1]
205 SHOULD be UTF-8 [RFC2279].
207 The Key Exchange Start Payload is used to tell connecting entities what
208 security properties and algorithms should be used in the communication.
209 The Key Exchange Start Payload is sent only once per session. Even if
210 the PFS (Perfect Forward Secrecy) flag is set the Key Exchange Start
211 Payload is not re-sent. When PFS is desired the Key Exchange Payloads
212 are sent to negotiate new key material. The procedure is equivalent to
213 the very first negotiation except that the Key Exchange Start Payload
216 As this payload is used only with the very first key exchange the payload
217 is never encrypted, as there are no keys to encrypt it with.
219 A cookie is also sent in this payload. A cookie is used to randomize the
220 payload so that none of the key exchange parties can determine this
221 payload before the key exchange procedure starts. The cookie MUST be
222 returned to the original sender by the responder.
224 Following diagram represents the Key Exchange Start Payload. The lists
225 mentioned below are always comma (`,') separated and the list MUST NOT
226 include white spaces (` ').
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
280 | Compression Alg Length | |
281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
283 ~ Compression Algorithms ~
285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
289 Figure 1: Key Exchange Start Payload
294 o RESERVED (1 byte) - Reserved field. Sender fills this with
297 o Flags (1 byte) - Indicates flags to be used in the key
298 exchange. Several flags can be set at once by ORing the
299 flags together. The following flags are reserved for this
304 In this case the field is ignored.
308 If set the receiver of the payload does not reply to
313 Perfect Forward Secrecy (PFS) to be used in the
314 key exchange protocol. If not set, re-keying
315 is performed using the old key. See the [SILC1]
316 for more information on this issue. When PFS is
317 used, re-keying and creating new keys for any
318 particular purpose MUST cause new key exchange.
319 In this key exchange only the Key Exchange Payload
320 is sent and the Key Exchange Start Payload MUST
321 NOT be sent. When doing PFS the Key Exchange
322 Payloads are encrypted with the old keys.
324 Mutual Authentication 0x04
326 Both of the parties will perform authentication
327 by providing signed data for the other party to
328 verify. By default, only responder will provide
329 the signature data. If this is set then the
330 initiator must also provide it. Initiator MAY
331 set this but also responder MAY set this even if
332 initiator did not set it.
334 Rest of the flags are reserved for the future and
337 o Payload Length (2 bytes) - Length of the entire Key Exchange
338 Start payload, not including any other field.
340 o Cookie (16 bytes) - Cookie that randomize this payload so
341 that each of the party cannot determine the payload before
342 hand. This field MUST be present.
344 o Version String Length (2 bytes) - The length of the Version
345 String field, not including any other field.
347 o Version String (variable length) - Indicates the version of
348 the sender of this payload. Initiator sets this when sending
349 the payload and responder sets this when it replies by sending
350 this payload. See [SILC1] for definition of the version
351 string format. This field MUST be present and include valid
354 o Key Exchange Grp Length (2 bytes) - The length of the
355 key exchange group list, not including any other field.
357 o Key Exchange Group (variable length) - The list of
358 key exchange groups. See the section 2.4 SILC Key Exchange
359 Groups for definitions of these groups. This field MUST
362 o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms
363 list, not including any other field.
365 o PKCS Algorithms (variable length) - The list of PKCS
366 algorithms. This field MUST be present.
368 o Encryption Alg Length (2 bytes) - The length of the encryption
369 algorithms list, not including any other field.
371 o Encryption Algorithms (variable length) - The list of
372 encryption algorithms. This field MUST be present.
374 o Hash Alg Length (2 bytes) - The length of the Hash algorithm
375 list, not including any other field.
377 o Hash Algorithms (variable length) - The list of Hash
378 algorithms. The hash algorithms are mainly used in the
379 SKE protocol. This field MUST be present.
381 o HMAC Length (2 bytes) - The length of the HMAC list, not
382 including any other field.
384 o HMACs (variable length) - The list of HMACs. The HMAC's
385 are used to compute the Message Authentication Codes (MAC)
386 of the SILC packets. This field MUST be present.
388 o Compression Alg Length (2 bytes) - The length of the
389 compression algorithms list, not including any other field.
391 o Compression Algorithms (variable length) - The list of
392 compression algorithms. This field MAY be omitted.
397 2.1.2 Key Exchange Payload
399 Key Exchange payload is used to deliver the public key (or certificate),
400 the computed Diffie-Hellman public value and possibly signature data
401 from one party to the other. When initiator is using this payload
402 and the Mutual Authentication flag is not set then the initiator MUST
403 NOT provide the signature data. If the flag is set then the initiator
404 MUST provide the signature data so that the responder can verify it.
406 The Mutual Authentication flag is usually used when a separate
407 authentication protocol will not be executed for the initiator of the
408 protocol. This is case for example when the SKE is performed between
409 two SILC clients. In normal case, where client is connecting to a
410 server, or server is connecting to a router the Mutual Authentication
411 flag may be omitted. However, if the connection authentication protocol
412 for the connecting entity is not based on public key authentication (it
413 is based on passphrase) then the Mutual Authentication flag SHOULD be
414 enabled. This way the connecting entity has to provide proof of
415 possession of the private key for the public key it will provide in
416 SILC Key Exchange protocol.
418 When performing re-key with PFS selected this is the only payload that
419 is sent in the SKE protocol. The Key Exchange Start Payload MUST NOT
420 be sent at all. However, this payload does not have all the fields
421 present. In the re-key with PFS the public key and a possible signature
422 data SHOULD NOT be present. If they are present they MUST be ignored.
423 The only field that is present is the Public Data that is used to create
424 the new key material. In the re-key the Mutual Authentication flag, that
425 may be set in the initial negotiation, MUST also be ignored.
427 This payload is sent inside SILC_PACKET_KEY_EXCHANGE_1 and inside
428 SILC_PACKET_KEY_EXCHANGE_2 packet types. The initiator uses the
429 SILC_PACKET_KEY_EXCHANGE_1 and the responder the latter.
431 The following diagram represent the Key Exchange Payload.
437 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
438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
439 | Public Key Length | Public Key Type |
440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
442 ~ Public Key of the party (or certificate) ~
444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
445 | Public Data Length | |
446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
451 | Signature Length | |
452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
460 Figure 2: Key Exchange Payload
464 o Public Key Length (2 bytes) - The length of the Public Key
465 (or certificate) field, not including any other field.
467 o Public Key Type (2 bytes) - The public key (or certificate)
468 type. This field indicates the type of the public key in
469 the packet. Following types are defined:
471 1 SILC style public key (mandatory)
472 2 SSH2 style public key (optional)
473 3 X.509 Version 3 certificate (optional)
474 4 OpenPGP certificate (optional)
475 5 SPKI certificate (optional)
477 The only required type to support is type number 1. See
478 [SILC1] for the SILC public key specification. See
479 SSH public key specification in [SSH-TRANS]. See X.509v3
480 certificate specification in [PKIX-Part1]. See OpenPGP
481 certificate specification in [PGP]. See SPKI certificate
482 specification in [SPKI]. If this field includes zero (0)
483 or unsupported type number the protocol MUST be aborted
484 sending SILC_PACKET_FAILURE message and the connection SHOULD
485 be closed immediately.
487 o Public Key (or certificate) (variable length) - The
488 public key or certificate of the party. This public key
489 is used to verify the digital signature. The public key
490 or certificate in this field is encoded in the manner as
491 defined in their respective definitions; see previous field.
493 o Public Data Length (2 bytes) - The length of the Public Data
494 field, not including any other field.
496 o Public Data (variable length) - The public data to be
497 sent to the receiver (Diffie-Hellman public values). See
498 section 2.2 Key Exchange Procedure for detailed description
499 how this field is computed. This value is binary encoded.
501 o Signature Length (2 bytes) - The length of the signature,
502 not including any other field.
504 o Signature Data (variable length) - The signature signed
505 by the sender. The receiver of this signature MUST
506 verify it. The verification is done using the sender's
507 public key. See section 2.2 Key Exchange Procedure for
508 detailed description how to produce the signature. If
509 the Mutual Authentication flag is not set then initiator
510 MUST NOT provide this field and the Signature Length field
511 MUST be set to zero (0) value. If the flag is set then
512 also the initiator MUST provide this field. The responder
513 MUST always provide this field.
518 2.2 Key Exchange Procedure
520 The key exchange begins by sending SILC_PACKET_KEY_EXCHANGE packet with
521 Key Exchange Start Payload to select the security properties to be used
522 in the key exchange and later in the communication.
524 After Key Exchange Start Payload has been processed by both of the
525 parties the protocol proceeds as follows:
528 Setup: p is a large and public safe prime. This is one of the
529 Diffie Hellman groups. q is order of subgroup (largest
530 prime factor of p). g is a generator and is defined
531 along with the Diffie Hellman group.
533 1. Initiator generates a random number x, where 1 < x < q,
534 and computes e = g ^ x mod p. The result e is then
535 encoded into Key Exchange Payload, with the public key
536 (or certificate) and sent to the responder.
538 If the Mutual Authentication flag is set then initiator
539 MUST also produce signature data SIGN_i which the responder
540 will verify. The initiator MUST compute a hash value
541 HASH_i = hash(Initiator's Key Exchange Start Payload |
542 public key (or certificate) | e). It then signs the HASH_i
543 value with its private key resulting a signature SIGN_i.
545 2. Responder generates a random number y, where 1 < y < q,
546 and computes f = g ^ y mod p. It then computes the
547 shared secret KEY = e ^ y mod p, and, a hash value
548 HASH = hash(Initiator's Key Exchange Start Payload |
549 public key (or certificate) | Initiator's public key
550 (or certificate) | e | f | KEY). It then signs
551 the HASH value with its private key resulting a signature
554 It then encodes its public key (or certificate), f and
555 SIGN into Key Exchange Payload and sends it to the
558 If the Mutual Authentication flag is set then the responder
559 SHOULD verify that the public key provided in the payload
560 is authentic, or if certificates are used it verifies the
561 certificate. The responder MAY accept the public key without
562 verifying it, however, doing so may result to insecure key
563 exchange (accepting the public key without verifying may be
564 desirable for practical reasons on many environments. For
565 long term use this is never desirable, in which case
566 certificates would be the preferred method to use). It then
567 computes the HASH_i value the same way initiator did in the
568 phase 1. It then verifies the signature SIGN_i from the
569 payload with the hash value HASH_i using the received public
572 3. Initiator verifies that the public key provided in
573 the payload is authentic, or if certificates are used
574 it verifies the certificate. The initiator MAY accept
575 the public key without verifying it, however, doing
576 so may result to insecure key exchange (accepting the
577 public key without verifying may be desirable for
578 practical reasons on many environments. For long term
579 use this is never desirable, in which case certificates
580 would be the preferred method to use).
582 Initiator then computes the shared secret KEY =
583 f ^ x mod p, and, a hash value HASH in the same way as
584 responder did in phase 2. It then verifies the
585 signature SIGN from the payload with the hash value
586 HASH using the received public key.
589 If any of these phases is to fail the SILC_PACKET_FAILURE MUST be sent
590 to indicate that the key exchange protocol has failed, and the connection
591 SHOULD be closed immediately. Any other packets MUST NOT be sent or
592 accepted during the key exchange except the SILC_PACKET_KEY_EXCHANGE_*,
593 SILC_PACKET_FAILURE and SILC_PACKET_SUCCESS packets.
595 The result of this protocol is a shared secret key material KEY and
596 a hash value HASH. The key material itself is not fit to be used as
597 a key, it needs to be processed further to derive the actual keys to be
598 used. The key material is also used to produce other security parameters
599 later used in the communication. See section 2.3 Processing the Key
600 Material for detailed description how to process the key material.
602 If the Mutual Authentication flag was set the protocol produces also
603 a hash value HASH_i. This value, however, must be discarded.
605 After the keys are processed the protocol is ended by sending the
606 SILC_PACKET_SUCCESS packet. Both entities send this packet to
607 each other. After this both parties will start using the new keys.
611 2.3 Processing the Key Material
613 Key Exchange protocol produces secret shared key material KEY. This
614 key material is used to derive the actual keys used in the encryption
615 of the communication channel. The key material is also used to derive
616 other security parameters used in the communication. Key Exchange
617 protocol produces a hash value HASH as well.
619 The keys MUST be derived from the key material as follows:
622 Sending Initial Vector (IV) = hash(0x0 | KEY | HASH)
623 Receiving Initial Vector (IV) = hash(0x1 | KEY | HASH)
624 Sending Encryption Key = hash(0x2 | KEY | HASH)
625 Receiving Encryption Key = hash(0x3 | KEY | HASH)
626 Sending HMAC Key = hash(0x4 | KEY | HASH)
627 Receiving HMAC Key = hash(0x5 | KEY | HASH)
631 The Initial Vector (IV) is used in the encryption when doing for
632 example CBC mode. As many bytes as needed are taken from the start of
633 the hash output for IV. Sending IV is for sending key and receiving IV
634 is for receiving key. For receiving party, the receiving IV is actually
635 sender's sending IV, and, the sending IV is actually sender's receiving
636 IV. Initiator uses IV's as they are (sending IV for sending and
637 receiving IV for receiving).
639 The Encryption Keys are derived as well from the hash(). If the hash()
640 output is too short for the encryption algorithm more key material MUST
641 be produced in the following manner:
644 K1 = hash(0x2 | KEY | HASH)
645 K2 = hash(KEY | HASH | K1)
646 K3 = hash(KEY | HASH | K1 | K2) ...
648 Sending Encryption Key = K1 | K2 | K3 ...
651 K1 = hash(0x3 | KEY | HASH)
652 K2 = hash(KEY | HASH | K1)
653 K3 = hash(KEY | HASH | K1 | K2) ...
655 Receiving Encryption Key = K1 | K2 | K3 ...
659 The key is distributed by hashing the previous hash with the original
660 key material. The final key is a concatenation of the hash values.
661 For Receiving Encryption Key the procedure is equivalent. Sending key
662 is used only for encrypting data to be sent. The receiving key is used
663 only to decrypt received data. For receiving party, the receive key is
664 actually sender's sending key, and, the sending key is actually sender's
665 receiving key. Initiator uses generated keys as they are (sending key
666 for sending and receiving key for receiving).
668 The HMAC keys are used to create MAC values to packets in the
669 communication channel. As many bytes as needed are taken from the start
670 of the hash output to generate the MAC keys.
672 These procedures are performed by all parties of the key exchange
673 protocol. This MUST be done before the protocol has been ended by
674 sending the SILC_PACKET_SUCCESS packet.
676 This same procedure is used in the SILC in some other circumstances
677 as well. Any changes to this procedure is mentioned separately when
678 this procedure is needed. See the [SILC1] and the [SILC2] for these
683 2.4 SILC Key Exchange Groups
685 The Following groups may be used in the SILC Key Exchange protocol.
686 The first group diffie-hellman-group1 is REQUIRED, other groups MAY be
687 negotiated to be used in the connection with Key Exchange Start Payload
688 and SILC_PACKET_KEY_EXCHANGE packet. However, the first group MUST be
689 proposed in the Key Exchange Start Payload regardless of any other
690 requested group (however, it does not have to be the first in the list).
694 2.4.1 diffie-hellman-group1
696 The length of this group is 1024 bits. This is REQUIRED group.
697 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
702 179769313486231590770839156793787453197860296048756011706444
703 423684197180216158519368947833795864925541502180565485980503
704 646440548199239100050792877003355816639229553136239076508735
705 759914822574862575007425302077447712589550957937778424442426
706 617334727629299387668709205606050270810842907692932019128194
710 Its hexadecimal value is
713 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
714 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
715 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
716 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
717 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
722 The generator used with this prime is g = 2. The group order q is
725 This group was taken from the OAKLEY specification.
729 2.4.2 diffie-hellman-group2
731 The length of this group is 1536 bits. This is OPTIONAL group.
732 The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
740 241031242692103258855207602219756607485695054850245994265411
741 694195810883168261222889009385826134161467322714147790401219
742 650364895705058263194273070680500922306273474534107340669624
743 601458936165977404102716924945320037872943417032584377865919
744 814376319377685986952408894019557734611984354530154704374720
745 774996976375008430892633929555996888245787241299381012913029
746 459299994792636526405928464720973038494721168143446471443848
747 8520940127459844288859336526896320919633919
750 Its hexadecimal value is
753 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
754 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
755 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
756 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
757 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
758 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
759 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
760 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
763 The generator used with this prime is g = 2. The group order q is
766 This group was taken from the OAKLEY specification.
770 2.5 Key Exchange Status Types
772 This section defines all key exchange protocol status types that may
773 be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
774 to indicate the status of the protocol. Implementations may map the
775 status types to human readable error message. All types except the
776 SILC_SKE_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
777 The length of status is 32 bits (4 bytes). The following status types
783 Protocol were executed successfully.
786 1 SILC_SKE_STATUS_ERROR
788 Unknown error occurred. No specific error type is defined.
791 2 SILC_SKE_STATUS_BAD_PAYLOAD
793 Provided KE payload were malformed or included bad fields.
796 3 SILC_SKE_STATUS_UNSUPPORTED_GROUP
798 None of the provided groups were supported.
801 4 SILC_SKE_STATUS_UNSUPPORTED_CIPHER
803 None of the provided ciphers were supported.
806 5 SILC_SKE_STATUS_UNSUPPORTED_PKCS
808 None of the provided public key algorithms were supported.
811 6 SILC_SKE_STATUS_UNSUPPORTED_HASH_FUNCTION
813 None of the provided hash functions were supported.
816 7 SILC_SKE_STATUS_UNSUPPORTED_HMAC
818 None of the provided HMACs were supported.
821 8 SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY
823 Provided public key type is not supported.
826 9 SILC_SKE_STATUS_INCORRECT_SIGNATURE
828 Provided signature was incorrect.
831 10 SILC_SKE_STATUS_BAD_VERSION
833 Provided version string was not acceptable.
836 11 SILC_SKE_STATUS_INVALID_COOKIE
838 The cookie in the Key Exchange Start Payload was malformed,
839 because responder modified the cookie.
844 3 SILC Connection Authentication Protocol
846 Purpose of Connection Authentication protocol is to authenticate the
847 connecting party with server. Usually connecting party is client but
848 server may connect to router server as well. Its other purpose is to
849 provide information for the server about which type of connection this
850 is. The type defines whether this is client, server or router
851 connection. Server uses this information to create the ID for the
854 After the authentication protocol has been successfully completed
855 SILC_PACKET_NEW_ID must be sent to the connecting client by the server.
856 See the [SILC1] for the details of the connecting procedure.
858 Server MUST verify the authentication data received and if it is to fail
859 the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
860 If everything checks out fine the protocol is ended by server by sending
861 SILC_PACKET_SUCCESS packet.
863 The protocol is executed after the SILC Key Exchange protocol. It MUST
864 NOT be executed in any other time. As it is performed after key exchange
865 protocol all traffic in the connection authentication protocol is
866 encrypted with the exchanged keys.
868 The protocol MUST be started by the connecting party by sending the
869 SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload,
870 described in the next section. This payload MUST include the
871 authentication data. The authentication data is set according
872 authentication method that MUST be known by both parties. If connecting
873 party does not know what is the mandatory authentication method it MAY
874 request it from the server by sending SILC_PACKET_CONNECTION_AUTH_REQUEST
875 packet. This packet is not part of this protocol and is described in
876 section Connection Auth Request Payload in [SILC2]. However, if
877 connecting party already knows the mandatory authentication method
878 sending the request is not necessary.
880 See [SILC1] and section Connection Auth Request Payload in [SILC2] also
881 for the list of different authentication methods. Authentication method
882 MAY also be NONE, in which case the server does not require
883 authentication at all. However, in this case the protocol still MUST be
884 executed; the authentication data just is empty indicating no
885 authentication is required.
887 If authentication method is passphrase the authentication data is
888 plaintext passphrase. As the payload is entirely encrypted it is safe
889 to have plaintext passphrase. It is also provided as plaintext passphrase
890 because the receiver may need to pass the entire passphrase into a
891 passphrase checker, and hash digest of the passphrase would prevent this.
892 See the section 3.2.1 Passphrase Authentication for more information.
894 If authentication method is public key authentication the authentication
895 data is a signature of the hash value of hash HASH plus Key Exchange
896 Start Payload, established by the SILC Key Exchange protocol. This
897 signature MUST then be verified by the server. See the section 3.2.2
898 Public Key Authentication for more information.
900 The connecting client of this protocol MUST wait after successful execution
901 of this protocol for the SILC_PACKET_NEW_ID packet where it will receive
902 the ID it will be using in the SILC network. The connecting client cannot
903 start normal SILC session (sending messages or commands) until it has
904 received its ID. The ID's are always created by the server except
905 for server to router connection where servers create their own ID's.
909 3.1 Connection Auth Payload
911 Client sends this payload to authenticate itself to the server. Server
912 connecting to another server also sends this payload. Server receiving
913 this payload MUST verify all the data in it and if something is to fail
914 the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
916 The payload may only be sent with SILC_PACKET_CONNECTION_AUTH packet.
917 It MUST NOT be sent in any other packet type. The following diagram
918 represent the Connection Auth Payload.
924 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
925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
926 | Payload Length | Connection Type |
927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
929 ~ Authentication Data ~
931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
935 Figure 3: Connection Auth Payload
939 o Payload Length (2 bytes) - Length of the entire Connection
942 o Connection Type (2 bytes) - Indicates the type of the
943 connection. See section Connection Auth Request Payload
944 in [SILC2] for the list of connection types. This field MUST
945 include valid connection type or the packet MUST be discarded
946 and authentication MUST be failed.
948 o Authentication Data (variable length) - The actual
949 authentication data. Contents of this depends on the
950 authentication method known by both parties. If no
951 authentication is required this field does not exist.
958 3.2 Connection Authentication Types
960 SILC supports two authentication types to be used in the connection
961 authentication protocol; passphrase or public key based authentication.
962 The following sections defines the authentication methods. See [SILC2]
963 for defined numerical authentication method types.
967 3.2.1 Passphrase Authentication
969 Passphrase authentication or pre-shared-key based authentication is
970 simply an authentication where the party that wants to authenticate
971 itself to the other end sends the passphrase that is required by
972 the other end, for example server. The plaintext passphrase is put
973 to the payload, that is then encrypted. The plaintext passphrase
974 MUST be in UTF-8 [RFC2279] encoding. If the passphrase is in the
975 sender's system in some other encoding it MUST be UTF-8 encoded
976 before transmitted. The receiver MAY change the encoding of the
977 passphrase to its system's default character encoding before verifying
980 If the passphrase matches with the one in the server's end the
981 authentication is successful. Otherwise SILC_PACKET_FAILURE MUST be
982 sent to the sender and the protocol execution fails.
984 This is REQUIRED authentication method to be supported by all SILC
987 When password authentication is used it is RECOMMENDED that maximum
988 amount of padding is applied to the SILC packet. This way it is not
989 possible to approximate the length of the password from the encrypted
995 3.2.2 Public Key Authentication
997 Public key authentication may be used if passphrase based authentication
998 is not desired. The public key authentication works by sending a
999 signature as authentication data to the other end, say, server. The
1000 server MUST then verify the signature by the public key of the sender,
1001 which the server has received earlier in SKE protocol.
1003 The signature is computed using the private key of the sender by signing
1004 the HASH value provided by the SKE protocol previously, and the Key
1005 Exchange Start Payload from SKE protocol that was sent to the server.
1006 These are concatenated and hash function is used to compute a hash value
1007 which is then signed.
1009 auth_hash = hash(HASH | Key Exchange Start Payload);
1010 signature = sign(auth_hash);
1012 The hash() function used to compute the value is the hash function
1013 negotiated in the SKE protocol. The server MUST verify the data, thus
1014 it must keep the HASH and the Key Exchange Start Payload saved during
1015 SKE and authentication protocols.
1017 If the verified signature matches the sent signature, the authentication
1018 were successful and SILC_PACKET_SUCCESS is sent. If it failed the
1019 protocol execution is stopped and SILC_PACKET_FAILURE is sent.
1021 This is REQUIRED authentication method to be supported by all SILC
1026 3.3 Connection Authentication Status Types
1028 This section defines all connection authentication status types that
1029 may be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
1030 to indicate the status of the protocol. Implementations may map the
1031 status types to human readable error message. All types except the
1032 SILC_AUTH_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
1033 The length of status is 32 bits (4 bytes). The following status types
1038 Protocol was executed successfully.
1043 Authentication failed.
1049 4 Security Considerations
1051 Security is central to the design of this protocol, and these security
1052 considerations permeate the specification. Common security considerations
1053 such as keeping private keys truly private and using adequate lengths for
1054 symmetric and asymmetric keys must be followed in order to maintain the
1055 security of this protocol.
1062 [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
1063 Protocol Specification", Internet Draft, May 2002.
1065 [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
1068 [SILC4] Riikonen, P., "SILC Commands", Internet Draft, May 2002.
1070 [IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
1073 [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
1076 [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
1079 [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
1082 [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
1085 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
1088 [PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
1091 [SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
1094 [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
1095 Infrastructure, Certificate and CRL Profile", RFC 2459,
1098 [Schneier] Schneier, B., "Applied Cryptography Second Edition",
1099 John Wiley & Sons, New York, NY, 1996.
1101 [Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
1104 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
1105 RFC 2412, November 1998.
1107 [ISAKMP] Maughan D., et al, "Internet Security Association and
1108 Key Management Protocol (ISAKMP)", RFC 2408, November
1111 [IKE] Harkins D., and Carrel D., "The Internet Key Exchange
1112 (IKE)", RFC 2409, November 1998.
1114 [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
1115 Authentication", RFC 2104, February 1997.
1117 [PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
1118 Specifications, Version 2.0", RFC 2437, October 1998.
1120 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
1121 Requirement Levels", BCP 14, RFC 2119, March 1997.
1123 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
1124 10646", RFC 2279, January 1998.
1132 Snellmaninkatu 34 A 15
1136 EMail: priikone@iki.fi
1138 This Internet-Draft expires 15 November 2002