Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Build It In, Dont Trowel It On


SD SECURE START :: February 2006

In this Issue:

  • Build It In, Don't Trowel It On
  • SSH Kerberos Authentication Using GSSAPI and SSPI
  • Hot Link


    >> Build It In, Don't Trowel It On

    I do tend to go on a bit about security. But it's only because the state of the art, as we developers practice it, is pretty pathetic. Crackers are still exploiting buffer overflows, for heaven's sake, world-famous since the Morris Worm trashed the Internet in 1998. How embarrassing is that?

    Gary McGraw has been striving mightily to save us from ourselves, with books like Building Secure Software and Exploiting Software: How To Break Code. These examined the nitty-gritty of code from the white-hat and black-hat points of view. Now, with Software Security: Building Security In (Addison-Wesley, 2005), McGraw takes a step back and looks at the development process itself. Security is too important to be left to today's operations-oriented security specialists, says McGraw, and I have to agree. You can install all the firewalls, intrusion detection and virus scanners you want, but at the end of the day, if exploitable software still makes up most of the system, it's going to be the same old story: Crunchy outside, chewy center.

    McGraw elucidates three "pillars of software security: Applied risk management, knowledge and a set of best practices he calls software security touch points: Code review, architectural risk analysis, penetration testing, risk-based security testing, abuse cases, security requirements, and security operations. As he points out, if it's cheaper to fix bugs found early in the development cycle, what price security vulnerabilities? Overall, Software Security is a detailed look at how to adapt your development process to reduce vulnerability risks, written in an approachable style that helps keep you reading about these hard problems. Software Security: Building Security In lists for $49.99, including a CD-ROM with a demo version of the Fortify source-code security analysis tool.

    —By Rick Wayne


    >>SSH Kerberos Authentication Using GSSAPI and SSPI

    Given the growing need for secure and private data transfer, the Secure Shell protocol (SSH) offers a robust and flexible solution to the problem of protecting your communications. A major component of such a solution involves authentication of the client and in the best of all worlds, the server. Part of the flexibility of SSH is that it supports a variety of authentication methods. Of particular interest for large enterprises is authentication using the Kerberos protocol, not only because of the single sign-on capability, but also because it has a potential to preclude classic man-in-the-middle attacks on the SSH protocol. Because Kerberos is the primary authentication mechanism for Windows (postWindows 2000) and because it is supported on all UNIX-like platforms, Kerberos provides these capabilities today.

    SSH is a complicated protocol—the Secure Shell IETF Working Group web page lists 16 Internet drafts (and as of this writing, no RFCs). The result of this complexity is a rich set of capabilities. In what follows, I describe how Kerberos authentication can be done using both the standard GSSAPI (Generic Security Services Application Programming Interface) and Microsoft's SSPI (Security Support Provider Interface).

    To run the SSH protocol, you do the following:

    (a) Negotiate encryption. (b) Authenticate the user. (c) Open and use channels.

    Steps (a) and (b) result in an encrypted and authenticated tunnel, which is a container for the communications. Step (c) — repeated within the tunnel as many times as desired, results in a channel. Channels run within an encrypted tunnel and carry the traffic that would normally be carried on a standard TCP/IP socket. I won't go into communications over channels because the focus of this article is really on step (b)— the authentication of the user of the tunnel.

    The SSH Protocol: A Bird's Eye View
    SSH provides an encrypted and authenticated communications tunnel between a client and server, usually on different machines. Within this tunnel, any number of virtual links called "channels" can be created. Although the initial purpose was to provide remote secure shells, other types of channels can be opened, including X11 channels, file transfer channels, and socket forwarding channels (port forwarding-both inbound and outbound).

    To support all of this, SSH uses a packetized binary protocol on the wire. The basic structure of an encrypted SSH packet consists of a short header, followed by the message type, followed by the payload, and finally followed by some Message Authentication Code (MAC) bytes. The payload encapsulates the traffic of the protocols previously mentioned, similar to how IP encapsulates other protocols. Of course, SSH packets themselves are usually encapsulated within TCP/IP packets.

    As part of negotiating the tunnel encryption keys between client and server, the server's public key is exchanged with the client. This key (and the associated private key) enables public key cryptography such as digital signatures to be performed between the two parties. At this point, the SSH protocol is most vulnerable. If an attacker is positioned in between the client and the server, the attacker can pose as the server to the client using some bogus key, and the client machine might not be able to tell the difference; the attacker would simply relay messages between the server and the client, pretending to each side to be the other. In a sense, the attacker would be acting as a malicious proxy. This is the classic man-in-the-middle attack.

    In order to continue, you must determine if the server's private key is correct. If the client machine has the key available through some mechanism (possibly a previous connection), then it can be compared and the authenticity of the server can be determined. If not, you are customarily asked to decide whether to accept the key or not. Unfortunately, you have little upon which to base such a decision for first-time connections, and so you customarily reply "yes."

    The reason for this weakness is that when the SSH protocol was first described, public-key infrastructures were poorly deployed. Although this was a logical place to embed some means of server authentication, there was nothing practical available. I'll come back to this point shortly.

    Once the server key has been negotiated, user authentication is then negotiated and carried out. In the case of a password authentication (for example), the client would send a login ID and password within an authentication packet, and the server would respond with either success or failure.

    This is a logical place to do authentication using Kerberos. "GSSAPI Authentication and Key Exchange for the Secure Shell Protocol" is an Internet draft Request for Comments (RFC) describing an authentication mechanism using Kerberos based on the GSSAPI. Using the same SSH protocol packets, Microsoft's SSPI can be called because one of the (several) security packages that it supports is Kerberos.

    A very interesting option described in this draft RFC is that of authenticated Diffie-Hellman key exchange. This mechanism performs a Kerberos-authenticated key exchange at the step above where the server key would be negotiated. The client first authenticates itself to the server via Kerberos. If mutual authentication (an option) is selected, then the server authenticates itself to the client (note that this is more than simply comparing keys). This allows a first-time connection to a new server to be completely safe from the man-in-the-middle because only the server can satisfactorily authenticate itself to the client via Kerberos. An interesting side effect is that the actual user authentication then becomes a formality because the user has already been authenticated in the key exchange step.

    Kerberos Authentication: Another Bird's Eye View In order to understand how the man-in-the-middle attack is defeated with mutual authentication, I need to review how Kerberos authentication is carried out. Kerberos deals with binary objects called "tickets"-and the name is suggestive of the role that they play.

    As a client, you need to acquire a ticket-granting ticket (TGT) initially by authenticating yourself to the Kerberos KDC (Key Distribution Center) using a KRB_AS_REQ (Kerberos Authentication Service Request) message. (Note that the KDC holds all of the user and server private keys in order to encrypt tickets using these keys.) Later, during the acquisition of service tickets, the TGT proves to the KDC that you have authenticated yourself when it is presented. A service ticket is like a letter of introduction in that it automatically authenticates you to the network service for which it was acquired, without needing to provide other credentials. Most importantly, the software that you are using (such as SSH) can acquire these subsequent service tickets automatically on your behalf, assuming that you have a previously acquired TGT.

    The reply back from the KDC contains a generated session key, as well as a separate message (the TGT) containing this key, and your authorization data, encrypted with the KDC's master key. Only the KDC can decrypt the TGT. The entire reply is encrypted with your private key, so that only your client software can decrypt this message. The client software on your machine stores your session key as well as the TGT into a local cache.

    To request a service ticket for some service, such as a login session for a remote host, you send a KRB_TGS_REQ (Kerberos Ticket Granting Service Request) message to the KDC. Included in that message is the TGT that you have obtained. The KDC's encrypted reply contains your service session key (the key that you will use to encrypt messages between you and the service) and a ticket for sessions with that service encrypted with its private key. The service key and ticket are also cached locally.

    To establish your session with the login service, you now send a KRB_AP_REQ (Kerberos Application Request) message. This contains your service ticket, an authenticator containing a timestamp that is encrypted with the service session key, and a flag indicating whether mutual authentication is desired. When the login service receives this message, it decrypts the service ticket-only it can do this. It then decrypts the authenticator (which can only be done if it can decrypt the service ticket!) and checks the authentication data and timestamp to authenticate you (or not). If the mutual authentication flag is set, it encrypts the timestamp from your authenticator message using the service session key and sends this back in a KRB_AP_REP (Kerberos Application Reply) message. Finally, when you receive this message, your client software decrypts this, and if the timestamp is the one you originally sent, then the server has authenticated itself to you: Mutual authentication is then complete.

    This cleverly defeats the man-in-the-middle attack because the information used for mutual authentication is encrypted using the session key, known only to the client and server. Of course, if the attacker has obtained this key by breaking into the KDC and monitoring your network traffic, then all bets are off-and you'll likely have larger problems!

    By now it should be clear that Kerberos authentication is a very desirable feature.

    —By Glen Matthews who is a developer at a well-known Canadian software company, where he has been occupied with implementing a commercial version of SSH. He can be reached at [email protected].

    This is an excerpt from an article previously printed in C/C++ Users Journal, December 2005


    >>HOT LINK

    IETF Secure Shell Working Group
    http://www.ietf.org/html.charters/secsh-charter.html
    Contains references to all Secure Shell Internet Draft documents.


  • Related Reading


    More Insights






    Currently we allow the following HTML tags in comments:

    Single tags

    These tags can be used alone and don't need an ending tag.

    <br> Defines a single line break

    <hr> Defines a horizontal line

    Matching tags

    These require an ending tag - e.g. <i>italic text</i>

    <a> Defines an anchor

    <b> Defines bold text

    <big> Defines big text

    <blockquote> Defines a long quotation

    <caption> Defines a table caption

    <cite> Defines a citation

    <code> Defines computer code text

    <em> Defines emphasized text

    <fieldset> Defines a border around elements in a form

    <h1> This is heading 1

    <h2> This is heading 2

    <h3> This is heading 3

    <h4> This is heading 4

    <h5> This is heading 5

    <h6> This is heading 6

    <i> Defines italic text

    <p> Defines a paragraph

    <pre> Defines preformatted text

    <q> Defines a short quotation

    <samp> Defines sample computer code text

    <small> Defines small text

    <span> Defines a section in a document

    <s> Defines strikethrough text

    <strike> Defines strikethrough text

    <strong> Defines strong text

    <sub> Defines subscripted text

    <sup> Defines superscripted text

    <u> Defines underlined text

    Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

     
    Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.