15.6 Extended Security: That Light at the End of the Tunnel

15.6 Extended Security: That Light at the End of the Tunnel

Our discussion of SMB authentication mechanisms is winding down now. There are a few more topics to be covered and a few others that will be carefully , but purposefully, avoided. Extended Security falls somewhere in between. We will dip our toes into its troubled waters, but we won't wade in too deep (or the monsters might get us).

One reason for trepidation is that as of this writing Extended Security is still an area of active research and development for the Samba Team and others. Though much has been learned, and much has been implemented, the dark pools are still being explored and the fine points are still being examined. Another deterrent is that Extended Security represents a full set of sub-protocols a whole, vast world of possibilities to be explored... some other day. As with MS-RPC (which we touched on just long enough to get our fingers burned), the topic is simply too large to cover here.

As suggested in Figure 15.4, Extended Security makes use of nested protocols. Go back to Section 13.3.2 on page 235 and take a look at the NEGOTIATE_PROTOCOL_RESPONSE.SMB_DATA structure. Note that the ext_sec.SecurityBlob field is nothing more than a block of bytes and it's what's inside that block that matters. If the client and server agree to use Extended Security, then the whole NEGOTIATE PROTOCOL RESPONSE / SESSION SETUP REQUEST business becomes a transport for the authentication protocol.

Figure 15.4. Protocols nested like Russian dolls

CIFS sub-protocols may be nested several layers deep. Extended Security, for example, is carried within SMB within NBT within TCP within IP.

In some cases the security exchange may require several packets and a few round trips to complete. When that happens, a single NEGOTIATE PROTOCOL RESPONSE / SESSION SETUP REQUEST pair will not be sufficient to handle it all. The solution to this dilemma is fairly simple: The server sends an error message to force the client to send another SESSION SETUP REQUEST containing the next chunk of data.

The process is briefly (and incompletely) described in Section 4.1.2 of the SNIA doc as part of the discussion of the SESSION SETUP RESPONSE . Simply put, as long as there are more Extended Security packets required, the server will reply to the SESSION SETUP REQUEST by sending a NEGATIVE SESSION SETUP RESPONSE with an NT_STATUS value of 0xC0000016 (which is known as STATUS_MORE_PROCESSING_REQUIRED ). The client then sends another SESSION SETUP REQUEST containing the additional data. This continues until the authentication protocol has completed.

There is no DOS error code equivalent for STATUS_MORE_PROCESSING_REQUIRED , something we have already whined about in the Strange Behavior Alert back in Section 12.1 on page 198. It seems that Extended Security expects that the client can handle NT_STATUS codes, which may be a significant issue for anyone trying to implement an SMB client. ^[18]

^[18] It might be worth doing some testing if you really want to use DOS codes in your implementation, but also want Extended Security. It may be possible to use the NT_STATUS codes for this exchange only, or you might try interpreting any unrecognized DOS error code as if it were STATUS_MORE_PROCESSING_REQUIRED .

15.6.1 The Extended Security Authentication Toolkit

There are several different authentication protocols which may be carried within the SecurityBlob . Those protocols, in turn , are built on top of a whole pile of different languages and APIs and data transfer formats. The result is an alphabet soup of acronyms. Here's a taste:

ASN.1: Abstract Syntax Notation One

ASN.1 is a language used to define the structure and content of objects such as data records and protocol messages. If you are not familiar with ASN.1, you might think of it as a super-duper-hyper version of the typedef in C only a lot more powerful. ASN.1 was developed as part of the Open Systems Interconnection (OSI) environment, and was originally used for writing specifications. More recently, though, tools have been developed that will generate software from ASN.1.

The development and promotion of the ASN.1 language is managed by the ASN.1 Consortium.

DER: Distinguished Encoding Rules of ASN.1

DER is a set of rules for encoding and decoding ASN.1 data. It provides a standard format for transport of data over a network so that the receiving end can convert the data back into its correct ASN.1 format. DER is a specialized form of a more general encoding known as BER ( B asic E ncoding R ules). DER is designed to work well with security protocols, and is used for encoding Kerberos and LDAP exchanges.

GSS-API: Generic Security Service Application Program Interface

As the name suggests, GSS-API is a generic interface to a set of security services. It makes it possible to write software that does not care what the underlying security mechanisms actually are. GSS-API is documented in RFC 2078.

Kerberos

("Kerberos" is a name, not an acronym.)

Kerberos is the preferred authentication system for SMB over naked TCP/IP transport. The use of Kerberos with CIFS is also tied in with GSS-API and SPNEGO.

LDAP: Lightweight Directory Access Protocol

Some folks at the University of Michigan realized that the DAP protocol (which was designed as part of the the Open Systems Interconnection (OSI) environment for use with the X.500 directory system) was just too big and hairy for general-purpose use, so they came up with a "lightweight" version, known as LDAP. LDAP was popularized in the mid-1990's, and support was included with directory service implementations such as Novell's NDS ( N ovell D irectory S ervice). When Microsoft created their Active Directory system they followed Novell's lead and added LDAP support as well.

MIDL: Microsoft Interface Definition Language

MIDL is Microsoft's version of the I nterface D efinition L anguage (IDL). It is used to specify the parameters to function calls, particularly function calls made across a network things like Remote Procedure Call (RPC). MIDL is also used to define the interfaces to Microsoft DLL library functions.

MS-RPC: Microsoft Remote Procedure Call

Paul Leach was one of the founders of Apollo Computer. At Apollo, he worked on a system for distributed computing that eventually became the DCE/RPC system. When Hewlett-Packard purchased Apollo, Leach went to Microsoft. That's probably why the MS-RPC system is so remarkably similar to the DCE/RPC system.

NDR: Network Data Representation

NDR is to DCE/RPC as DER (or BER) is to ASN.1. That is, NDR is an on-the-wire encoding for parameters passed via RPC. When an MS-RPC call is made on the client side, the parameters are converted into NDR format ( marshaled ) for transmission over the network. On the server side, the NDR formatted data is unmarshaled and passed into the called function. The process is then reversed to return the results.

NTLMSSP: NTLM Security Support Provider

It seems there are a few variations on the interpretation of the acronym. A quick web search for "NTLMSSP" turns up NTLM Security Service Provider and NTLM Secure Service Provider in addition to NTLM Security Support Provider . No matter. They all amount to the same thing.

NTLMSSP is a Windows authentication service that is accessed in much the same way as MS-RPC services. NTLMSSP authentication requests are formatted into a record structure and converted to NDR format for transport to the NTLMSSP authentication service provider. In addition to Extended Security, NTLMSSP authentication shows up in lots of odd places. It is even used by Microsoft Internet Explorer to authenticate HTTP (web) connections.

SPNEGO: Simple, Protected Negotiation

Also known as "The Simple and Protected GSS-API Negotiation Mechanism," SPNEGO is a protocol that underlies GSS-API. It is used to negotiate the security mechanism to be used between two systems. SPNEGO is documented in RFC 2478.

Quite a list, eh?

As you can see, there is a lot going on below the surface of Extended Security. We could try diving into a few of the above topics, but the waters are deep and the currents are strong and we would quickly be swept away. Out of necessity, we will spend a little time talking about Kerberos, but we won't swim out too far and we will be wearing a PFD ( P ersonal F loatation D evice don'cha just love acronyms?).