idnits 2.17.1 draft-ietf-secsh-userauth-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 92: '...is reserved, and MUST NOT be listed as...' RFC 2119 keyword, line 93: '...ed. However, it MAY be sent by the cl...' RFC 2119 keyword, line 95: '...which case the server MUST accept this...' RFC 2119 keyword, line 99: '...The server SHOULD have a timeout for a...' RFC 2119 keyword, line 102: '...implementation SHOULD limit the number...' (59 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 113 has weird spacing: '... string use...' == Line 114 has weird spacing: '... string ser...' == Line 115 has weird spacing: '... string met...' == Line 154 has weird spacing: '... string aut...' == Line 155 has weird spacing: '...boolean part...' == (41 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC-1766' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'RFC-2044' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'SSH-CONNECT' is defined on line 544, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) -- No information found for draft-secsh-architecture - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-ARCH' -- No information found for draft-secsh-transport - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-TRANS' -- No information found for draft-secsh-connect - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-CONNECT' Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Ylonen 2 INTERNET-DRAFT T. Kivinen 3 draft-ietf-secsh-userauth-08.txt M. Saarinen 4 Expires in six months T. Rinne 5 S. Lehtinen 6 SSH Communications Security 7 21 Nov, 2000 9 SSH Authentication Protocol 11 Status of This memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 SSH is a protocol for secure remote login and other secure network ser- 36 vices over an insecure network. This document describes the SSH authen- 37 tication protocol framework and public key, password, and host-based 38 client authentication methods. Additional authentication methods are 39 described in separate documents. The SSH authentication protocol runs 40 on top of the SSH transport layer protocol and provides a single authen- 41 ticated tunnel for the SSH connection protocol. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 46 2. The Authentication Protocol Framework . . . . . . . . . . . . . 2 47 2.1. Authentication Requests . . . . . . . . . . . . . . . . . . 3 48 2.2. Responses to Authentication Requests . . . . . . . . . . . . 4 49 2.3. The "none" Authentication Request . . . . . . . . . . . . . 4 50 2.4. Completion of User Authentication . . . . . . . . . . . . . 5 51 2.5. Banner Message . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. Authentication Protocol Message Numbers . . . . . . . . . . . . 5 53 4. Public Key Authentication Method: publickey . . . . . . . . . . 6 54 5. Password Authentication Method: password . . . . . . . . . . . . 7 55 6. Host-Based Authentication: hostbased . . . . . . . . . . . . . . 9 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 57 8. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . . 10 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 61 1. Introduction 63 The SSH authentication protocol is a general-purpose user authentication 64 protocol. It is intended to be run over the SSH transport layer protocol 65 [SSH-TRANS]. This protocol assumes that the underlying protocols provide 66 integrity and confidentiality protection. 68 This document should be read only after reading the SSH architecture 69 document [SSH-ARCH]. This document freely uses terminology and notation 70 from the architecture document without reference or further explanation. 72 The service name for this protocol is "ssh-userauth". 74 When this protocol starts, it receives the session identifier from the 75 lower-level protocol (this is the exchange hash H from the first key 76 exchange). The session identifier uniquely identifies this session and 77 is suitable for signing in order to prove ownership of a private key. 78 This protocol also needs to know whether the lower-level protocol 79 provides confidentiality protection. 81 2. The Authentication Protocol Framework 83 The server drives the authentication by telling the client which 84 authentication methods can be used to continue the exchange at any given 85 time. The client has the freedom to try the methods listed by the server 86 in any order. This gives the server complete control over the 87 authentication process if desired, but also gives enough flexibility for 88 the client to use the methods it supports or that are most convenient 89 for the user, when multiple methods are offered by the server. 91 Authentication methods are identified by their name, as defined in [SSH- 92 ARCH]. The "none" method is reserved, and MUST NOT be listed as 93 supported. However, it MAY be sent by the client. The server MUST 94 always reject this request, unless the client is to be allowed in 95 without any authentication, in which case the server MUST accept this 96 request. The main purpose of sending this request is to get the list of 97 supported methods from the server. 99 The server SHOULD have a timeout for authentication, and disconnect if 100 the authentication has not been accepted within the timeout period. The 101 RECOMMENDED timeout period is 10 minutes. Additionally, the 102 implementation SHOULD limit the number of failed authentication attempts 103 a client may perform in a single session (the RECOMMENDED limit is 20 104 attempts). If the threshold is exceeded, the server SHOULD disconnect. 106 2.1. Authentication Requests 108 All authentication requests MUST use the following message format. Only 109 the first few fields are defined; the remaining fields depend on the 110 authentication method. 112 byte SSH_MSG_USERAUTH_REQUEST 113 string user name (in ISO-10646 UTF-8 encoding) 114 string service name (in US-ASCII) 115 string method name (US-ASCII) 116 The rest of the packet is method-specific. 118 The user name and service are repeated in every new authentication 119 attempt, and MAY change. The server implementation MUST carefully check 120 them in every message, and MUST flush any accumulated authentication 121 states if they change. If it is unable to flush some authentication 122 state, it MUST disconnect if the user or service name changes. 124 The service name specifies the service to start after authentication. 125 There may be several different authenticated services provided. If the 126 requested service is not available, the server MAY disconnect 127 immediately or at any later time. Sending a proper disconnect message 128 is RECOMMENDED. In any case, if the service does not exist, 129 authentication MUST NOT be accepted. 131 If the requested user does not exist, the server MAY disconnect, or MAY 132 send a bogus list of acceptable authentication methods, but never accept 133 any. This makes it possible for the server to avoid disclosing 134 information on which accounts exist. In any case, if the user does not 135 exist, the authentication request MUST NOT be accepted. 137 While there is usually little point for clients to send requests that 138 the server does not list as acceptable, sending such requests is not an 139 error, and the server SHOULD simply reject requests that it does not 140 recognize. 142 An authentication request MAY result in a further exchange of messages. 143 All such messages depend on the authentication method used, and the 144 client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST 145 message, in which case the server MUST abandon the previous 146 authentication attempt and continue with the new one. 148 2.2. Responses to Authentication Requests 150 If the server rejects the authentication request, it MUST respond with 151 the following: 153 byte SSH_MSG_USERAUTH_FAILURE 154 string authentications that can continue 155 boolean partial success 157 "Authentications that can continue" is a comma-separated list of 158 authentication method names that may productively continue the 159 authentication dialog. 161 It is RECOMMENDED that servers only include those methods in the list 162 that are actually useful. However, it is not illegal to include methods 163 that cannot be used to authenticate the user. 165 Already successfully completed authentications SHOULD NOT be included in 166 the list, unless they really should be performed again for some reason. 168 "Partial success" MUST be TRUE if the authentication request to which 169 this is a response was successful. It MUST be FALSE if the request was 170 not successfully processed. 172 When the server accepts authentication, it MUST respond with the 173 following: 175 byte SSH_MSG_USERAUTH_SUCCESS 177 Note that this is not sent after each step in a multi-method 178 authentication sequence, but only when the authentication is complete. 180 The client MAY send several authentication requests without waiting for 181 responses from previous requests. The server MUST acknowledge any 182 failed requests with a SSH_MSG_USERAUTH_FAILURE message. However, 183 SSH_MSG_USERAUTH_SUCCESS MUST be sent only once, and once 184 SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication 185 requests received after that SHOULD be silently ignored. 187 Any non-authentication messages sent by the client after the request 188 that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed to 189 the service being run on top of this protocol. Such messages can be 190 identified by their message numbers (see Section ``Message Numbers''). 192 2.3. The "none" Authentication Request 194 A client may request a list of authentication methods that may continue 195 by using the "none" authentication method. 197 If no authentication at all is needed for the user, the server MUST 198 return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return 199 SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of authentication 200 methods that can continue. 202 This method MUST NOT be listed as supported by the server. 204 2.4. Completion of User Authentication 206 Authentication is complete when the server has responded with 207 SSH_MSG_USERAUTH_SUCCESS; all authentication related messages received 208 after sending this message SHOULD be silently ignored. 210 After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the requested 211 service. 213 2.5. Banner Message 215 In some jurisdictions, sending a warning message before authentication 216 may be relevant for getting legal protection. Many UNIX machines, for 217 example, normally display text from `/etc/issue', or use "tcp wrappers" 218 or similar software to display a banner before issuing a login prompt. 220 The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time 221 before authentication is successful. This message contains text to be 222 displayed to the client user before authentication is attempted. The 223 format is as follows: 225 byte SSH_MSG_USERAUTH_BANNER 226 string message (ISO-10646 UTF-8) 227 string language tag (as defined in RFC 1766) 229 The client SHOULD by default display the message on the screen. 230 However, since the message is likely to be sent for every login attempt, 231 and since some client software will need to open a separate window for 232 this warning, the client software may allow the user to explicitly 233 disable the display of banners from the server. The message may consist 234 of multiple lines. 236 If the message string is displayed, control character filtering 237 discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending 238 terminal control characters. 240 3. Authentication Protocol Message Numbers 242 All message numbers used by this authentication protocol are in the 243 range from 50 to 79, which is part of the range reserved for protocols 244 running on top of the SSH transport layer protocol. 246 Message numbers of 80 and higher are reserved for protocols running 247 after this authentication protocol, so receiving one of them before 248 authentication is complete is an error, to which the server MUST respond 249 by disconnecting (preferably with a proper disconnect message sent first 250 to ease troubleshooting). 252 After successful authentication, such messages are passed to the higher- 253 level service. 255 These are the general authentication message codes: 257 #define SSH_MSG_USERAUTH_REQUEST 50 258 #define SSH_MSG_USERAUTH_FAILURE 51 259 #define SSH_MSG_USERAUTH_SUCCESS 52 260 #define SSH_MSG_USERAUTH_BANNER 53 262 In addition to the above, there is a range of message numbers (60..79) 263 reserved for method-specific messages. These messages are only sent by 264 the server (client sends only SSH_MSG_USERAUTH_REQUEST messages). 265 Different authentication methods reuse the same message numbers. 267 4. Public Key Authentication Method: publickey 269 The only REQUIRED authentication method is public key authentication. 270 All implementations MUST support this method; however, not all users 271 need to have public keys, and most local policies are not likely to 272 require public key authentication for all users in the near future. 274 With this method, the possession of a private key serves as 275 authentication. This method works by sending a signature created with a 276 private key of the user. The server MUST check that the key is a valid 277 authenticator for the user, and MUST check that the signature is valid. 278 If both hold, the authentication request MUST be accepted; otherwise it 279 MUST be rejected. (Note that the server MAY require additional 280 authentications after successful authentication.) 281 Private keys are often stored in an encrypted form at the client host, 282 and the user must supply a passphrase before the signature can be 283 generated. Even if they are not, the signing operation involves some 284 expensive computation. To avoid unnecessary processing and user 285 interaction, the following message is provided for querying whether 286 authentication using the key would be acceptable. 288 byte SSH_MSG_USERAUTH_REQUEST 289 string user name 290 string service 291 string "publickey" 292 boolean FALSE 293 string public key algorithm name 294 string public key blob 296 Public key algorithms are defined in the transport layer specification 297 [SSH-TRANS]. The public key blob may contain certificates. 299 Any public key algorithm may be offered for use in authentication. In 300 particular, the list is not constrained by what was negotiated during 301 key exchange. If the server does not support some algorithm, it MUST 302 simply reject the request. 304 The server MUST respond to this message with either 305 SSH_MSG_USERAUTH_FAILURE or with the following: 307 byte SSH_MSG_USERAUTH_PK_OK 308 string public key algorithm name from the request 309 string public key blob from the request 311 To perform actual authentication, the client MAY then send a signature 312 generated using the private key. The client MAY send the signature 313 directly without first verifying whether the key is acceptable. The 314 signature is sent using the following packet: 316 byte SSH_MSG_USERAUTH_REQUEST 317 string user name 318 string service 319 string "publickey" 320 boolean TRUE 321 string public key algorithm name 322 string public key to be used for authentication 323 string signature 325 Signature is a signature by the corresponding private key over the 326 following data, in the following order: 328 string session identifier 329 byte SSH_MSG_USERAUTH_REQUEST 330 string user name 331 string service 332 string "publickey" 333 boolean TRUE 334 string public key algorithm name 335 string public key to be used for authentication 337 When the server receives this message, it MUST check whether the 338 supplied key is acceptable for authentication, and if so, it MUST check 339 whether the signature is correct. 341 If both checks succeed, this method is successful. Note that the server 342 may require additional authentications. The server MUST respond with 343 SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or 344 SSH_MSG_USERAUTH_FAILURE (if the request failed, or more authentications 345 are needed). 347 The following method-specific message numbers are used by the publickey 348 authentication method. 350 /* Key-based */ 351 #define SSH_MSG_USERAUTH_PK_OK 60 353 5. Password Authentication Method: password 355 Password authentication uses the following packets. Note that a server 356 MAY request the user to change the password. All implementations SHOULD 357 support password authentication. 359 byte SSH_MSG_USERAUTH_REQUEST 360 string user name 361 string service 362 string "password" 363 boolean FALSE 364 string plaintext password (ISO-10646 UTF-8) 366 Note that the password is encoded in ISO-10646 UTF-8. It is up to the 367 server how it interprets the password and validates it against the 368 password database. However, if the client reads the password in some 369 other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert the 370 password to ISO-10646 UTF-8 before transmitting, and the server MUST 371 convert the password to the encoding used on that system for passwords. 373 Note that even though the cleartext password is transmitted in the 374 packet, the entire packet is encrypted by the transport layer. Both the 375 server and the client should check whether the underlying transport 376 layer provides confidentiality (i.e., if encryption is being used). If 377 no confidentiality is provided (none cipher), password authentication 378 SHOULD be disabled. If there is no confidentiality or no MAC, password 379 change SHOULD be disabled. 381 Normally, the server responds to this message with success or failure. 382 However, the server MAY also respond with 383 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 385 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 386 string prompt (ISO-10646 UTF-8) 387 string language tag (as defined in RFC 1766) 389 In this case, the software client SHOULD request a new password from the 390 user, and send a new request using the following message. The client 391 may also send this message instead of the normal password authentication 392 request without the server asking for it. 394 byte SSH_MSG_USERAUTH_REQUEST 395 string user name 396 string service 397 string "password" 398 boolean TRUE 399 string plaintext old password (ISO-10646 UTF-8) 400 string plaintext new password (ISO-10646 UTF-8) 402 The server must reply to request message with SSH_MSG_USERAUTH_SUCCESS, 403 SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 404 The meaning of these is as follows: 406 SSH_MSG_USERAUTH_SUCCESS 407 The password has been changed, and authentication has been 408 successfully completed. 410 SSH_MSG_USERAUTH_FAILURE with partial success 411 The password has been changed, but more authentications are 412 needed. 414 SSH_MSG_USERAUTH_FAILURE without partial success 415 The password has not been changed. Either password changing was 416 not supported, or the old password was bad. Note that if the 417 server has already sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know 418 that it supports changing the password. 420 SSH_MSG_USERAUTH_CHANGEREQ 421 The password was not changed because the new password was not 422 acceptable (e.g. too easy to guess). 424 The following method-specific message numbers are used by the password 425 authentication method. 427 #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 429 6. Host-Based Authentication: hostbased 431 Some sites wish to allow authentication based on the host where the user 432 is coming from, and the user name on the remote host. While this form 433 of authentication is not suitable for high-security sites, it can be 434 very convenient in many environments. This form of authentication is 435 OPTIONAL. When used, special care SHOULD be taken to prevent a regular 436 user from obtaining the private host key. 438 The client requests this form of authentication by sending the following 439 message. It is similar to the UNIX "rhosts" and "hosts.equiv" styles of 440 authentication, except that the identity of the client host is checked 441 more rigorously. 443 This method works by having the client send a signature created with the 444 private key of the client host, which the server checks with that host's 445 public key. Once the client host's identity is established, 446 authorization (but no further authentication) is performed based on the 447 user names on the server and the client, and the client host name. 449 byte SSH_MSG_USERAUTH_REQUEST 450 string user name 451 string service 452 string "hostbased" 453 string public key algorithm for host key 454 string public host key and certificates for client host 455 string client host name (FQDN; US-ASCII) 456 string client user name on the remote host (ISO-10646 UTF-8) 457 string signature 459 Public key algorithm names for use in "public key algorithm for host 460 key" are defined in the transport layer specification. The "public host 461 key for client host" may include certificates. 463 Signature is a signature with the private host key of the following 464 data, in this order: 466 string session identifier 467 byte SSH_MSG_USERAUTH_REQUEST 468 string user name 469 string service 470 string "hostbased" 471 string public key algorithm for host key 472 string public host key and certificates for client host 473 string client host name (FQDN; US-ASCII) 474 string client user name on the remote host (ISO-10646 UTF-8) 476 The server MUST verify that the host key actually belongs to the client 477 host named in the message, that the given user on that host is allowed 478 to log in, and that the signature is a valid signature on the 479 appropriate value by the given host key. The server MAY ignore the 480 client user name, if it wants to authenticate only the client host. 482 It is RECOMMENDED that whenever possible, the server perform additional 483 checks to verify that the network address obtained from the (untrusted) 484 network matches the given client host name. This makes exploiting 485 compromised host keys more difficult. Note that this may require 486 special handling for connections coming through a firewall. 488 7. Security Considerations 490 The purpose of this protocol is to perform client user authentication. 491 It assumed that this runs over a secure transport layer protocol, which 492 has already authenticated the server machine, established an encrypted 493 communications channel, and computed a unique session identifier for 494 this session. The transport layer provides forward secrecy for password 495 authentication and other methods that rely on secret data. 497 The server may go into a "sleep" period after repeated unsuccessful 498 authentications to make key search harder. 500 If the transport layer does not provide encryption, authentication 501 methods that rely on secret data SHOULD be disabled. If it does not 502 provide MAC protection, requests to change authentication data (e.g. 503 password change) SHOULD be disabled to avoid an attacker from modifying 504 the ciphertext without being noticed, rendering the new authentication 505 data unusable (denial of service). 507 Several authentication methods with different security characteristics 508 are allowed. It is up to the server's local policy to decide which 509 methods (or combinations of methods) it is willing to accept for each 510 user. Authentication is no stronger than the weakest combination 511 allowed. 513 Special care should be taken when designing debug messages. These 514 messages may reveal surprising amounts of information about the host if 515 not properly designed. Debug messages can be disabled (during user 516 authentication phase) if high security is required. 517 8. Trademark Issues 519 SSH is a registered trademark and Secure Shell is a trademark of SSH 520 Communications Security Corp. SSH Communications Security Corp permits 521 the use of these trademarks as the name of this standard and protocol, 522 and permits their use to describe that a product conforms to this 523 standard, provided that the following acknowledgement is included where 524 the trademarks are used: ''SSH is a registered trademark and Secure 525 Shell is a trademark of SSH Communications Security Corp 526 (www.ssh.com)''. These trademarks may not be used as part of a product 527 name or in otherwise confusing manner without prior written permission 528 of SSH Communications Security Corp. 530 9. References 532 [RFC-1766] Alvestrand, H: "Tags for the Identification of Languages", 533 March 1995. 535 [RFC-2044] Yergeau, F: "UTF-8, a Transformation Format of Unicode and 536 ISO 10646", October 1996. 538 [SSH-ARCH] Ylonen, T., et al: "SSH Protocol Architecture", Internet 539 Draft, draft-secsh-architecture-05.txt 541 [SSH-TRANS] Ylonen, T., et al: "SSH Transport Layer Protocol", Internet 542 Draft, draft-secsh-transport-07.txt 544 [SSH-CONNECT] Ylonen, T., et al: "SSH Connection Protocol", Internet 545 Draft, draft-secsh-connect-07.txt 547 10. Authors' Addresses 549 Tatu Ylonen 550 SSH Communications Security Corp 551 Fredrikinkatu 42 552 FIN-00100 HELSINKI 553 Finland 554 E-mail: ylo@ssh.com 556 Tero Kivinen 557 SSH Communications Security Corp 558 Fredrikinkatu 42 559 FIN-00100 HELSINKI 560 Finland 561 E-mail: kivinen@ssh.com 563 Markku-Juhani O. Saarinen 564 University of Jyvaskyla 566 Timo J. Rinne 567 SSH Communications Security Corp 568 Fredrikinkatu 42 569 FIN-00100 HELSINKI 570 Finland 571 E-mail: tri@ssh.com 572 Sami Lehtinen 573 SSH Communications Security Corp 574 Fredrikinkatu 42 575 FIN-00100 HELSINKI 576 Finland 577 E-mail: sjl@ssh.com