8 .ds RF FORMFEED[Page %]
17 Network Working Group P. Riikonen
19 draft-riikonen-silc-ke-auth-01.txt 6 October 2000
25 SILC Key Exchange and Authentication Protocols
26 <draft-riikonen-silc-ke-auth-01.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 1 Payload .............................. 7
81 2.1.3 Key Exchange 2 Payload .............................. 9
82 2.2 Key Exchange Procedure .................................... 10
83 2.3 Processing the Key Material ............................... 12
84 2.4 SILC Key Exchange Groups .................................. 13
85 2.4.1 diffie-hellman-group1 ............................... 13
86 2.4.2 diffie-hellman-group2 ............................... 14
87 2.5 Key Exchange Status Types ................................. 14
88 3 SILC Connection Authentication Protocol ....................... 16
89 3.1 Connection Auth Payload ................................... 17
90 3.2 Connection Authentication Types ........................... 18
91 3.2.1 Passphrase Authentication ........................... 18
92 3.2.2 Public Key Authentication ........................... 18
93 3.3 Connection Authentication Status Types .................... 19
94 4 Security Considerations ....................................... 19
95 5 References .................................................... 19
96 6 Author's Address .............................................. 20
103 Figure 1: Key Exchange Start Payload
104 Figure 2: Key Exchange 1 Payload
105 Figure 3: Key Exchange 2 Payload
106 Figure 4: 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 Internet-Draft [SILC1]. The
115 SILC Key Exchange (SKE) protocol provides secure key exchange between
116 two parties resulting into shared secret key material. The protocol
117 is based on Diffie Hellman key exchange algorithm and its functionality
118 is derived from several key exchange protocols. SKE uses best parts
119 of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol
120 and the OAKLEY Key Determination protocol.
122 The SILC Connection Authentication protocol provides user level
123 authentication used when creating connections in SILC network. The
124 protocol is transparent to the authentication data which means that it
125 can be used to authenticate the user with, for example, passphrase
126 (pre-shared- secret) or public key (and certificate).
128 The basis of secure SILC session requires strong and secure key exchange
129 protocol and authentication. The authentication protocol is entirely
130 secured and no authentication data is ever sent in the network without
131 encrypting and authenticating it first. Thus, authentication protocol
132 may be used only after the key exchange protocol has been successfully
135 This document refers constantly to other SILC protocol specification
136 Internet Drafts that are a must read for those who wants to understand
137 the function of these protocols. The most important references are
138 the Secure Internet Live Conferencing, Protocol Specification [SILC1]
139 and SILC Packet Protocol [SILC2] Internet Drafts.
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 2 SILC Key Exchange Protocol
149 SILC Key Exchange Protocol (SKE) is used to exchange shared secret
150 between connecting entities. The result of this protocol is a key
151 material used to secure the communication channel. The protocol uses
152 Diffie-Hellman key exchange algorithm and its functionality is derived
153 from several key exchange protocols. SKE uses best parts of the SSH2
154 Key Exchange protocol, Station-To-Station (STS) protocol and the OAKLEY
155 Key Determination protocol. The protocol does not claim any conformance
156 to any of these protocols, they were merely used as a reference when
157 designing this protocol.
159 The purpose of SILC Key Exchange protocol is to create session keys to
160 be used in current SILC session. The keys are valid only for some period
161 of time (usually an hour) or at most until the session ends. These keys
162 are used to protect packets like commands, command replies and other
163 communication between two entities. If connection is server to server
164 connection, the keys are used to protect all traffic between those
165 servers. In client connections usually all the packets are protected
166 with this key except channel messages; channels has their own keys and
167 they are not exchanged with this protocol.
171 2.1 Key Exchange Payloads
173 During the key exchange procedure public data is sent between initiator
174 and responder. This data is later used in the key exchange procedure.
175 There are several payloads used in the key exchange. As for all SILC
176 packets, SILC Packet Header, described in [SILC2], is at the start of all
177 packets, the same is done with these payloads as well. All fields in
178 all payloads are always in MSB (most significant byte first) order.
179 Following descriptions of these payloads.
183 2.1.1 Key Exchange Start Payload
185 Key exchange between two entities always begins with a
186 SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
187 Initiator sends the Key Exchange Start Payload to the responder filled with
188 all security properties it supports. The responders then checks whether
189 it supports the security properties.
191 It then sends a Key Exchange Start Payload to the initiator filled with
192 security properties it selected from the original payload. The payload sent
193 by responder must include only one chosen property per list.
195 The Key Exchange Start Payload is used to tell connecting entities what
196 security properties and algorithms should be used in the communication.
197 If perfect forward secrecy (PFS) is not desired (PFS is undefined by
198 default) Key Exchange Start Payload is sent only once per session, thus,
199 for example, re-keying will not cause sending of a new payload. If PFS
200 is desired, re-keying will always cause new key exchange thus causes
201 sending of a new Key Exchange Start Payload.
203 When performing first key exchange this payload is never encrypted, as
204 there are no existing keys to encrypt it with. If performing re-keying
205 (PFS was selected) this payload is encrypted with the existing key and
206 encryption algorithm.
208 A cookie is also sent in this payload. A cookie is used to uniform the
209 payload so that none of the key exchange parties can determine this
210 payload before hand. The cookie must be returned to the original sender
213 Following diagram represents the Key Exchange Start Payload. The lists
214 mentioned below are always comma (`,') separated and the list must
215 not include spaces (` ').
227 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
228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
229 | RESERVED | Flags | Payload Length |
230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
239 | Version String Length | |
240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
245 | Key Exchange Grp Length | |
246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
248 ~ Key Exchange Groups ~
250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
251 | PKCS Alg Length | |
252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
257 | Encryption Alg Length | |
258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
260 ~ Encryption Algorithms ~
262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
263 | Hash Alg Length | |
264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
269 | Compression Alg Length | |
270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
272 ~ Compression Algorithms ~
274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
278 Figure 1: Key Exchange Start Payload
283 o RESERVED (1 byte) - Reserved field. Sender fills this with
286 o Flags (1 byte) - Indicates flags to be used in the key
287 exchange. Several flags can be set at once by ORing the
288 flags together. Following flags are reserved for this field.
292 In this case the field is ignored.
296 If set the receiver of the payload does not reply to
301 Perfect Forward Secrecy (PFS) to be used in the
302 key exchange protocol. If not set, re-keying
303 is performed using the old key. When PFS is used,
304 re-keying and creating new keys for any particular
305 purpose will cause new key exchange.
307 Rest of the flags are reserved for the future and
310 o Payload Length (2 bytes) - Length of the entire Key Exchange
311 Start payload, not including any other field.
313 o Cookie (16 bytes) - Cookie that uniforms this payload so
314 that each of the party cannot determine the payload before
317 o Version String Length (2 bytes) - The length of the Version
318 String field, not including any other field.
320 o Version String (variable length) - Indicates the version of
321 the sender of this payload. Initiator sets this when sending
322 the payload and responder sets this when it replies by sending
323 this payload. See [SILC1] for definition of the version
326 o Key Exchange Grp Length (2 bytes) - The length of the
327 key exchange group list, not including any other field.
329 o Key Exchange Group (variable length) - The list of
330 key exchange groups. See the section 2.1.2 SILC Key Exchange
331 Groups for definitions of these groups.
333 o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms
334 list, not including any other field.
336 o PKCS Algorithms (variable length) - The list of PKCS
339 o Encryption Alg Length (2 bytes) - The length of the encryption
340 algorithms list, not including any other field.
342 o Encryption Algorithms (variable length) - The list of
343 encryption algorithms.
345 o Hash Alg Length (2 bytes) - The length of the Hash algorithms
346 list, not including any other field.
348 o Hash Algorithms (variable length) - The list of Hash algorithms.
350 o Compression Alg Length (2 bytes) - The length of the
351 compression algorithms list, not including any other field.
353 o Compression Algorithms (variable length) - The list of
354 compression algorithms.
359 2.1.2 Key Exchange 1 Payload
361 Key Exchange 1 Payload is used to deliver computed public data from
362 initiator to responder. This data is used to compute the shared secret,
363 later by all parties. Key Exchange 1 Payload is only sent after the
364 SILC_PACKET_KEY_EXCHANGE packet and the Key Exchange Start Payload has
365 been processed by all the parties.
367 This payload sends the initiator's public key to the responder. Responder
368 may need the public key in which case it should be checked to be trusted
371 The payload may only be sent with SILC_PACKET_KEY_EXCHANGE_1 packet.
372 It must not be sent in any other packet type. Following diagram
373 represent the Key Exchange 1 Payload.
393 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
394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
395 | Public Key Length | Public Key Type |
396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
398 ~ Public Key of the Host (or certificate) ~
400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
401 | Public Data Length | |
402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
404 ~ Public Data (e = g ^ x mod p) ~
406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
410 Figure 2: Key Exchange 1 Payload
414 o Public Key Length (2 bytes) - The length of the Public Key
415 (or certificate) field, not including any other field.
417 o Public Key Type (2 bytes) - The public key (or certificate)
418 type. This field indicates the type of the public key in
419 the packet. Following types are defined:
421 1 SILC style public key (mandatory)
422 2 SSH2 style public key (optional)
423 3 X.509 Version 3 certificate (optional)
424 4 OpenPGP certificate (optional)
425 5 SPKI certificate (optional)
427 The only required type to support is type number 1. See
428 [SILC1] for the SILC public key specification. See
429 SSH public key specification in [SSH-TRANS]. See X.509v3
430 certificate specification in [PKIX-Part1]. See OpenPGP
431 certificate specification in [PGP]. See SPKI certificate
432 specification in [SPKI]. If this field includes zero (0)
433 or unsupported type number the protocol must be aborted
434 sending SILC_PACKET_FAILURE message.
436 o Public Data Length (2 bytes) - The length of the public
437 data computed by the responder, not including any other
440 o Public Data (variable length) - The public data to be
441 sent to the responder. See section 2.2 Key Exchange
442 Procedure for detailed description how this field is
443 computed. This value is binary encoded.
448 2.1.3 Key Exchange 2 Payload
450 Key Exchange 2 Payload is used to deliver public key, computed public
451 data and signature from responder to initiator. Initiator uses these
452 public parts of the key exchange protocol to compute the shared secret.
454 The payload may only be sent with SILC_PACKET_KEY_EXCHANGE_2 packet.
455 It must not be sent in any other packet type. Following diagram
456 represent the Key Exchange 2 Payload.
463 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
464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
465 | Public Key Length | Public Key Type |
466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
468 ~ Public Key of the Host (or certificate) ~
470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
471 | Public Data Length | |
472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
474 ~ Public Data (f = g ^ y mod p) ~
476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
477 | Signature Length | |
478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
486 Figure 3: Key Exchange 2 Payload
491 o Public Key Length (2 bytes) - The length of the Public Key
492 (or certificate) field, not including any other field.
494 o Public Key Type (2 bytes) - The public key (or certificate)
495 type. This field indicates the type of the public key in
496 the packet. See previous sections for defined public key
499 o Public Key of the host (variable length) - The public
500 key of the sender (or its certificate). This is verified
501 by the receiver of the packet. The type of this field
502 is indicated by previous Public Key Type field.
504 o Public Data Length (2 bytes) - The length of the public
505 data computed by the responder, not including any other
508 o Public Data (variable length) - The public data computed
509 by the responder. See section 2.2 Key Exchange Procedure
510 for detailed description how this field is computed. This
511 value is binary encoded.
513 o Signature Length (2 bytes) - The length of the signature,
514 not including any other field.
516 o Signature Data (variable length) - The signature signed
517 by the responder. The receiver of this signature must
518 verify it. The verification is done using the public
519 key received in this same payload. See section 2.2
520 Key Exchange Procedure for detailed description how
521 to produce the signature.
525 2.2 Key Exchange Procedure
527 The key exchange begins by sending SILC_PACKET_KEY_EXCHANGE packet with
528 Key Exchange Start Payload to select the security properties to be used
529 in the key exchange and later in the communication.
531 After Key Exchange Start Payload has been processed by both of the
532 parties the protocol proceeds as follows:
535 Setup: p is a large and public safe prime. This is one of the
536 Diffie Hellman groups. q is order of subgroup (largest
537 prime factor of p). g is a generator and is defined
538 along with the Diffie Hellman group.
540 1. Initiator generates a random number x, where 1 < x < q,
541 and computes e = g ^ x mod p. The result e is then
542 encoded into Key Exchange 1 Payload and sent
546 2. Responder generates a random number y, where 1 < y < q,
547 and computes f = g ^ y mod p. It then computes the
548 shared secret KEY = e ^ y mod p, and, a hash value
549 HASH = hash(Key Exchange Start Payload data | Host public
550 key (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 2 Payload and sends it to the
559 3. Initiator verifies that the public key provided in
560 the payload is authentic, or if certificates are used
561 it verifies the certificate. Initiator may accept
562 the public key without verifying it, however, doing
563 so may result to insecure key exchange (accepting the
564 public key without verifying may be desirable for
565 practical reasons on many environments. For long term
566 use this is never desirable, in which case certificates
567 would be the preferred method to use).
569 Initiator then computes the shared secret KEY =
570 f ^ x mod p, and, a hash value HASH in the same way as
571 responder did in phase 2. It then verifies the
572 signature SIGN from the payload with the hash value
573 HASH using the received public key.
576 If any of these phases is to fail SILC_PACKET_FAILURE is sent to
577 indicate that the key exchange protocol failed. Any other packets must
578 not be sent or accepted during the key exchange except the
579 SILC_PACKET_KEY_EXCHANGE_*, SILC_PACKET_DISCONNECT, SILC_PACKET_FAILURE
580 and/or SILC_PACKET_SUCCESS packets.
582 The result of this protocol is a shared secret key material KEY and
583 a hash value HASH. The key material itself is not fit to be used as
584 a key, it needs to be processed further to derive the actual keys to be
585 used. The key material is also used to produce other security parameters
586 later used in the communication. See section 2.3 Processing the Key
587 Material for detailed description how to process the key material.
589 After the keys are processed the protocol is ended by sending the
590 SILC_PACKET_SUCCESS packet. Both entities send this packet to
591 each other. After this both parties will start using the new keys.
597 2.3 Processing the Key Material
599 Key Exchange protocol produces secret shared key material KEY. This
600 key material is used to derive the actual keys used in the encryption
601 of the communication channel. The key material is also used to derive
602 other security parameters used in the communication. Key Exchange
603 protocol produces a hash value HASH as well. This is used in the key
604 deriving process as a session identifier.
606 Keys are derived from the key material as follows:
609 Sending Initial Vector (IV) = hash(0 | KEY | HASH)
610 Receiving Initial Vector (IV) = hash(1 | KEY | HASH)
611 Sending Encryption Key = hash(2 | KEY | HASH)
612 Receiving Encryption Key = hash(3 | KEY | HASH)
613 HMAC Key = hash(4 | KEY | HASH)
617 The Initial Vector (IV) is used in the encryption when doing for
618 example CBC mode. As many bytes as needed are taken from the start of
619 the hash output for IV. Sending IV is for sending key and receiving IV
620 is for receiving key. For receiving party, the receiving IV is actually
621 sender's sending IV, and, the sending IV is actually sender's receiving
622 IV. Initiator uses IV's as they are (sending IV for sending and
623 receiving IV for receiving).
625 The Encryption Keys are derived as well from the hash(). If the hash()
626 output is too short for the encryption algorithm more key material is
627 produced in following manner:
630 K1 = hash(2 | KEY | HASH)
632 K3 = hash(KEY | K1 | K2) ...
634 Sending Encryption Key = K1 | K2 | K3 ...
637 K1 = hash(3 | KEY | HASH)
639 K3 = hash(KEY | K1 | K2) ...
641 Receiving Encryption Key = K1 | K2 | K3 ...
645 The key is distributed by hashing the previous hash with the original
646 key material. The final key is a concatenation of the hash values.
647 For Receiving Encryption Key the procedure is equivalent. Sending key
648 is used only for encrypting data to be sent. The receiving key is used
649 only to decrypt received data. For receiving party, the receive key is
650 actually sender's sending key, and, the sending key is actually sender's
651 receiving key. Initiator uses generated keys as they are (sending key
652 for sending and receiving key for sending).
654 The HMAC key is used to create MAC values to packets in the communication
655 channel. As many bytes as needed are taken from the start of the hash
658 These procedures are performed by all parties of the key exchange
659 protocol. This must be done before the protocol has been ended by
660 sending the SILC_PACKET_SUCCESS packet.
664 2.4 SILC Key Exchange Groups
666 Following groups may be used in the SILC Key Exchange protocol. The
667 first group diffie-hellman-group1 is mandatory, other groups maybe
668 negotiated to be used in the connection with Key Exchange Start Payload
669 and SILC_PACKET_KEY_EXCHANGE packet. However, the first group must be
670 proposed in the Key Exchange Start Payload regardless of any other
671 requested group (however, it does not have to be the first on the list).
675 2.4.1 diffie-hellman-group1
677 The length of this group is 1024 bits. This is mandatory group.
678 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
683 179769313486231590770839156793787453197860296048756011706444
684 423684197180216158519368947833795864925541502180565485980503
685 646440548199239100050792877003355816639229553136239076508735
686 759914822574862575007425302077447712589550957937778424442426
687 617334727629299387668709205606050270810842907692932019128194
691 Its hexadecimal value is
694 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
695 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
696 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
697 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
698 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
703 The generator used with this prime is g = 2. The group order q is
706 This group was taken from the OAKLEY specification.
710 2.4.2 diffie-hellman-group2
712 The length of this group is 1536 bits. This is optional group.
713 The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
718 241031242692103258855207602219756607485695054850245994265411
719 694195810883168261222889009385826134161467322714147790401219
720 650364895705058263194273070680500922306273474534107340669624
721 601458936165977404102716924945320037872943417032584377865919
722 814376319377685986952408894019557734611984354530154704374720
723 774996976375008430892633929555996888245787241299381012913029
724 459299994792636526405928464720973038494721168143446471443848
725 8520940127459844288859336526896320919633919
728 Its hexadecimal value is
731 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
732 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
733 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
734 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
735 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
736 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
737 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
738 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
741 The generator used with this prime is g = 2. The group order q is
744 This group was taken from the OAKLEY specification.
748 2.5 Key Exchange Status Types
750 This section defines all key exchange protocol status types that may be
751 returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets to
752 indicate the status of the protocol. Implementations may map the
753 status types to human readable error message. All types except the
754 SILC_SKE_STATUS_OK type must be sent in SILC_PACKET_FAILURE packet.
755 Following status types are defined:
760 Protocol were executed successfully.
763 1 SILC_SKE_STATUS_ERROR
765 Unknown error occured. No specific error type is defined.
768 2 SILC_SKE_STATUS_BAD_PAYLOAD
770 Provided KE payload were malformed or included bad fields.
773 3 SILC_SKE_STATUS_UNSUPPORTED_GROUP
775 None of the provided groups were supported.
778 4 SILC_SKE_STATUS_UNSUPPORTED_CIPHER
780 None of the provided ciphers were supported.
783 5 SILC_SKE_STATUS_UNSUPPORTED_PKCS
785 None of the provided public key algorithms were supported.
788 6 SILC_SKE_STATUS_UNSUPPORTED_HASH_FUNCTION
790 None of the provided hash functions were supported.
793 7 SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY
795 Provided public key type is not supported.
798 8 SILC_SKE_STATUS_INCORRECT_SIGNATURE
800 Provided signature was incorrect.
808 3 SILC Connection Authentication Protocol
810 Purpose of Connection Authentication protocol is to authenticate the
811 connecting party with server. Usually connecting party is client but
812 server may connect to server as well. Its other purpose is to provide
813 information for the server about which type of connection this is.
814 The type defines whether this is client, server or router connection.
815 Server uses this information to create the ID for the connection. After
816 the authentication protocol has been successfully completed
817 SILC_PACKET_NEW_ID must be sent to the connecting party by the server.
818 See section New ID Payload in [SILC2] for detailed description for this
821 Server must verify the authentication data received and if it is to fail
822 the authentication must be failed by sending SILC_PACKET_FAILURE packet.
823 If everything checks out fine the protocol is ended by server by sending
824 SILC_PACKET_SUCCESS packet.
826 The protocol is executed after the SILC Key Exchange protocol. It must
827 not be executed in any other time. As it is performed after key exchange
828 protocol all traffic in the connection authentication protocol is
829 encrypted with the exchanged keys.
831 The protocol is started by the connecting party by sending
832 SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload,
833 described in the next section. This payload must include the
834 authentication data. Authentication data is set according
835 authentication method that must be known by both parties. If connecting
836 party does not know what is the mandatory authentication method it must
837 request it from the server by sending SILC_PACKET_CONNECTION_AUTH_REQUEST
838 packet. This packet is not part of this protocol and is described in
839 section Connection Auth Request Payload in [SILC2]. However, if
840 connecting party already knows the mandatory authentication method
841 sending the request is not necessary.
843 See [SILC1] and section Connection Auth Request Payload in [SILC2] also
844 for the list of different authentication methods. Authentication method
845 may also be NONE, in which case the server does not require
846 authentication at all. However, in this case the protocol still must be
847 executed; the authentication data just is empty indicating no
848 authentication is required.
850 If authentication method is passphrase the authentication data is
851 plaintext passphrase. As the payload is entirely encrypted it is safe
852 to have plaintext passphrase. 3.2.1 Passphrase Authentication for
856 If authentication method is public key authentication the authentication
857 data is signature of the hash value HASH plus Key Exchange Start Payload,
858 established by the SILC Key Exchange protocol. This signature must then
859 be verified by the server. See section 3.2.2 Public Key Authentication
860 for more information.
862 The connecting party of this protocol must wait after successful execution
863 of this protocol for the SILC_PACKET_NEW_ID packet where it will receive
864 the ID it will be using in the SILC network. Connecting party cannot
865 start normal SILC session (sending messages or commands) until it has
866 received its ID. The ID's are always created by the server except
867 for server to server connection where servers create their own ID's.
872 3.1 Connection Auth Payload
874 Client sends this payload to authenticate itself to the server. Server
875 connecting to another server also sends this payload. Server receiving
876 this payload must verify all the data in it and if something is to fail
877 the authentication must be failed by sending SILC_PACKET_FAILURE packet.
879 The payload may only be sent with SILC_PACKET_CONNECTION_AUTH packet.
880 It must not be sent in any other packet type. Following diagram
881 represent the Connection Auth Payload.
887 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
888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
889 | Payload Length | Connection Type |
890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
892 ~ Authentication Data ~
894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
898 Figure 4: Connection Auth Payload
902 o Payload Length (2 bytes) - Length of the entire Connection
905 o Connection Type (2 bytes) - Indicates the type of the
906 connection. See section Connection Auth Request Payload
907 in [SILC2] for the list of connection types. This field must
908 include valid connection type or the packet must be discarded
909 and authentication must be failed.
911 o Authentication Data (variable length) - The actual
912 authentication data. Contents of this depends on the
913 authentication method known by both parties. If no
914 authentication is required this field does not exist.
919 3.2 Connection Authentication Types
921 SILC supports two authentication types to be used in the connection
922 authentication protocol; passphrase or public key based authentication.
923 Following sections defines the authentication methods. See [SILC2]
924 for defined numerical authentication method types.
928 3.2.1 Passphrase Authentication
930 Passphrase authentication or pre-shared-key base authentication is
931 simply an authentication where the party that wants to authenticate
932 itself to the other end sends the passphrase that is required by
933 the other end, for example server.
935 If the passphrase matches with the one in the server's end the
936 authentication is successful. Otherwise SILC_PACKET_FAILURE must be
937 sent to the sender and the protocol execution fails.
939 This is required authentication method to be supported by all SILC
944 3.2.2 Public Key Authentication
946 Public key authentication may be used if passphrase based authentication
947 is not desired. The public key authentication works by sending a
948 signature as authentication data to the other end, say, server. The
949 server must then verify the signature by the public key of the sender,
950 which the server has received earlier in SKE protocol.
952 The signature is computed using the private key of the sender by signing
953 the HASH value provided by the SKE protocol previously, and the Key
954 Exchange Start Payload from SKE protocol that was sent to the server.
955 The server must verify the data, thus it must keep the HASH and the
956 Key Exchange Start Payload saved during SKE and authentication protocols.
958 If the verified signature matches the sent signature, the authentication
959 were successful and SILC_PACKET_SUCCESS is sent. If it failed the protocol
960 execution is stopped and SILC_PACKET_FAILURE is sent.
962 This is required authentication method to be supported by all SILC
967 3.3 Connection Authentication Status Types
969 This section defines all connection authentication status types that
970 may be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
971 to indicate the status of the protocol. Implementations may map the
972 status types to human readable error message. All types except the
973 SILC_AUTH_STATUS_OK type must be sent in SILC_PACKET_FAILURE packet.
974 Following status types are defined:
978 Protocol was executed successfully.
983 Authentication failed.
987 4 Security Considerations
989 Security is central to the design of this protocol, and these security
990 considerations permeate the specification.
996 [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
997 Protocol Specification", Internet Draft, June 2000.
999 [SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
1002 [IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
1005 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
1008 [PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
1011 [SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
1014 [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
1015 Infrastructure, Certificate and CRL Profile", RFC 2459,
1018 [Schneier] Schneier, B., "Applied Cryptography Second Edition",
1019 John Wiley & Sons, New York, NY, 1996.
1021 [Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
1024 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
1025 RFC 2412, November 1998.
1027 [ISAKMP] Maughan D., et al, "Internet Security Association and
1028 Key Management Protocol (ISAKMP)", RFC 2408, November
1031 [IKE] Harkins D., and Carrel D., "The Internet Key Exchange
1032 (IKE)", RFC 2409, November 1998.
1034 [HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
1035 Authentication", RFC 2104, February 1997.
1047 EMail: priikone@poseidon.pspt.fi
1049 This Internet-Draft expires 6 Jun 2001