Added SILC Thread Queue API
[crypto.git] / doc / draft-riikonen-silc-ke-auth-01.nroff
index 4fff906d2d673d68dc1b6154b1d4ee730bd15a04..0adf9b83800b5831314e3d4f7f4f29f27aa37973 100644 (file)
@@ -7,8 +7,8 @@
 .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
@@ -16,8 +16,8 @@
 .nf
 Network Working Group                                      P. Riikonen
 Internet-Draft
-draft-riikonen-silc-ke-auth-01.txt                   13 September 2000
-Expires: 13 May 2001
+draft-riikonen-silc-ke-auth-01.txt                      6 October 2000
+Expires: 6 Jun 2001
 
 .in 3
 
@@ -111,7 +111,7 @@ Figure 4:  Connection Auth Payload
 
 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
@@ -166,6 +166,9 @@ servers.  In client connections usually all the packets are protected
 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
@@ -220,6 +223,7 @@ not include spaces (` ').
 
 
 
+
 .in 5
 .nf
                      1                   2                   3
@@ -262,7 +266,13 @@ not include spaces (` ').
 |       Hash Alg Length         |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
-~                        Hash Algorithms                        ~
+~                         Hash Algorithms                       ~
+|                                                               |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|         HMAC Length           |                               |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+|                                                               |
+~                             HMACs                             ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Compression Alg Length     |                               |
@@ -341,10 +351,19 @@ o Encryption Alg Length (2 bytes) - The length of the encryption
 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.
@@ -430,7 +449,8 @@ o Public Key Type (2 bytes) - The public key (or certificate)
   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
@@ -573,10 +593,10 @@ Setup:  p is a large and public safe prime.  This is one of the
 
 
 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 
@@ -591,6 +611,7 @@ each other.  After this both parties will start using the new keys.
 
 
 
+
 .ti 0
 2.3 Processing the Key Material
 
@@ -750,12 +771,13 @@ 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.
-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
@@ -788,14 +810,24 @@ Following status types are defined:
     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
 
 
@@ -830,8 +862,8 @@ The protocol is started by the connecting party by sending
 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
@@ -969,11 +1001,12 @@ 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.
-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
@@ -985,7 +1018,10 @@ Following status types are defined:
 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
@@ -1000,6 +1036,18 @@ considerations permeate the specification.
 [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.
 
@@ -1026,12 +1074,15 @@ considerations permeate the specification.
              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
@@ -1044,5 +1095,5 @@ Finland
 
 EMail: priikone@poseidon.pspt.fi
 
-This Internet-Draft expires 13 May 2001 
+This Internet-Draft expires 6 Jun 2001