8 .ds RF FORMFEED[Page %]
17 Network Working Group P. Riikonen
19 draft-riikonen-silc-ke-auth-02.txt XXXXXXXXXXXXXX
25 SILC Key Exchange and Authentication Protocols
26 <draft-riikonen-silc-ke-auth-02.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 2 SILC Key Exchange Protocol .................................... 3
78 2.1 Key Exchange Payloads ..................................... 3
79 2.1.1 Key Exchange Start Payload .......................... 4
80 2.1.2 Key Exchange Payload ................................ 7
81 2.2 Key Exchange Procedure .................................... 10
82 2.3 Processing the Key Material ............................... 12
83 2.4 SILC Key Exchange Groups .................................. 13
84 2.4.1 diffie-hellman-group1 ............................... 13
85 2.4.2 diffie-hellman-group2 ............................... 14
86 2.5 Key Exchange Status Types ................................. 14
87 3 SILC Connection Authentication Protocol ....................... 16
88 3.1 Connection Auth Payload ................................... 17
89 3.2 Connection Authentication Types ........................... 18
90 3.2.1 Passphrase Authentication ........................... 18
91 3.2.2 Public Key Authentication ........................... 18
92 3.3 Connection Authentication Status Types .................... 19
93 4 Security Considerations ....................................... 19
94 5 References .................................................... 19
95 6 Author's Address .............................................. 20
102 Figure 1: Key Exchange Start Payload
103 Figure 2: Key Exchange Payload
104 Figure 3: Connection Auth Payload
110 This memo describes two protocols used in the Secure Internet Live
111 Conferencing (SILC) protocol specified in the Secure Internet Live
112 Conferencing, Protocol Specification Internet-Draft [SILC1]. The
113 SILC Key Exchange (SKE) protocol provides secure key exchange between
114 two parties resulting into shared secret key material. The protocol
115 is based on Diffie Hellman key exchange algorithm and its functionality
116 is derived from several key exchange protocols. SKE uses best parts
117 of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol
118 and the OAKLEY Key Determination protocol.
120 The SILC Connection Authentication protocol provides user level
121 authentication used when creating connections in SILC network. The
122 protocol is transparent to the authentication data which means that it
123 can be used to authenticate the user with, for example, passphrase
124 (pre-shared- secret) or public key (and certificate).
126 The basis of secure SILC session requires strong and secure key exchange
127 protocol and authentication. The authentication protocol is entirely
128 secured and no authentication data is ever sent in the network without
129 encrypting and authenticating it first. Thus, authentication protocol
130 may be used only after the key exchange protocol has been successfully
133 This document refers constantly to other SILC protocol specification
134 Internet Drafts that are a must read for those who wants to understand
135 the function of these protocols. The most important references are
136 the Secure Internet Live Conferencing, Protocol Specification [SILC1]
137 and SILC Packet Protocol [SILC2] Internet Drafts.
139 The protocol is intended to be used with the SILC protocol thus it
140 does not define own framework that could be used. The framework is
141 provided by the SILC protocol.
145 2 SILC Key Exchange Protocol
147 SILC Key Exchange Protocol (SKE) is used to exchange shared secret
148 between connecting entities. The result of this protocol is a key
149 material used to secure the communication channel. The protocol uses
150 Diffie-Hellman key exchange algorithm and its functionality is derived
151 from several key exchange protocols. SKE uses best parts of the SSH2
152 Key Exchange protocol, Station-To-Station (STS) protocol and the OAKLEY
153 Key Determination protocol. The protocol does not claim any conformance
154 to any of these protocols, they were merely used as a reference when
155 designing this protocol.
157 The purpose of SILC Key Exchange protocol is to create session keys to
158 be used in current SILC session. The keys are valid only for some period
159 of time (usually an hour) or at most until the session ends. These keys
160 are used to protect packets like commands, command replies and other
161 communication between two entities. If connection is server to server
162 connection, the keys are used to protect all traffic between those
163 servers. In client connections usually all the packets are protected
164 with this key except channel messages; channels has their own keys and
165 they are not exchanged with this protocol.
167 The Diffie-Hellman implementation used in the SILC should be compliant
172 2.1 Key Exchange Payloads
174 During the key exchange procedure public data is sent between initiator
175 and responder. This data is later used in the key exchange procedure.
176 There are several payloads used in the key exchange. As for all SILC
177 packets, SILC Packet Header, described in [SILC2], is at the start of all
178 packets, the same is done with these payloads as well. All fields in
179 all payloads are always in MSB (most significant byte first) order.
180 Following descriptions of these payloads.
184 2.1.1 Key Exchange Start Payload
186 Key exchange between two entities always begins with the
187 SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
188 Initiator sends the Key Exchange Start Payload to the responder filled with
189 all security properties it supports. The responders then checks whether
190 it supports the security properties.
192 It then sends a Key Exchange Start Payload to the initiator filled with
193 security properties it selected from the original payload. The payload sent
194 by responder must include only one chosen property per list.
196 The Key Exchange Start Payload is used to tell connecting entities what
197 security properties and algorithms should be used in the communication.
198 If perfect forward secrecy (PFS) is not desired (PFS is undefined by
199 default) Key Exchange Start Payload is sent only once per session, thus,
200 for example, re-keying will not cause sending of a new payload. If PFS
201 is desired, re-keying will always cause new key exchange thus causes
202 sending of a new Key Exchange Start Payload.
204 When performing first key exchange this payload is never encrypted, as
205 there are no existing keys to encrypt it with. If performing re-keying
206 (PFS was selected) this payload is encrypted with the existing key and
207 encryption algorithm.
209 A cookie is also sent in this payload. A cookie is used to uniform the
210 payload so that none of the key exchange parties can determine this
211 payload before hand. The cookie must be returned to the original sender
214 Following diagram represents the Key Exchange Start Payload. The lists
215 mentioned below are always comma (`,') separated and the list must
216 not include spaces (` ').
228 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
229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
230 | RESERVED | Flags | Payload Length |
231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
240 | Version String Length | |
241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
246 | Key Exchange Grp Length | |
247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
249 ~ Key Exchange Groups ~
251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
252 | PKCS Alg Length | |
253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
258 | Encryption Alg Length | |
259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
261 ~ Encryption Algorithms ~
263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
264 | Hash Alg Length | |
265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
276 | Compression Alg Length | |
277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
279 ~ Compression Algorithms ~
281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
285 Figure 1: Key Exchange Start Payload
290 o RESERVED (1 byte) - Reserved field. Sender fills this with
293 o Flags (1 byte) - Indicates flags to be used in the key
294 exchange. Several flags can be set at once by ORing the
295 flags together. Following flags are reserved for this field.
299 In this case the field is ignored.
303 If set the receiver of the payload does not reply to
308 Perfect Forward Secrecy (PFS) to be used in the
309 key exchange protocol. If not set, re-keying
310 is performed using the old key. When PFS is used,
311 re-keying and creating new keys for any particular
312 purpose will cause new key exchange.
314 Rest of the flags are reserved for the future and
317 Mutual Authentication 0x04
319 Both of the parties will perform authenetication
320 by providing signed data for the other party to
321 verify. By default, only responder will provide
322 the signature data. If this is set then the
323 inititator must also provide it. Initiator may
324 set this but also responder may set this even if
325 initiator did not set it.
327 o Payload Length (2 bytes) - Length of the entire Key Exchange
328 Start payload, not including any other field.
330 o Cookie (16 bytes) - Cookie that uniforms this payload so
331 that each of the party cannot determine the payload before
334 o Version String Length (2 bytes) - The length of the Version
335 String field, not including any other field.
337 o Version String (variable length) - Indicates the version of
338 the sender of this payload. Initiator sets this when sending
339 the payload and responder sets this when it replies by sending
340 this payload. See [SILC1] for definition of the version
343 o Key Exchange Grp Length (2 bytes) - The length of the
344 key exchange group list, not including any other field.
346 o Key Exchange Group (variable length) - The list of
347 key exchange groups. See the section 2.1.2 SILC Key Exchange
348 Groups for definitions of these groups.
350 o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms
351 list, not including any other field.
353 o PKCS Algorithms (variable length) - The list of PKCS
356 o Encryption Alg Length (2 bytes) - The length of the encryption
357 algorithms list, not including any other field.
359 o Encryption Algorithms (variable length) - The list of
360 encryption algorithms.
362 o Hash Alg Length (2 bytes) - The length of the Hash algorithm
363 list, not including any other field.
365 o Hash Algorithms (variable length) - The list of Hash
366 algorithms. The hash algorithms are mainly used in the
369 o HMAC Length (2 bytes) - The length of the HMAC list, not
370 including any other field.
372 o HMACs (variable length) - The list of HMACs. The HMAC's
373 are used to compute the Message Authentication Codes (MAC)
376 o Compression Alg Length (2 bytes) - The length of the
377 compression algorithms list, not including any other field.
379 o Compression Algorithms (variable length) - The list of
380 compression algorithms.
385 2.1.2 Key Exchange Payload
387 Key Exchange payload is used to deliver the public key (or certificate),
388 the computed Diffie-Hellman public value and possibly signature data
389 from one party to the other. When initiator is using this payload
390 and the Mutual Authentication flag is not set then the initiator must
391 not provide the signature data. If the flag is set then the initiator
392 must provide the signature data so that the responder may verify it.
394 The Mutual Authentication flag is usually used only if a separate
395 authentication protocol will not be executed for the initiator of the
396 prtocool. This is case for example when the SKE is performed between
397 two SILC clients. In normal case, where client is connecting to the
398 server or server is connecting to the router the Mutual Authentication
399 flag is not necessary.
401 This payload is sent inside SILC_PACKET_KEY_EXCHANGE_1 and inside
402 SILC_PACKET_KEY_EXCHANGE_2 packet types. The initiator uses the
403 SILC_PACKET_KEY_EXCHANGE_1 and the responder the latter.
405 The following diagram represent the Key Exchange 1 Payload.
411 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
412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
413 | Public Key Length | Public Key Type |
414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
416 ~ Public Key of the party (or certificate) ~
418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
419 | Public Data Length | |
420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
425 | Signature Length | |
426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
434 Figure 2: Key Exchange Payload
438 o Public Key Length (2 bytes) - The length of the Public Key
439 (or certificate) field, not including any other field.
441 o Public Key Type (2 bytes) - The public key (or certificate)
442 type. This field indicates the type of the public key in
443 the packet. Following types are defined:
445 1 SILC style public key (mandatory)
446 2 SSH2 style public key (optional)
447 3 X.509 Version 3 certificate (optional)
448 4 OpenPGP certificate (optional)
449 5 SPKI certificate (optional)
451 The only required type to support is type number 1. See
452 [SILC1] for the SILC public key specification. See
453 SSH public key specification in [SSH-TRANS]. See X.509v3
454 certificate specification in [PKIX-Part1]. See OpenPGP
455 certificate specification in [PGP]. See SPKI certificate
456 specification in [SPKI]. If this field includes zero (0)
457 or unsupported type number the protocol must be aborted
458 sending SILC_PACKET_FAILURE message and the connection should
459 be closed immediately.
461 o Public Data Length (2 bytes) - The length of the Public Data
462 field, not including any other field.
464 o Public Data (variable length) - The public data to be
465 sent to the receiver. See section 2.2 Key Exchange
466 Procedure for detailed description how this field is
467 computed. This value is binary encoded.
469 o Signature Length (2 bytes) - The length of the signature,
470 not including any other field.
472 o Signature Data (variable length) - The signature signed
473 by the sender. The receiver of this signature must
474 verify it. The verification is done using the public
475 key received in this same payload. See section 2.2
476 Key Exchange Procedure for detailed description how
477 to produce the signature. If the Mutual Authentication
478 flag is not set then initiator must not provide this
479 field and the Signature Length field must be set to zero (0)
480 value. If the flag is set then also the initiator must
481 provide this field. The responder always provides this
487 2.2 Key Exchange Procedure
489 The key exchange begins by sending SILC_PACKET_KEY_EXCHANGE packet with
490 Key Exchange Start Payload to select the security properties to be used
491 in the key exchange and later in the communication.
493 After Key Exchange Start Payload has been processed by both of the
494 parties the protocol proceeds as follows:
497 Setup: p is a large and public safe prime. This is one of the
498 Diffie Hellman groups. q is order of subgroup (largest
499 prime factor of p). g is a generator and is defined
500 along with the Diffie Hellman group.
502 1. Initiator generates a random number x, where 1 < x < q,
503 and computes e = g ^ x mod p. The result e is then
504 encoded into Key Exchange Payload and sent to the
507 If the Mutual Authentication flag is set then initiator
508 must also produce signature data SIGN_i which the responder
509 will verify. The initiator must compute a hash value
510 HASH_i = hash(Key Exchange Start Payload | public key
511 (or certificate) | e). It then signs the HASH_i value with
512 its private key resulting a signature SIGN_i.
514 2. Responder generates a random number y, where 1 < y < q,
515 and computes f = g ^ y mod p. It then computes the
516 shared secret KEY = e ^ y mod p, and, a hash value
517 HASH = hash(Key Exchange Start Payload data | public
518 key (or certificate) | e | f | KEY). It then signs
519 the HASH value with its private key resulting a signature
522 It then encodes its public key (or certificate), f and
523 SIGN into Key Exchange Payload and sends it to the
526 If the Mutual Authentication flag is set then the responder
527 should verify that the public key provided in the payload
528 is authentic, or if certificates are used it verifies the
529 certificate. The responder may accept the public key without
530 verifying it, however, doing so may result to insecure key
531 exchange (accepting the public key without verifying may be
532 desirable for practical reasons on many environments. For
533 long term use this is never desirable, in which case
534 certificates would be the preferred method to use). It then
535 computes the HASH_i value the same way initiator did in the
536 phase 1. It then verifies the signature SIGN_i from the
537 payload with the hash value HASH_i using the received public
540 3. Initiator verifies that the public key provided in
541 the payload is authentic, or if certificates are used
542 it verifies the certificate. The initiator may accept
543 the public key without verifying it, however, doing
544 so may result to insecure key exchange (accepting the
545 public key without verifying may be desirable for
546 practical reasons on many environments. For long term
547 use this is never desirable, in which case certificates
548 would be the preferred method to use).
550 Initiator then computes the shared secret KEY =
551 f ^ x mod p, and, a hash value HASH in the same way as
552 responder did in phase 2. It then verifies the
553 signature SIGN from the payload with the hash value
554 HASH using the received public key.
557 If any of these phases is to fail SILC_PACKET_FAILURE is sent to
558 indicate that the key exchange protocol has failed, and the connection
559 should be closed immediately. Any other packets must not be sent or
560 accepted during the key exchange except the SILC_PACKET_KEY_EXCHANGE_*,
561 SILC_PACKET_FAILURE and SILC_PACKET_SUCCESS packets.
563 The result of this protocol is a shared secret key material KEY and
564 a hash value HASH. The key material itself is not fit to be used as
565 a key, it needs to be processed further to derive the actual keys to be
566 used. The key material is also used to produce other security parameters
567 later used in the communication. See section 2.3 Processing the Key
568 Material for detailed description how to process the key material.
570 If the Mutual Authentication flag was set the protocol produces also
571 a hash value HASH_i. This value, however, must be discarded.
573 After the keys are processed the protocol is ended by sending the
574 SILC_PACKET_SUCCESS packet. Both entities send this packet to
575 each other. After this both parties will start using the new keys.
581 2.3 Processing the Key Material
583 Key Exchange protocol produces secret shared key material KEY. This
584 key material is used to derive the actual keys used in the encryption
585 of the communication channel. The key material is also used to derive
586 other security parameters used in the communication. Key Exchange
587 protocol produces a hash value HASH as well.
589 Keys are derived from the key material as follows:
592 Sending Initial Vector (IV) = hash(0 | KEY | HASH)
593 Receiving Initial Vector (IV) = hash(1 | KEY | HASH)
594 Sending Encryption Key = hash(2 | KEY | HASH)
595 Receiving Encryption Key = hash(3 | KEY | HASH)
596 HMAC Key = hash(4 | KEY | HASH)
600 The Initial Vector (IV) is used in the encryption when doing for
601 example CBC mode. As many bytes as needed are taken from the start of
602 the hash output for IV. Sending IV is for sending key and receiving IV
603 is for receiving key. For receiving party, the receiving IV is actually
604 sender's sending IV, and, the sending IV is actually sender's receiving
605 IV. Initiator uses IV's as they are (sending IV for sending and
606 receiving IV for receiving).
608 The Encryption Keys are derived as well from the hash(). If the hash()
609 output is too short for the encryption algorithm more key material is
610 produced in following manner:
613 K1 = hash(2 | KEY | HASH)
615 K3 = hash(KEY | K1 | K2) ...
617 Sending Encryption Key = K1 | K2 | K3 ...
620 K1 = hash(3 | KEY | HASH)
622 K3 = hash(KEY | K1 | K2) ...
624 Receiving Encryption Key = K1 | K2 | K3 ...
628 The key is distributed by hashing the previous hash with the original
629 key material. The final key is a concatenation of the hash values.
630 For Receiving Encryption Key the procedure is equivalent. Sending key
631 is used only for encrypting data to be sent. The receiving key is used
632 only to decrypt received data. For receiving party, the receive key is
633 actually sender's sending key, and, the sending key is actually sender's
634 receiving key. Initiator uses generated keys as they are (sending key
635 for sending and receiving key for sending).
637 The HMAC key is used to create MAC values to packets in the communication
638 channel. As many bytes as needed are taken from the start of the hash
641 These procedures are performed by all parties of the key exchange
642 protocol. This must be done before the protocol has been ended by
643 sending the SILC_PACKET_SUCCESS packet.
647 2.4 SILC Key Exchange Groups
649 Following groups may be used in the SILC Key Exchange protocol. The
650 first group diffie-hellman-group1 is mandatory, other groups maybe
651 negotiated to be used in the connection with Key Exchange Start Payload
652 and SILC_PACKET_KEY_EXCHANGE packet. However, the first group must be
653 proposed in the Key Exchange Start Payload regardless of any other
654 requested group (however, it does not have to be the first on the list).
658 2.4.1 diffie-hellman-group1
660 The length of this group is 1024 bits. This is mandatory group.
661 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
666 179769313486231590770839156793787453197860296048756011706444
667 423684197180216158519368947833795864925541502180565485980503
668 646440548199239100050792877003355816639229553136239076508735
669 759914822574862575007425302077447712589550957937778424442426
670 617334727629299387668709205606050270810842907692932019128194
674 Its hexadecimal value is
677 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
678 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
679 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
680 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
681 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
686 The generator used with this prime is g = 2. The group order q is
689 This group was taken from the OAKLEY specification.
693 2.4.2 diffie-hellman-group2
695 The length of this group is 1536 bits. This is optional group.
696 The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
701 241031242692103258855207602219756607485695054850245994265411
702 694195810883168261222889009385826134161467322714147790401219
703 650364895705058263194273070680500922306273474534107340669624
704 601458936165977404102716924945320037872943417032584377865919
705 814376319377685986952408894019557734611984354530154704374720
706 774996976375008430892633929555996888245787241299381012913029
707 459299994792636526405928464720973038494721168143446471443848
708 8520940127459844288859336526896320919633919
711 Its hexadecimal value is
714 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
715 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
716 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
717 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
718 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
719 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
720 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
721 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
724 The generator used with this prime is g = 2. The group order q is
727 This group was taken from the OAKLEY specification.
731 2.5 Key Exchange Status Types
733 This section defines all key exchange protocol status types that may be
734 returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets to
735 indicate the status of the protocol. Implementations may map the
736 status types to human readable error message. All types except the
737 SILC_SKE_STATUS_OK type must be sent in SILC_PACKET_FAILURE packet.
738 The length of status is 32 bits (4 bytes). Following status types are
744 Protocol were executed successfully.
747 1 SILC_SKE_STATUS_ERROR
749 Unknown error occured. No specific error type is defined.
752 2 SILC_SKE_STATUS_BAD_PAYLOAD
754 Provided KE payload were malformed or included bad fields.
757 3 SILC_SKE_STATUS_UNSUPPORTED_GROUP
759 None of the provided groups were supported.
762 4 SILC_SKE_STATUS_UNSUPPORTED_CIPHER
764 None of the provided ciphers were supported.
767 5 SILC_SKE_STATUS_UNSUPPORTED_PKCS
769 None of the provided public key algorithms were supported.
772 6 SILC_SKE_STATUS_UNSUPPORTED_HASH_FUNCTION
774 None of the provided hash functions were supported.
777 7 SILC_SKE_STATUS_UNSUPPORTED_HMAC
779 None of the provided HMACs were supported.
782 8 SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY
784 Provided public key type is not supported.
787 9 SILC_SKE_STATUS_INCORRECT_SIGNATURE
789 Provided signature was incorrect.
792 10 SILC_SKE_STATUS_BAD_VERSION
794 Provided version string was not acceptable.
802 3 SILC Connection Authentication Protocol
804 Purpose of Connection Authentication protocol is to authenticate the
805 connecting party with server. Usually connecting party is client but
806 server may connect to server as well. Its other purpose is to provide
807 information for the server about which type of connection this is.
808 The type defines whether this is client, server or router connection.
809 Server uses this information to create the ID for the connection. After
810 the authentication protocol has been successfully completed
811 SILC_PACKET_NEW_ID must be sent to the connecting party by the server.
812 See section New ID Payload in [SILC2] for detailed description for this
815 Server must verify the authentication data received and if it is to fail
816 the authentication must be failed by sending SILC_PACKET_FAILURE packet.
817 If everything checks out fine the protocol is ended by server by sending
818 SILC_PACKET_SUCCESS packet.
820 The protocol is executed after the SILC Key Exchange protocol. It must
821 not be executed in any other time. As it is performed after key exchange
822 protocol all traffic in the connection authentication protocol is
823 encrypted with the exchanged keys.
825 The protocol is started by the connecting party by sending
826 SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload,
827 described in the next section. This payload must include the
828 authentication data. Authentication data is set according
829 authentication method that must be known by both parties. If connecting
830 party does not know what is the mandatory authentication method it may
831 request it from the server by sending SILC_PACKET_CONNECTION_AUTH_REQUEST
832 packet. This packet is not part of this protocol and is described in
833 section Connection Auth Request Payload in [SILC2]. However, if
834 connecting party already knows the mandatory authentication method
835 sending the request is not necessary.
837 See [SILC1] and section Connection Auth Request Payload in [SILC2] also
838 for the list of different authentication methods. Authentication method
839 may also be NONE, in which case the server does not require
840 authentication at all. However, in this case the protocol still must be
841 executed; the authentication data just is empty indicating no
842 authentication is required.
844 If authentication method is passphrase the authentication data is
845 plaintext passphrase. As the payload is entirely encrypted it is safe
846 to have plaintext passphrase. 3.2.1 Passphrase Authentication for
850 If authentication method is public key authentication the authentication
851 data is signature of the hash value HASH plus Key Exchange Start Payload,
852 established by the SILC Key Exchange protocol. This signature must then
853 be verified by the server. See section 3.2.2 Public Key Authentication
854 for more information.
856 The connecting party of this protocol must wait after successful execution
857 of this protocol for the SILC_PACKET_NEW_ID packet where it will receive
858 the ID it will be using in the SILC network. Connecting party cannot
859 start normal SILC session (sending messages or commands) until it has
860 received its ID. The ID's are always created by the server except
861 for server to server connection where servers create their own ID's.
866 3.1 Connection Auth Payload
868 Client sends this payload to authenticate itself to the server. Server
869 connecting to another server also sends this payload. Server receiving
870 this payload must verify all the data in it and if something is to fail
871 the authentication must be failed by sending SILC_PACKET_FAILURE packet.
873 The payload may only be sent with SILC_PACKET_CONNECTION_AUTH packet.
874 It must not be sent in any other packet type. Following diagram
875 represent the Connection Auth Payload.
881 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
882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
883 | Payload Length | Connection Type |
884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
886 ~ Authentication Data ~
888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
892 Figure 3: Connection Auth Payload
896 o Payload Length (2 bytes) - Length of the entire Connection
899 o Connection Type (2 bytes) - Indicates the type of the
900 connection. See section Connection Auth Request Payload
901 in [SILC2] for the list of connection types. This field must
902 include valid connection type or the packet must be discarded
903 and authentication must be failed.
905 o Authentication Data (variable length) - The actual
906 authentication data. Contents of this depends on the
907 authentication method known by both parties. If no
908 authentication is required this field does not exist.
913 3.2 Connection Authentication Types
915 SILC supports two authentication types to be used in the connection
916 authentication protocol; passphrase or public key based authentication.
917 Following sections defines the authentication methods. See [SILC2]
918 for defined numerical authentication method types.
922 3.2.1 Passphrase Authentication
924 Passphrase authentication or pre-shared-key base authentication is
925 simply an authentication where the party that wants to authenticate
926 itself to the other end sends the passphrase that is required by
927 the other end, for example server.
929 If the passphrase matches with the one in the server's end the
930 authentication is successful. Otherwise SILC_PACKET_FAILURE must be
931 sent to the sender and the protocol execution fails.
933 This is required authentication method to be supported by all SILC
938 3.2.2 Public Key Authentication
940 Public key authentication may be used if passphrase based authentication
941 is not desired. The public key authentication works by sending a
942 signature as authentication data to the other end, say, server. The
943 server must then verify the signature by the public key of the sender,
944 which the server has received earlier in SKE protocol.
946 The signature is computed using the private key of the sender by signing
947 the HASH value provided by the SKE protocol previously, and the Key
948 Exchange Start Payload from SKE protocol that was sent to the server.
949 The server must verify the data, thus it must keep the HASH and the
950 Key Exchange Start Payload saved during SKE and authentication protocols.
952 If the verified signature matches the sent signature, the authentication
953 were successful and SILC_PACKET_SUCCESS is sent. If it failed the protocol
954 execution is stopped and SILC_PACKET_FAILURE is sent.
956 This is required authentication method to be supported by all SILC
961 3.3 Connection Authentication Status Types
963 This section defines all connection authentication status types that
964 may be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
965 to indicate the status of the protocol. Implementations may map the
966 status types to human readable error message. All types except the
967 SILC_AUTH_STATUS_OK type must be sent in SILC_PACKET_FAILURE packet.
968 The length of status is 32 bits (4 bytes). Following status types are
973 Protocol was executed successfully.
978 Authentication failed.
982 4 Security Considerations
984 Security is central to the design of this protocol, and these security
985 considerations permeate the specification. Common security considerations
986 such as keeping private keys truly private and using adequate lengths for
987 symmetric and asymmetric keys must be followed in order to maintain the
988 security of this protocol.
994 [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
995 Protocol Specification", Internet Draft, June 2000.
997 [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
1000 [IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
1003 [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
1006 [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
1009 [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
1012 [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
1015 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
1018 [PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
1021 [SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
1024 [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
1025 Infrastructure, Certificate and CRL Profile", RFC 2459,
1028 [Schneier] Schneier, B., "Applied Cryptography Second Edition",
1029 John Wiley & Sons, New York, NY, 1996.
1031 [Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
1034 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
1035 RFC 2412, November 1998.
1037 [ISAKMP] Maughan D., et al, "Internet Security Association and
1038 Key Management Protocol (ISAKMP)", RFC 2408, November
1041 [IKE] Harkins D., and Carrel D., "The Internet Key Exchange
1042 (IKE)", RFC 2409, November 1998.
1044 [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
1045 Authentication", RFC 2104, February 1997.
1047 [PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
1048 Specifications, Version 2.0", RFC 2437, October 1998.
1060 EMail: priikone@poseidon.pspt.fi
1062 This Internet-Draft expires 6 Jun 2001