A LOT updates. Cannot separate. :)
[silc.git] / doc / draft-riikonen-silc-ke-auth-01.nroff
index f385571a95f50c91a9e1b354dbf53b2c731cf768..8f71edce74510b0987e17f730115dde7fa7d8cf3 100644 (file)
@@ -7,17 +7,17 @@
 .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
 
@@ -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
@@ -184,20 +184,13 @@ Following descriptions of these 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.
@@ -212,8 +205,8 @@ there are no existing keys to encrypt it with.  If performing re-keying
 (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.
 
@@ -227,6 +220,7 @@ not include spaces (` ').
 
 
 
+
 .in 5
 .nf
                      1                   2                   3
@@ -598,6 +592,7 @@ each other.  After this both parties will start using the new keys.
 
 
 
+
 .ti 0
 2.3 Processing the Key Material
 
@@ -673,7 +668,7 @@ first group diffie-hellman-group1 is mandatory, other groups maybe
 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
@@ -757,12 +752,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
@@ -803,6 +799,11 @@ Following status types are defined:
 8   SILC_SKE_STATUS_INCORRECT_SIGNATURE
 
     Provided signature was incorrect.
+
+
+9   SILC_SKE_STATUS_BAD_VERSION
+
+    Provided version string was not acceptable.
 .in 3
 
 
@@ -976,11 +977,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
@@ -1033,7 +1035,7 @@ 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
@@ -1051,5 +1053,5 @@ Finland
 
 EMail: priikone@poseidon.pspt.fi
 
-This Internet-Draft expires 13 May 2001 
+This Internet-Draft expires 6 Jun 2001