idnits 2.17.1 draft-ietf-secsh-userauth-07.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 91: '...is reserved, and MUST NOT be listed as...' RFC 2119 keyword, line 92: '...ed. However, it MAY be sent by the cl...' RFC 2119 keyword, line 94: '...which case the server MUST accept this...' RFC 2119 keyword, line 98: '...The server SHOULD have a timeout for a...' RFC 2119 keyword, line 101: '...implementation SHOULD limit the number...' (57 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 112 has weird spacing: '... string use...' == Line 113 has weird spacing: '... string ser...' == Line 114 has weird spacing: '... string met...' == Line 152 has weird spacing: '... string aut...' == Line 153 has weird spacing: '...boolean part...' == (30 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.) -- The document date (11 May 2000) is 8748 days in the past. Is this intentional? -- 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 519, but no explicit reference was found in the text == Unused Reference: 'RFC-2044' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'SSH-CONNECT' is defined on line 531, 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-07.txt M. Saarinen 4 Expires in six months T. Rinne 5 S. Lehtinen 6 SSH Communications Security 7 11 May 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 deferred to separate documents. The SSH authentication protocol runs on 40 top the SSH transport layer protocol and provides a single authenticated 41 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 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. The session identifier uniquely identifies this 76 session and is suitable for signing to prove ownership of a private key. 77 This protocol also needs to know whether the lower-level protocol 78 provides confidentiality protection. 80 2. The Authentication Protocol Framework 82 The server drives the authentication by telling the client which 83 authentications can usefully continue the dialog at any given time. The 84 client has the freedom to try the methods listed by the server in any 85 order. This gives the server complete control over the authentication 86 process if it so desired, but also gives enough flexibility for the 87 client to use the methods it supports or that are most convenient for 88 the user when multiple methods are offered by the server. 90 Authentication methods are identified by names, as defined in [SSH- 91 ARCH]. The "none" method is reserved, and MUST NOT be listed as 92 supported. However, it MAY be sent by the client. The server MUST 93 always reject this request, unless the client is to be allowed in 94 without any authentication, in which case the server MUST accept this 95 request. The main purpose of sending this request is to get the list of 96 supported methods from the server. 98 The server SHOULD have a timeout for authentication, and disconnect if 99 the authentication has not been accepted within the timeout period. The 100 RECOMMENDED timeout period is 10 minutes. Additionally, the 101 implementation SHOULD limit the number of failed authentication attempts 102 a client may perform in a single session (the RECOMMENDED limit is 20 103 attempts). If the threshold is exceeded, the server SHOULD disconnect. 105 2.1. Authentication Requests 107 All authentication requests MUST use the following message format. Only 108 the first few fields are defined; the remaining fields depend on the 109 authentication method. 111 byte SSH_MSG_USERAUTH_REQUEST 112 string user name (in ISO-10646 UTF-8 encoding) 113 string service name (in US-ASCII) 114 string method name (US-ASCII) 115 rest of the packet is method-specific 117 The user name and service are repeated in every new authentication 118 attempt, and MAY change. The server implementation MUST carefully check 119 them in every message, and MUST flush any accumulated authentication 120 state if they change. If it is unable to flush some authentication 121 state, it MUST disconnect if the user or service name changes. 123 The service name specifies the service to start after authentication. 124 There may be several different authenticated services provided. If the 125 requested service is not available, the server MAY disconnect 126 immediately or any time later. Sending a proper disconnect message is 127 RECOMMENDED. In any case, if the service does not exist, authentication 128 MUST NOT be accepted. 130 If the requested user does not exist, the server MAY disconnect, or MAY 131 send a bogus list of acceptable authentications but never accept any. 132 This makes it possible for the server to avoid disclosing information 133 about which accounts exist. In any case, if the user does not exist, 134 the authentication request MUST NOT be accepted. 136 While there is usually little point for clients to send requests that 137 the server does not list as acceptable, sending such requests is not an 138 error, and the server SHOULD simply reject requests that it does not 139 recognize. 141 An authentication request MAY result in a further exchange of messages. 142 All such messages depend on the authentication method used, and the 143 client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST 144 message, in which case the server MUST abandon the previous 145 authentication attempt and continue with the new one. 147 2.2. Responses to Authentication Requests 149 If the server rejects the authentication request, it MUST respond with 151 byte SSH_MSG_USERAUTH_FAILURE 152 string authentications that can continue 153 boolean partial success 155 "Authentications that can continue" is a comma-separated list of 156 authentication method names that may productively continue the 157 authentication dialog. 159 It is RECOMMENDED that servers only include those methods in the list 160 that are actually useful. However, it is not illegal to include methods 161 that cannot be used to authenticate the user. 163 Already successfully completed authentications SHOULD NOT be included in 164 the list, unless they really should be performed again for some reason. 166 "Partial success" MUST be true if the authentication request to which 167 this is a response was successful. It MUST be false if the request was 168 not successfully processed. 170 When the server accepts authentication, it MUST respond with 172 byte SSH_MSG_USERAUTH_SUCCESS 174 Note that this is not sent after each step in a multi-method authentica- 175 tion sequence, but only when authentication is complete. 177 The client MAY send several authentication requests without waiting for 178 responses from previous requests. The server MUST acknowledge any 179 failed requests with a SSH_MSG_USERAUTH_FAILURE message. However, 180 SSH_MSG_USERAUTH_SUCCESS MUST sent only once, and once 181 SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication 182 requests received after that SHOULD be silently ignored. 184 Any non-authentication messages sent by the client after the request 185 that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed to 186 the service being run on top of this protocol. Such messages can be 187 identified by their message numbers (see Section ``Message Numbers''). 189 2.3. The none Authentication Request 191 A client may request a list of authentication methods that may continue 192 by using the "none" authentication method. 194 If no authentication at all is needed for the user, the server MUST 195 return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return 196 SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of authentication 197 methods that can continue. 199 This method MUST NOT be listed as supported by the server. 201 2.4. Completion of User Authentication 203 Authentication is complete when the server has responded with 204 SSH_MSG_USERAUTH_SUCCESS; all authentication related messages received 205 after sending this message SHOULD be silently ignored. 207 After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the requested 208 service. 210 2.5. Banner Message 212 In some jurisdictions, sending a warning message before authentication 213 may be relevant to getting legal protection. Many UNIX machines, for 214 example, normally display text from /etc/issue, or use "tcp wrappers" or 215 similar software to display a banner before issuing a login prompt. 217 The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time 218 before authentication is successful. This message contains text to be 219 displayed to the client user before authentication is attempted. The 220 format is as follows. 222 byte SSH_MSG_USERAUTH_BANNER 223 string message (ISO-10646 UTF-8) 224 string language tag (as defined in RFC 1766) 226 The client SHOULD by default display the message on the screen. 227 However, since the message is likely to be sent for every login attempt, 228 and since some client software will need to open a separate window for 229 this warning, the client software may allow the user to explicitly 230 disable the display of banners from the server. The message may consist 231 of multiple lines. 233 If the message string is displayed, control character filtering 234 discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending 235 terminal control characters. 237 3. Authentication Protocol Message Numbers 239 All message numbers used by this authentication protocol are in the 240 range 50..79, which is part of the range reserved for protocols running 241 on top of the SSH transport layer protocol. 243 Message numbers 80 and higher are reserved for protocols running after 244 this authentication protocol, so receiving one of them before 245 authentication is complete is an error, to which the server MUST respond 246 by disconnecting (preferably with a proper disconnect message sent first 247 to ease troubleshooting). 249 After successful authentication, such messages are passed to the higher- 250 level service. 252 These are the general authentication message codes: 254 #define SSH_MSG_USERAUTH_REQUEST 50 255 #define SSH_MSG_USERAUTH_FAILURE 51 256 #define SSH_MSG_USERAUTH_SUCCESS 52 257 #define SSH_MSG_USERAUTH_BANNER 53 259 In addition to the above, there is a range of message numbers (60..79) 260 reserved for method-specific messages. These messages are only sent by 261 the server (client only sends SSH_MSG_USERAUTH_REQUEST messages). 262 Different authentication methods reuse the same message numbers. 264 4. Public Key Authentication Method: publickey 266 The only REQUIRED authentication method is public key authentication. 267 All implementations MUST support this method; however, not all users 268 need to have public keys, and most local policies are not likely to 269 require public key authentication for all users in near future. 271 With this method, the possession of a private key serves as 272 authentication. This method works by sending a signature created with a 273 private key of the user. The server MUST check that the key is a valid 274 authenticator for the user, and MUST check that the signature is valid. 275 If both hold, the authentication request MUST be accepted; otherwise it 276 MUST be rejected. (Note that the server MAY require additional 277 authentications after successful authentication.) 279 Private keys are often stored encrypted at the client host, and the user 280 must supply a passphrase before the signature can be generated. Even if 281 they are not, the signing operation involves some expensive computation. 282 To avoid unnecessary processing and user interaction, the following 283 message is provided for querying whether authentication using the key 284 would be acceptable. 286 byte SSH_MSG_USERAUTH_REQUEST 287 string user name 288 string service 289 string "publickey" 290 boolean FALSE 291 string public key algorithm name 292 string public key blob 294 Public key algorithms are defined in the transport layer specification 295 [SSH-TRANS]. The public key blob may contain certificates. 297 Any public key algorithm may be offered for use in authentication. In 298 particular, the list is not constrained by what was negotiated during 299 key exchange (as that was affected by which algorithms the server had a 300 host key). If the server does not support some algorithm, it MUST 301 simply reject the request. 303 The server MUST respond to this message with either 304 SSH_MSG_USERAUTH_FAILURE or with 306 byte SSH_MSG_USERAUTH_PK_OK 307 string public key algorithm name from the request 308 string public key blob from the request 310 To do actual authentication, the client MAY then send a signature 311 generated using the private key. Client MAY send the signature directly 312 without first verifying whether the key is acceptable. The signature is 313 sent using the following packet 315 byte SSH_MSG_USERAUTH_REQUEST 316 string user name 317 string service 318 string "publickey" 319 boolean TRUE 320 string public key algorithm name 321 string public key to be used for authentication 322 string signature 324 Signature is a signature by the corresponding private key over the 325 following data, in this order: 327 o session identifier (encoded as string), and 329 o packet payload without the signature. 331 When the server receives this message, it MUST check whether the 332 supplied key is acceptable for authentication, and if so, it MUST check 333 whether the signature is correct. 335 If both checks succeed, this method is successful. Note that the server 336 may require additional authentications. The server MUST respond with 337 SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or 338 SSH_MSG_USERAUTH_FAILURE (if the request failed, or more authentications 339 are needed). 341 The following method-specific message numbers are used by the publickey 342 authentication method. 344 /* Key-based */ 345 #define SSH_MSG_USERAUTH_PK_OK 60 347 5. Password Authentication Method: password 349 Password authentication uses the following packets. Note that a server 350 MAY request the user to change password. All implementations SHOULD 351 support password authentication. 353 byte SSH_MSG_USERAUTH_REQUEST 354 string user name 355 string service 356 string "password" 357 boolean FALSE 358 string plaintext password (ISO-10646 UTF-8) 360 Note that the password is encoded in ISO-10646 UTF-8. It is up to the 361 server how it interprets the password and validates it against the 362 password database. However, if the client reads the password in some 363 other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert the 364 password to ISO-10646 UTF-8 before transmitting, and the server MUST 365 convert the password to the encoding used on that system for passwords. 367 Note that even though the cleartext password is transmitted in the 368 packet, the entire packet is encrypted by the transport layer. Both the 369 server and the client should check whether the underlying transport 370 layer provides confidentiality (i.e., encryption is being used). If no 371 confidentiality is provided ("none" cipher), password authentication 372 SHOULD be disabled. If there is no confidentiality or no MAC, password 373 change SHOULD be disabled. 375 Normally, the server responds to this message with success or failure. 376 However, the server MAY also respond with 377 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 379 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 380 string prompt (ISO-10646 UTF-8) 381 string language tag (as defined in RFC 1766) 383 In this case, the software client SHOULD request a new password from the 384 user, and send a new request using the following message. The client 385 may also send this message instead of the normal password authentication 386 request without the server asking for it. 388 byte SSH_MSG_USERAUTH_REQUEST 389 string user name 390 string service 391 string "password" 392 boolean TRUE 393 string plaintext old password (ISO-10646 UTF-8) 394 string plaintext new password (ISO-10646 UTF-8) 396 The server must reply to request message with SSH_MSG_USERAUTH_SUCCESS, 397 SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 398 The meaning of these is as follows: 400 SSH_MSG_USERAUTH_SUCCESS 401 Password has been changed, and authentication has been 402 successfully completed. 404 SSH_MSG_USERAUTH_FAILURE with partial success 405 The password has been changed, but more authentications are 406 needed. 408 SSH_MSG_USERAUTH_FAILURE without partial success 409 The password has not been changed. Either password changing was 410 not supported, or the old password was bad. Note that if the 411 server has already sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know 412 that it supports changing the password. 414 SSH_MSG_USERAUTH_CHANGEREQ 415 The password was not changed because the new password was not 416 acceptable (e.g. too easy to guess). 418 The following method-specific message numbers are used by the password 419 authentication method. 421 #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 423 6. Host-Based Authentication: hostbased 425 Some sites wish to allow authentication based on the host where the user 426 is coming from and the user name on the remote host. While this form of 427 authentication is not suitable for high-security sites, it can be very 428 convenient in many environments. This form of authentication is 429 OPTIONAL. When used, special care SHOULD be taken to prevent a regular 430 user from obtaining the private host key. 431 The client requests this form of authentication by sending the following 432 message. It is similar to the UNIX "rhosts" and "hosts.equiv" styles of 433 authentication, except that the identity of the client host is checked 434 more rigorously. 436 This method works by having the client send a signature created with the 437 private key of the client host, which the server checks with that host's 438 public key. Once the client host's identity is established, 439 authorization, but no further authentication, is performed based on the 440 user names on the server and client, and the client host name. 442 byte SSH_MSG_USERAUTH_REQUEST 443 string user name 444 string service 445 string "hostbased" 446 string public key algorithm for host key 447 string public host key and certificates for client host 448 string client host name (FQDN; US-ASCII) 449 string client user name on the remote host (ISO-10646 UTF-8) 450 string signature 452 Public key algorithm names for use in "public key algorithm for host 453 key" are defined in the transport layer specification. The "public host 454 key for client host" may include certificates. 456 Signature is a signature with the private host key of the following 457 data, in this order: 459 o session identifier (encoded as string), and 461 o packet payload without the signature. 463 The server MUST verify that the host key actually belongs to the client 464 host named in the message, that the given user on that host is allowed 465 to log in, and that the signature is a valid signature on the 466 appropriate value by the given host key. The server MAY ignore the 467 client user name, if it wants to authenticate only the client host. 469 It is RECOMMENDED that whenever possible, the server perform additional 470 checks to verify that the network address obtained from the (untrusted) 471 network matches the given client host name. This makes exploiting 472 compromised host keys more difficult. Note that this may require 473 special handling for connections coming through a firewall. 475 7. Security Considerations 477 The purpose of this protocol is to perform client user authentication. 478 It assumed that this runs over a secure transport layer protocol, which 479 has already authenticated the server machine, established an encrypted 480 communications channel, and computed a unique session identifier for 481 this session. The transport layer provides forward secrecy for password 482 authentication and other methods that rely on secret data. 484 The server may go into a "sleep" period after repeated unsuccesful 485 authentications to make key search harder. 487 If the transport layer does not provide encryption, authentication 488 methods that rely on secret data SHOULD be disabled. If it does not 489 provide MAC protection, requests to change authentication data (e.g. 490 password change) SHOULD be disabled to avoid an attacker from modifying 491 the ciphertext without being noticed, rendering the new authentication 492 data unusable (denial of service). 494 Several authentication methods with different security characteristics 495 are allowed. It is up to the server's local policy to decide which 496 methods (or combinations of methods) it is willing to accept for each 497 user. Authentication is no stronger than the weakest combination 498 allowed. 500 Special care should be taken when designing debug messages. These 501 messages may reveal surprising amounts of information about the host if 502 not properly designed. Debug messages can be disabled (during user 503 authentication phase) if high security is sought after. 505 8. Trademark Issues 507 SSH is a registered trademark and Secure Shell is a trademark of SSH 508 Communications Security Corp. SSH Communications Security Corp permits 509 the use of these trademarks as the name of this standard and protocol, 510 and permits their use to describe that a product conforms to this 511 standard, provided that the following acknowledgement is included where 512 the trademarks are used: ``SSH is a registered trademark and Secure 513 Shell is a trademark of SSH Communications Security Corp 514 (www.ssh.com)''. These trademarks may not be used as part of a product 515 name or in otherwise confusing manner without prior written permission 516 of SSH Communications Security Corp. 518 9. References 519 [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", 520 March 1995. 522 [RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and 523 ISO 10646", October 1996. 525 [SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet 526 Draft, draft-secsh-architecture-05.txt 528 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet 529 Draft, draft-secsh-transport-07.txt 531 [SSH-CONNECT] Ylonen, T., et al, "SSH Connection Protocol", Internet 532 Draft, draft-secsh-connect-07.txt 534 10. Author's Address 536 Tatu Ylonen 537 SSH Communications Security Corp 538 Fredrikinkatu 42 539 FIN-00100 HELSINKI 540 Finland 541 E-mail: ylo@ssh.com 543 Tero Kivinen 544 SSH Communications Security Corp 545 Fredrikinkatu 42 546 FIN-00100 HELSINKI 547 Finland 548 E-mail: kivinen@ssh.com 550 Markku-Juhani O. Saarinen 551 University of Jyvaskyla 553 Timo J. Rinne 554 SSH Communications Security Corp 555 Fredrikinkatu 42 556 FIN-00100 HELSINKI 557 Finland 558 E-mail: tri@ssh.com 560 Sami Lehtinen 561 SSH Communications Security Corp 562 Fredrikinkatu 42 563 FIN-00100 HELSINKI 564 Finland 565 E-mail: sjl@ssh.com