It is important that we understand SPNego and its terminologies before we actually configure the same for SAP WAS Java 7.02.
The guide available with SAP Note 1488409 - New SPNego Implementation gives a limited glimpse of what really the SPNego protocol is. A person new to the discussion may be misguided to assume that SPNego is somehow related to SAP. The fact, however, is otherwise.
The below presentation aims at understanding the framework of SPNEGO which at its core is Kerberos authentication:
The Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO)
- GSSAPI solves the problem of providing a single API to different authentication mechanisms
- However, it does not solve the problem of negotiating which mechanism to use
- Indeed, for GSSAPI to work, the two applications communicating with each other must know and agree ahead of time what authentication mechanism they plan to use
- Since most GSSAPI implementations only support one mechanism anyway (namely, Kerberos 5), this is usually not a problem
- However, if there are multiple mechanisms to choose from, a method is needed to securely negotiate an authentication mechanism that is mutually supported between both client and server
- SPNEGO, documented in RFC 2478, performs this function.
The Generic Security Services API (GSSAPI)
- GSSAPI is widely used by protocol implementers as a means to implement Kerberos 5 support in their applications
- It provides a generic interface and message format that can encapsulate authentication exchanges from any authentication method that has a GSSAPI-compliant library
- GSSAPI does not define a protocol, authentication, or security mechanism itself; it instead makes it easier for application programmers to support multiple authentication mechanisms by providing a uniform, generic API for security services
- Most applications that support GSSAPI also support Kerberos 5
- Microsoft Windows Kerberos implementation does not include GSSAPI support but instead includes a Microsoft-specific API, the Security Support Provider Interface (SSPI)
- In Windows, an SSPI client can communicate with a GSSAPI server
- Microsoft includes an implementation of SPNEGO in its Kerberos and SSPI implementation in Windows 2000 and above
Services and Keytabs
- Kerberos provides a service that verifies the identity of two connection endpoints, identified by unique names, or principals
- Each user (which may be person, computer, service or server-host) is associated with a principal name that is stored in the Kerberos database
- All services, like Oracle, MSSQL or Web-server (SAP WAS Java), that users contact through Kerberos also require a principal and secret key
- On Windows hosts, service keys are automatically created as needed when Kerberized services are installed like while installing MSSQL in Windows domain
- For any Kerberized Service, there is an encryption key or keys (possibly more than one, with different key version numbers, encryption types, and salts) associated with a given service principal
- On Unix hosts, service keys are stored on the server providing the service, in a special file called the keytab
- A keytab file contains highly sensitive information, notably encryption keys and should be secured
- The default keytab file—for most Unix-based Kerberos implementations—is /etc/krb5.keytab
Kerberos in Microsoft Windows Domain Controller
- The primary encryption type used in Windows is based on the RC4 stream cipher, with an MD5-HMAC algorithm used for the checksum field and is called RC4-HMAC
- Microsoft added DES support to Windows 2000 and users created in a Windows Active Directory have both RC4 and DES encryption keys associated with their account
- Windows 2000 DC adds proprietary Privilege Access Certificate (PAC) to tickets returned by the KDC
- The PAC is generated by the KDC during the Authentication Server exchange and contains authorization data about the client, including the SID (a unique numeric identifier for users and groups) associated with the user who requested the ticket and any groups that the user is a member of
- If a user is a member of a large number of groups (around 70), then the PAC might grow large enough that the KDC reply does not fit in a single UDP packet and KDC asks the client to retry using TCP
Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)
- SPNEGO provides a framework for two parties that are engaged in authentication to select from a set of possible authentication mechanisms, in a manner that preserves the opaque nature of the security protocols to the application protocol that uses SPNEGO
- SPNEGO was first defined in [RFC2478], which has been superseded by [RFC4178]
Generic Security Services Application Programming Interface (GSSAPI)
- SPNEGO is a security protocol that uses a GSS-API authentication mechanism
- GSS–API is a literal set of functions that include both an API and a methodology for approaching authentication
- GSS-API aims to insulate application protocols from the specifics of security protocols as much as possible
- Application Protocol (say HTTP) has only the responsibility of transporting opaque discrete packets the Authentication Protocol produces
- These packets are called Security Tokens in GSS-API
- Application Protocol (say HTTP) does not need to look into the contents of these Security Tokens
- Application Protocol keeps on exchanging security tokens between Client and Authentication Server until one side determines that authentication has failed or both sides decide that authentication is complete
- Because more than one GSS–compatible authentication protocol exists, determining which protocol to use has become more important
- The Application Protocol need not be compile-time bound with an Authentication Protocol
- SPNEGO negotiates among several available authentication mechanisms in an implementation, selecting one for use to satisfy the authentication needs of the application protocol
SPNEGO Exchange
- The client puts the Kerberos ticket in an SPNEGO token
- The client responds to the “Authenticate: Negotiate” challenge with the SPNEGO token in the request HTTP header
- The server sees the HTTP header with the SPNEGO token. It extracts the Kerberos ticket and validates the ticket.
- After validation, the server checks authorization and if appropriate, grants the requests and serves the requested secure resources. Otherwise, it will respond with access denied.
Client Initiated SPNEGO Exchange
- The client sends a negTokenInit message to the server. This message specifies the available authentication methods and an optimistic token
- The server sends a negTokenResp message to the client. The message specifies the state of the negotiation
Server Initiated SPNEGO Exchange
- The server sends a negTokenInit2 message to the client. This message specifies the available authentication methods and an optimistic token
- The client sends a negTokenInit message to the server. This message specifies the available authentication methods and an optimistic token
- The server sends a negTokenResp message to the client. The message specifies the state of the negotiation.
SPNEGO and other Protocols
- SPNEGO requires at least one other GSS–compatible authentication protocol to be present for it to work
- Microsoft Windows implementations of SPNEGO negotiate the following authentication protocols by using the object identifier (OID) assigned to them:
- Kerberos Network Authentication Service (V5) protocol
- User to User Kerberos Authentication
- NT LAN Manager (NTLM) Authentication Protocol
- Extended GSS-API Negotiation Mechanism (NEGOEX) protocol
SPNEGO Summary
- SPNEGO is a meta protocol that travels entirely in other application protocols; it is never used directly without an application protocol
- After SPNEGO has completed the ferrying of the other security protocol's authentication tokens, SPNEGO is finished
- All further access to security context state and per-message services, such as signatures or encryption, is done by directly using the "real" security protocol (like Kerberos) whose authentication tokens were communicated via SPNEGO
- SPNEGO is used by Microsoft Application Protocols like:
- Common Internet File System (CIFS) / Server Message Block (SMB)
- HTTP
- Remote Procedure Call Extensions
- Lightweight Directory Access Protocol (LDAP)
References and Bibliography
- Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) Extension © 2012 Microsoft Corporation, Released Mar 28, 2012
- HTTP-Based Cross-Platform Authentication by Using the Negotiate Protocol, MSDN, © Microsoft Corporation
- Kerberos – The Definitive Guide by Jason Garman, © O'Reilly & Associates, August 2003
