.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet-Draft
-.ds RH XXX
+.ds RH 13 November 2001
.ds CH
.na
.hy 0
.in 0
.nf
-Network Working Group P. Riikonen
+Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-ke-auth-04.txt XXX
-Expires: XXX
+draft-riikonen-silc-ke-auth-04.txt 13 November 2001
+Expires: 13 May 2002
.in 3
2.5 Key Exchange Status Types ................................. 15
3 SILC Connection Authentication Protocol ....................... 16
3.1 Connection Auth Payload ................................... 18
- 3.2 Connection Authentication Types ........................... 18
+ 3.2 Connection Authentication Types ........................... 19
3.2.1 Passphrase Authentication ........................... 19
3.2.2 Public Key Authentication ........................... 19
- 3.3 Connection Authentication Status Types .................... 19
+ 3.3 Connection Authentication Status Types .................... 20
4 Security Considerations ....................................... 20
5 References .................................................... 20
-6 Author's Address .............................................. 21
+6 Author's Address .............................................. 22
.ti 0
returned to the original sender 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 spaces (` ').
+mentioned below are always comma (`,') separated and the list MUST NOT
+include spaces (` ').
.in 5
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 only if a separate
+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 the
-server, or server is connecting to the router the Mutual Authentication
-flag is not necessary.
+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 public key authentication (it
+is based on passphrase) then the Mutual Authentication flag SHOULD be
+enabled. This way the connecting entity has to provide proof of
+posession of the private key for the public key it will provide in
+SILC Key Exchange 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
1. Initiator generates a random number x, where 1 < x < q,
and computes e = g ^ x mod p. The result e is then
- encoded into Key Exchange Payload and sent to the
- responder.
+ 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
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) | e | f | KEY). It then signs
+ 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.
Receiving Initial Vector (IV) = hash(1 | KEY | HASH)
Sending Encryption Key = hash(2 | KEY | HASH)
Receiving Encryption Key = hash(3 | KEY | HASH)
-HMAC Key = hash(4 | KEY | HASH)
+Sending HMAC Key = hash(4 | KEY | HASH)
+Receiving HMAC Key = hash(5 | KEY | HASH)
.in 3
receiving key. Initiator uses generated keys as they are (sending key
for sending and receiving key for receiving).
-The HMAC key is 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.
+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
Authentication for more information.
If authentication method is public key authentication the authentication
-data is signature of the hash value HASH plus 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.
+data is a signature of the hash value of hash HASH plus 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.
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
.in 3
+
+
.ti 0
3.2 Connection Authentication Types
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.
+
.ti 0
3.2.2 Public Key Authentication
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.
-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 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.
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.
+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.
EMail: priikone@silcnet.org
-This Internet-Draft expires XXX
+This Internet-Draft expires 13 May 2002
projects / crypto.git / blobdiff