.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet-Draft
-.ds RH XXX
+.ds RH 15 May 2002
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-ke-auth-05.txt XXX
-Expires: XXX
+draft-riikonen-silc-ke-auth-05.txt 15 May 2002
+Expires: 15 November 2002
.in 3
2.1.2 Key Exchange Payload ................................ 8
2.2 Key Exchange Procedure .................................... 10
2.3 Processing the Key Material ............................... 12
- 2.4 SILC Key Exchange Groups .................................. 13
+ 2.4 SILC Key Exchange Groups .................................. 14
2.4.1 diffie-hellman-group1 ............................... 14
2.4.2 diffie-hellman-group2 ............................... 14
2.5 Key Exchange Status Types ................................. 15
3.1 Connection Auth Payload ................................... 18
3.2 Connection Authentication Types ........................... 19
3.2.1 Passphrase Authentication ........................... 19
- 3.2.2 Public Key Authentication ........................... 19
+ 3.2.2 Public Key Authentication ........................... 20
3.3 Connection Authentication Status Types .................... 20
-4 Security Considerations ....................................... 20
-5 References .................................................... 20
+4 Security Considerations ....................................... 21
+5 References .................................................... 21
6 Author's Address .............................................. 22
The SILC Connection Authentication protocol provides user level
authentication used when creating connections in SILC network. The
protocol is transparent to the authentication data which means that it
-can be used to authenticate the user with, for example, pass phrase
+can be used to authenticate the user with, for example, passphrase
(pre-shared- secret) or public key (and certificate).
The basis of secure SILC session requires strong and secure key exchange
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.
+sent by responder MUST include only one chosen property per list. The
+character encoding for the security property values as defined in [SILC1]
+SHOULD be UTF-8 [RFC2279].
The Key Exchange Start Payload is used to tell connecting entities what
security properties and algorithms should be used in the communication.
Following diagram represents the Key Exchange Start Payload. The lists
mentioned below are always comma (`,') separated and the list MUST NOT
-include spaces (` ').
+include white spaces (` ').
.in 5
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
+possession 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
be closed immediately.
o Public Key (or certificate) (variable length) - The
- public key or certificate.
+ 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.
o Public Data Length (2 bytes) - The length of the Public Data
field, not including any other field.
The length of this group is 1536 bits. This is OPTIONAL group.
The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
+
+
+
Its decimal value is
.in 6
Provided version string was not acceptable.
+
11 SILC_SKE_STATUS_INVALID_COOKIE
The cookie in the Key Exchange Start Payload was malformed,
If authentication method is passphrase the authentication data is
plaintext passphrase. As the payload is entirely encrypted it is safe
-to have plaintext passphrase. See the section 3.2.1 Passphrase
-Authentication for more information.
+to have plaintext passphrase. It is also provided as plaintext passphrase
+because the receiver may need to pass the entire passphrase into a
+passphrase checker, and hash digest of the passphrase would prevent this.
+See the section 3.2.1 Passphrase Authentication for more information.
If authentication method is public key authentication the authentication
data is a signature of the hash value of hash HASH plus Key Exchange
Passphrase authentication or pre-shared-key based authentication is
simply an authentication where the party that wants to authenticate
itself to the other end sends the passphrase that is required by
-the other end, for example server.
+the other end, for example server. The plaintext passphrase is put
+to the payload, that is then encrypted. The plaintext passphrase
+MUST be in UTF-8 [RFC2279] encoding. If the passphrase is in the
+sender's system in some other encoding it MUST be UTF-8 encoded
+before transmitted. The receiver MAY change the encoding of the
+passphrase to its system's default character encoding before verifying
+the passphrase.
If the passphrase matches with the one in the server's end the
authentication is successful. Otherwise SILC_PACKET_FAILURE MUST be
packet.
+
.ti 0
3.2.2 Public Key Authentication
The length of status is 32 bits (4 bytes). The following status types
are defined:
-
-
0 SILC_AUTH_OK
Protocol was executed successfully.
Authentication failed.
+
+
.ti 0
4 Security Considerations
security of this protocol.
+
.ti 0
5 References
[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
- Protocol Specification", Internet Draft, April 2001.
+ Protocol Specification", Internet Draft, May 2002.
[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
- April 2001.
+ May 2002.
-[SILC4] Riikonen, P., "SILC Commands", Internet Draft, April 2001.
+[SILC4] Riikonen, P., "SILC Commands", Internet Draft, May 2002.
[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
RFC 1459, May 1993.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
+[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
.ti 0
6 Author's Address
.nf
Pekka Riikonen
-Snellmanninkatu 34 A 15
+Snellmaninkatu 34 A 15
70100 Kuopio
Finland
-EMail: priikone@silcnet.org
+EMail: priikone@iki.fi
-This Internet-Draft expires XXX
+This Internet-Draft expires 15 November 2002
projects / crypto.git / blobdiff