Network Working Group P. Riikonen
Internet-Draft
draft-riikonen-silc-ke-auth-09.txt 15 January 2007
Expires: 15 July 2007
SILC Key Exchange and Authentication Protocols
<draft-riikonen-silc-ke-auth-09.txt>
Status of this Draft
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo describes two protocols used in the Secure Internet Live
Conferencing (SILC) protocol, specified in the Secure Internet Live
Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange
(SKE) protocol provides secure key exchange between two parties
resulting into shared secret key material. The protocol is based
on Diffie-Hellman key exchange algorithm and its functionality is
derived from several key exchange protocols.
The second protocol, SILC Connection Authentication protocol provides
user level authentication used when creating connections in SILC
network. The protocol supports passphrase (pre-shared secret)
authentication and public key (and certificate) authentication based
on digital signatures.
Riikonen [Page 1]
Internet-Draft 15 January 2007
Table of Contents
1 Introduction .................................................. 2
1.1 Requirements Terminology .................................. 3
2 SILC Key Exchange Protocol .................................... 3
2.1 Key Exchange Payloads ..................................... 4
2.1.1 Key Exchange Start Payload .......................... 4
2.1.2 Key Exchange Payload ................................ 9
2.2 Key Exchange Procedure .................................... 11
2.3 Processing the Key Material ............................... 13
2.4 SILC Key Exchange Groups .................................. 15
2.4.1 diffie-hellman-group1 ............................... 15
2.4.2 diffie-hellman-group2 ............................... 15
2.4.3 diffie-hellman-group3 ............................... 16
2.5 Key Exchange Status Types ................................. 16
3 SILC Connection Authentication Protocol ....................... 18
3.1 Connection Auth Payload ................................... 19
3.2 Connection Authentication Types ........................... 20
3.2.1 Passphrase Authentication ........................... 20
3.2.2 Public Key Authentication ........................... 21
3.3 Connection Authentication Status Types .................... 21
4 Security Considerations ....................................... 22
5 References .................................................... 22
6 Author's Address .............................................. 23
7 Full Copyright Statement ...................................... 24
List of Figures
Figure 1: Key Exchange Start Payload
Figure 2: Key Exchange Payload
Figure 3: Connection Auth Payload
1 Introduction
This memo describes two protocols used in the Secure Internet Live
Conferencing (SILC) protocol specified in the Secure Internet Live
Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange
(SKE) protocol provides secure key exchange between two parties
resulting into shared secret key material. The protocol is based on
Diffie-Hellman key exchange algorithm and its functionality is derived
from several key exchange protocols, such as SSH2 Key Exchange protocol,
Station-To-Station (STS) protocol and the OAKLEY Key Determination
protocol [OAKLEY].
The second protocol, SILC Connection Authentication protocol provides
user level authentication used when creating connections in SILC
Riikonen [Page 2]
Internet-Draft 15 January 2007
network. The protocol supports passphrase (pre-shared secret)
authentication and public key (and certificate) authentication based
on digital signatures.
The basis of secure SILC session requires strong and secure key exchange
protocol and authentication. The authentication protocol is secured and
no authentication data is ever sent in the network without encrypting
and authenticating it first. Thus, authentication protocol may be used
only after the key exchange protocol has been successfully completed.
This document constantly refers to other SILC protocol specifications
that should be read to be able to fully understand the functionality
and purpose of these protocols. The most important references are
the Secure Internet Live Conferencing, Protocol Specification [SILC1]
and the SILC Packet Protocol [SILC2].
The protocol is intended to be used with the SILC protocol thus it
does not define own framework that could be used. The framework is
provided by the SILC protocol.
1.1 Requirements Terminology
The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
MAY, and OPTIONAL, when they appear in this document, are to be
interpreted as described in [RFC2119].
2 SILC Key Exchange Protocol
SILC Key Exchange Protocol (SKE) is used to exchange shared secret
material used to secure the communication channel. The protocol use
Diffie-Hellman key exchange algorithm and its functionality is derived
from several key exchange protocols, such as SSH2 Key Exchange protocol,
Station-To-Station (STS) protocol and the OAKLEY Key Determination
protocol [OAKLEY]. The protocol does not claim any conformance
to any of these protocols, they were only used as a reference when
designing this protocol. The protocol can mutually authenticate the
negotiating parties during the key exchange.
The purpose of SILC Key Exchange protocol is to create session keys to
be used in current SILC session. The keys are valid only for some period
of time (usually an hour) or at most until the session ends. These keys
are used to protect packets traveling between the two entities.
Usually all traffic is secured with the key material derived from this
protocol.
The Diffie-Hellman implementation used in the SILC SHOULD be compliant
Riikonen [Page 3]
Internet-Draft 15 January 2007
to the PKCS #3.
2.1 Key Exchange Payloads
During the key exchange procedure public data is sent between initiator
and responder. This data is later used in the key exchange procedure.
There are several payloads used in the key exchange. As for all SILC
packets, SILC Packet Header, described in [SILC2], is at the beginning
of all packets sent in during this protocol. All the fields in the
following payloads are in MSB (most significant byte first) order.
2.1.1 Key Exchange Start Payload
The key exchange between two entities MUST be started by sending the
SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
Initiator sends the Key Exchange Start Payload to the responder filled
with all security properties it supports. The responder then checks
whether it supports the security properties.
It then sends a Key Exchange Start Payload to the initiator filled with
security properties it selected from the original payload. The payload
sent by responder MUST include only one chosen property per list. The
character encoding for the security property values as defined in [SILC1]
SHOULD be UTF-8 [RFC2279] in Key Exchange Start Payload.
The Key Exchange Start Payload is used to tell connecting entities what
security properties and algorithms should be used in the communication.
The Key Exchange Start Payload is sent only once per session. Even if
the PFS (Perfect Forward Secrecy) flag is set the Key Exchange Start
Payload is not re-sent. When PFS is desired the Key Exchange Payloads
are sent to negotiate new key material. The procedure is equivalent to
the very first negotiation except that the Key Exchange Start Payload
is not sent.
As this payload is used only with the very first key exchange the payload
is never encrypted, as there are no keys to encrypt it with.
A cookie is also sent in this payload. A cookie is used to randomize the
payload so that none of the key exchange parties can determine this
payload before the key exchange procedure starts. The cookie MUST be
returned to the original sender unmodified by the responder.
Following diagram represents the Key Exchange Start Payload. The lists
mentioned below are always comma (`,') separated and the list MUST NOT
include white spaces (` ').
Riikonen [Page 4]
Internet-Draft 15 January 2007
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Cookie +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version String Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Version String ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Exchange Grp Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Key Exchange Groups ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS Alg Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ PKCS Algorithms ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Alg Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Encryption Algorithms ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash Alg Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Hash Algorithms ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ HMACs ~
| |
Riikonen [Page 5]
Internet-Draft 15 January 2007
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Compression Alg Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Compression Algorithms ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Key Exchange Start Payload
o RESERVED (1 byte) - Reserved field. Sender fills this with
zero (0) value.
o Flags (1 byte) - Indicates flags to be used in the key
exchange. Several flags can be set at once by ORing the
flags together. The following flags are reserved for this
field:
No flags 0x00
In this case the field is ignored.
IV Included 0x01
This flag is used to indicate that Initialization
Vector (IV) in encryption will be included in the
ciphertext which the recipient must use in decryption.
At the beginning of the SILC packet, before the SILC
Packet header an 8-bit Security ID (SID) MUST be
placed. After the SID, the IV MUST be placed. After
the IV, a 32-bit MSB first ordered packet sequence
number MUST be placed. The SID and IV MUST NOT be
encrypted, but the sequence number MUST be included
in encryption. The recipient MUST use the sequence
number during MAC verification [SILC2]. All fields
however are authenticated with MAC.
The Security ID is set to value 0 when the key
exchange is performed for the first time. It is
monotonically increased after each re-key, wrapping
eventually. The SID in combination with the current
session can be used to identify which key has been
used to encrypt an incoming packet. This is especially
important after rekey when using UDP/IP protocol,
where packets may be lost or reordered. A packet with
unknown SID will result into discarding the packet as
it cannot be decrypted. After rekey, implementation
Riikonen [Page 6]
Internet-Draft 15 January 2007
should understand that it may still receive packets
with old SID and be prepared to decrypt them with the
old key.
With this flag it is possible to use SILC protocol on
unreliable transport such as UDP/IP which may cause
packet reordering and packet losses. By default,
this flag is not set and thus IV is not included
in the ciphertext. Setting this flag increases the
packet length by one ciphertext block plus 1 byte for
the Security ID and 32 bits for the sequence number.
Responder MAY override this flag for the initiator,
however without this flag UDP connection cannot be
used. The flag MAY also be used in TCP connection.
When using with UDP/IP implementations SHOULD use
anti-replay methods where an anti-replay window
defines what packets are replays. An example of
anti-window protocol is in [RFC2406] Section 3.4.2
with example source code in [RFC2401] Appendix C.
While [RFC2401] and [RFC2406] does not relate to SILC,
the anti-replay method used is applicable in SILC.
PFS 0x02
Perfect Forward Secrecy (PFS) to be used in the
key exchange protocol. If not set, re-keying
is performed using the old key. See the [SILC1]
for more information on this issue. When PFS is
used, re-keying and creating new keys for any
particular purpose MUST cause new key exchange with
new Diffie-Hellman exponent values. In this key
exchange only the Key Exchange Payload is sent and
the Key Exchange Start Payload MUST NOT be sent.
When doing PFS the Key Exchange Payloads are
encrypted with the old keys.
Mutual Authentication 0x04
Both of the parties will perform authentication
by providing signed data for the other party to
verify. By default, only responder will provide
the signature data. If this is set then the
initiator must also provide it. Initiator MAY
set this but also responder MAY set this even if
initiator did not set it.
Rest of the flags are reserved for the future and
Riikonen [Page 7]
Internet-Draft 15 January 2007
MUST NOT be set.
o Payload Length (2 bytes) - Length of the entire Key Exchange
Start payload, not including any other field.
o Cookie (16 bytes) - Cookie that randomize this payload so
that each of the party cannot determine the payload before
hand. This field MUST be present.
o Version String Length (2 bytes) - The length of the Version
String field, not including any other field.
o Version String (variable length) - Indicates the version of
the sender of this payload. Initiator sets this when sending
the payload and responder sets this when it replies by sending
this payload. See [SILC1] for definition for the version
string format. This field MUST be present and include valid
version string.
o Key Exchange Grp Length (2 bytes) - The length of the
key exchange group list, not including any other field.
o Key Exchange Group (variable length) - The list of
key exchange groups. See the section 2.4 SILC Key Exchange
Groups for definitions of these groups. This field MUST
be present.
o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms
list, not including any other field.
o PKCS Algorithms (variable length) - The list of PKCS
algorithms. This field MUST be present.
o Encryption Alg Length (2 bytes) - The length of the encryption
algorithms list, not including any other field.
o Encryption Algorithms (variable length) - The list of
encryption algorithms. This field MUST be present.
o Hash Alg Length (2 bytes) - The length of the Hash algorithm
list, not including any other field.
o Hash Algorithms (variable length) - The list of Hash
algorithms. The hash algorithms are mainly used in the
SKE protocol. This field MUST be present.
o HMAC Length (2 bytes) - The length of the HMAC list, not
including any other field.
Riikonen [Page 8]
Internet-Draft 15 January 2007
o HMACs (variable length) - The list of HMACs. The HMAC's
are used to compute the Message Authentication Code (MAC)
of the SILC packets. This field MUST be present.
o Compression Alg Length (2 bytes) - The length of the
compression algorithms list, not including any other field.
o Compression Algorithms (variable length) - The list of
compression algorithms. This field MAY be omitted.
2.1.2 Key Exchange Payload
Key Exchange payload is used to deliver the public key (or certificate),
the computed Diffie-Hellman public value and possibly signature data
from one party to the other. When initiator is using this payload
and the Mutual Authentication flag is not set then the initiator MUST
NOT provide the signature data. If the flag is set then the initiator
MUST provide the signature data so that the responder can verify it.
The Mutual Authentication flag is usually used when a separate
authentication protocol will not be executed for the initiator of the
protocol. This is case for example when the SKE is performed between
two SILC clients. In normal case, where client is connecting to a
server, or server is connecting to a router the Mutual Authentication
flag MAY be omitted. However, if the connection authentication protocol
for the connecting entity is not based on digital signatures (it is
based on pre-shared key or there is no authentication) then the Mutual
Authentication flag SHOULD be enabled. This way the connecting entity
has to provide proof of possession of the private key for the public key
it will provide in this protocol.
When performing re-key with PFS selected this is the only payload that
is sent in the SKE protocol. The Key Exchange Start Payload MUST NOT
be sent at all. However, this payload does not have all the fields
present. In the re-key with PFS the public key and a possible signature
data SHOULD NOT be present. If they are present they MUST be ignored.
The only field that is present is the Public Data that is used to create
the new key material. In the re-key the Mutual Authentication flag, that
may be set in the initial negotiation, MUST also be ignored.
This payload is sent inside SILC_PACKET_KEY_EXCHANGE_1 and inside
SILC_PACKET_KEY_EXCHANGE_2 packet types. The initiator uses the
SILC_PACKET_KEY_EXCHANGE_1 and the responder the latter.
The following diagram represent the Key Exchange Payload.
Riikonen [Page 9]
Internet-Draft 15 January 2007
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key Length | Public Key Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Public Key of the party (or certificate) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Data Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Public Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Signature Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Key Exchange Payload
o Public Key Length (2 bytes) - The length of the Public Key
(or certificate) field, not including any other field.
o Public Key Type (2 bytes) - The public key (or certificate)
type. This field indicates the type of the public key in
the packet. Following types are defined:
1 SILC style public key (mandatory)
2 SSH2 style public key (optional)
3 X.509 Version 3 certificate (optional)
4 OpenPGP certificate (optional)
5 SPKI certificate (optional)
The only required type to support is type number 1. See
[SILC1] for the SILC public key specification. See
SSH2 public key specification in [SSH-TRANS]. See X.509v3
certificate specification in [PKIX-Part1]. See OpenPGP
certificate specification in [PGP]. See SPKI certificate
specification in [SPKI]. If this field includes zero (0)
or unsupported type number the protocol MUST be aborted
sending SILC_PACKET_FAILURE message and the connection SHOULD
be closed immediately.
Riikonen [Page 10]
Internet-Draft 15 January 2007
o Public Key (or certificate) (variable length) - The
public key or certificate of the party. This public key
may be used to verify the digital signature. The public key
or certificate in this field is encoded in the manner as
defined in their respective definitions; see previous field.
o Public Data Length (2 bytes) - The length of the Public Data
field, not including any other field.
o Public Data (variable length) - The public data to be
sent to the receiver (computed Diffie-Hellman public values).
See section 2.2 Key Exchange Procedure for detailed description
how this field is computed. This field is MP integer and is
encoded as defined in [SILC1].
o Signature Length (2 bytes) - The length of the signature,
not including any other field.
o Signature Data (variable length) - The signature signed
by the sender. The receiver of this signature MUST
verify it. The verification is done using the sender's
public key. See section 2.2 Key Exchange Procedure for
detailed description how to produce the signature. If
the Mutual Authentication flag is not set then initiator
MUST NOT provide this field and the Signature Length field
MUST be set to zero (0) value. If the flag is set then
also the initiator MUST provide this field. The responder
always MUST provide this field. The encoding for signature
is defined in [SILC1].
2.2 Key Exchange Procedure
The key exchange begins by sending SILC_PACKET_KEY_EXCHANGE packet with
Key Exchange Start Payload to select the security properties to be used
in the key exchange and later in the communication.
After Key Exchange Start Payload has been processed by both of the
parties the protocol proceeds as follows:
Setup: p is a large and public safe prime. This is one of the
Diffie Hellman groups. q is order of subgroup (largest
prime factor of p). g is a generator and is defined
along with the Diffie Hellman group.
1. Initiator generates a random number x, where 1 < x < q,
Riikonen [Page 11]
Internet-Draft 15 January 2007
and computes e = g ^ x mod p. The result e is then
encoded into Key Exchange Payload, with the public key
(or certificate) and sent to the responder.
If the Mutual Authentication flag is set then initiator
MUST also produce signature data SIGN_i which the responder
will verify. The initiator MUST compute a hash value
HASH_i = hash(Initiator's Key Exchange Start Payload |
public key (or certificate) | e). The '|' stands for
concatenation. It then signs the HASH_i value with its
private key resulting a signature SIGN_i.
2. Responder generates a random number y, where 1 < y < q,
and computes f = g ^ y mod p. It then computes the
shared secret KEY = e ^ y mod p, and, a hash value
HASH = hash(Initiator's Key Exchange Start Payload |
public key (or certificate) | Initiator's public key
(or certificate) | e | f | KEY). It then signs
the HASH value with its private key resulting a signature
SIGN.
It then encodes its public key (or certificate), f and
SIGN into Key Exchange Payload and sends it to the
initiator.
If the Mutual Authentication flag is set then the responder
SHOULD verify that the public key provided in the payload
is authentic, or if certificates are used it verifies the
certificate. The responder MAY accept the public key without
verifying it, however, doing so may result to insecure key
exchange (accepting the public key without verifying may be
desirable for practical reasons on many environments. For
long term use this is never desirable, in which case
certificates would be the preferred method to use). It then
computes the HASH_i value the same way initiator did in the
phase 1. It then verifies the signature SIGN_i from the
payload with the hash value HASH_i using the received public
key.
3. Initiator verifies that the public key provided in
the payload is authentic, or if certificates are used
it verifies the certificate. The initiator MAY accept
the public key without verifying it, however, doing
so may result to insecure key exchange (accepting the
public key without verifying may be desirable for
practical reasons on many environments. For long term
use this is never desirable, in which case certificates
would be the preferred method to use).
Riikonen [Page 12]
Internet-Draft 15 January 2007
Initiator then computes the shared secret KEY =
f ^ x mod p, and, a hash value HASH in the same way as
responder did in phase 2. It then verifies the
signature SIGN from the payload with the hash value
HASH using the received public key.
If any of these phases is to fail the SILC_PACKET_FAILURE MUST be sent
to indicate that the key exchange protocol has failed, and the connection
SHOULD be closed immediately. Any other packets MUST NOT be sent or
accepted during the key exchange except the SILC_PACKET_KEY_EXCHANGE_*,
SILC_PACKET_FAILURE and SILC_PACKET_SUCCESS packets.
The result of this protocol is a shared secret key material KEY and
a hash value HASH. The key material itself is not fit to be used as
a key, it needs to be processed further to derive the actual keys to be
used. The key material is also used to produce other security parameters
later used in the communication. See section 2.3 Processing the Key
Material for detailed description how to process the key material.
If the Mutual Authentication flag was set the protocol produces also
a hash value HASH_i. This value, however, must be discarded.
After the keys are processed the protocol is ended by sending the
SILC_PACKET_SUCCESS packet. Both entities send this packet to
each other. After this both parties MUST start using the new keys.
2.3 Processing the Key Material
Key Exchange protocol produces secret shared key material KEY. This
key material is used to derive the actual keys used in the encryption
of the communication channel. The key material is also used to derive
other security parameters used in the communication. Key Exchange
protocol produces a hash value HASH as well.
The keys MUST be derived from the key material as follows:
Sending Initial Vector (IV) = hash(0x0 | KEY | HASH)
Receiving Initial Vector (IV) = hash(0x1 | KEY | HASH)
Sending Encryption Key = hash(0x2 | KEY | HASH)
Receiving Encryption Key = hash(0x3 | KEY | HASH)
Sending HMAC Key = hash(0x4 | KEY | HASH)
Receiving HMAC Key = hash(0x5 | KEY | HASH)
The Initial Vector (IV) is used in the encryption when doing for
example CBC mode. As many bytes as needed are taken from the start of
Riikonen [Page 13]
Internet-Draft 15 January 2007
the hash output for IV. Sending IV is for sending key and receiving IV
is for receiving key. For receiving party, the receiving IV is actually
sender's sending IV, and, the sending IV is actually sender's receiving
IV. Initiator uses IV's as they are (sending IV for sending and
receiving IV for receiving).
The Encryption Keys are derived as well from the hash(). If the hash()
output is too short for the encryption algorithm more key material MUST
be produced in the following manner:
K1 = hash(0x2 | KEY | HASH)
K2 = hash(KEY | HASH | K1)
K3 = hash(KEY | HASH | K1 | K2) ...
Sending Encryption Key = K1 | K2 | K3 ...
K1 = hash(0x3 | KEY | HASH)
K2 = hash(KEY | HASH | K1)
K3 = hash(KEY | HASH | K1 | K2) ...
Receiving Encryption Key = K1 | K2 | K3 ...
The key is distributed by hashing the previous hash with the original
key material. The final key is a concatenation of the hash values.
For Receiving Encryption Key the procedure is equivalent. Sending key
is used only for encrypting data to be sent. The receiving key is used
only to decrypt received data. For receiving party, the receive key is
actually sender's sending key, and, the sending key is actually sender's
receiving key. Initiator uses generated keys as they are (sending key
for sending and receiving key for receiving).
The HMAC keys are used to create MAC values to packets in the
communication channel. As many bytes as needed are taken from the start
of the hash output to generate the MAC keys.
These procedures are performed by all parties of the key exchange
protocol. This MUST be done before the protocol has been ended by
sending the SILC_PACKET_SUCCESS packet, to assure that parties can
successfully process the key material.
This same key processing procedure MAY be used in the SILC in some
other circumstances as well. Any changes to this procedure is defined
separately when this procedure is needed. See the [SILC1] and the
[SILC2] for these circumstances.
Riikonen [Page 14]
Internet-Draft 15 January 2007
2.4 SILC Key Exchange Groups
The Following groups may be used in the SILC Key Exchange protocol.
The first group diffie-hellman-group1 is REQUIRED, other groups MAY be
negotiated to be used in the connection with Key Exchange Start Payload
and SILC_PACKET_KEY_EXCHANGE packet. However, the first group MUST be
proposed in the Key Exchange Start Payload regardless of any other
requested group (however, it does not have to be the first in the list).
2.4.1 diffie-hellman-group1
The length of this group is 1024 bits. This is REQUIRED group.
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its hexadecimal value is
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
The generator used with this prime is g = 2. The group order q is
(p - 1) / 2.
This group was taken from RFC 2412.
2.4.2 diffie-hellman-group2
The length of this group is 1536 bits. This is OPTIONAL group.
The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
Its hexadecimal value is
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
The generator used with this prime is g = 2. The group order q is
Riikonen [Page 15]
Internet-Draft 15 January 2007
(p - 1) / 2.
This group was taken from RFC 3526.
2.4.3 diffie-hellman-group3
The length of this group is 2048 bits. This is OPTIONAL group.
This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }.
Its hexadecimal value is
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
The generator used with this prime is g = 2. The group order q is
(p - 1) / 2.
This group was taken from RFC 3526.
Additional larger groups are defined in RFC 3526 and may be used in SKE
by defining name for them using the above name format.
2.5 Key Exchange Status Types
This section defines all key exchange protocol status types that may
be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
to indicate the status of the protocol. Implementations may map the
status types to human readable error message. All types except the
SILC_SKE_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
The length of status is 32 bits (4 bytes). The following status types
are defined:
0 SILC_SKE_STATUS_OK
Protocol were executed successfully.
Riikonen [Page 16]
Internet-Draft 15 January 2007
1 SILC_SKE_STATUS_ERROR
Unknown error occurred. No specific error type is defined.
2 SILC_SKE_STATUS_BAD_PAYLOAD
Provided KE payload were malformed or included bad fields.
3 SILC_SKE_STATUS_UNSUPPORTED_GROUP
None of the provided groups were supported.
4 SILC_SKE_STATUS_UNSUPPORTED_CIPHER
None of the provided ciphers were supported.
5 SILC_SKE_STATUS_UNSUPPORTED_PKCS
None of the provided public key algorithms were supported.
6 SILC_SKE_STATUS_UNSUPPORTED_HASH_FUNCTION
None of the provided hash functions were supported.
7 SILC_SKE_STATUS_UNSUPPORTED_HMAC
None of the provided HMACs were supported.
8 SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY
Provided public key type is not supported.
9 SILC_SKE_STATUS_INCORRECT_SIGNATURE
Provided signature was incorrect.
10 SILC_SKE_STATUS_BAD_VERSION
Provided version string was not acceptable.
Riikonen [Page 17]
Internet-Draft 15 January 2007
11 SILC_SKE_STATUS_INVALID_COOKIE
The cookie in the Key Exchange Start Payload was malformed,
because responder modified the cookie.
3 SILC Connection Authentication Protocol
Purpose of Connection Authentication protocol is to authenticate the
connecting party with server. Usually connecting party is client but
server may connect to router server as well. Its other purpose is to
provide information for the server about which type of entity the
connection is. The type defines whether the connection is client,
server or router connection. Server use this information to create the
ID for the connection.
Server MUST verify the authentication data received and if it is to fail
the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
If authentication is successful the protocol is ended by server by sending
SILC_PACKET_SUCCESS packet.
The protocol is executed after the SILC Key Exchange protocol. It MUST
NOT be executed in any other time. As it is performed after key exchange
protocol all traffic in the connection authentication protocol is
encrypted with the exchanged keys.
The protocol MUST be started by the connecting party by sending the
SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload,
described in the next section. This payload MUST include the
authentication data. The authentication data is set according
authentication method that MUST be known by both parties. If connecting
party does not know what is the mandatory authentication method it MAY
request it from the server by sending SILC_PACKET_CONNECTION_AUTH_REQUEST
packet. This packet is not part of this protocol and is described in
section Connection Auth Request Payload in [SILC2]. However, if
connecting party already knows the mandatory authentication method
sending the request is not necessary.
See [SILC1] and section Connection Auth Request Payload in [SILC2] also
for the list of different authentication methods. Authentication method
MAY also be NONE, in which case the server does not require
authentication. However, in this case the protocol still MUST be
executed; the authentication data is empty indicating no authentication
is required.
If authentication method is passphrase the authentication data is
plaintext passphrase. As the payload is encrypted it is safe to have
plaintext passphrase. It is also provided as plaintext passphrase
Riikonen [Page 18]
Internet-Draft 15 January 2007
because the receiver may need to pass the entire passphrase into a
passphrase verifier, and a message digest of the passphrase would
prevent this. See the section 3.2.1 Passphrase Authentication for
more information.
If authentication method is public key authentication the authentication
data is a digital signature of the hash value of hash HASH and Key
Exchange Start Payload, established by the SILC Key Exchange protocol.
This signature MUST then be verified by the server. See the section
3.2.2 Public Key Authentication for more information.
See the section 4 SILC Procedures in [SILC1] for more information about
client creating connection to server, and server creating connection
to router, and how to register the session in the SILC Network after
successful Connection Authentication protocol.
3.1 Connection Auth Payload
Client sends this payload to authenticate itself to the server. Server
connecting to another server also sends this payload. Server receiving
this payload MUST verify all the data in it and if something is to fail
the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
The payload may only be sent with SILC_PACKET_CONNECTION_AUTH packet.
It MUST NOT be sent in any other packet type. The following diagram
represent the Connection Auth Payload.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Connection Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Connection Auth Payload
o Payload Length (2 bytes) - Length of the entire Connection
Riikonen [Page 19]
Internet-Draft 15 January 2007
Auth Payload.
o Connection Type (2 bytes) - Indicates the type of the
connection. See section Connection Auth Request Payload
in [SILC2] for the list of connection types. This field MUST
include valid connection type or the packet MUST be discarded
and authentication MUST be failed.
o Authentication Data (variable length) - The actual
authentication data. Contents of this depends on the
authentication method known by both parties. If no
authentication is required this field does not exist.
3.2 Connection Authentication Types
SILC supports two authentication types to be used in the connection
authentication protocol; passphrase authentication or public key
authentication based on digital signatures. The following sections
defines the authentication methods. See [SILC2] for defined numerical
authentication method types.
3.2.1 Passphrase Authentication
Passphrase authentication or pre-shared key based authentication is
simply an authentication where the party that wants to authenticate
itself to the other end sends the passphrase that is required by
the other end, for example server. The plaintext passphrase is put
to the payload, that is then encrypted. The plaintext passphrase
MUST be in UTF-8 [RFC2279] encoding. If the passphrase is in the
sender's system in some other encoding it MUST be UTF-8 encoded
before transmitted. The receiver MAY change the encoding of the
passphrase to its system's default character encoding before verifying
the passphrase.
If the passphrase matches with the one in the server's end the
authentication is successful. Otherwise SILC_PACKET_FAILURE MUST be
sent to the sender and the protocol execution fails.
This is REQUIRED authentication method to be supported by all SILC
implementations.
When password authentication is used it is RECOMMENDED that maximum
amount of padding is applied to the SILC packet. This way it is not
possible to approximate the length of the password from the encrypted
packet.
Riikonen [Page 20]
Internet-Draft 15 January 2007
3.2.2 Public Key Authentication
Public key authentication may be used if passphrase based authentication
is not desired. The public key authentication works by sending a
digital signature as authentication data to the other end, say, server.
The server MUST then verify the signature by the public key of the sender,
which the server has received earlier in SKE protocol, or which the
server has cached locally at some previous time.
The signature is computed using the private key of the sender by signing
the HASH value provided by the SKE protocol previously, and the Key
Exchange Start Payload from SKE protocol that was sent to the server.
These are concatenated and hash function is used to compute a hash value
which is then signed.
auth_hash = hash(HASH | Key Exchange Start Payload);
signature = sign(auth_hash);
The hash() function used to compute the value is the hash function
negotiated in the SKE protocol. The server MUST verify the data, thus
it must keep the HASH and the Key Exchange Start Payload saved during
SKE and authentication protocols. These values can be discarded after
Connection Authentication protocol is completed.
If the verified signature matches the sent signature, the authentication
were successful and SILC_PACKET_SUCCESS is sent. If it failed the
protocol execution is stopped and SILC_PACKET_FAILURE is sent.
This is REQUIRED authentication method to be supported by all SILC
implementations.
3.3 Connection Authentication Status Types
This section defines all connection authentication status types that
may be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
to indicate the status of the protocol. Implementations may map the
status types to human readable error message. All types except the
SILC_AUTH_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
The length of status is 32 bits (4 bytes). The following status types
are defined:
0 SILC_AUTH_OK
Protocol was executed successfully.
Riikonen [Page 21]
Internet-Draft 15 January 2007
1 SILC_AUTH_FAILED
Authentication failed.
4 Security Considerations
Security is central to the design of this protocol, and these security
considerations permeate the specification. Common security considerations
such as keeping private keys truly private and using adequate lengths for
symmetric and asymmetric keys must be followed in order to maintain the
security of this protocol.
5 References
[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
Protocol Specification", Internet Draft, January 2007.
[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
January 2007.
[SILC4] Riikonen, P., "SILC Commands", Internet Draft, January 2007.
[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
RFC 1459, May 1993.
[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
April 2000.
[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
2811, April 2000.
[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
2812, April 2000.
[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
2813, April 2000.
[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
Internet Draft.
[PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
November 1998.
[SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
September 1999.
Riikonen [Page 22]
Internet-Draft 15 January 2007
[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
Infrastructure, Certificate and CRL Profile", RFC 2459,
January 1999.
[Schneier] Schneier, B., "Applied Cryptography Second Edition",
John Wiley & Sons, New York, NY, 1996.
[Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
CRC Press 1997.
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.
[ISAKMP] Maughan D., et al, "Internet Security Association and
Key Management Protocol (ISAKMP)", RFC 2408, November
1998.
[IKE] Harkins D., and Carrel D., "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
[PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
Specifications, Version 2.0", RFC 2437, October 1998.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC2401] Kent, S., et al, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[RFC2406] Kent, S., et al, "Security Architecture for the Internet
Protocol", RFC 2406, November 1998.
6 Author's Address
Pekka Riikonen
Helsinki
Finland
EMail: priikone@iki.fi
Riikonen [Page 23]
Internet-Draft 15 January 2007
7 Full Copyright Statement
Copyright (C) The Internet Society (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Riikonen [Page 24]
distrib
>
Mandriva
>
2009.1
>
x86_64
>
media
>
main-testing
>
by-pkgid
>
ab7ad4fe88fbdcf4125a767f7f3c4e92
>
files
>
119
