idnits 2.17.1 draft-ietf-secsh-userauth-10.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: ---------------------------------------------------------------------------- == 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 94: '...[SECSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as...' RFC 2119 keyword, line 95: '...ed. However, it MAY be sent by the cl...' RFC 2119 keyword, line 97: '...which case the server MUST accept this...' RFC 2119 keyword, line 101: '...The server SHOULD have a timeout for a...' RFC 2119 keyword, line 104: '...implementation SHOULD limit the number...' (59 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 115 has weird spacing: '... string use...' == Line 116 has weird spacing: '... string ser...' == Line 117 has weird spacing: '... string met...' == Line 156 has weird spacing: '... string aut...' == Line 157 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: 'SECSH-CONNECT' is defined on line 537, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) -- No information found for draft-secsh-architecture - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SECSH-ARCH' -- No information found for draft-secsh-transport - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SECSH-TRANS' -- No information found for draft-secsh-connect - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SECSH-CONNECT' Summary: 6 errors (**), 0 flaws (~~), 8 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-10.txt M. Saarinen 4 Expires: 2 September, 2001 T. Rinne 5 S. Lehtinen 6 SSH Communications Security 7 2 March, 2001 9 Secure Shell 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 The Secure Shell Remote Login Protocol is a protocol for secure remote 36 login and other secure network services over an insecure network. This 37 document describes the Secure Shell authentication protocol framework 38 and public key, password, and host-based client authentication methods. 39 Additional authentication methods are described in separate documents. 40 The Secure Shell Authentication Protocol runs on top of the Secure Shell 41 Transport Layer Protocol and provides a single authenticated tunnel for 42 the Secure Shell Connection Protocol. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 47 2. The Authentication Protocol Framework . . . . . . . . . . . . . 2 48 2.1. Authentication Requests . . . . . . . . . . . . . . . . . . 3 49 2.2. Responses to Authentication Requests . . . . . . . . . . . . 4 50 2.3. The "none" Authentication Request . . . . . . . . . . . . . 4 51 2.4. Completion of User Authentication . . . . . . . . . . . . . 5 52 2.5. Banner Message . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. Authentication Protocol Message Numbers . . . . . . . . . . . . 5 54 4. Public Key Authentication Method: publickey . . . . . . . . . . 6 55 5. Password Authentication Method: password . . . . . . . . . . . . 7 56 6. Host-Based Authentication: hostbased . . . . . . . . . . . . . . 9 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 58 8. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . . 10 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 62 1. Introduction 64 The Secure Shell Authentication Protocol is a general-purpose user 65 authentication protocol. It is intended to be run over the Secure Shell 66 Transport Layer Protocol [SECSH-TRANS]. This protocol assumes that the 67 underlying protocols provide integrity and confidentiality protection. 69 This document should be read only after reading the Secure Shell Remote 70 Login Protocol Architecture document [SECSH-ARCH]. This document freely 71 uses terminology and notation from the architecture document without 72 reference or further explanation. 74 The service name for this protocol is "ssh-userauth". 76 When this protocol starts, it receives the session identifier from the 77 lower-level protocol (this is the exchange hash H from the first key 78 exchange). The session identifier uniquely identifies this session and 79 is suitable for signing in order to prove ownership of a private key. 80 This protocol also needs to know whether the lower-level protocol 81 provides confidentiality protection. 83 2. The Authentication Protocol Framework 85 The server drives the authentication by telling the client which 86 authentication methods can be used to continue the exchange at any given 87 time. The client has the freedom to try the methods listed by the server 88 in any order. This gives the server complete control over the 89 authentication process if desired, but also gives enough flexibility for 90 the client to use the methods it supports or that are most convenient 91 for the user, when multiple methods are offered by the server. 93 Authentication methods are identified by their name, as defined in 94 [SECSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as 95 supported. However, it MAY be sent by the client. The server MUST 96 always reject this request, unless the client is to be allowed in 97 without any authentication, in which case the server MUST accept this 98 request. The main purpose of sending this request is to get the list of 99 supported methods from the server. 101 The server SHOULD have a timeout for authentication, and disconnect if 102 the authentication has not been accepted within the timeout period. The 103 RECOMMENDED timeout period is 10 minutes. Additionally, the 104 implementation SHOULD limit the number of failed authentication attempts 105 a client may perform in a single session (the RECOMMENDED limit is 20 106 attempts). If the threshold is exceeded, the server SHOULD disconnect. 108 2.1. Authentication Requests 110 All authentication requests MUST use the following message format. Only 111 the first few fields are defined; the remaining fields depend on the 112 authentication method. 114 byte SSH_MSG_USERAUTH_REQUEST 115 string user name (in ISO-10646 UTF-8 encoding [RFC-2279]) 116 string service name (in US-ASCII) 117 string method name (US-ASCII) 118 The rest of the packet is method-specific. 120 The user name and service are repeated in every new authentication 121 attempt, and MAY change. The server implementation MUST carefully check 122 them in every message, and MUST flush any accumulated authentication 123 states if they change. If it is unable to flush some authentication 124 state, it MUST disconnect if the user or service name changes. 126 The service name specifies the service to start after authentication. 127 There may be several different authenticated services provided. If the 128 requested service is not available, the server MAY disconnect 129 immediately or at any later time. Sending a proper disconnect message 130 is RECOMMENDED. In any case, if the service does not exist, 131 authentication MUST NOT be accepted. 133 If the requested user does not exist, the server MAY disconnect, or MAY 134 send a bogus list of acceptable authentication methods, but never accept 135 any. This makes it possible for the server to avoid disclosing 136 information on which accounts exist. In any case, if the user does not 137 exist, the authentication request MUST NOT be accepted. 139 While there is usually little point for clients to send requests that 140 the server does not list as acceptable, sending such requests is not an 141 error, and the server SHOULD simply reject requests that it does not 142 recognize. 144 An authentication request MAY result in a further exchange of messages. 145 All such messages depend on the authentication method used, and the 146 client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST 147 message, in which case the server MUST abandon the previous 148 authentication attempt and continue with the new one. 150 2.2. Responses to Authentication Requests 152 If the server rejects the authentication request, it MUST respond with 153 the following: 155 byte SSH_MSG_USERAUTH_FAILURE 156 string authentications that can continue 157 boolean partial success 159 "Authentications that can continue" is a comma-separated list of 160 authentication method names that may productively continue the 161 authentication dialog. 163 It is RECOMMENDED that servers only include those methods in the list 164 that are actually useful. However, it is not illegal to include methods 165 that cannot be used to authenticate the user. 167 Already successfully completed authentications SHOULD NOT be included in 168 the list, unless they really should be performed again for some reason. 170 "Partial success" MUST be TRUE if the authentication request to which 171 this is a response was successful. It MUST be FALSE if the request was 172 not successfully processed. 174 When the server accepts authentication, it MUST respond with the 175 following: 177 byte SSH_MSG_USERAUTH_SUCCESS 179 Note that this is not sent after each step in a multi-method 180 authentication sequence, but only when the authentication is complete. 182 The client MAY send several authentication requests without waiting for 183 responses from previous requests. The server MUST acknowledge any 184 failed requests with a SSH_MSG_USERAUTH_FAILURE message. However, 185 SSH_MSG_USERAUTH_SUCCESS MUST be sent only once, and once 186 SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication 187 requests received after that SHOULD be silently ignored. 189 Any non-authentication messages sent by the client after the request 190 that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed to 191 the service being run on top of this protocol. Such messages can be 192 identified by their message numbers (see Section ``Message Numbers''). 194 2.3. The "none" Authentication Request 196 A client may request a list of authentication methods that may continue 197 by using the "none" authentication method. 199 If no authentication at all is needed for the user, the server MUST 200 return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return 201 SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of authentication 202 methods that can continue. 204 This method MUST NOT be listed as supported by the server. 206 2.4. Completion of User Authentication 208 Authentication is complete when the server has responded with 209 SSH_MSG_USERAUTH_SUCCESS; all authentication related messages received 210 after sending this message SHOULD be silently ignored. 212 After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the requested 213 service. 215 2.5. Banner Message 217 In some jurisdictions, sending a warning message before authentication 218 may be relevant for getting legal protection. Many UNIX machines, for 219 example, normally display text from `/etc/issue', or use "tcp wrappers" 220 or similar software to display a banner before issuing a login prompt. 222 The server may send a SSH_MSG_USERAUTH_BANNER message at any time before 223 authentication is successful. This message contains text to be 224 displayed to the client user before authentication is attempted. The 225 format is as follows: 227 byte SSH_MSG_USERAUTH_BANNER 228 string message (ISO-10646 UTF-8) 229 string language tag (as defined in [RFC-1766]) 231 The client SHOULD by default display the message on the screen. 232 However, since the message is likely to be sent for every login attempt, 233 and since some client software will need to open a separate window for 234 this warning, the client software may allow the user to explicitly 235 disable the display of banners from the server. The message may consist 236 of multiple lines. 238 If the message string is displayed, control character filtering 239 discussed in [SECSH-ARCH] SHOULD be used to avoid attacks by sending 240 terminal control characters. 242 3. Authentication Protocol Message Numbers 244 All message numbers used by this authentication protocol are in the 245 range from 50 to 79, which is part of the range reserved for protocols 246 running on top of the Secure Shell Transport Layer Protocol. 248 Message numbers of 80 and higher are reserved for protocols running 249 after this authentication protocol, so receiving one of them before 250 authentication is complete is an error, to which the server MUST respond 251 by disconnecting (preferably with a proper disconnect message sent first 252 to ease troubleshooting). 254 After successful authentication, such messages are passed to the higher- 255 level service. 257 These are the general authentication message codes: 259 #define SSH_MSG_USERAUTH_REQUEST 50 260 #define SSH_MSG_USERAUTH_FAILURE 51 261 #define SSH_MSG_USERAUTH_SUCCESS 52 262 #define SSH_MSG_USERAUTH_BANNER 53 264 In addition to the above, there is a range of message numbers (60..79) 265 reserved for method-specific messages. These messages are only sent by 266 the server (client sends only SSH_MSG_USERAUTH_REQUEST messages). 267 Different authentication methods reuse the same message numbers. 269 4. Public Key Authentication Method: publickey 271 The only REQUIRED authentication method is public key authentication. 272 All implementations MUST support this method; however, not all users 273 need to have public keys, and most local policies are not likely to 274 require public key authentication for all users in the near future. 276 With this method, the possession of a private key serves as 277 authentication. This method works by sending a signature created with a 278 private key of the user. The server MUST check that the key is a valid 279 authenticator for the user, and MUST check that the signature is valid. 280 If both hold, the authentication request MUST be accepted; otherwise it 281 MUST be rejected. (Note that the server MAY require additional 282 authentications after successful authentication.) 283 Private keys are often stored in an encrypted form at the client host, 284 and the user must supply a passphrase before the signature can be 285 generated. Even if they are not, the signing operation involves some 286 expensive computation. To avoid unnecessary processing and user 287 interaction, the following message is provided for querying whether 288 authentication using the key would be acceptable. 290 byte SSH_MSG_USERAUTH_REQUEST 291 string user name 292 string service 293 string "publickey" 294 boolean FALSE 295 string public key algorithm name 296 string public key blob 298 Public key algorithms are defined in the transport layer specification 299 [SECSH-TRANS]. The public key blob may contain certificates. 301 Any public key algorithm may be offered for use in authentication. In 302 particular, the list is not constrained by what was negotiated during 303 key exchange. If the server does not support some algorithm, it MUST 304 simply reject the request. 306 The server MUST respond to this message with either 307 SSH_MSG_USERAUTH_FAILURE or with the following: 309 byte SSH_MSG_USERAUTH_PK_OK 310 string public key algorithm name from the request 311 string public key blob from the request 313 To perform actual authentication, the client MAY then send a signature 314 generated using the private key. The client MAY send the signature 315 directly without first verifying whether the key is acceptable. The 316 signature is sent using the following packet: 318 byte SSH_MSG_USERAUTH_REQUEST 319 string user name 320 string service 321 string "publickey" 322 boolean TRUE 323 string public key algorithm name 324 string public key to be used for authentication 325 string signature 327 Signature is a signature by the corresponding private key over the 328 following data, in the following order: 330 string session identifier 331 byte SSH_MSG_USERAUTH_REQUEST 332 string user name 333 string service 334 string "publickey" 335 boolean TRUE 336 string public key algorithm name 337 string public key to be used for authentication 339 When the server receives this message, it MUST check whether the 340 supplied key is acceptable for authentication, and if so, it MUST check 341 whether the signature is correct. 343 If both checks succeed, this method is successful. Note that the server 344 may require additional authentications. The server MUST respond with 345 SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or 346 SSH_MSG_USERAUTH_FAILURE (if the request failed, or more authentications 347 are needed). 349 The following method-specific message numbers are used by the publickey 350 authentication method. 352 /* Key-based */ 353 #define SSH_MSG_USERAUTH_PK_OK 60 355 5. Password Authentication Method: password 357 Password authentication uses the following packets. Note that a server 358 MAY request the user to change the password. All implementations SHOULD 359 support password authentication. 361 byte SSH_MSG_USERAUTH_REQUEST 362 string user name 363 string service 364 string "password" 365 boolean FALSE 366 string plaintext password (ISO-10646 UTF-8) 368 Note that the password is encoded in ISO-10646 UTF-8. It is up to the 369 server how it interprets the password and validates it against the 370 password database. However, if the client reads the password in some 371 other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert the 372 password to ISO-10646 UTF-8 before transmitting, and the server MUST 373 convert the password to the encoding used on that system for passwords. 375 Note that even though the cleartext password is transmitted in the 376 packet, the entire packet is encrypted by the transport layer. Both the 377 server and the client should check whether the underlying transport 378 layer provides confidentiality (i.e., if encryption is being used). If 379 no confidentiality is provided (none cipher), password authentication 380 SHOULD be disabled. If there is no confidentiality or no MAC, password 381 change SHOULD be disabled. 383 Normally, the server responds to this message with success or failure. 384 However, the server MAY also respond with 385 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 387 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 388 string prompt (ISO-10646 UTF-8) 389 string language tag (as defined in [RFC-1766]) 391 In this case, the software client SHOULD request a new password from the 392 user, and send a new request using the following message. The client 393 may also send this message instead of the normal password authentication 394 request without the server asking for it. 396 byte SSH_MSG_USERAUTH_REQUEST 397 string user name 398 string service 399 string "password" 400 boolean TRUE 401 string plaintext old password (ISO-10646 UTF-8) 402 string plaintext new password (ISO-10646 UTF-8) 404 The server must reply to request message with SSH_MSG_USERAUTH_SUCCESS, 405 SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 406 The meaning of these is as follows: 408 SSH_MSG_USERAUTH_SUCCESS 409 The password has been changed, and authentication has been 410 successfully completed. 412 SSH_MSG_USERAUTH_FAILURE with partial success 413 The password has been changed, but more authentications are 414 needed. 416 SSH_MSG_USERAUTH_FAILURE without partial success 417 The password has not been changed. Either password changing was 418 not supported, or the old password was bad. Note that if the 419 server has already sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know 420 that it supports changing the password. 422 SSH_MSG_USERAUTH_CHANGEREQ 423 The password was not changed because the new password was not 424 acceptable (e.g. too easy to guess). 426 The following method-specific message numbers are used by the password 427 authentication method. 429 #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 431 6. Host-Based Authentication: hostbased 433 Some sites wish to allow authentication based on the host where the user 434 is coming from, and the user name on the remote host. While this form 435 of authentication is not suitable for high-security sites, it can be 436 very convenient in many environments. This form of authentication is 437 OPTIONAL. When used, special care SHOULD be taken to prevent a regular 438 user from obtaining the private host key. 440 The client requests this form of authentication by sending the following 441 message. It is similar to the UNIX "rhosts" and "hosts.equiv" styles of 442 authentication, except that the identity of the client host is checked 443 more rigorously. 445 This method works by having the client send a signature created with the 446 private key of the client host, which the server checks with that host's 447 public key. Once the client host's identity is established, 448 authorization (but no further authentication) is performed based on the 449 user names on the server and the client, and the client host name. 451 byte SSH_MSG_USERAUTH_REQUEST 452 string user name 453 string service 454 string "hostbased" 455 string public key algorithm for host key 456 string public host key and certificates for client host 457 string client host name (FQDN; US-ASCII) 458 string client user name on the remote host (ISO-10646 UTF-8) 459 string signature 461 Public key algorithm names for use in "public key algorithm for host 462 key" are defined in the transport layer specification. The "public host 463 key for client host" may include certificates. 465 Signature is a signature with the private host key of the following 466 data, in this order: 468 string session identifier 469 byte SSH_MSG_USERAUTH_REQUEST 470 string user name 471 string service 472 string "hostbased" 473 string public key algorithm for host key 474 string public host key and certificates for client host 475 string client host name (FQDN; US-ASCII) 476 string client user name on the remote host (ISO-10646 UTF-8) 478 The server MUST verify that the host key actually belongs to the client 479 host named in the message, that the given user on that host is allowed 480 to log in, and that the signature is a valid signature on the 481 appropriate value by the given host key. The server MAY ignore the 482 client user name, if it wants to authenticate only the client host. 484 It is RECOMMENDED that whenever possible, the server perform additional 485 checks to verify that the network address obtained from the (untrusted) 486 network matches the given client host name. This makes exploiting 487 compromised host keys more difficult. Note that this may require 488 special handling for connections coming through a firewall. 490 7. Security Considerations 492 The purpose of this protocol is to perform client user authentication. 493 It assumed that this runs over a secure transport layer protocol, which 494 has already authenticated the server machine, established an encrypted 495 communications channel, and computed a unique session identifier for 496 this session. The transport layer provides forward secrecy for password 497 authentication and other methods that rely on secret data. 499 The server may go into a "sleep" period after repeated unsuccessful 500 authentications to make key search harder. 502 If the transport layer does not provide encryption, authentication 503 methods that rely on secret data SHOULD be disabled. If it does not 504 provide MAC protection, requests to change authentication data (e.g. 505 password change) SHOULD be disabled to avoid an attacker from modifying 506 the ciphertext without being noticed, rendering the new authentication 507 data unusable (denial of service). 509 Several authentication methods with different security characteristics 510 are allowed. It is up to the server's local policy to decide which 511 methods (or combinations of methods) it is willing to accept for each 512 user. Authentication is no stronger than the weakest combination 513 allowed. 515 Special care should be taken when designing debug messages. These 516 messages may reveal surprising amounts of information about the host if 517 not properly designed. Debug messages can be disabled (during user 518 authentication phase) if high security is required. 519 8. Trademark Issues 520 "ssh" is a registered trademark of SSH Communications Security Corp in 521 the United States and/or other countries. 523 9. References 525 [RFC-1766] Alvestrand, H: "Tags for the Identification of Languages", 526 March 1995. 528 [RFC-2279] Yergeau, F: "UTF-8, a transformation format of ISO 10646", 529 January 1998. 531 [SECSH-ARCH] Ylonen, T., et al: "Secure Shell Remote Login Protocol 532 Architecture", Internet-Draft, draft-secsh-architecture-08.txt 534 [SECSH-TRANS] Ylonen, T., et al: "Secure Shell Transport Layer 535 Protocol", Internet-Draft, draft-secsh-transport-10.txt 537 [SECSH-CONNECT] Ylonen, T., et al: "Secure Shell Connection Protocol", 538 Internet-Draft, draft-secsh-connect-10.txt 540 10. Authors' Addresses 542 Tatu Ylonen 543 SSH Communications Security Corp 544 Fredrikinkatu 42 545 FIN-00100 HELSINKI 546 Finland 547 E-mail: ylo@ssh.com 549 Tero Kivinen 550 SSH Communications Security Corp 551 Fredrikinkatu 42 552 FIN-00100 HELSINKI 553 Finland 554 E-mail: kivinen@ssh.com 556 Markku-Juhani O. Saarinen 557 University of Jyvaskyla 559 Timo J. Rinne 560 SSH Communications Security Corp 561 Fredrikinkatu 42 562 FIN-00100 HELSINKI 563 Finland 564 E-mail: tri@ssh.com 566 Sami Lehtinen 567 SSH Communications Security Corp 568 Fredrikinkatu 42 569 FIN-00100 HELSINKI 570 Finland 571 E-mail: sjl@ssh.com