IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Pulling it all together - New Section 11 on Security Considerations
Hi Nico,
I agree it's awkward. It was suppsed to be two "types" within the "first
case". For those that may not have yet gotten to that section, the first
case is an active mitm with the first type being on the first connection
attempt when the client has not previously seen the key of the host, and
the second type just noting the subversion of the distribution of the host
keys prior to the first connection attempt.
I'll rework it to make it clear and get that back out.
I appreciate the review.
Thanks,
Chris
On Wed, 28 May 2003, Nicolas Williams wrote:
> I like it. But I've one nit about the MITM section: it speaks of two
> MITM possibilities, describes a "first" case and *two* "second" cases!
>
> Cheers,
>
> Nico
>
>
> On Wed, May 21, 2003 at 12:36:49PM -0700, Chris Lonvick wrote:
> > Hi Folks,
> >
> > Below is the latest version of the Security Considerations section. This
> > reflects all of the discussions on the lists on the various parts of this
> > over the past few weeks. I appreciate all of the feedback and help.
> >
> > I've also put together an html document of the changes from the previous
> > version; red strike outs for deletions and green text for insertions.
> > I'll put it on a web server and send around a pointer rsn. [The server
> > isn't doing so well today but I think it will be fixed in the next day
> > or so.] If you'd like to see that sooner rather than later, please email
> > me directly and I'll send it to you.
> >
> > If you would like to suggest any changes, please call out the relevent
> > section in the Subject line of your email. Also, please remove the
> > non-related sections from your reply as this thing is getting a bit long.
> >
> > Thanks,
> > Chris
> >
> > ==========================================================================
> >
> >
> > 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
> > Information Processing Standards [FIPS-197] and the cryptographic
> > community as being acceptable for this purpose as well. As always,
> > 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
> > 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) 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.
> >
> >
> > 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
> >
> >
> >
> >
> >
>
Home |
Main Index |
Thread Index |
Old Index