o Cookie (16 bytes) - Cookie that randomize this payload so
that each of the party cannot determine the payload before
- hand.
+ hand. This field MUST be present.
o Version String Length (2 bytes) - The length of the Version
String field, not including any other field.
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 of the version
- string format.
+ 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.
+ 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.
+ 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.
+ 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.
+ SKE protocol. This field MUST be present.
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.
+ 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.
+ compression algorithms. This field MAY be omitted.
.in 3
be closed immediately.
o Public Key (or certificate) (variable length) - The
- public key or certificate. The public key or certificate
- in this field is encoded in the manner as defined in their
- respective definitions; see previous field.
+ public key or certificate of the party. This public key
+ is 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. See section 2.2 Key Exchange
- Procedure for detailed description how this field is
- computed. This value is binary encoded.
+ sent to the receiver (Diffie-Hellman public values). See
+ section 2.2 Key Exchange Procedure for detailed description
+ how this field is computed. This value is binary encoded.
o Signature Length (2 bytes) - The length of the signature,
not including any other field.
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(Key Exchange Start Payload | public key
- (or certificate) | e). It then signs the HASH_i value with
- its private key resulting a signature SIGN_i.
+ HASH_i = hash(Initiator's Key Exchange Start Payload |
+ public key (or certificate) | e). 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(Key Exchange Start Payload data | public
- key (or certificate) | Initiator's public key (or
- certificate) | e | f | KEY). It then signs
+ 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.
The keys MUST be derived from the key material as follows:
.in 6
-Sending Initial Vector (IV) = hash(0 | KEY | HASH)
-Receiving Initial Vector (IV) = hash(1 | KEY | HASH)
-Sending Encryption Key = hash(2 | KEY | HASH)
-Receiving Encryption Key = hash(3 | KEY | HASH)
-Sending HMAC Key = hash(4 | KEY | HASH)
-Receiving HMAC Key = hash(5 | KEY | HASH)
+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)
.in 3
be produced in the following manner:
.in 6
-K1 = hash(2 | KEY | HASH)
+K1 = hash(0x2 | KEY | HASH)
K2 = hash(KEY | HASH | K1)
K3 = hash(KEY | HASH | K1 | K2) ...
Sending Encryption Key = K1 | K2 | K3 ...
-K1 = hash(3 | KEY | HASH)
+K1 = hash(0x3 | KEY | HASH)
K2 = hash(KEY | HASH | K1)
K3 = hash(KEY | HASH | K1 | K2) ...
connection. Server uses this information to create the ID for the
connection.
-After the authentication protocol has been successfully completed
-SILC_PACKET_NEW_ID must be sent to the connecting client by the server.
-See the [SILC1] for the details of the connecting procedure.
-
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 everything checks out fine the protocol is ended by server by sending
signature MUST then be verified by the server. See the section 3.2.2
Public Key Authentication for more information.
-The connecting client of this protocol MUST wait after successful execution
-of this protocol for the SILC_PACKET_NEW_ID packet where it will receive
-the ID it will be using in the SILC network. The connecting client cannot
-start normal SILC session (sending messages or commands) until it has
-received its ID. The ID's are always created by the server except
-for server to router connection where servers create their own ID's.
+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.
.ti 0
projects / crypto.git / blobdiff