.ds LF Riikonen
.ds RF FORMFEED[Page %]
.ds CF
-.ds LH INTERNET-DRAFT
-.ds RH 13 September 2000
+.ds LH Internet-Draft
+.ds RH 6 October 2000
.ds CH
.na
.hy 0
.in 0
.nf
Network Working Group P. Riikonen
-INTERNET-DRAFT
-draft-riikonen-silc-ke-auth-01.txt 13 September 2000
-Expires: 13 May 2001
+Internet-Draft
+draft-riikonen-silc-ke-auth-01.txt 6 October 2000
+Expires: 6 Jun 2001
.in 3
This memo describes two protocols used in the Secure Internet Live
Conferencing (SILC) protocol specified in the Secure Internet Live
-Conferencing, Protocol Specification internet-draft [SILC1]. The
+Conferencing, Protocol Specification Internet-Draft [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
with this key except channel messages; channels has their own keys and
they are not exchanged with this protocol.
+The Diffie-Hellman implementation used in the SILC should be compliant
+to the PKCS #3.
+
.ti 0
2.1 Key Exchange Payloads
Key exchange between two entities always begins with a
SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
-When performing key exchange between client and server, the client sends
-Key Exchange Start Payload to server filled with all security properties
-that the client supports. Server then checks if it supports the security
-properties.
-
-It then sends a Key Exchange Start Payload to client filled with security
-properties it selected from the payload client originally sent. The
-payload sent by server must include only one chosen property per list.
+Initiator sends the Key Exchange Start Payload to the responder filled with
+all security properties it supports. The responders then checks whether
+it supports the security properties.
-When performing key exchange between server and server, the server who
-is contacting sends the Key Exchange Start Payload with security property
-list it supports to the other server. The contacted party then chooses
-the preferred properties same way as previously described. It then
-replies with the properties it wanted same way as previously described.
+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 Key Exchange Start Payload is used to tell connecting entities what
security properties and algorithms should be used in the communication.
(PFS was selected) this payload is encrypted with the existing key and
encryption algorithm.
-Cookie is also send in this payload. Cookie is used to uniform the
-payload so that none of the key exchange parties cannot determine this
+A cookie is also sent in this payload. A cookie is used to uniform the
+payload so that none of the key exchange parties can determine this
payload before hand. The cookie must be returned to the original sender
by the responder.
+
.in 5
.nf
1 2 3
| Hash Alg Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
-~ Hash Algorithms ~
+~ Hash Algorithms ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| HMAC Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ HMACs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Compression Alg Length | |
o Encryption Algorithms (variable length) - The list of
encryption algorithms.
-o Hash Alg Length (2 bytes) - The length of the Hash algorithms
+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.
+o Hash Algorithms (variable length) - The list of Hash
+ algorithms. The hash algorithms are mainly used in the
+ SKE protocol.
+
+o HMAC Length (2 bytes) - The length of the HMAC list, not
+ including any other field.
+
+o HMACs (variable length) - The list of HMACs. The HMAC's
+ are used to compute the Message Authentication Codes (MAC)
+ of the SILC packets.
o Compression Alg Length (2 bytes) - The length of the
compression algorithms list, not including any other field.
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.
+ sending SILC_PACKET_FAILURE message and the connection should
+ be closed immediately.
o Public Data Length (2 bytes) - The length of the public
data computed by the responder, not including any other
If any of these phases is to fail SILC_PACKET_FAILURE is sent to
-indicate that the key exchange protocol failed. Any other packets must
-not be sent or accepted during the key exchange except the
-SILC_PACKET_KEY_EXCHANGE_*, SILC_PACKET_DISCONNECT, SILC_PACKET_FAILURE
-and/or SILC_PACKET_SUCCESS packets.
+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
+
.ti 0
2.3 Processing the Key Material
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 doesn't have to be the first on the list).
+requested group (however, it does not have to be the first on the list).
.ti 0
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.
-Following status types are defined:
+The length of status is 32 bits (4 bytes). Following status types are
+defined:
.in 6
0 SILC_SKE_STATUS_OK
- Protocol were exeucted succesfully.
+ Protocol were executed successfully.
1 SILC_SKE_STATUS_ERROR
None of the provided hash functions were supported.
-7 SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY
+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.
-8 SILC_SKE_STATUS_INCORRECT_SIGNATURE
+9 SILC_SKE_STATUS_INCORRECT_SIGNATURE
Provided signature was incorrect.
+
+
+10 SILC_SKE_STATUS_BAD_VERSION
+
+ Provided version string was not acceptable.
.in 3
SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload,
described in the next section. This payload must include the
authentication data. 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 must
+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
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.
-Following status types are defined:
+The length of status is 32 bits (4 bytes). Following status types are
+defined:
0 SILC_AUTH_OK
- Protocol was executed succesfully.
+ Protocol was executed successfully.
1 SILC_AUTH_FAILED
4 Security Considerations
Security is central to the design of this protocol, and these security
-considerations permeate the specification.
+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.
.ti 0
[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.
Key Management Protocol (ISAKMP)", RFC 2408, November
1998.
-[IKE] Harkins D., and Carrel D., "The Internet Key Exhange
+[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.
+
.ti 0
6 Author's Address
EMail: priikone@poseidon.pspt.fi
-This Internet-Draft expires 13 May 2001
+This Internet-Draft expires 6 Jun 2001
projects / runtime.git / blobdiff