idnits 2.17.1 draft-ietf-secsh-userauth-02.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-25) 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. ** 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 87: '...is reserved, and MUST NOT be listed as...' RFC 2119 keyword, line 88: '...ed. However, it MAY be sent by the cl...' RFC 2119 keyword, line 90: '...which case the server MUST accept this...' RFC 2119 keyword, line 94: '...The server SHOULD have a timeout for a...' RFC 2119 keyword, line 97: '...implementation SHOULD limit the number...' (57 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 108 has weird spacing: '... string use...' == Line 109 has weird spacing: '... string ser...' == Line 110 has weird spacing: '... string met...' == Line 148 has weird spacing: '... string aut...' == Line 149 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 (14 October 1997) is 9690 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 500, but no explicit reference was found in the text == Unused Reference: 'RFC-2044' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'SSH-CONNECT' is defined on line 512, 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: 12 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-02.txt M. Saarinen 4 Expires in six months SSH 5 14 October 1997 7 SSH Authentication Protocol 9 Status of This memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), 25 or ftp.isi.edu (US West Coast). 27 Abstract 29 SSH is a protocol for secure remote login and other secure network ser- 30 vices over an insecure network. 32 This document describes the SSH authentication protocol framework and 33 public key, password, and host-based client authentication methods. 34 Additional authentication methods are deferred to separate documents. 36 The SSH authentication protocol runs on top the SSH transport layer 37 protocol and provides a single authenticated tunnel for the SSH 38 connection protocol. 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 43 2. The Authentication Protocol Framework . . . . . . . . . . . . . 2 44 2.1. Authentication Requests . . . . . . . . . . . . . . . . . . 3 45 2.2. Responses to Authentication Requests . . . . . . . . . . . . 3 46 2.3. The none Authentication Request . . . . . . . . . . . . . . 4 47 2.4. Completion of User Authentication . . . . . . . . . . . . . 5 48 2.5. Banner Message . . . . . . . . . . . . . . . . . . . . . . . 5 49 3. Authentication Protocol Message Numbers . . . . . . . . . . . . 5 50 4. Public Key Authentication Method: publickey . . . . . . . . . . 6 51 5. Password Authentication Method: password . . . . . . . . . . . . 7 52 6. Host-Based Authentication: hostbased . . . . . . . . . . . . . . 9 53 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 54 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 55 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 57 1. Introduction 59 The SSH authentication protocol is a general-purpose user authentication 60 protocol. It is intended to be run over the SSH transport layer 61 protocol [SSH-TRANS]. This protocol assumes that the underlying 62 protocols provide integrity and confidentiality protection. 64 This document should be read only after reading the SSH architecture 65 document [SSH-ARCH]. This document freely uses terminology and notation 66 from the architecture document without reference or further explanation. 68 The service name for this protocol is "ssh-userauth". 70 When this protocol starts, it receives the session identifier from the 71 lower-level protocol. The session identifier uniquely identifies this 72 session and is suitable for signing to prove ownership of a private key. 73 This protocol also needs to know whether the lower-level protocol 74 provides confidentiality protection. 76 2. The Authentication Protocol Framework 78 The server drives the authentication by telling the client which 79 authentications can usefully continue the dialog at any given time. The 80 client has the freedom to try the methods listed by the server in any 81 order. This gives the server complete control over the authentication 82 process if it so desired, but also gives enough flexibility for the 83 client to use the methods it supports or that are most convenient for 84 the user when multiple methods are offered by the server. 86 Authentication methods are identified by names, as defined in [SSH- 87 ARCH]. The "none" method is reserved, and MUST NOT be listed as 88 supported. However, it MAY be sent by the client. The server MUST 89 always reject this request, unless the client is to be allowed in 90 without any authentication, in which case the server MUST accept this 91 request. The main purpose of sending this request is to get the list of 92 supported methods from the server. 94 The server SHOULD have a timeout for authentication, and disconnect if 95 the authentication has not been accepted within the timeout period. The 96 RECOMMENDED timeout period is 10 minutes. Additionally, the 97 implementation SHOULD limit the number of failed authentication attempts 98 a client may perform in a single session (the RECOMMENDED limit is 20 99 attempts). If the threshold is exceeded, the server SHOULD disconnect. 101 2.1. Authentication Requests 103 All authentication requests MUST use the following message format. Only 104 the first few fields are defined; the remaining fields depend on the 105 authentication method. 107 byte SSH_MSG_USERAUTH_REQUEST 108 string user name (in ISO-10646 UTF-8 encoding) 109 string service name (in US-ASCII) 110 string method name (US-ASCII) 111 rest of the packet is method-specific 113 The user name and service are repeated in every new authentication 114 attempt, and MAY change. The server implementation MUST carefully check 115 them in every message, and MUST flush any accumulated authentication 116 state if they change. If it is unable to flush some authentication 117 state, it MUST disconnect if the user or service name changes. 119 The service name specifies the service to start after authentication. 120 There may be several different authenticated services provided. If the 121 requested service is not available, the server MAY disconnect 122 immediately or any time later. Sending a proper disconnect message is 123 RECOMMENDED. In any case, if the service does not exist, authentication 124 MUST NOT be accepted. 126 If the requested user does not exist, the server MAY disconnect, or MAY 127 send a bogus list of acceptable authentications but never accept any. 128 This makes it possible for the server to avoid disclosing information 129 about which accounts exist. In any case, if the user does not exist, 130 the authentication request MUST NOT be accepted. 132 While there is usually little point for clients to send requests that 133 the server does not list as acceptable, sending such requests is not an 134 error, and the server SHOULD simply reject requests that it does not 135 recognize. 137 An authentication request MAY result in a further exchange of messages. 138 All such messages depend on the authentication method used, and the 139 client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST 140 message, in which case the server MUST abandon the previous 141 authentication attempt and continue with the new one. 143 2.2. Responses to Authentication Requests 145 If the server rejects the authentication request, it MUST respond with 147 byte SSH_MSG_USERAUTH_FAILURE 148 string authentications that can continue 149 boolean partial success 151 "Authentications that can continue" is a comma-separated list of 152 authentication method names that may productively continue the 153 authentication dialog. 155 It is RECOMMENDED that servers only include those methods in the list 156 that are actually useful. However, it is not illegal to include methods 157 that cannot be used to authenticate the user. 159 Already successfully completed authentications SHOULD NOT be included in 160 the list, unless they really should be performed again for some reason. 162 "Partial success" MUST be true if the authentication request to which 163 this is a response was successful. It MUST be false if the request was 164 not successfully processed. 166 When the server accepts authentication, it MUST respond with 168 byte SSH_MSG_USERAUTH_SUCCESS 170 Note that this is not sent after each step in a multi-method authentica- 171 tion sequence, but only when authentication is complete. 173 The client MAY send several authentication requests without waiting for 174 responses from previous requests. The server MUST acknowledge any 175 failed requests with a SSH_MSG_USERAUTH_FAILURE message. However, 176 SSH_MSG_USERAUTH_SUCCESS MUST sent only once, and once 177 SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication 178 requests received after that SHOULD be silently ignored. 180 Any non-authentication messages sent by the client after the request 181 that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed to 182 the service being run on top of this protocol. Such messages can be 183 identified by their message numbers (see Section ``Message Numbers''). 185 2.3. The none Authentication Request 187 A client may request a list of authentication methods that may continue 188 by using the "none" authentication method. 190 If no authentication at all is needed for the user, the server MUST 191 return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return 192 SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of authentication 193 methods that can continue. 195 This method MUST NOT be listed as supported by the server. 197 2.4. Completion of User Authentication 199 Authentication is complete when the server has responded with 200 SSH_MSG_USERAUTH_SUCCESS; all authentication related messages received 201 after sending this message SHOULD be silently ignored. 203 After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the requested 204 service. 206 2.5. Banner Message 208 In some jurisdictions, sending a warning message before authentication 209 may be relevant to getting legal protection. Many UNIX machines, for 210 example, normally display text from /etc/issue, or use "tcp wrappers" or 211 similar software to display a banner before issuing a login prompt. 213 The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time 214 before authentication is successful. This message contains text to be 215 displayed to the client user before authentication is attempted. The 216 format is as follows. 218 byte SSH_MSG_USERAUTH_BANNER 219 string message (ISO-10646 UTF-8) 220 string language tag (as defined in RFC 1766) 222 The client SHOULD by default display the message on the screen. 223 However, since the message is likely to be sent for every login attempt, 224 and since some client software will need to open a separate window for 225 this warning, the client software may allow the user to explicitly 226 disable the display of banners from the server. The message may consist 227 of multiple lines. 229 If the message string is displayed, control character filtering 230 discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending 231 terminal control characters. 233 3. Authentication Protocol Message Numbers 235 All message numbers used by this authentication protocol are in the 236 range 50..79, which is part of the range reserved for protocols running 237 on top of the SSH transport layer protocol. 239 Message numbers 80 and higher are reserved for protocols running after 240 this authentication protocol, so receiving one of them before 241 authentication is complete is an error, to which the server MUST respond 242 by disconnecting (preferably with a proper disconnect message sent first 243 to ease troubleshooting). 245 After successful authentication, such messages are passed to the higher- 246 level service. 248 These are the general authentication message codes: 250 #define SSH_MSG_USERAUTH_REQUEST 50 251 #define SSH_MSG_USERAUTH_FAILURE 51 252 #define SSH_MSG_USERAUTH_SUCCESS 52 253 #define SSH_MSG_USERAUTH_BANNER 53 255 In addition to the above, there is a range of message numbers (25..29) 256 reserved for method-specific messages. These messages are only sent by 257 the server (client only sends SSH_MSG_USERAUTH_REQUEST messages). 258 Different authentication methods reuse the same message numbers. 260 4. Public Key Authentication Method: publickey 262 The only REQUIRED authentication method is public key authentication. 263 All implementations MUST support this method; however, not all users 264 need to have public keys, and most local policies are not likely to 265 require public key authentication for all users in near future. 267 With this method, the possession of a private key serves as 268 authentication. This method works by sending a signature created with a 269 private key of the user. The server MUST check that the key is a valid 270 authenticator for the user, and MUST check that the signature is valid. 271 If both hold, the authentication request MUST be accepted; otherwise it 272 MUST be rejected. (Note that the server MAY require additional 273 authentications after successful authentication.) 275 Private keys are often stored encrypted at the client host, and the user 276 must supply a passphrase before the signature can be generated. Even if 277 they are not, the signing operation involves some expensive computation. 278 To avoid unnecessary processing and user interaction, the following 279 message is provided for querying whether authentication using the key 280 would be acceptable. 282 byte SSH_MSG_USERAUTH_REQUEST 283 string user name 284 string service 285 string "publickey" 286 boolean FALSE 287 string public key algorithm name 288 string public key blob 290 Public key algorithms are defined in the transport layer specification 291 [SSH-TRANS]. The public key blob may contain certificates. 293 Any public key algorithm may be offered for use in authentication. In 294 particular, the list is not constrained by what was negotiated during 295 key exchange (as that was affected by which algorithms the server had a 296 host key). If the server does not support some algorithm, it MUST 297 simply reject the request. 299 The server MUST respond to this message with either 300 SSH_MSG_USERAUTH_FAILURE or with 302 byte SSH_MSG_USERAUTH_PK_OK 303 string public key algorithm name from the request 304 string public key blob from the request 306 To do actual authentication, the client MAY then send a signature 307 generated using the private key. Client MAY send the signature directly 308 without first verifying whether the key is acceptable. The signature is 309 sent using the following packet 311 byte SSH_MSG_USERAUTH_REQUEST 312 string user name 313 string service 314 string "publickey" 315 boolean TRUE 316 string public key algorithm name 317 string public key to be used for authentication 318 string signature 320 Signature is a signature by the corresponding private key over the 321 following data, in this order: 323 o session identifier, and 325 o packet payload without the signature. 327 When the server receives this message, it MUST check whether the 328 supplied key is acceptable for authentication, and if so, it MUST check 329 whether the signature is correct. 331 If both checks succeed, this method is successful. Note that the server 332 may require additional authentications. The server MUST respond with 333 SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or 334 SSH_MSG_USERAUTH_FAILURE (if the request failed, or more authentications 335 are needed). 337 The following method-specific message numbers are used by the publickey 338 authentication method. 340 /* Key-based */ 341 #define SSH_MSG_USERAUTH_PK_OK 60 343 5. Password Authentication Method: password 345 Password authentication uses the following packets. Note that a server 346 MAY request the user to change password. All implementations SHOULD 347 support password authentication. 349 byte SSH_MSG_USERAUTH_REQUEST 350 string user name 351 string service 352 string "password" 353 boolean FALSE 354 string plaintext password (ISO-10646 UTF-8) 356 Note that the password is encoded in ISO-10646 UTF-8. It is up to the 357 server how it interprets the password and validates it against the 358 password database. However, if the client reads the password in some 359 other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert the 360 password to ISO-10646 UTF-8 before transmitting, and the server MUST 361 convert the password to the encoding used on that system for passwords. 363 Note that even though the cleartext password is transmitted in the 364 packet, the entire packet is encrypted by the transport layer. Both the 365 server and the client should check whether the underlying transport 366 layer provides confidentiality (i.e., encryption is being used). If no 367 confidentiality is provided ("none" cipher), password authentication 368 SHOULD be disabled. If there is no confidentiality or no MAC, password 369 change SHOULD be disabled. 371 Normally, the server responds to this message with success or failure. 372 However, the server MAY also respond with 373 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 375 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 376 string prompt (ISO-10646 UTF-8) 377 string language tag (as defined in RFC 1766) 379 In this case, the software client SHOULD request a new password from the 380 user, and send a new request using the following message. The client 381 may also send this message instead of the normal password authentication 382 request without the server asking for it. 384 byte SSH_MSG_USERAUTH_REQUEST 385 string user name 386 string service 387 string "password" 388 boolean TRUE 389 string plaintext old password (ISO-10646 UTF-8) 390 string plaintext new password (ISO-10646 UTF-8) 392 The server must reply to request message with SSH_MSG_USERAUTH_SUCCESS, 393 SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 394 The meaning of these is as follows: 396 SSH_MSG_USERAUTH_SUCCESS 397 Password has been changed, and authentication has been 398 successfully completed. 400 SSH_MSG_USERAUTH_FAILURE with partial success 401 The password has been changed, but more authentications are 402 needed. 404 SSH_MSG_USERAUTH_FAILURE without partial success 405 The password has not been changed. Either password changing was 406 not supported, or the old password was bad. Note that if the 407 server has already sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know 408 that it supports changing the password. 410 SSH_MSG_USERAUTH_CHANGEREQ 411 The password was not changed because the new password was not 412 acceptable (e.g. too easy to guess). 414 The following method-specific message numbers are used by the password 415 authentication method. 417 #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 419 6. Host-Based Authentication: hostbased 421 Some sites wish to allow authentication based on the host where the user 422 is coming from and the user name on the remote host. While this form of 423 authentication is not suitable for high-security sites, it can be very 424 convenient in many environments. This form of authentication is 425 OPTIONAL. When used, special care SHOULD be taken to prevent a regular 426 user from obtaining the private host key. 427 The client requests this form of authentication by sending the following 428 message. It is similar to the UNIX "rhosts" and "hosts.equiv" styles of 429 authentication, except that the identity of the client host is checked 430 more rigorously. 432 This method works by having the client send a signature created with the 433 private key of the client host, which the server checks with that host's 434 public key. Once the client host's identity is established, 435 authorization, but no further authentication, is performed based on the 436 user names on the server and client, and the client host name. 438 byte SSH_MSG_USERAUTH_REQUEST 439 string user name 440 string service 441 string "hostbased" 442 string public key algorithm for host key 443 string public host key and certificates for client host 444 string client host name (FQDN; US-ASCII) 445 string client user name on the remote host (ISO-10646 UTF-8) 446 string signature 448 Public key algorithm names for use in "public key algorithm for host 449 key" are defined in the transport layer specification. The "public host 450 key for client host" may include certificates. 452 Signature is a signature with the private host key of the following 453 data, in this order: 455 o session identifier, and 457 o packet payload without the signature. 459 The server MUST verify that the host key actually belongs to the client 460 host named in the message, that the given user on that host is allowed 461 to log in, and that the signature is a valid signature on the 462 appropriate value by the given host key. The server MAY ignore the 463 client user name, if it wants to authenticate only the client host. 465 It is RECOMMENDED that whenever possible, the server perform additional 466 checks to verify that the network address obtained from the (untrusted) 467 network matches the given client host name. This makes exploiting 468 compromised host keys more difficult. Note that this may require 469 special handling for connections coming through a firewall. 471 7. Security Considerations 473 The purpose of this protocol is to perform client user authentication. 474 It assumed that this runs over a secure transport layer protocol, which 475 has already authenticated the server machine, established an encrypted 476 communications channel, and computed a unique session identifier for 477 this session. The transport layer provides forward secrecy for password 478 authentication and other methods that rely on secret data. 480 If the transport layer does not provide encryption, authentication 481 methods that rely on secret data SHOULD be disabled. If it does not 482 provide MAC protection, requests to change authentication data (e.g. 483 password change) SHOULD be disabled to avoid an attacker from modifying 484 the ciphertext without being noticed, rendering the new authentication 485 data unusable (denial of service). 487 Several authentication methods with different security characteristics 488 are allowed. It is up to the server's local policy to decide which 489 methods (or combinations of methods) it is willing to accept for each 490 user. Authentication is no stronger than the weakest combination 491 allowed. 493 Special care should be taken when designing debug messages. These 494 messages may reveal surprising amounts of information about the host if 495 not properly designed. Debug messages can be disabled (during user 496 authentication phase) if high security is sought after. 498 8. References 500 [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", 501 March 1995. 503 [RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and 504 ISO 10646", October 1996. 506 [SSH-ARCH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Protocol 507 Architecture", Internet Draft, draft-secsh-architecture-00.txt 509 [SSH-TRANS] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Transport 510 Layer Protocol", Internet Draft, draft-secsh-transport-02.txt 512 [SSH-CONNECT] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Connection 513 Protocol", Internet Draft, draft-secsh-connect-02.txt 514 9. Author's Address 516 Tatu Ylonen 517 SSH Communications Security Ltd. 518 Tekniikantie 12 519 FIN-02150 ESPOO 520 Finland 521 E-mail: ylo@ssh.fi 523 Tero Kivinen 524 SSH Communications Security Ltd. 525 Tekniikantie 12 526 FIN-02150 ESPOO 527 Finland 528 E-mail: kivinen@ssh.fi 530 Markku-Juhani O. Saarinen 531 SSH Communications Security Ltd. 532 Tekniikantie 12 533 FIN-02150 ESPOO 534 Finland 535 E-mail: mjos@ssh.fi