From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jun 5 20:38:39 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23737 for ; Thu, 5 Jun 2003 20:38:36 -0400 (EDT) Received: (qmail 22363 invoked by uid 605); 6 Jun 2003 00:38:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22356 invoked from network); 6 Jun 2003 00:38:27 -0000 Received: from woodstock.binhost.com (207.228.252.5) by mail.netbsd.org with SMTP; 6 Jun 2003 00:38:27 -0000 Received: (qmail 17677 invoked by uid 0); 6 Jun 2003 00:37:16 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.33.143) by woodstock.binhost.com with SMTP; 6 Jun 2003 00:37:16 -0000 Message-Id: <5.2.0.9.2.20030605155633.040b2ea0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 05 Jun 2003 16:17:07 -0400 To: Chris Lonvick , ietf-ssh@netbsd.org From: Russ Housley Subject: Re: Pulling it all together - New Section 11 on Security Considerations In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@netbsd.org Precedence: list Chris: A few nit picky notes below. >11. Security Considerations > > In order to make the entire body of Security Considerations more > accessible, Security Considerations for the transport, authentication, > and connection documents have been gathered here. > > The transport protocol [SSH-TRANS] provides a confidential channel > over an insecure network. It performs server host authentication, key > exchange, encryption, and integrity protection. It also derives a > unique session id that may be used by higher-level protocols. > > The authentication protocol [SSH-USERAUTH] provides a suite of > mechanisms which can be used to authenticatethe client user to the > server. Individual mechanisms specified in the in authentication > protocol use the session id provided by the transport protocol and/or > depend on the security and integrity guarantees of the transport > protocol. > > The connection protocol [SSH-CONNECT] specifies a mechanism to > multiplex multiple streams (channels) of data over the confidential > and authenticated transport. It also specifies channels for accessing > an interactive shell, for 'proxy-forwarding' various external > protocols over the secure transport (including arbitrary TCP/IP > protocols), and for accessing secure 'subsystems' on the server host. > > >11.1 PRNG > > This protocol binds each session key to the session by including > random, session specific data in the hash used to produce session > keys. Special care should be taken to ensure that all of the random > numbers are of good quality. If the random data here (e.g., DH > parameters) are pseudo-random then the pseudo-random number generator > should be cryptographically secure (i.e., its next output not easily > guessed even when knowing all previous outputs) and, furthermore, > proper entropy needs to be added to the pseudo-random number > generator. RFC 1750 [RFC1750] offers suggestions for sources of > random numbers and entropy. Implementors should note the importance > of entropy and the well-meant, anecdotal warning about the difficulty > in properly implementing pseudo-random number generating functions. > > The amount of entropy available to a given client or server may > sometimes be less than what is required. In this case one must either > resort to pseudo-random number generation regardless of insufficient > entropy or refuse to run the protocol. The latter is preferable. > > >11.2 Transport > > >11.2.1 Confidentiality > > It is beyond the scope of this document and the Secure Shell Working > Group to analyze or recommend specific ciphers other than the ones > which have been established and accepted within the industry. At the > time of this writing, ciphers commonly in use include 3DES, ARCFOUR, > twofish, serpent and blowfish. AES has been accepted by The US Federal s/accepted by The/published as a/ > Information Processing Standards [FIPS-197] and the cryptographic > community as being acceptable for this purpose as well. As always, s/as being acceptable for this purpose as well/has accepted AES/ > implementors and users should check current literature to ensure that > no recent vulnerabilities have been found in ciphers used within > products. Implementors should also check to see which ciphers are > considered to be relatively stronger than others and should recommend > their use to users over relatively weaker ciphers. It would be > considered good form for an implementation to politely and > unobtrusively notify a user that a stronger cipher is available and > should be used when a weaker one is actively chosen. > > The "none" cipher is provided for debugging and SHOULD NOT be used > except for that purpose. It's cryptographic properties are > sufficiently described in RFC 2410 [RFC2410], which will show that its > use does not meet the intent of this protocol. > > The relative merits of these and other ciphers may also be found in > current literature. Two references that may provide information on the > subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER]. Both of these > describe the CBC mode of operation of certain ciphers and the weakness > of this scheme. Essentially, this mode is theoretically vulnerable to > chosen cipher-text attacks because of the high predictability of the > start of packet sequence. However, this attack is still deemed Delete "still" > difficult and not considered fully practicable especially if relatively > longer block sizes are used. > > Additionally, another CBC mode attack may be mitigated through the > insertion of packets containing SSH_MSG_IGNORE. Without this > technique, a specific attack may be successful. For this attack > (commonly known as the Rogaway attack) ... Can you provide a reference? > ... to work, the attacker would > need to know the IV of the next block that is going to be encrypted. > In CBC mode that is the output of the encryption of the previous > block. If the attacker does not have any way to see the packet yet > (i.e it is in the internal buffers of the ssh implementation or even > in the kernel) then this attack will not work. If the last packet has > been sent out to the network (i.e the attacker has access to it) then > he can use the attack. > > In the optimal case an implementor would need to add an extra packet > only if the packet has been sent out onto the network and there are no > other packets waiting for transmission. Implementors may wish to check > to see if there are any unsent packets awaiting transmission, but > unfortunately it is not normally easy to obtain this information from > the kernel or buffers. If there are not, then a packet containing > SSH_MSG_IGNORE SHOULD be sent. If a new packet is added to the stream > every time the attacker knows the IV that is supposed to be used for > the next packet, then the attacker will not be able to guess the > correct IV, thus the attack will never be successfull. > > As an example, consider the following case: > > Client Server > ------ ------ > TCP(seq=x, len=500) -> > contains Record 1 > > [500 ms passes, no ACK] > > TCP(seq=x, len=1000) -> > contains Records 1,2 > > <- ACK > > > (1) The Nagle algorithm + TCP retransmits mean that the two > records get coalesced into a single TCP segment > (2) Record 2 is *not* at the beginning of the TCP segment > and never will be, since it gets ACKed. > (3) Yet, the attack is possible because Record 1 has already > been seen. > > As this example indicates, it's totally unsafe to use the existence > of unflushed data in the TCP buffers proper as a guide to whether > you need an empty packet, since when you do the second write(), > the buffers will contain the un-ACKed Record 1. > > On the other hand, it's perfectly safe to have the following > situation: > > Client Server > ------ ------ > TCP(seq=x, len=500) -> > contains SSH_MSG_IGNORE > > TCP(seq=y, len=500) -> > contains Data > > Provided that the IV for second SSH Record is fixed after the data for > the Data packet is determined -i.e. you do: > read from user > encrypt null packet > encrypt data packet > > >11.2.2 Data Integrity > > This protocol does allow the Data Integrity mechanism to be disabled. > Implementors SHOULD be wary of exposing this feature for any purpose > other than debugging. Users and administrators SHOULD be explicitly > warned anytime the "none" MAC is enabled. > > So long as the "none" MAC is not used, this protocol > provides data integrity. > > Because MACs use a 32 bit sequence number, they might start to leak > information after 2**32 packets have been sent. However, following > the rekeying recommendations should prevent this attack. The > transport protocol [1] recommends rekeying after one gigabyte of data, > and the smallest possible packet is 16 bytes. Therefore, rekeying > SHOULD happen after 2**28 packets at the very most. > > >11.2.3 Replay > > The use of a MAC other than 'none' provides integrity and > authentication. In addition, the transport protocol provides a unique > session identifier (bound in part to pseudo-random data that is part > of the algorithm and key exchange process) that can be used by higher > level protocols to bind data to a given session and prevent replay of > data from prior sessions. For example, the authentication protocol uses > this to prevent replay of signatures from previous sessions. Because > public key authentication exchanges are cryptographically bound to the > session (i.e., to the initial key exchange) they cannot be successfully > replayed in other sessions. Note that the session ID can be made > public without harming the security of the protocol. > > If two session happen to have the same session ID [hash of key > exchanges] then packets from one can be replayed against the other. > It must be stressed that the chances of such an occurrence are, > needless to say, minimal when using modern cryptographic methods. > This is all the more so true when specifying larger hash function > outputs and DH parameters. > > Replay detection using monotonically increasing sequence numbers as > input to the MAC, or HMAC in some cases, is described in RFC 2085 > [RFC2085], RFC 2246 [RFC2246], RFC 2743 [RFC2743], RFC 1964 [RFC1964], > RFC 2025 [RFC2025], and RFC 1510 [RFC1510]. The underlying construct > is discussed in RFC 2104 [RFC2104]. Essentially a different sequence > number in each packet ensures that at least this one input to the MAC > function will be unique and will provide a nonrecurring MAC output > that is not predictable to an attacker. If the session stays active > long enough, however, this sequence number will wrap. This event may > provide an attacker an opportunity to replay a previously recorded > packet with an identical sequence number but only if the peers have > not rekeyed since the transmission of the first packet with that > sequence number. If the peers have rekeyed, then the replay will be > detected as the MAC check will fail. For this reason, it must be > emphasized that peers MUST rekey before a wrap of the sequence > numbers. Naturally, if an attacker does attempt to replay a captured > packet before the peers have rekeyed, then the receiver of the > duplicate packet will not be able to validate the MAC and it will be > discarded. The reason that the MAC will fail is because the receiver > will formulate a MAC based upon the packet contents, the shared > secret, and the expected sequence number. Since the replayed packet > will not be using that expected sequence number (the sequence number > of the replayed packet will have already been passed by the receiver) > then the calculated MAC will not match the MAC received with the > packet. > > >11.2.4 Man-in-the-middle > > This protocol makes no assumptions nor provisions for an > infrastructure or means for distributing the public keys of hosts. It > is expected that this protocol will sometimes be used without first > verifying the association between the server host key and the server > host name. Such usage is vulnerable to man-in-the-middle attacks. > This section describes this and encourages administrators and users to > understand the importance of verifying this association before any > session is initiated. > > There are two cases of man-in-the-middle attacks to consider. The > first is where an attacker places a device between the client and the > server before the session is initiated. In this case, the attack > device is trying to mimic the legitimate server and will offer its > public key to the client when the client initiates a session. If it > were to offer the public key of the server, then it would not be able > to decrypt or sign the transmissions between the legitimate server and > the client unless it also had access to the private-key of the host. > The attack device will also, simultaneously to this, initiate a > session to the legitimate server masquerading itself as the client. > If the public key of the server had been securely distributed to the > client prior to that session initiation, the key offered to the client > by the attack device will not match the key stored on the client. In > that case, the user SHOULD be given a warning that the offered host > key does not match the host key cached on the client. As described in > Section 3.1 of [SSH-ARCH], the user may be free to accept the new key > and continue the session. It is RECOMMENDED that the warning provide > sufficient information to the user of the client device so they may > make an informed decision. If the user chooses to continue the > session with the stored public-key of the server (not the public-key > offered at the start of the session), then the session specific data > between the attacker and server will be different between the > client-to-attacker session and the attacker-to-server sessions due to > the randomness discussed above. From this, the attacker will not be > able to make this attack work since the attacker will not be able to > correctly sign packets containing this session specific data from the > server since he does not have the private key of that server. > > Insecure distribution of server public keys allows a second type of > man-in-the-middle attack that should also be considered in this case; > one with suitable but incorrect host keys. If the server public keys > are not securely distributed then the client cannot know if it is > talking to the intended server. An attacker may use social > engineering techniques to pass off server keys to unsuspecting users > and may then place a man-in-the-middle attack device between the > legitimate server and the clients. If this is allowed to happen then > the clients will form client-to-attacker sessions and the attacker > will form attacker-to-server sessions and will be able to monitor and > manipulate all of the traffic between the clients and the legitimate > servers. Server administrators are encouraged to make host key > fingerprints available for checking by some means whose security does > not rely on the integrity of the actual host keys. Possible > mechanisms are discussed in Section 3.1 of [SSH-ARCH] and may also > include secured Web pages, physical pieces of paper, etc. > Implementors SHOULD provide recommendations on how best to do this > with their implementation. Because the protocol is extensible, future > extensions to the protocol may provide better mechanisms for dealing > with the need to know the server's host key before connecting. For > example, making the host key fingerprint available through a secure > DNS lookup, or using kerberos over gssapi during key exchange to > authenticate the server are possibilities. > > As a second man-in-the-middle case, attackers may attempt to > manipulate packets in transit between peers after the session has been > established. As described in the Replay part of this section, a > successful attack of this nature is very improbable. As in the Replay > section, this reasoning does assume that the MAC is secure and that it > is infeasible to construct inputs to a MAC algorithm to give a known > output. This is discussed in much greater detail in Section 6 of RFC > 2104. If the MAC algorithm has a vulnerability or is weak enough, > then the attacker may be able to specify certain inputs to yield a > known MAC. With that they may be able to alter the contents of a > packet in transit. Alternatively the attacker may be able to exploit > the algorithm vulnerability or weakness to find the shared secret by > reviewing the MACs from captured packets. In either of those cases, > an attacker could construct a packet or packets that could be inserted > into an SSH stream. To prevent that, implementors are encouraged to > utilize commonly accepted MAC algorithms and administrators are > encouraged to watch current literature and discussions of cryptography > to ensure that they are not using a MAC algorithm that has a recently > found vulnerability or weakness. > > In summary, the use of this protocol without a reliable association of > the binding between a host and its host keys is inherently insecure > and is NOT RECOMMENDED. It may however be necessary in non-security > critical environments, and will still provide protection against > passive attacks. Implementors of protocols and applications running > on top of this protocol should keep this possibility in mind. > > >11.2.5 Denial-of-service > > This protocol is designed to be used over a reliable transport. If > transmission errors or message manipulation occur, the connection is > closed. The connection SHOULD be re-established if this occurs. > Denial of service attacks of this type ("wire cutter") are almost > impossible to avoid. > > In addition, this protocol is vulnerable to Denial of Service > attacks because an attacker can force the server to go through > the CPU and memory intensive tasks of connection setup and > key exchange without authenticating. Implementors SHOULD provide > features that make this more difficult. For example, only allowing > connections from a subset of IPs known to have valid users. > > >11.2.6 Covert Channels > > The protocol was not designed to eliminate covert channels. For > example, the padding, SSH_MSG_IGNORE messages, and several other > places in the protocol can be used to pass covert information, and > the recipient has no reliable way to verify whether such information > is being sent. > > >11.2.7 Forward Secrecy > > It should be noted that the Diffie-Hellman key exchanges may provide > perfect forward secrecy (PFS). PFS is essentially defined as the > cryptographic property of a key-establishment protocol in which the > compromise of a session key or long-term private key after a given > session does not cause the compromise of any earlier session. > [ANSI T1.523-2001] SSHv2 sessions resulting from a key exchange using > diffie-hellman-group1-sha1 are secure even if private > keying/authentication material is later revealed, but not if the > session keys are revealed. So, given this definition of PFS, SSHv2 > does have PFS. It is hoped that all other key exchange mechanisms > proposed and used in the future will also provide PFS. This property > is not commuted to any of the applications or protocols using SSH as a > transport however. The transport layer of SSH provides > confidentiality for password authentication and other methods that > rely on secret data. > > Of course, if the DH private parameters for the client and server are > revealed then the session key is revealed, but these items can be > thrown away after the key exchange completes. It's worth pointing out > that these items should not be allowed to end up on swap space and > that they should be erased from memory as soon as the key exchange > completes. > > >11.3 Authentication Protocol > > The purpose of this protocol is to perform client user authentication. > It assumes that this run over a secure transport layer protocol, which > has already authenticated the server machine, established an encrypted > communications channel, and computed a unique session identifier for > this session. > > Several authentication methods with different security characteristics > are allowed. It is up to the server's local policy to decide which > methods (or combinations of methods) it is willing to accept for each > user. Authentication is no stronger than the weakest combination > allowed. > > The server may go into a "sleep" period after repeated unsuccessful > authentication attempts to make key search more difficult for > attackers. Care should be taken so that this doesn't become a > self-denial of service vector. > > >11.3.1 Weak Transport > > If the transport layer does not provide confidentiality, > authentication methods that rely on secret data SHOULD be disabled. > If it does not provide strong integrity protection, requests to change > authentication data (e.g. a password change) SHOULD be disabled to > prevent an attacker from modifying the ciphertext without being > noticed, or rendering the new authentication data unusable (denial > of service). > > The assumption as stated above that the Authentication Protocol only > run over a secure transport that has previously authenticated the > server is very important to note. People deploying SSH are reminded > of the consequences of man-in-the-middle attacks if the client does > not have a very strong a priori association of the server with the > host key of that server. Specifically for the case of the > Authentication Protocol the client may form a session to a > man-in-the-middle attack device and divulge user credentials such as > their username and password. Even in the cases of authentication > where no user credentials are divulged, an attacker may still gain > information they shouldn't have by capturing key-strokes in much the > same way that a honeypot works. > > >11.3.2 Debug messages > > Special care should be taken when designing debug messages. These > messages may reveal surprising amounts of information about the host > if not properly designed. Debug messages can be disabled (during > user authentication phase) if high security is required. Can we encourage products to ship with them turned off, requiring an action to turn them on? >11.3.3 Local security policy > > Implementer MUST ensure that the credentials provided validate the > professed user and also MUST ensure that the local policy of the > server permits the user the access requested. In particular, > because of the flexible nature of the SSH connection protocol, it may > not be possible to determine the local security policy, if any, that > should apply at the time of authentication because the kind of service > being requested is not clear at that instant. For example, local > policy might allow a user to access files on the server, but not start > an interactive shell. However, during the authentication protocol, it > is not known whether the user will be accessing files or attempting to > use an interactive shell, or even both. In any event, where local > security policy for the server host exists, it MUST be applied and > enforced correctly. > > Implementors are encouraged to provide a default local policy and > make its parameters known to administrators and users. At the > discretion of the implementors, this default policy may be along the > lines of 'anything goes' where there are no restrictions placed upon > users, or it may be along the lines of 'excessively restrictive' in > which case the administrators will have to actively make changes to > this policy to meet their needs. Alternatively, it may be some > attempt at providing something practical and immediately useful to the > administrators of the system so they don't have to put in much effort > to get SSH working. Whatever choice is made MUST be applied and > enforced as required above. > > >11.3.4 Public key authentication > > The use of public-key authentication assumes that the client host has > not been compromised. > > This risk can be mitigated by the use of passphrases on private keys; > however, this is not an enforceable policy. The use of smartcards, or > other technology to make passphrases an enforceable policy is > suggested. > > The server could require both password and public-key authentication, > however, this requires the client to expose its password to the server > (see section on password authentication below.) > > >11.3.5 Password authentication > > The password mechanism as specified in the authentication protocol > assumes that the server has not been compromised. If the server has > been compromised, using password authentication will reveal a valid > username / password combination to the attacker, which may lead to > further compromises. > > This vulnerability can be mitigated by using an alternative form of > authentication. For example, public-key authentication makes no > assumptions about security on the server. > > >11.3.6 Host based authentication > > Host based authentication assumes that the client has not been > compromised. There are no mitigating strategies, other than to use > host based authentication in combination with another authentication > method. > > >11.4 Connection protocol > > >11.4.1 End point security > > End point security is assumed by the connection protocol. If the > server has been compromised, any terminal sessions, port forwarding, > or systems accessed on the host are compromised. There are no > mitigating factors for this. > > If the client end point has been compromised, and the server fails to > stop the attacker at the authentication protocol, all services exposed > (either as subsystems or through forwarding) will be vulnerable to > attack. Implementors SHOULD provide mechanisms for administrators to > control which services are exposed to limit the vulnerability of other > services. > > These controls might include controlling which machines and ports can > be target in 'port-forwarding' operations, which users are allowed to > use interactive shell facilities, or which users are allowed to use > exposed subsystems. > > >11.4.2 Proxy forwarding > > The SSH connection protocol allows for proxy forwarding of other > protocols such as SNMP, POP3, and HTTP. This may be a concern for > network administrators who wish to control the access of certain > applications by users located outside of their physical location. > Essentially, the forwarding of these protocols may violate site > specific security policies as they may be undetectably tunneled > through a firewall. Implementors SHOULD provide an administrative > mechanism to control the proxy forwarding functionality so that > site specific security policies may be upheld. > > In addition, a reverse proxy forwarding functionality > is available, which again can be used to bypass firewall > controls. > > As indicated above, end-point security is assumed during > proxy forwarding operations. Failure of end-point security > will compromise all data passed over proxy forwarding. > > >11.4.3 X11 forwarding > > Another form of proxy forwarding provided by the ssh connection > protocol is the forwarding of the X11 protocol. If end-point security > has been compromised, X11 forwarding may allow attacks against the X11 > server. Users and administrators should, as a matter of course, use > appropriate X11 security mechanisms to prevent unauthorized use of the > X11 server. Implementors, administrators and users who wish to > further explore the security mechanisms of X11 are invited to read > [SCHEIFLER] and analyze previously reported problems with the > interactions between SSH forwarding and X11 in CERT vulnerabilities > VU#363181 and VU#118892 [CERT]. > > X11 display forwarding with SSH, by itself, is not sufficient to > correct well known problems with X11 security [VENEMA]. However, X11 > display forwarding in SSHv2 (or other, secure protocols), combined > with actual and pseudo-displays which accept connections only over > local IPC mechanisms authorized by permissions or ACLs, does correct > many X11 security problems as long as the "none" MAC is not used. It > is RECOMMENDED that X11 display implementations default to allowing > display opens only over local IPC. It is RECOMMENDED that SSHv2 > server implementations that support X11 forwarding default to allowing > display opens only over local IPC. On single-user systems it might be > reasonable to default to allowing local display opens over TCP/IP. > > Implementors of the X11 forwarding protocol SHOULD implement the magic > cookie access checking spoofing mechanism as described in [ssh-connect] > as an additional mechanism to prevent unauthorized use of the proxy. > > >References from this section: > >[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication > Service (V5)", RFC 1510, September 1993. > >[RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", > RFC 1964, June 1996. > >[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness > Recommendations for Security", RFC 1750, December 1994. > >[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism > (SPKM)", RFC 2025, October 1996. > >[RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with Replay > Prevention", RFC 2085, February 1997. > >[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: > Keyed-Hashing for Message Authentication", RFC 2104, > February 1997. > >[RFC2246] Diercks, T. and C. Allen, "The TLS Protocol Version > 1.0", RFC 2246, January 1999. > >[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its > Use With IPsec", RFC 2410, November 1998 > >[RFC2743] Linn, J., "Generic Security Service Application Program > Interface Version 2, Update 1", RFC 2743, January 2000. > >[SCHNEIER] Applied Cryptography, Second Edition, Bruce Schneier, Wiley > and Sons Publisher, 1996 > >[KAUFMAN,PERLMAN,SPECINER] Network Security; PRIVATE Communication in > a PUBLIC World, Charlie Kaufman, Radia Perlman, Mike Speciner, > Prentice Hall Publisher, 1995 > >[FIPS-197] National Institute of Standards and Technology, > "Specification for the Advanced Encryption Standard (AES)" > FIPS 197. November 26, 2001. > >[ANSI T1.523-2001] American National Standard T1.523-2001, "Telecom > Glossary 2000", American National Standards Institute, Inc., > Approved February 28, 2001. > > >[SCHEIFLER] Scheifler, R., "X Window System : The Complete > Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd > edition.", Digital Press ISBN 1555580882, Feburary > 1992. > >[CERT] The CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh, PA 15213-3890 > U.S.A. > ( http://www.cert.org/nav/index_red.html ) > >[VENEMA] Wietse Venema, "Murphy's Law and Computer Security", Proceedings > of 6th USENIX Security Symposium, San Jose, CA, July 1996. >http://www.usenix.org/publications/library/proceedings/sec96/venema.html From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 10 11:06:46 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04660 for ; Tue, 10 Jun 2003 11:06:45 -0400 (EDT) Received: (qmail 12853 invoked by uid 605); 10 Jun 2003 15:06:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12846 invoked from network); 10 Jun 2003 15:06:40 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by mail.netbsd.org with SMTP; 10 Jun 2003 15:06:40 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5AF6ams016872 for ; Tue, 10 Jun 2003 08:06:36 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA15679 for ; Tue, 10 Jun 2003 08:06:36 -0700 (PDT) Date: Tue, 10 Jun 2003 08:06:35 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: Re: Pulling it all together - New Section 11 on Security Considerations In-Reply-To: <5.2.0.9.2.20030605155633.040b2ea0@mail.binhost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, Nominal nits nuked. http://www.employees.org/~lonvick/newssh10.html The only signigicant chances were in Section 11.3.2 Debug messages. Please look that over and provide comments. I've found the following references to the "Rogaway attack". [Rogaway] P. Rogaway, "Problems with Proposed IP Cryptography, 1995. Unpublished paper available at http://www.cs.ucdavis.edu/ ~rogaway/papers/draft-rogaway-ipsec-comments-00.txt [Dai] W. Dai, "an attack against SSH2 protocol", Email to the SecSH Working Group ietf-ssh@netbsd.org, Feb. 2002, available at ftp://ftp.ietf.org/ietf-mail-archive/secsh/2002-02.mail [BELLARE,KOHNO,NAMPREMPRE] "Authenticated Encryption in SSH: Fixing the SSH Binary Packet Protocol", Proceedings of the 9th ACM Conference on Computer and Communications Security, M. Bellaire, T. Kohno, C. Namprempre, Sept. 2002 For the last one, the paper is online at http://www.cs.ucsd.edu/users/tkohno/papers/SSH/ The first two are ephemeral so I'm not sure if they're appropriate for inclusion in a Standards Track RFC. On the other hand, I think it appropriate to give credit where it is deserved and it looks like Dr. Phillip Rogaway was the first person to discuss this. Wei Dai discussed it in the mailing list and showed its applicability to SSH. The third reference also gives credible analysis of the attack in Section 3 and also references the prior discussions of Rogaway and Dai. Are there any objections to including all three references? Are there any other references to this that should be included? Thanks, Chris On Thu, 5 Jun 2003, Russ Housley wrote: > Chris: > > A few nit picky notes below. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 10 12:30:57 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07956 for ; Tue, 10 Jun 2003 12:30:57 -0400 (EDT) Received: (qmail 24881 invoked by uid 605); 10 Jun 2003 16:30:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24873 invoked from network); 10 Jun 2003 16:30:51 -0000 Received: from softdnserror (HELO xanthine.gratuitous.org) (199.232.39.35) by mail.netbsd.org with SMTP; 10 Jun 2003 16:30:51 -0000 Received: by xanthine.gratuitous.org with local; Tue, 10 Jun 2003 12:28:07 -0400 From: "Joel N. Weber II" To: Chris Lonvick CC: ietf-ssh@netbsd.org In-reply-to: (message from Chris Lonvick on Tue, 10 Jun 2003 08:06:35 -0700 (PDT)) Subject: Re: Pulling it all together - New Section 11 on Security Considerations References: Message-Id: Date: Tue, 10 Jun 2003 12:28:07 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list The paragraphs in the man in the middle attack section are awefully long. It might be more readable if there was a subheading for each of the three cases that are currently paragraphs, so that each of the existing paragraphs could be broken into multiple paragraphs. newssh10.html appears to have lost some changes to the mitm attack section that were made in newssh9.html, such as starting off the paragraph with ``There are {two,three} cases to consider'' There are several issues with the host key of a mitm being presented instead of the real host that are not adaquately discussed in the current text, some of which I think have been previously brought up in discussion on this list: 1) There should be an explicit discussion of the problem that in the real world, hosts occasionally get reinstalled, CNAMEs sometimes move around, etc. When this happens, people often learn that the meaning of the man in the middle attack warning is simply that they should delete the relevant line of their known_hosts file. The standard usage of bare ssh host keys is such that, given only the message from the ssh client, it is impossible to figure out whether there is a mitm attack or a legitimate host key change, and that only with a lot of user education and increased user paranoia or a better mechanism is this vulnerability going to go away. 2) It would be useful to discuss how if public key userauth is used, the mitm will not be able to authenticate to the real server as the user, because the signature will be against the wrong session identifier. 3) It would be useful to mention that if agent forwarding is enabled, and if the host key of a bogus server is accepted by the client, the man in the middle *will* be able to authenticate to the real server. It should probably be recommended that agent forwarding be disabled by default. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 10 12:34:54 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08288 for ; Tue, 10 Jun 2003 12:34:54 -0400 (EDT) Received: (qmail 27563 invoked by uid 605); 10 Jun 2003 16:34:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27556 invoked from network); 10 Jun 2003 16:34:53 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by mail.netbsd.org with SMTP; 10 Jun 2003 16:34:53 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5AGYnjc029267; Tue, 10 Jun 2003 09:34:49 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA13315; Tue, 10 Jun 2003 09:34:49 -0700 (PDT) Date: Tue, 10 Jun 2003 09:34:49 -0700 (PDT) From: Chris Lonvick To: "Joel N. Weber II" cc: ietf-ssh@netbsd.org Subject: Re: Pulling it all together - New Section 11 on Security Considerations In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, On Tue, 10 Jun 2003, Joel N. Weber II wrote: > newssh10.html appears to have lost some changes to the mitm attack > section that were made in newssh9.html, such as starting off the > paragraph with ``There are {two,three} cases to consider'' Apologies for that. I'm thinking of switching to cvs. I'll get that rectified and address your other points as well. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jun 12 11:05:59 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14914 for ; Thu, 12 Jun 2003 11:05:58 -0400 (EDT) Received: (qmail 28900 invoked by uid 605); 12 Jun 2003 15:05:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28893 invoked from network); 12 Jun 2003 15:05:55 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by mail.netbsd.org with SMTP; 12 Jun 2003 15:05:55 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5CF5s3p001934 for ; Thu, 12 Jun 2003 08:05:54 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA20378 for ; Thu, 12 Jun 2003 08:05:54 -0700 (PDT) Date: Thu, 12 Jun 2003 08:05:54 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: Updated Section 11 online In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi Folks, I've redone the Section 11 incorporating Russ' comments and adding the references to the Rogaway attack. http://www.employees.org/~lonvick/newssh010.html If anyone cannot view this, or has difficulties viewing it, please send me a note separately and I'll ship the plain-text version to you. I'll start working on the comments provided by Joel with hopes of making them available next week. For those who may wish to propose helpful text, here are the comments. === The paragraphs in the man in the middle attack section are awefully long. It might be more readable if there was a subheading for each of the three cases that are currently paragraphs, so that each of the existing paragraphs could be broken into multiple paragraphs. [Note: I learned that a paragraph is a separate thought in the whole of the document reguardless of length. I'll think about it. (Kafka had a way with paragraphs. ;) ] newssh10.html appears to have lost some changes to the mitm attack section that were made in newssh9.html, such as starting off the paragraph with ``There are {two,three} cases to consider'' [Note: All fixed up now in 010.html] There are several issues with the host key of a mitm being presented instead of the real host that are not adaquately discussed in the current text, some of which I think have been previously brought up in discussion on this list: 1) There should be an explicit discussion of the problem that in the real world, hosts occasionally get reinstalled, CNAMEs sometimes move around, etc. When this happens, people often learn that the meaning of the man in the middle attack warning is simply that they should delete the relevant line of their known_hosts file. The standard usage of bare ssh host keys is such that, given only the message from the ssh client, it is impossible to figure out whether there is a mitm attack or a legitimate host key change, and that only with a lot of user education and increased user paranoia or a better mechanism is this vulnerability going to go away. 2) It would be useful to discuss how if public key userauth is used, the mitm will not be able to authenticate to the real server as the user, because the signature will be against the wrong session identifier. 3) It would be useful to mention that if agent forwarding is enabled, and if the host key of a bogus server is accepted by the client, the man in the middle *will* be able to authenticate to the real server. It should probably be recommended that agent forwarding be disabled by default. === Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jun 12 11:46:42 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16402 for ; Thu, 12 Jun 2003 11:46:41 -0400 (EDT) Received: (qmail 25776 invoked by uid 605); 12 Jun 2003 15:46:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25768 invoked from network); 12 Jun 2003 15:46:37 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 12 Jun 2003 15:46:37 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5CFkQ4Z011484; Thu, 12 Jun 2003 08:46:26 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5CFkQ27029238; Thu, 12 Jun 2003 11:46:26 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h5CFkPq3025794; Thu, 12 Jun 2003 11:46:26 -0400 (EDT) Message-Id: <200306121546.h5CFkPq3025794@thunk.east.sun.com> From: Bill Sommerfeld To: Chris Lonvick cc: ietf-ssh@netbsd.org Subject: Re: Updated Section 11 online In-Reply-To: Your message of "Thu, 12 Jun 2003 08:05:54 PDT." Reply-to: sommerfeld@east.sun.com Date: Thu, 12 Jun 2003 11:46:25 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi. This is your wg chair speaking. I've been busy with the day job so i haven't been as active as I'd like but you've been making steady albeit slow progress on this. That said, with the impending I-D publications deadline for the Vienna meeting, I think it's time to shoot the engineers and ship these documents. Remember, they're only going to Proposed Standard. Anyone who has objections to reissuing the documents with the text proposed in: http://www.employees.org/~lonvick/newssh010.html should speak up now. Anyone with objections MUST SUPPLY PRECISE SUGGESTED EDITS. In particular, in order to hold the documents you MUST CONVINCE ME THAT IT'S A SHOWSTOPPER that can't be fixed when we go to draft standard. With regards to the issues remaining: > 1) There should be an explicit discussion of the problem that in the > real world, hosts occasionally get reinstalled, CNAMEs sometimes move > around, etc. When this happens, people often learn that the meaning > of the man in the middle attack warning is simply that they should > delete the relevant line of their known_hosts file. Anyone who feels that this issue is a showstopper should provide corrected text to this list by this Friday. > 2) It would be useful to discuss how if public key userauth is used, > the mitm will not be able to authenticate to the real server as the > user, because the signature will be against the wrong session > identifier. Not a showstopper as it doesn't disclose a weakness in the protocol. > 3) It would be useful to mention that if agent forwarding is enabled, > and if the host key of a bogus server is accepted by the client, the > man in the middle *will* be able to authenticate to the real server. > It should probably be recommended that agent forwarding be disabled by > default. Agent forwarding is not part of the core drafts. Not a showstopper. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jun 16 19:25:40 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08400 for ; Mon, 16 Jun 2003 19:25:39 -0400 (EDT) Received: (qmail 7206 invoked by uid 605); 16 Jun 2003 23:25:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7197 invoked from network); 16 Jun 2003 23:25:27 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 16 Jun 2003 23:25:27 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5GNPD4Z004443; Mon, 16 Jun 2003 16:25:14 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5GNPD27009850; Mon, 16 Jun 2003 19:25:13 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h5GNPDq3025247; Mon, 16 Jun 2003 19:25:13 -0400 (EDT) Message-Id: <200306162325.h5GNPDq3025247@thunk.east.sun.com> From: Bill Sommerfeld To: Darren.Moffat@sun.com Cc: ietf-ssh@netbsd.org, Chris Lonvick Subject: Re: Updated Section 11 online In-Reply-To: Your message of "Thu, 12 Jun 2003 11:46:25 EDT." Reply-to: sommerfeld@east.sun.com Date: Mon, 16 Jun 2003 19:25:13 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list All, I've heard no objections to my proposal of last week to declare Chris's draft 10 of the security consideration sections done. Darren, Please reissue the core SSH protocol documents ASAP with a security considerations section pulled from: http://www.employees.org/~lonvick/newssh010.html If you have any trouble, please work with Chris to ensure the right thing happens. Chris, Thank you for your hard work bringing this revised document section together. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jun 19 16:14:34 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16286 for ; Thu, 19 Jun 2003 16:14:33 -0400 (EDT) Received: (qmail 28875 invoked by uid 605); 19 Jun 2003 20:14:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28868 invoked from network); 19 Jun 2003 20:14:31 -0000 Received: from mailrelay1.lanl.gov (128.165.4.101) by mail.netbsd.org with SMTP; 19 Jun 2003 20:14:31 -0000 Received: from lanl.gov (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (8.12.9/8.12.9/(ccn-5)) with ESMTP id h5JKENck012497 for ; Thu, 19 Jun 2003 14:14:23 -0600 Message-ID: <3EF2199F.7000902@lanl.gov> Date: Thu, 19 Jun 2003 14:14:23 -0600 From: "David M. Williams" Organization: CCN-2 User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@netbsd.org Subject: Re: I-D ACTION:draft-ietf-secsh-gsskeyex-06.txt References: <200303071154.GAA21532@ietf.org> In-Reply-To: <200303071154.GAA21532@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit does anyone know where I can get the nroff version of this draft?? I have edits I'd like to propose to the group and find nroff easier to work with. Dave Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Secure Shell Working Group of the IETF. > > Title : GSSAPI Authentication and Key Exchange for the Secure > Shell Protocol > Author(s) : J. Hutzelman, J. Salowey, J. Galbraith, V. Welch > Filename : draft-ietf-secsh-gsskeyex-06.txt > Pages : 27 > Date : 2003-3-6 > >The Secure Shell protocol (SSH) is a protocol for secure remote >login and other secure network services over an insecure network. >The Generic Security Service Application Program Interface (GSS-API) >[2] provides security services to callers in a mechanism-independent >fashion. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-06.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-secsh-gsskeyex-06.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-secsh-gsskeyex-06.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > -- David M. Williams, CISSP Phone: 505-665-8062 Systems Engineer, CCN-2 Fax: 505-667-7942 Los Alamos National Laboratory Email: d_wllmsATlanlDOTgov "Nel mezzo del cammin di nostra vita / mi ritrouvai per una selva oscura / che la diritta via era smarrita" -Dante Aligheri From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jun 19 21:42:00 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28479 for ; Thu, 19 Jun 2003 21:41:59 -0400 (EDT) Received: (qmail 11215 invoked by uid 605); 20 Jun 2003 01:41:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11208 invoked from network); 20 Jun 2003 01:41:57 -0000 Received: from sngrel7.hp.com (192.6.86.111) by mail.netbsd.org with SMTP; 20 Jun 2003 01:41:57 -0000 Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by sngrel7.hp.com (Postfix) with SMTP id 770FF37F for ; Fri, 20 Jun 2003 09:41:53 +0800 (SGP) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Fri, 20 Jun 2003 11:41:44 +1000 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id N1P3VYGZ; Fri, 20 Jun 2003 11:41:43 +1000 Received: from 16.176.65.78 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Fri, 20 Jun 2003 11:41:43 +1000 Received: from mbp by vexed with local (Exim 3.36 #1 (Debian)) id 19TAtn-00046I-00; Fri, 20 Jun 2003 11:41:07 +1000 Date: Fri, 20 Jun 2003 11:41:07 +1000 From: Martin Pool To: Joseph Galbraith , Alfred Perlstein , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. Message-ID: <20030620014103.GF15304@vexed.ozlabs.hp.com> References: <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> X-GPG: 1024D/A0B3E88B: AFAC578F 1841EE6B FD95E143 3C63CA3F A0B3E88B User-Agent: Mutt/1.5.4i Sender: ietf-ssh-owner@netbsd.org Precedence: list On 13 May 2003, Joseph Galbraith wrote: > Let me make sure I understand the problem: > > - SSH_FXP_RENAME specifies that it is an > error if the new file exists. > > - rename(2) specifies that if the new file > exists, it is always overwritten. > > Therefore rename(2) can't be used to implement > SSH_FXP_RENAME. > > Is this a correct summary of the problem? I think the fact that SSH_FXP_RENAME is impossible to reliably implemented on Unix is a serious problem. Secondarily it is a shame that it prevents use of the atomic-rename Unix idiom. I would like to suggest that the phrasing be changed to The server MAY return SSH_FX_FILE_ALREADY_EXISTS if there exists a file with the name specified by newpath. Clients which wish to always replace the path without knowing the server filesystem can precede the rename operation with an attempt to delete the destination file. That does not seem to be an undue burden. Clients which know the server is Unix and which wish to take advantage of atomic replace can do so. -- Martin From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jun 19 21:57:14 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29049 for ; Thu, 19 Jun 2003 21:57:14 -0400 (EDT) Received: (qmail 17151 invoked by uid 605); 20 Jun 2003 01:57:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17144 invoked from network); 20 Jun 2003 01:57:11 -0000 Received: from sngrel7.hp.com (192.6.86.111) by mail.netbsd.org with SMTP; 20 Jun 2003 01:57:11 -0000 Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by sngrel7.hp.com (Postfix) with SMTP id 27DD825F for ; Fri, 20 Jun 2003 09:57:03 +0800 (SGP) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Fri, 20 Jun 2003 11:57:01 +1000 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id N1P3VYXB; Fri, 20 Jun 2003 11:57:01 +1000 Received: from 16.176.65.78 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Fri, 20 Jun 2003 11:57:00 +1000 Received: from mbp by vexed with local (Exim 3.36 #1 (Debian)) id 19TB8a-0004UK-00 for ; Fri, 20 Jun 2003 11:56:24 +1000 Date: Fri, 20 Jun 2003 11:56:24 +1000 From: Martin Pool To: ietf-ssh@netbsd.org Subject: secsh-filexfer: any limit on the number of filehandles? Message-ID: <20030620015623.GG15304@vexed.ozlabs.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-GPG: 1024D/A0B3E88B: AFAC578F 1841EE6B FD95E143 3C63CA3F A0B3E88B User-Agent: Mutt/1.5.4i Sender: ietf-ssh-owner@netbsd.org Precedence: list I have been reading the current draft-ietf-secsh-filexfer-04.txt. It looks like a very nicely designed protocol. Many operations in the protocol operate on open files. The SSH_FXP_OPEN request can return a file handle (which is an opaque variable-length string) which may be used to access the file later (e.g. in a read operation). The client MUST NOT send requests the server with bogus or closed handles. However, the server MUST perform adequate checks on the handle in order to avoid security risks due to fabricated handles. I am a little concerned that there is no discussion of a limit on the number of open files. In a situation where the user is not completely trusted by the server this could pose some kind of resource exhaustion problem, either by using up file descriptors, kernel file handles, or just entries in a table of handles. Consider for example a customer uploading files to a shared web host over sftp, or an anonymous/readonly server over TCP. The server could of course impose a limit on the number of files that any client is allowed to open at a time. In itself that kind of implementation decision doesn't need to be discussed here. It is not clear to me what error a server ought to return in that situation. Perhaps SSH_FX_INVALID_HANDLE? It might be nice if this were specified, so that a client could potentially close off another handle and try again. Possibly a new error should be defined? I do think requiring clients to close files is probably easier than the NFSv4 system of the server invalidating handles and requiring the client to reacquire them. The standard perhaps should mention what expectations a client can have about keeping handles open. For example, it might say that a client must be able to handle a server which only allows a single file to be open at a time, or perhaps it should say that a server SHOULD allow at least (say) eight handles to be open. I don't know what limit would make sense for existing implementations but I do think the question should be addressed. -- Martin From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jun 20 08:12:43 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01585 for ; Fri, 20 Jun 2003 08:12:40 -0400 (EDT) Received: (qmail 18818 invoked by uid 605); 20 Jun 2003 12:12:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18811 invoked from network); 20 Jun 2003 12:12:18 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 20 Jun 2003 12:12:18 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jun 2003 08:13:00 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC0C7@lespaul.process.com> From: Richard Whalen To: "'Martin Pool'" , Joseph Galbraith , Alfred Perlstein , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: RE: sftp rename not good. Date: Fri, 20 Jun 2003 08:12:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list The suggested change sounds good. Note that there is no method specified to determine what the server operating system is. -----Original Message----- From: Martin Pool [mailto:mbp@samba.org] Sent: Thursday, June 19, 2003 9:41 PM To: Joseph Galbraith; Alfred Perlstein; ietf-ssh@netbsd.org; Markus Friedl; openssh@openssh.com Subject: Re: sftp rename not good. On 13 May 2003, Joseph Galbraith wrote: > Let me make sure I understand the problem: > > - SSH_FXP_RENAME specifies that it is an > error if the new file exists. > > - rename(2) specifies that if the new file > exists, it is always overwritten. > > Therefore rename(2) can't be used to implement > SSH_FXP_RENAME. > > Is this a correct summary of the problem? I think the fact that SSH_FXP_RENAME is impossible to reliably implemented on Unix is a serious problem. Secondarily it is a shame that it prevents use of the atomic-rename Unix idiom. I would like to suggest that the phrasing be changed to The server MAY return SSH_FX_FILE_ALREADY_EXISTS if there exists a file with the name specified by newpath. Clients which wish to always replace the path without knowing the server filesystem can precede the rename operation with an attempt to delete the destination file. That does not seem to be an undue burden. Clients which know the server is Unix and which wish to take advantage of atomic replace can do so. -- Martin From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 24 06:56:53 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10948 for ; Tue, 24 Jun 2003 06:56:52 -0400 (EDT) Received: (qmail 13202 invoked by uid 605); 24 Jun 2003 10:56:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13195 invoked from network); 24 Jun 2003 10:56:35 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 24 Jun 2003 10:56:35 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10873; Tue, 24 Jun 2003 06:56:30 -0400 (EDT) Message-Id: <200306241056.GAA10873@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt Date: Tue, 24 Jun 2003 06:56:30 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure Shell 'none' Public Key Algorithm Author(s) : J. Weber Filename : draft-weber-secsh-pkalg-none-00.txt Pages : 4 Date : 2003-6-23 This document describes the 'none' public key encryption algorithm for the Secure Shell protocol, which is useful for rekeying when the server has no keys to support for non-GSSAPI key exchange and when GSSAPI credentials are expired, or for use in embedded systems where there is a desire to minimize the overhead of rekeying to prevent sequence number rollover. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-weber-secsh-pkalg-none-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-weber-secsh-pkalg-none-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-weber-secsh-pkalg-none-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-23142330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-weber-secsh-pkalg-none-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-weber-secsh-pkalg-none-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-23142330.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 24 09:21:09 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15180 for ; Tue, 24 Jun 2003 09:21:06 -0400 (EDT) Received: (qmail 22031 invoked by uid 605); 24 Jun 2003 13:21:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22024 invoked from network); 24 Jun 2003 13:21:01 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 24 Jun 2003 13:21:01 -0000 Received: by xanthine.gratuitous.org with local; Tue, 24 Jun 2003 09:21:00 -0400 From: "Joel N. Weber II" To: Subject: gssapi host key algorithm usage Message-Id: Date: Tue, 24 Jun 2003 09:21:00 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list The secsh transport draft suggests that there can be different kinds of host key algorithms, and that some key exchange operations may support different host key algorithms than others. The idea that GSS mechanisms don't have host keys strikes me as confused. As far as I can tell, if I have a Kerberos 5 principal named host/foo.example.com@EXAMPLE.COM and I store that encryption key in /etc/krb5.keytab on the host foo.example.com, it is very much the case that that krb5.keytab is a form of a host key. As far as I know, all GSS mechanisms that anyone cares about for use with ssh do support host keys, albeit abstracted away to the point where ssh protocol designers and implementers don't directly deal with them. On furthur thought, I don't really understand why gss-group1-sha1-* has to be defined as gss-group1-sha1-*. Wouldn't it have been cleaner to define it as gss-group1-sha1 and then put information on which gss mechanism is being used in the host key algorithm field? It may well be too late to change now for gss-group1-sha1 (on the other hand, sxw's patches seem to have survived a change in the OID->string conversion), but if gss-group-exchange-sha1 gets defined, I hope it will use the host key field to specify which GSS mechanism to use. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 24 10:46:05 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18898 for ; Tue, 24 Jun 2003 10:46:04 -0400 (EDT) Received: (qmail 1137 invoked by uid 605); 24 Jun 2003 14:45:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1126 invoked from network); 24 Jun 2003 14:45:56 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 24 Jun 2003 14:45:56 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5OEjrfU021590; Tue, 24 Jun 2003 07:45:53 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5OEjqNg016938; Tue, 24 Jun 2003 08:45:52 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h5OEguQx009710; Tue, 24 Jun 2003 07:42:56 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h5OEguvk009709; Tue, 24 Jun 2003 07:42:56 -0700 (PDT) Date: Tue, 24 Jun 2003 07:42:56 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@netbsd.org Subject: Re: gssapi host key algorithm usage Message-ID: <20030624074252.A9703@binky.central.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ietf-secsh@joelweber.com on Tue, Jun 24, 2003 at 09:21:00AM -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jun 24, 2003 at 09:21:00AM -0400, Joel N. Weber II wrote: > The secsh transport draft suggests that there can be different kinds > of host key algorithms, and that some key exchange operations may > support different host key algorithms than others. > > The idea that GSS mechanisms don't have host keys strikes me as > confused. As far as I can tell, if I have a Kerberos 5 principal > named host/foo.example.com@EXAMPLE.COM and I store that encryption key > in /etc/krb5.keytab on the host foo.example.com, it is very much the > case that that krb5.keytab is a form of a host key. As far as I know, > all GSS mechanisms that anyone cares about for use with ssh do support > host keys, albeit abstracted away to the point where ssh protocol > designers and implementers don't directly deal with them. You're confused. When using the GSS-API for SSHv2 key-exchange what you don't need is "SSHv2 host keys" - you know, RSA and DSA host keys, the keys that go into the known_hosts public keys file. > On furthur thought, I don't really understand why gss-group1-sha1-* > has to be defined as gss-group1-sha1-*. Wouldn't it have been cleaner > to define it as gss-group1-sha1 and then put information on which gss > mechanism is being used in the host key algorithm field? No, it wouldn't because a client and server might first both agree that they can use the GSS-API and then realize that they have no mechanisms in common, by which time the key exchange has to fail because the SSHv2 keyex phase cannot be re-tried in one connection. By putting the mechanism name into the keyex method name the client and server can fully negotiate between all the keyx methods, including GSS-API mechanism available. > It may well be too late to change now for gss-group1-sha1 (on the > other hand, sxw's patches seem to have survived a change in the > OID->string conversion), but if gss-group-exchange-sha1 gets defined, > I hope it will use the host key field to specify which GSS mechanism > to use. Why would you want to make such a change? What would you gain? Simon Wilkinson's patches for OpenSSH are not the only implementation of draft-ietf-secsh-gsskeyex-06, so changing the spec now sure would hurt, and there'd be nothing to gain from what you suggest. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 24 10:49:57 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18974 for ; Tue, 24 Jun 2003 10:49:56 -0400 (EDT) Received: (qmail 3092 invoked by uid 605); 24 Jun 2003 14:49:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3082 invoked from network); 24 Jun 2003 14:49:52 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 24 Jun 2003 14:49:52 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5OElxKo015130; Tue, 24 Jun 2003 07:47:59 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5OElwuP025364; Tue, 24 Jun 2003 08:47:58 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h5OEj2Qx009723; Tue, 24 Jun 2003 07:45:02 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h5OEj10Z009722; Tue, 24 Jun 2003 07:45:01 -0700 (PDT) Date: Tue, 24 Jun 2003 07:45:01 -0700 From: Nicolas Williams To: Internet-Drafts@ietf.org Cc: IETF-Announce: ;, ietf-ssh@netbsd.org Subject: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt Message-ID: <20030624074458.A9718@binky.central.sun.com> References: <200306241056.GAA10873@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200306241056.GAA10873@ietf.org>; from Internet-Drafts@ietf.org on Tue, Jun 24, 2003 at 06:56:30AM -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list draft-ietf-secsh-gsskeyex-06 allows for hosts to give clients their host keys in a secure manner, which makes it possible for subsequent re-keys to work even when the client's GSS-API credentials are expired. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 24 13:09:07 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24511 for ; Tue, 24 Jun 2003 13:09:06 -0400 (EDT) Received: (qmail 17952 invoked by uid 605); 24 Jun 2003 16:56:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17927 invoked from network); 24 Jun 2003 16:56:20 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 24 Jun 2003 16:56:20 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5OGuH1J001469; Tue, 24 Jun 2003 10:56:17 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5OGuHuP026418; Tue, 24 Jun 2003 10:56:17 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h5OGrJQx009853; Tue, 24 Jun 2003 09:53:20 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h5OGrJgr009852; Tue, 24 Jun 2003 11:53:19 -0500 (CDT) Date: Tue, 24 Jun 2003 11:53:19 -0500 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@netbsd.org Subject: Re: gssapi host key algorithm usage Message-ID: <20030624115319.N6921@binky.central.sun.com> References: <20030624074252.A9703@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030624074252.A9703@binky.central.sun.com>; from Nicolas.Williams@sun.com on Tue, Jun 24, 2003 at 07:42:56AM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jun 24, 2003 at 07:42:56AM -0700, Nicolas Williams wrote: > On Tue, Jun 24, 2003 at 09:21:00AM -0400, Joel N. Weber II wrote: > > On furthur thought, I don't really understand why gss-group1-sha1-* > > has to be defined as gss-group1-sha1-*. Wouldn't it have been cleaner > > to define it as gss-group1-sha1 and then put information on which gss > > mechanism is being used in the host key algorithm field? > > No, it wouldn't because a client and server might first both agree that > they can use the GSS-API and then realize that they have no mechanisms > in common, by which time the key exchange has to fail because the SSHv2 > keyex phase cannot be re-tried in one connection. By putting the > mechanism name into the keyex method name the client and server can > fully negotiate between all the keyx methods, including GSS-API > mechanism available. Also, I happen to find the way GSS-API mechanism negotiation for keyex is specified in draft-ietf-secsh-gsskeyex is quite elegant. It is simple (simpler than SPNEGO, for example), it fits right into the SSHv2 keyex model and it is secure (because of the way the session ID is derived as a hash of data that includes the KEXINIT messages) without suffering from the unfortunate problems that have arisen with SPNEGO[1]. There really is no alternative if you wish for clients and servers with non-overlapping supported GSS-API mechanisms[2] to be able to successfully complete key exchanges without user input; the only alternative would have been to have the basic SSHv2 keyex protocol modified so that keyex could be re-tried without having to restart the connection. [1] Long story. Suffice it to say that it is not currently possible to implement SPNEGO correctly and also interoperate with deployed implementations without also fixing the deployed SPNEGO implementations. [2] And note that what matters is not so much what GSS-API mechs are supported by the client and server implementations as which ones they have initiator and acceptor credentials for, respectively. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 24 16:10:27 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08041 for ; Tue, 24 Jun 2003 16:10:26 -0400 (EDT) Received: (qmail 5005 invoked by uid 605); 24 Jun 2003 20:10:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4840 invoked from network); 24 Jun 2003 20:10:12 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 24 Jun 2003 20:10:12 -0000 Received: by xanthine.gratuitous.org with local; Tue, 24 Jun 2003 16:10:11 -0400 From: "Joel N. Weber II" To: Nicolas Williams cc: ietf-ssh@netbsd.org In-reply-to: <20030624074252.A9703@binky.central.sun.com> (message from Nicolas Williams on Tue, 24 Jun 2003 07:42:56 -0700) Subject: Re: gssapi host key algorithm usage References: <20030624074252.A9703@binky.central.sun.com> Message-Id: Date: Tue, 24 Jun 2003 16:10:11 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list > On Tue, Jun 24, 2003 at 09:21:00AM -0400, Joel N. Weber II wrote: > > The secsh transport draft suggests that there can be different kinds > > of host key algorithms, and that some key exchange operations may > > support different host key algorithms than others. > > > > The idea that GSS mechanisms don't have host keys strikes me as > > confused. As far as I can tell, if I have a Kerberos 5 principal > > named host/foo.example.com@EXAMPLE.COM and I store that encryption key > > in /etc/krb5.keytab on the host foo.example.com, it is very much the > > case that that krb5.keytab is a form of a host key. As far as I know, > > all GSS mechanisms that anyone cares about for use with ssh do support > > host keys, albeit abstracted away to the point where ssh protocol > > designers and implementers don't directly deal with them. > > You're confused. When using the GSS-API for SSHv2 key-exchange what you > don't need is "SSHv2 host keys" - you know, RSA and DSA host keys, the > keys that go into the known_hosts public keys file. The implementation of pgp-sign-{dss,rsa} that I wrote uses things that I guess you are calling ``SSHv2 host keys'' which don't go into the known_hosts file. It certainly uses the same key exchange algorithms that ssh-rsa uses. (Of course, it should make a known_hosts file entry, so that a MitM who offers a bare ssh-rsa or ssh-dss key doesn't cause prompting about a brand new host with an unknown key, but sxw's GSS patches have the same problem.) > > On furthur thought, I don't really understand why gss-group1-sha1-* > > has to be defined as gss-group1-sha1-*. Wouldn't it have been cleaner > > to define it as gss-group1-sha1 and then put information on which gss > > mechanism is being used in the host key algorithm field? > > No, it wouldn't because a client and server might first both agree that > they can use the GSS-API and then realize that they have no mechanisms > in common, by which time the key exchange has to fail because the SSHv2 > keyex phase cannot be re-tried in one connection. By putting the > mechanism name into the keyex method name the client and server can > fully negotiate between all the keyx methods, including GSS-API > mechanism available. I think you're confused. Consider this part of the transport draft: Choose the first algorithm that satisfies the following conditions: + the server also supports the algorithm, + if the algorithm requires an encryption-capable host key, there is an encryption-capable algorithm on the server's server_host_key_algorithms that is also supported by the client, and + if the algorithm requires a signature-capable host key, there is a signature-capable algorithm on the server's server_host_key_algorithms that is also supported by the client. + If no algorithm satisfying all these conditions can be found, the connection fails, and both sides MUST disconnect. It's clearly the case that you ignore a key exchange algorithm and pick the next one if the subnegotiation on the host key finds that there's no compatible key. So if GSS defined one keyex method and used the host key type to specify which GSS mechanism to use, the problem you describe doesn't really exist, near as I can tell. But I've realized another potential problem: there is no way to specify that your first preference is to use a pgp-sign-{dss,rsa} key, your second preference is a GSSAPI method, and your third perference is ssh-{dss,rsa}. A cleaner algorithm would be: Choose the first host key type on the client's list that is also on the server's list. Choose the first host key algorithm on the client's list that's also on the server's list that supports the host key type choosen. (Actually, this will work regardless of which field you use to encode which GSS mechanism you're using, but if you want it all in the key exchange field you'd have to define gssapi as a host key type, and then you'd lose the ability to mix non-GSS methods in between the GSS methods in the priority list.) The ssh v2.1 protocol could be defined to negotiate in this new fashion if both client and server claimed to have a version of at least 2.1, otherwise using the old method. And maybe we could define a 1.991 protocol version value for those people who want to support v2.1, v2, and v1, or something. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 24 16:29:35 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09629 for ; Tue, 24 Jun 2003 16:29:34 -0400 (EDT) Received: (qmail 12686 invoked by uid 605); 24 Jun 2003 20:29:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12679 invoked from network); 24 Jun 2003 20:29:32 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 24 Jun 2003 20:29:32 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5OKTTfU008341; Tue, 24 Jun 2003 13:29:30 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5OKTTuP007466; Tue, 24 Jun 2003 14:29:29 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h5OKQXQx010657; Tue, 24 Jun 2003 13:26:33 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h5OKQXcV010656; Tue, 24 Jun 2003 13:26:33 -0700 (PDT) Date: Tue, 24 Jun 2003 13:26:33 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@netbsd.org Subject: Re: gssapi host key algorithm usage Message-ID: <20030624132632.F3522@binky.central.sun.com> References: <20030624074252.A9703@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ietf-secsh@joelweber.com on Tue, Jun 24, 2003 at 04:10:11PM -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jun 24, 2003 at 04:10:11PM -0400, Joel N. Weber II wrote: > > On Tue, Jun 24, 2003 at 09:21:00AM -0400, Joel N. Weber II wrote: > > > > No, it wouldn't because a client and server might first both agree that > > they can use the GSS-API and then realize that they have no mechanisms > > in common, by which time the key exchange has to fail because the SSHv2 > > keyex phase cannot be re-tried in one connection. By putting the > > mechanism name into the keyex method name the client and server can > > fully negotiate between all the keyx methods, including GSS-API > > mechanism available. > > I think you're confused. Consider this part of the transport draft: > > Choose the first algorithm that satisfies the following > conditions: > + the server also supports the algorithm, > + if the algorithm requires an encryption-capable host key, > there is an encryption-capable algorithm on the server's > server_host_key_algorithms that is also supported by the > client, and > + if the algorithm requires a signature-capable host key, > there is a signature-capable algorithm on the server's > server_host_key_algorithms that is also supported by the > client. > + If no algorithm satisfying all these conditions can be > found, the connection fails, and both sides MUST disconnect. > > It's clearly the case that you ignore a key exchange algorithm and > pick the next one if the subnegotiation on the host key finds that > there's no compatible key. So if GSS defined one keyex method and > used the host key type to specify which GSS mechanism to use, the > problem you describe doesn't really exist, near as I can tell. I don't see how this could be called more elegant, or even as elegant as the current draft. And it's clear that it is much, much too late to change the draft should we all agree that this is approach is better. > But I've realized another potential problem: there is no way to > specify that your first preference is to use a pgp-sign-{dss,rsa} key, > your second preference is a GSSAPI method, and your third perference > is ssh-{dss,rsa}. > > A cleaner algorithm would be: > > Choose the first host key type on the client's list that is also on > the server's list. Choose the first host key algorithm on the > client's list that's also on the server's list that supports the host > key type choosen. (Actually, this will work regardless of which field > you use to encode which GSS mechanism you're using, but if you want it > all in the key exchange field you'd have to define gssapi as a host > key type, and then you'd lose the ability to mix non-GSS methods in > between the GSS methods in the priority list.) Why so complicated? The current approach to negotiating GSS-API mechanisms is simple, it works, it's elegant. And the GSS-API is not about "host key types" - it's about mechanisms. Why conflate the two? > The ssh v2.1 protocol could be defined to negotiate in this new > fashion if both client and server claimed to have a version of at > least 2.1, otherwise using the old method. And maybe we could define > a 1.991 protocol version value for those people who want to support > v2.1, v2, and v1, or something. Why bother? Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 24 17:07:02 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11287 for ; Tue, 24 Jun 2003 17:07:01 -0400 (EDT) Received: (qmail 791 invoked by uid 605); 24 Jun 2003 21:06:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 784 invoked from network); 24 Jun 2003 21:06:58 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 24 Jun 2003 21:06:58 -0000 Received: by xanthine.gratuitous.org with local; Tue, 24 Jun 2003 17:06:57 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: ietf-ssh@netbsd.org In-reply-to: <20030624074458.A9718@binky.central.sun.com> (message from Nicolas Williams on Tue, 24 Jun 2003 07:45:01 -0700) Subject: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt References: <200306241056.GAA10873@ietf.org> <20030624074458.A9718@binky.central.sun.com> Message-Id: Date: Tue, 24 Jun 2003 17:06:57 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list > draft-ietf-secsh-gsskeyex-06 allows for hosts to give clients their host > keys in a secure manner, which makes it possible for subsequent re-keys > to work even when the client's GSS-API credentials are expired. However, when you use a client that supports both GSS and pgp-sign-{rsa,dss} and a server that also supports both of these and has a pgp-sign-{rsa,dss} host key, the server will send the pgp-sign-{rsa,dss} host key, and it is possible that the client will decide that according to whatever trust model and trust values it happens to be using, the key isn't trusted, and cause the connection to fail. You could special case it to not consult the trust model when rekeying, I guess... From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 24 17:37:21 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12141 for ; Tue, 24 Jun 2003 17:37:20 -0400 (EDT) Received: (qmail 10291 invoked by uid 605); 24 Jun 2003 21:29:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10267 invoked from network); 24 Jun 2003 21:29:12 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 24 Jun 2003 21:29:12 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5OLTAvc005285; Tue, 24 Jun 2003 15:29:10 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5OLTAuP029771; Tue, 24 Jun 2003 15:29:10 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h5OLQEQx010742; Tue, 24 Jun 2003 14:26:14 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h5OLQDWa010741; Tue, 24 Jun 2003 14:26:13 -0700 (PDT) Date: Tue, 24 Jun 2003 14:26:13 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@netbsd.org Subject: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt Message-ID: <20030624142613.J3522@binky.central.sun.com> References: <200306241056.GAA10873@ietf.org> <20030624074458.A9718@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ietf-secsh@joelweber.com on Tue, Jun 24, 2003 at 05:06:57PM -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list I have thought that the gss keyex spec should allow the server to send its public host keys (as opposed to one public host key). I think that would be the right thing to do and the right fix. I don't mind this none keyex too much though and it may be the easiest way to resolve your problem. Cheers, Nico -- On Tue, Jun 24, 2003 at 05:06:57PM -0400, Joel N. Weber II wrote: > > draft-ietf-secsh-gsskeyex-06 allows for hosts to give clients their host > > keys in a secure manner, which makes it possible for subsequent re-keys > > to work even when the client's GSS-API credentials are expired. > > However, when you use a client that supports both GSS and > pgp-sign-{rsa,dss} and a server that also supports both of these and > has a pgp-sign-{rsa,dss} host key, the server will send the > pgp-sign-{rsa,dss} host key, and it is possible that the client will > decide that according to whatever trust model and trust values it > happens to be using, the key isn't trusted, and cause the connection > to fail. You could special case it to not consult the trust model > when rekeying, I guess... > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 24 18:09:18 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13608 for ; Tue, 24 Jun 2003 18:09:18 -0400 (EDT) Received: (qmail 26418 invoked by uid 605); 24 Jun 2003 22:09:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26337 invoked from network); 24 Jun 2003 22:09:15 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 24 Jun 2003 22:09:15 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5OM96vc027708; Tue, 24 Jun 2003 16:09:06 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5OM95uP019446; Tue, 24 Jun 2003 16:09:05 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h5OM3KQx010807; Tue, 24 Jun 2003 15:03:20 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h5OM3Jv9010806; Tue, 24 Jun 2003 17:03:19 -0500 (CDT) Date: Tue, 24 Jun 2003 17:03:19 -0500 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@netbsd.org Subject: Re: gssapi host key algorithm usage Message-ID: <20030624170319.B10543@binky.central.sun.com> References: <20030624074252.A9703@binky.central.sun.com> <20030624132632.F3522@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030624132632.F3522@binky.central.sun.com>; from Nicolas.Williams@sun.com on Tue, Jun 24, 2003 at 01:26:32PM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Joel points out that one cannot specify a preference such as: - 1st, pubkey keyex with pgp-sign-{dss,rsa} keys - 2nd, gss keyex with some mechanism - 3rd, pubkey keyex with ssh-{dss,rsa} keys I think Joel's right. Joel's proposed solution, i.e., treating the GSS-API mechanisms as host key algorithms (which I find to be conceptually incorrect) would not work, I think. The KEXINIT packets probably should have, from the get go, negotiated {keyex method, } tuples, but it doesn't. One solution might be to add aliases of the pubkey keyex methods (e.g., diffie-hellman-group1-sha1) for use with PGP and other non-ssh-{dss,rsa} host key types. I think this would solve the problem. I'll think about it more when I have the time for it. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 24 22:43:44 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03718 for ; Tue, 24 Jun 2003 22:43:44 -0400 (EDT) Received: (qmail 21516 invoked by uid 605); 25 Jun 2003 00:14:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21509 invoked from network); 25 Jun 2003 00:14:49 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 25 Jun 2003 00:14:49 -0000 Received: by xanthine.gratuitous.org with local; Tue, 24 Jun 2003 20:14:47 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: ietf-ssh@netbsd.org In-reply-to: <20030624142613.J3522@binky.central.sun.com> (message from Nicolas Williams on Tue, 24 Jun 2003 14:26:13 -0700) Subject: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt References: <200306241056.GAA10873@ietf.org> <20030624074458.A9718@binky.central.sun.com> <20030624142613.J3522@binky.central.sun.com> Message-Id: Date: Tue, 24 Jun 2003 20:14:47 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list > I have thought that the gss keyex spec should allow the server to send > its public host keys (as opposed to one public host key). Do you have a reasonable way to implement this that doesn't break interoperability? Are there implementations in the wild that send the host's public key? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jun 25 11:20:23 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14973 for ; Wed, 25 Jun 2003 11:20:22 -0400 (EDT) Received: (qmail 25837 invoked by uid 605); 25 Jun 2003 15:13:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25830 invoked from network); 25 Jun 2003 15:13:03 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 25 Jun 2003 15:13:03 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5PFCi1J006597; Wed, 25 Jun 2003 09:12:44 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PFChNg005528; Wed, 25 Jun 2003 09:12:43 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h5PF9lQx011089; Wed, 25 Jun 2003 08:09:47 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h5PF9kHD011088; Wed, 25 Jun 2003 08:09:46 -0700 (PDT) Date: Wed, 25 Jun 2003 08:09:46 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@netbsd.org Subject: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt Message-ID: <20030625080941.A11084@binky.central.sun.com> References: <200306241056.GAA10873@ietf.org> <20030624074458.A9718@binky.central.sun.com> <20030624142613.J3522@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ietf-secsh@joelweber.com on Tue, Jun 24, 2003 at 08:14:47PM -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jun 24, 2003 at 08:14:47PM -0400, Joel N. Weber II wrote: > > I have thought that the gss keyex spec should allow the server to send > > its public host keys (as opposed to one public host key). > > Do you have a reasonable way to implement this that doesn't break > interoperability? Are there implementations in the wild that send > the host's public key? No, and I don't know. Anyone else? Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jun 26 11:52:43 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05276 for ; Thu, 26 Jun 2003 11:52:27 -0400 (EDT) Received: (qmail 11319 invoked by uid 605); 26 Jun 2003 15:51:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11309 invoked from network); 26 Jun 2003 15:51:53 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 26 Jun 2003 15:51:53 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5QFpi1J004650; Thu, 26 Jun 2003 09:51:44 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5QFpiNg002328; Thu, 26 Jun 2003 09:51:44 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h5QFmlQx012013; Thu, 26 Jun 2003 08:48:47 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h5QFmktO012012; Thu, 26 Jun 2003 08:48:46 -0700 (PDT) Date: Thu, 26 Jun 2003 08:48:46 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@netbsd.org Subject: Re: gssapi host key algorithm usage Message-ID: <20030626084843.A11987@binky.central.sun.com> References: <20030624074252.A9703@binky.central.sun.com> <20030624132632.F3522@binky.central.sun.com> <20030624170319.B10543@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030624170319.B10543@binky.central.sun.com>; from Nicolas.Williams@sun.com on Tue, Jun 24, 2003 at 05:03:19PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Joel, I've thought more about it and I see but one easy way to get the ability to specify preferences such as: - 1st, pubkey keyex with pgp-sign-{dss,rsa} keys - 2nd, gss keyex with some mechanism - 3rd, pubkey keyex with ssh-{dss,rsa} keys without breaking existing deployed systems. That would be to add aliases of the "pubkey" keyex methods ("diffie-hellman-group1-sha1" and "diffie-hellman-group-exchange-sha1") which are understood to be usable only with a subset of the host key algorithms normally usable with those kex methods. Thus the preferences in the above scenario could be expressed as follows: - kex methods: diffie-hellman-group1-sha1-pgp,gss-group1-sha1-XYZ,diffie-hellman-group1-sha1 - host key algorithms: pgp-sign-rsa,pgp-sign-dss,ssh-dss,ssh-rsa [The nice thing about these kex method aliases is that their use would not break existing implementations.] Treating the GSS-API mechanisms as host key algorithms wouldn't solve the problem because of the way that the key exchange method is to be picked as per draft-ietf-secsh-transport-15. That is, something like this in the client's KEXINIT: - kex methods: diffie-hellman-group1-sha1,gss-group1-sha1 - host key algorithms: pgp-sign-rsa,pgp-sign-dss,gss-api-XYZ,ssh-dss,ssh-rsa would lead to the selection of diffie-hellman-group1-sha1 whenever the server offers it and any of the pgp-sign-*,ssh-* host key algorithms. The kex method selection algorithm could be specified in such a way that draft-ietf-secsh-gsskeyex could have treated GSS-API mechanisms as host key algorithms and so that the second example above would have worked. But it wasn't. What's clear to me is that this issue was not caused by the introduction of draft-ietf-secsh-gsskeyex - it was there all along and all that had to happen for it to annoy someone was for some kex method to be introduced with a host key algorithm set disjoint with respect to the original kex method's. In fact, even without GSS-API in the picture there are preferences that you can't specify (though no one would want to specify such preferences), such as: - 1st, diffie-hellman-group-exchange-sha1 keyex with pgp-sign-{dss,rsa} keys - 3rd, diffie-hellman-group1-sha1 keyex with ssh-{dss,rsa} keys - 2nd, diffie-hellman-group-exchange-sha1 keyex with ssh-{dss,rsa} keys No amount of tinkering with draft-ietf-secsh-gsskeyex will fix the underlying problem because the underlying problem is in draft-ietf-secsh-transport. Cheers, Nico From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jun 26 13:06:27 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09514 for ; Thu, 26 Jun 2003 13:06:27 -0400 (EDT) Received: (qmail 25673 invoked by uid 605); 26 Jun 2003 17:06:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25666 invoked from network); 26 Jun 2003 17:06:24 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 26 Jun 2003 17:06:24 -0000 Received: by xanthine.gratuitous.org with local; Thu, 26 Jun 2003 13:06:23 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: ietf-ssh@netbsd.org In-reply-to: <20030625080941.A11084@binky.central.sun.com> (message from Nicolas Williams on Wed, 25 Jun 2003 08:09:46 -0700) Subject: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt References: <200306241056.GAA10873@ietf.org> <20030624074458.A9718@binky.central.sun.com> <20030624142613.J3522@binky.central.sun.com> <20030625080941.A11084@binky.central.sun.com> Message-Id: Date: Thu, 26 Jun 2003 13:06:23 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jun 24, 2003 at 08:14:47PM -0400, Joel N. Weber II wrote: > > I have thought that the gss keyex spec should allow the server to send > > its public host keys (as opposed to one public host key). > > Do you have a reasonable way to implement this that doesn't break > interoperability? Are there implementations in the wild that send > the host's public key? No, and I don't know. Anyone else? I think in the long run it would be useful for KEX_MSG_KEXINIT to support negotiating additional features by adding more strings to the end, with each string having a tag indicating the name of the feature that string is negotiating. This would allow you to provide an alternate list of host key algorithms and key exchange algorithms that would use a new negotiation algorithm, for example, as well as negotiating the format of SSH_MSG_KEXGSS_HOSTKEY as to whether it contains multiple host keys. (I'm not convinced we should have that multiple host key support, but if the protocol doesn't allow it to be negotiated in an interoperable fashion when someone wants to add the feature late in the game, it's somewhat poorly designed.) Alternatively, there could be a seprate field for negotiating which host key algorithm to use for the key sent with SSH_MSG_KEXGSS_HOSTKEY. The last field of KEX_MSG_KEXINIT is uint32 0 (reserved for future extension) with no real explaination of how this should be used, as far as I can tell. It looks to me like openssh-3.6.1p2 prints the reserved value with a call to debug2 and otherwise ignores it, and will probably ignore anything that appears after that field. I have no idea what other implementations will do if there's extra data after that reserved value. I bet if just adding strings at the end of KEX_MSG_KEXINIT would cause real or potential problems, defining KEX_MSG_KEXINIT2 for additional strings when both the client and server send 1 as the reserved value would be likely to allow this to be extended without breaking interoperability, and would be a far better idea than changing the protocol version to 2.1. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jun 26 17:33:53 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22913 for ; Thu, 26 Jun 2003 17:33:52 -0400 (EDT) Received: (qmail 22240 invoked by uid 605); 26 Jun 2003 21:30:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22232 invoked from network); 26 Jun 2003 21:30:47 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 26 Jun 2003 21:30:47 -0000 Received: by xanthine.gratuitous.org with local; Thu, 26 Jun 2003 17:30:46 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: ietf-ssh@netbsd.org In-reply-to: <20030625080941.A11084@binky.central.sun.com> (message from Nicolas Williams on Wed, 25 Jun 2003 08:09:46 -0700) Subject: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt References: <200306241056.GAA10873@ietf.org> <20030624074458.A9718@binky.central.sun.com> <20030624142613.J3522@binky.central.sun.com> <20030625080941.A11084@binky.central.sun.com> Message-Id: Date: Thu, 26 Jun 2003 17:30:46 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list Thinking about this some more, SSH_MSG_KEXGSS_HOSTKEY feels like the wrong place to solve the problem that it solves if it is even a problem worth solving at all. X.509 certificates can expire, OpenPGP signatures and subkeys can expire, and OpenPGP trust values can be changed. If ``none'' as a public key algorithm is not an acceptable solution, we should find a solution that also works for X.509 and OpenPGP. In general, if you are not using ssh-rsa or ssh-dss as your host key, you probably want a way to do rekeying using either an ssh-rsa or ssh-dss key, or no host key. I don't think I see any reason why we couldn't define a SSH_MSG_KEX_HOSTKEY which would send a host key along with which algorithm it uses. In particular, the transport draft says: An implementation MUST respond to all unrecognized messages with an SSH_MSG_UNIMPLEMENTED message in the order in which the messages were received. Such messages MUST be otherwise ignored. Later protocol versions may define other meanings for these message types. It also appears that we could define SSH_MSG_KEXINIT2 and assume that SSH_MSG_UNIMPLEMENTED will be sent if the client or server on the other end doesn't recognize that message. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Jun 28 12:57:15 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27525 for ; Sat, 28 Jun 2003 12:56:59 -0400 (EDT) Received: (qmail 4098 invoked by uid 605); 28 Jun 2003 16:55:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4086 invoked from network); 28 Jun 2003 16:55:57 -0000 Received: from unknown (HELO scanmail1.nyc.untd.com) (64.136.20.160) by mail.netbsd.org with SMTP; 28 Jun 2003 16:55:57 -0000 Received: (from daemon@localhost) by scanmail1.nyc.untd.com (8.8.6.Beta0/8.8.7/juno-1.2) id MAAAA23437; Sat, 28 Jun 2003 12:55:57 -0400 (EDT) Date: Sat, 28 Jun 2003 12:55:57 -0400 (EDT) Message-Id: <200306281655.MAAAA23437@scanmail1.nyc.untd.com> From: announcement@support.netzero.com To: ietf-ssh@netbsd.org Subject: Re: Re: Movie --> Ref #[1M2seBCeq865rmu] Sender: ietf-ssh-owner@netbsd.org Precedence: list Hello, Thank you contacting NetZero. Please be advised that this is an automated reply and no further response will be sent. The NetZero Customer Support team is here to provide fast, easy and reliable ways for you to get answers to your questions regarding your NetZero service. If you have an issue to resolve, we offer several convenient support methods that allow you to get answers anytime, anywhere. From Web to Quick Help (our offline assistance tool) and e-mail to telephone support, choose the option that works best for you! Web site Support ---------------- NetZero Help Center: Visit our online technical support customer care knowledge base at the following link - http://www.netzero.com/support My Account Section: If you are a NetZero Platinum member, you can find answers to most of your Customer Service or Billing questions. You will also be able to view your billing history, change your credit card information, and check your service level any time of the day. Visit http://account.netzero.com Automated E-mail Support ------------------------ Get automated replies in five minutes or less! Send a blank e-mail to instantanswers@support.netzero.com Access Number Information ------------------------- For a complete list of access numbers visit http://my.netzero.com/s/numbers Password Information -------------------- If you have forgotten your password you can always reset it at the following link - http://my.netzero.com/s/resetpassword Offline assistance: ------------------- Download NetZero Quick Help today! Regardless of whether you are connected to the Internet, NetZero Quick Help, an offline help wizard, can guide you through the most common issues, step by step. Visit http://www.netzero.com/support/quickhelp/index.html to download this tool. Live E-mail Assistance ---------------------- For personal e-mail assistance from our technical support team, fill out a support request at the following link - www.netzero.com/support/pat/ Note: This service is only available for Platinum members. Automated Telephone Support --------------------------- Call our automated support hotline at 1-800-586-6889 for answers to many common questions about using NetZero. Note: This service requires a touch-tone telephone. Telephone Technical Support --------------------------- If you prefer to speak to someone over the phone, you can get one-on-one, personal assistance by speaking to a NetZero Technical Support professional, 24 hours a day, seven days a week. In the U.S.,call 877-912-5866. If you are in Canada, please visit the following link: http://www.netzero.com/support/canadian-phone.html Note: A per-minute rate of $1.95 will apply. You must provide a valid credit card at the time of your call and all fees incurred will be charged to the card provided. You must be at least 18 years old or have a parent or guardian's permission to call. Report Spam ----------- To report spam, harassing, or otherwise offensive e-mail from a NetZero member, forward the message(s), including full headers, to spamdesk@support.netzero.com Other security & abuse related queries -------------------------------------- Send an e-mail to abuse@netzero.com, with a brief description of your query or problem.