idnits 2.17.1 draft-ietf-secsh-userauth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an Authors' Addresses Section. ** There are 59 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 135 has weird spacing: '... string use...' == Line 136 has weird spacing: '... string ser...' == Line 137 has weird spacing: '... string met...' == Line 171 has weird spacing: '... string aut...' == Line 172 has weird spacing: '...boolean part...' == (54 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 (July 30, 1997) is 9760 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) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tatu Ylonen 2 INTERNET-DRAFT SSH Communications Security 3 draft-ietf-secsh-userauth-01.txt July 30, 1997 4 Expires in six months 6 SSH Authentication Protocol 8 Status of This memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check 21 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), 24 or ftp.isi.edu (US West Coast). 26 Abstract 28 This documents describes the SSH authentication protocol. It is used to 29 prove that the client is authorized to access the requested service with 30 the supplied user name. This authorization can be demonstrated through 31 possession of a password, through possession of a key, by authenticating 32 the client host and user, by some other method, or a combination of 33 these. 35 Table of Contents 37 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 38 2. User Authentication . . . . . . . . . . . . . . . . . . . . . . 2 39 2.1. Authentication Requests . . . . . . . . . . . . . . . . . . 3 40 2.2. Responses to Authentication Requests . . . . . . . . . . . . 4 41 2.3. No Authentication . . . . . . . . . . . . . . . . . . . . . 5 42 2.4. Password Authentication . . . . . . . . . . . . . . . . . . 5 43 2.5. Challenge-Response Authentication . . . . . . . . . . . . . 6 44 2.6. SecurID Authentication . . . . . . . . . . . . . . . . . . . 6 45 2.7. Public Key Authentication . . . . . . . . . . . . . . . . . 7 46 2.8. Host-Based Authentication . . . . . . . . . . . . . . . . . 9 47 2.9. Kerberos Authentication . . . . . . . . . . . . . . . . . . 10 48 2.10. When Authentication Is Complete . . . . . . . . . . . . . . 11 49 3. Banner Message . . . . . . . . . . . . . . . . . . . . . . . . . 11 50 4. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . . 11 51 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 52 6. Address of Author . . . . . . . . . . . . . . . . . . . . . . . 12 54 1. Introduction 56 This protocol is designed to run over the SSH transport layer protocol 57 using the same packet-based protocol as the transport layer. The 58 service name is "ssh-userauth". 60 This document should be read only after reading the transport layer 61 document. This document uses terminology and notation from the 62 transport layer document without further explanation. 64 Authentication works as follows: the client declares the service name, 65 and the user name under which to access this service. The server 66 responds to this declaration with a set of acceptable authentication 67 methods for the given user/service combination. The client then sends 68 an authentication request using one of the methods listed by the server. 69 This dialog continues until access has been granted, or until either the 70 client or the server disconnects. 72 When the authentication protocols protocol starts, it receives the 73 session identifier from the transport layer protocol. The session 74 identifier uniquely identifies this session and is suitable for signing 75 to prove ownership of a private key. 77 2. User Authentication 79 The server drives the authentication by telling the client which 80 authentications can usefully continue the dialog at any given time. The 81 client has the freedom to try the methods listed by the server in any 82 order. This gives the server complete control ver the authentication 83 process if it so desired, but also gives enough flexibility for the 84 client to use the methods it supports or that are most convenient for 85 the user when multiple methods are offered by the server. 87 Authentication methods are identified by names. Some methods are 88 defined in the protocol; additional methods may be defined using the 89 syntax "name@domainname" as the method name (for example, 90 "footoken@footoken.com"). This ensures that private extensions can be 91 implemented without breaking compatibility and without requiring a 92 central registry of method names. Method names are case-sensitive, and 93 must consist of alphanumeric characters and hyphens. 95 The following methods are predefined: 97 none Unsupported authentication method 98 password Password-based authentication 99 securid SecurID authentication 100 otp-md4 One-time passwords using MD4 hashing 101 otp-md5 One-time passwords using MD5 hashing 102 otp-sha1 One-time passwords using SHA1 hashing 103 publickey Possession of private key 104 hostbased Client host and user (.rhosts-style) 105 kerberos4 Kerberos v4 authentication 106 kerberos5 Kerberos v5 authentication 107 kerberos-afs AFS Kerberos authentication 109 The "none" method should never be listed as supported. However, it may 110 be sent by the client. The server should always reject this request, 111 unless the client is to be allowed in without any authentication. The 112 main purpose of sending this request is to get the list of supported 113 methods from the server. 115 There are no mandatory authentication methods; all methods are optional. 116 The motivation for this is that which methods to use is a matter of 117 local policy rather than protocol. However, it is strongly recommended 118 that all implementations support at least "password" authentication. 120 The server should have a timeout for authentication, and disconnect if 121 the authentication has not been accepted within the timeout period. The 122 recommended timeout period is 10 minutes. Additionally, the 123 implementation may want to limit the number of failed authentication 124 attempts a client may perform in a single session (the recommended limit 125 is 20 attempts). If the threshold is exceeded, the server should 126 disconnect. 128 2.1. Authentication Requests 130 All authentication requests use the same generic message format. Only 131 the first few fields are defined; the remaining fields depend on the 132 authentication method. 134 byte SSH_MSG_USERAUTH_REQUEST 135 string username 136 string service 137 string method name 138 rest of the packet is method-specific 140 The username and service are repeated in every new authentication 141 attempt, and may change. The server implementation must carefully check 142 them in every message, and must flush any accumulated authentication 143 state if they change. 145 Service specifies the service to start after authentication. There may 146 be several different authenticated services provided. If the requested 147 service is not available, the server may disconnect immediately or any 148 time later. Sending a proper disconnect message is recommended. 150 If the requested user does not exist, the server is allowed to 151 disconnect, or may send a bogus list of acceptable authentications but 152 never accept any. This makes it possible for the server to avoid 153 disclosing information about which accounts exist. 155 While there is usually little point in clients sending requests that the 156 server does not list as acceptable, sending such requests is not an 157 error, and the server should simply reject requests that it does not 158 recognize. 160 An authentication request may result in a further exchange of messages. 161 All such messages depend on the authentication method used, and the 162 client may at any time continue with a new SSH_MSG_USERAUTH_REQUEST 163 message, in which case the server must abandon the previous 164 authentication attempt and continue with the new one. 166 2.2. Responses to Authentication Requests 168 If the server rejects the authentication request, it responds with 170 byte SSH_MSG_USERAUTH_FAILURE 171 string authentications that can continue 172 boolean partial success 174 "Authentications that can continue" is a comma-separated list of 175 authentication method names that may productively continue the 176 authentication dialog. 178 It is recommended that servers only include those methods in the list 179 that are actually useful. However, it is not illegal to include methods 180 that cannot be used to authenticate the user. 182 Already successfully completed authentications should not be included in 183 the list unless they really should be performed again for some weird 184 reason. 186 "Partial success" is TRUE if the particular authentication request, in 187 response to which this is being sent, was accepted, but more 188 authentication is still needed. It is FALSE if the request was not 189 successfully processed. 191 When the server accepts authentication, it responds with 192 byte SSH_MSG_USERAUTH_SUCCESS 194 The client may send several authentication requests without waiting for 195 responses from previous requests. The server will acknowledge any 196 failed requests with a SSH_SMSG_AUTH_FAILURE message. However, 197 SSH_SMSG_AUTH_SUCCESS is sent only once. 199 Once SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication 200 requests received after that are silently ignored, while any non- 201 authentication messages sent by the client will be passed to the service 202 being run above this authentication protocol. 204 2.3. No Authentication 206 A client may request the list of real authentication methods that may 207 continue by using the "none" authentication method. This is actually an 208 authentication request: if no authentication at all is needed for the 209 user, this returns SSH_MSG_USERAUTH_SUCCESS. Otherwise, this returns 210 failure and with it the list of authentication methods that can 211 continue. 213 This method should never be listed as supported by the server. 215 2.4. Password Authentication 217 Password authentication uses the following packets. Note that a server 218 may request the user to change password. 220 byte SSH_MSG_USERAUTH_REQUEST 221 string username 222 string service 223 string "password" 224 boolean FALSE 225 string plaintext password 227 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 228 string prompt 230 byte SSH_MSG_USERAUTH_REQUEST 231 string username 232 string service 233 string "password" 234 boolean TRUE 235 string plaintext old password 236 string plaintext new password 238 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREPLY 239 boolean password changed 241 Normally, the client sends the first form, and the server responds with 242 success or failure. However, the server may also send a 243 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. In this case, the client should 244 request a new password from the user, and send a new request of the 245 second form to change the password. The server will then reply with 246 SSH_MSG_USERAUTH_PASSWD_CHANGEREPLY. If "password changed" is true, the 247 server will continue with either SSH_MSG_USERAUTH_SUCCESS or 248 SSH_MSG_USERAUTH_FAILURE. Otherwise, the dialog continues and the 249 client can try changing the password again. 251 2.5. Challenge-Response Authentication 253 Most challenge-response authentication methods use the following message 254 exchange: 256 byte SSH_MSG_USERAUTH_REQUEST 257 string username 258 string service 259 string method name 260 boolean FALSE 262 The server responds with either SSH_MSG_USERAUTH_FAILURE or 264 byte SSH_MSG_USERAUTH_CHALLENGE 265 string prompt 267 The client then responds with either a new authentication request or 269 byte SSH_MSG_USERAUTH_REQUEST 270 string username 271 string service 272 string method name 273 boolean TRUE 274 string response 276 The server responds to this message with either success or failure. 278 The "otp-md4", "otp-md5" and "otp-sha1" methods are defined in RFC 1938, 279 and follow this pattern. 281 2.6. SecurID Authentication 283 SecurID is a timing-based hardware token authenticator. The user enters 284 a code displayed on the token as authentication. There are different 285 versions of the SecurID tokens. Some versions support changing the PIN 286 (either to a server-supplied or user-supplied pin), and some might even 287 allow textual passphrases. 289 The method name for SecurID authentication is "securid". The following 290 packets are used: 292 byte SSH_MSG_USERAUTH_REQUEST 293 string username 294 string service 295 string "securid" 296 boolean is_new_pin 297 string pin 299 byte SSH_MSG_USERAUTH_SECURID_PINREQ 300 boolean user may supply 301 string suggested pin 302 uint32 min len 303 uint32 max len 304 boolean nondigits ok 306 byte SSH_MSG_USERAUTH_SECURID_PINREPLY 307 boolean pin accepted 309 Authentication starts by the client sending the SSH_MSG_USERAUTH_REQUEST 310 message with "is_new_pin" FALSE. The server responds with 311 SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or with 312 SSH_MSG_USERAUTH_SECURID_PINREQ if it wants the user to change his/her 313 pincode. In this message, "user may supply" is TRUE if the user may 314 choose the new pin, and FALSE if the server-supplied pin (in "suggested 315 pin") must be used. "Suggested pin" is a new PIN suggested by the 316 server, but may also be empty. "Min len" is the minimum length of the 317 new pin, "max len" is the maximum length, and "nondigits ok" is TRUE if 318 characters other than digits are allowed. 320 To change the pin, the client continues with a new 321 SSH_MSG_USERAUTH_REQUEST with "is_new_pin" TRUE and the new pin in 322 "pin". The server responds to this message with 323 SSH_MSG_USERAUTH_SECURID_PINREPLY (with "pin accepted" TRUE if the new 324 pin is now in effect, FALSE otherwise), followed by either 325 SSH_MSG_USERAUTH_SUCCESS or SSH_MSG_USERAUTH_FAILURE. Note that some 326 versions of SecurID do not permit the user in if the pin was changed. 328 2.7. Public Key Authentication 330 The possession of a private key can serve as authentication. This 331 method works by sending a signature created with the private key of the 332 user, which the server checks with the client user's public key. 334 Private keys are often stored encrypted at the client host, and the user 335 must supply a passphrase before the signature can be generated. To 336 avoid needing to supply passphrases when it is not necessary, the client 337 can optionally verify whether a particular key would be acceptable as 338 authentication. This is done with the following message. 340 byte SSH_MSG_USERAUTH_REQUEST 341 string username 342 string service 343 string "publickey" 344 boolean FALSE 345 string public key algorithm name 346 string public key to be used for authentication 348 Public key algorithms are defined in the transport layer specification. 349 The "public key to be used for authentication" may include certificates. 351 The server will respond to this message with either 352 SSH_MSG_USERAUTH_FAILURE or with 354 byte SSH_MSG_USERAUTH_PK_OK 355 string public key algorithm name from the request 356 string public key from the request 358 To do actual authentication, the client should then send a signature 359 generated using the private key. It is permissible to send the 360 signature directly without first verifying whether the key is 361 acceptable. 363 byte SSH_MSG_USERAUTH_REQUEST 364 string username 365 string service 366 string "publickey" 367 boolean TRUE 368 string public key algorithm name 369 string public key to be used for authentication 370 string signature 372 Signature is a signature by the corresponding private key of the HASH 373 of the concatenation of the following, in this order: 375 o session identifier (which binds the signature to the server host key 376 and the particular key exchange), 378 o length of the user name as a 32-bit integer, msb first, 380 o user name (without length or null characters), 382 o length of the service name as a 32-bit integer, msb first, 384 o service name (without length or null characters), 386 o length of the public key algorithm name as a 32-bit integer, msb 387 first, 389 o public key algorithm name (without length or null characters), 391 o length of the public key from the message as a 32-bit integer, msb 392 first, and 394 o public key from the message (without length or null characters). 396 When the server receives this message, it checks whether the supplied 397 key is acceptable for authentication, and if so, checks whether the 398 signature is correct. 400 If both checks succeed, authentication may be granted (the server may 401 also require further authentication with other methods, without letting 402 the client know at this point that authentication has partially 403 succeeded). 405 2.8. Host-Based Authentication 407 Some sites wish to allow authentication based on the host where the user 408 is coming from and the user name on the remote host. While this form of 409 authentication is not suitable for high-security sites, it can be very 410 convenient in many environments. The client requests this form of 411 authentication by sending the following message. It is rather similar 412 to the Unix "rhosts" and "hosts.equiv" styles of authentication, except 413 that the identity of the client host is checked more rigorously. 415 This method works by having the client send a signature created with the 416 private key of the client host, which the server checks with that host's 417 public key. Once the client host's identity is established, 418 authorization, but no further authentication, is performed based on the 419 usernames on the server and client, and the client host name. 421 byte SSH_MSG_USERAUTH_REQUEST 422 string username 423 string service 424 string "hostbased" 425 string public key algorithm for host key 426 string public host key for client host 427 string client host name 428 string client user name 429 string signature 431 Public key algorithm names for use in "public key algorithm for host 432 key" are defined in the transport layer specification. The "public host 433 key for client host" may include certificates. 434 Signature is a signature with the private host key for the client host 435 of the HASH (where the hash algorithm is from the transport layer) of 436 the concatenation of the following, in this order: 438 o session identifier (which binds the signature to the server host key 439 and the particular key exchange), 441 o length of the user name as a 32-bit integer, msb first, 443 o user name (without length or null characters), 445 o length of the service name as a 32-bit integer, msb first, 447 o service name (without length or null characters), 449 o length of the public host key algorithm name as a 32-bit integer, msb 450 first, 452 o public host key algorithm name (without length or null characters), 454 o length of the public host key from the message as a 32-bit integer, 455 msb first, 457 o public host key from the message (without length or null characters), 458 o length of the client host name as a 32-bit integer, msb first, 460 o client host name (without length or null characters), 462 o length of the client user name as a 32-bit integer, msb first, and 464 o client user name (without length or null characters). 466 Authentication is accepted if the server can verify that the host key 467 actually belongs to the client host named in the message, the given user 468 on that host is allowed to log in, and the signature is a valid 469 signature on the appropriate value by the given host key. (The server 470 is also allowed to ignore the client user name, if it wants to 471 authenticate only the client host.) 473 It is recommended that whenever possible, the server perform additional 474 checks to verify that the network address obtained from the (untrusted) 475 network matches the given client host name. This makes exploiting 476 compromised host keys more difficult. Note that this may require 477 special handling for connections coming through a firewall. 479 2.9. Kerberos Authentication 481 There are several ways to authenticate the user using Kerberos (OSF DCE 482 and AFS are also incarnations of Kerberos). Different versions of 483 Kerberos (v4, v5, DCE, and AFS) have different capabilities. Separate 484 messages have been defined for each of these. In each case, the server 485 should respond with success or failure. 487 byte SSH_MSG_USERAUTH_REQUEST 488 string username 489 string service 490 string "kerberos4" 491 string kerberos v4 credentials 493 byte SSH_MSG_USERAUTH_REQUEST 494 string username 495 string service 496 string "kerberos5" 497 string kerberos v5 credentials 498 string kerberos v5 ticket granting ticket (may be empty) 500 byte SSH_MSG_USERAUTH_REQUEST 501 string username 502 string service 503 string "kerberos-afs" 504 string AFS token 506 The Kerberos authentication requests should be sent before other 507 authentication requests. The other authentication methods may need to 508 access files from the user's home directory, which may not be accessible 509 until e.g. the AFS token has been passed. Note that even if these 510 requests fail, they may have side effects, such as making the home 511 directory accessible. 513 2.10. When Authentication Is Complete 515 Authentication is complete when the server has responded with 516 SSH_MSG_USERAUTH_SUCCESS; any SSH_MSG_USERAUTH_REQUEST messages received 517 after sending this message are silently ignored. 519 When sending SSH_MSG_USERAUTH_SUCCESS, the server also starts whatever 520 application was requested as the service. Any non-authentication 521 messages received after this point are passed to the requested service. 523 3. Banner Message 525 In some jurisdictions, sending a warning message before authentication 526 may be relevant to getting legal protection. Many Unix machines, for 527 example, display text from /etc/issue, or use "tcp_wrappers" or similar 528 software to display a banner before issuing a login prompt. 530 The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time 531 before authentication is successful. This message contains text to be 532 displayed to the client user before authentication is attempted. The 533 form is as follows, where "message" may contain newlines: 535 byte SSH_MSG_USERAUTH_BANNER 536 string message 538 The client should by default display the message on the screen. 539 However, since the message is likely to be sent for every login attempt, 540 and since some client software will need to open a separate window for 541 this warning, the client software may allow the user to explicitly 542 disable the display of banners from the server. 544 4. Message Numbers 546 All message numbers used by this authentication protocol are in the 547 range 20..29, which is part of the range reserved for protocols running 548 on top of the SSH transport layer protocol. 550 Message numbers 30 and higher are reserved for protocols running after 551 this authentication protocol, so receiving one of them before 552 authentication is complete is an error, to which the server must respond 553 by disconnecting (preferably with a proper disconnect sent first to ease 554 troubleshooting). 556 After successful authentication, such messages are passed to the higher- 557 level service. 559 These are the general authentication message codes: 561 #define SSH_MSG_USERAUTH_REQUEST 20 562 #define SSH_MSG_USERAUTH_FAILURE 21 563 #define SSH_MSG_USERAUTH_SUCCESS 22 564 #define SSH_MSG_USERAUTH_BANNER 23 566 In addition to the above, there is a range of message numbers (25..29) 567 reserved for method-specific messages. These messages are only sent by 568 the server (client only sends SSH_MSG_USERAUTH_REQUEST messages). 569 Differnet authentication methods reuse the same message numbers. 571 /* Password */ 572 #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 25 573 #define SSH_MSG_USERAUTH_PASSWD_CHANGEREPLY 26 574 /* Key-based */ 575 #define SSH_MSG_USERAUTH_PK_OK 25 576 /* One-time passwords */ 577 #define SSH_MSG_USERAUTH_CHALLENGE 25 578 /* SecurID */ 579 #define SSH_MSG_USERAUTH_SECURID_PINREQ 25 580 #define SSH_MSG_USERAUTH_SECURID_PINREPLY 26 582 5. Security Considerations 584 The purpose of this protocol is to perform client user authentication. 585 It assumed that this runs over a secure transport layer protocol, which 586 has already authenticated the server machine, established an encrypted 587 communications channel, and computed a unique session identifier for 588 this session. 590 Several authentication methods with different security characteristics 591 are allowed. It is up to the server's local policy to decide which 592 methods (or combinations of methods) it is willing to accept for each 593 user. 595 6. Address of Author 597 Tatu Ylonen 598 SSH Communications Security Ltd. 599 Tekniikantie 12 600 FIN-02150 ESPOO 601 Finland 603 E-mail: ylo@ssh.fi