Export (0) Print
Expand All
Expand Minimize

Windows 2000 RSVP/Kerberos User Authentication Interoperability

This white paper demonstrates how an RSVP-aware Policy Decision Point (PDP) implementation can extract the Kerberos ticket embedded in the Policy Element Object of a PATH or RESV message sent out by a Windows 2000 operating system RSVP process.

On This Page

Introduction
Kerberos System
RSVP Identity Representation
Sample Code Abstract Data Types
Using the User Identity ATD
Building Sample Data Files
MIT's Kerberos 5, Version 1.0 Reference Implementation
Configuration for MIT's Kerberos on UNIX/Solaris Systems
Windows 98 Clients Interoperability
Terminology
References

Introduction

This white paper demonstrates how an RSVP-aware PDP device can extract the Kerberos ticket embedded in the Policy Element Object of a PATH or RESV message sent out by a Windows® 2000 operating system RSVP process1. By extracting this ticket, the PDP device can securely identify the user requesting the resource and thus make policy decisions based on the user's identity.

Sample code using Microsoft's Security Support Interface (SSPI) as well as the Massachusetts Institute of Technology's (MIT) Generic Security Service Application Program Interface (GSSAPI) is included. (The GSSAPI is a part of MIT's Kerberos 5, version 1.0 distribution.)

The paper assumes some familiarity with Quality of Service (QoS) components, the Windows 2000 QoS suite, Kerberos, and the C++ programming language. A list of acronyms and their meanings is included in the "Terminology" section.

Kerberos System

The Kerberos system employed by the Windows 2000 RSVP stack enables a PDP (which, in our discussion, is the Windows 2000 ACS) to authenticate an end user (called the Kerberos client) who is requesting network resources through a trusted KDC called the Kerberos server2. A DC can also serve as a KDC, but this paper shows that the process works with any Kerberos 5 KDC. To simplify administration, it is recommended that both the end user and the PDP device belong to the same Windows 2000 domain or Kerberos realm. All ACS systems in a domain share the same ACS account and all password changes for the ACS account must be synchronized. The ACS domain is the set of ACS servers that can access a directory for a given DN.

The authentication process requires that both the client and the server (in this case, the PDP) be able to authenticate to the KDC and acquire credentials for the PDP service account. For Windows 2000 QoS, this service account is a user account named AcsService, or the ACS Kerberos principal name. To authenticate itself to the PDP, a client requests a Kerberos ticket with a target name of AcsService. This ticket contains a session key. The client then transmits the ticket, which contains an encrypted version of the client's identity and the session key, in the PATH message. The PATH message is intercepted by the PEP and forwarded to the PDP. Having acquired its own credentials for the AcsService account, and using the session key from the PATH message, the PDP is now able to extract the client principal name from the ticket, reveal the user identity, and use it to authenticate the user.

Figure 1, below, shows elements of the authentication process using the Microsoft ACS server as a combined policy decision and policy enforcement point. It is intended to illustrate the procedure used by any RSVP-aware network element to extract the Windows 2000 user ID for authentication. Non-Microsoft implementations may include additional elements and/or steps, but the basic process is the same.

Bb742505.rsvpke01(en-us,TechNet.10).gif

Figure 1: Kerberos authentication process
  1. At startup, the PDP (in this case, the Windows 2000 ACS) authenticates itself to the KDC and acquires the credential handle for service principal AcsService.

  2. The KDC returns the credential handle for AcsSerivce to the PDP.

  3. Prior to sending a PATH message, the client requests a Kerberos ticket for a target service of AcsService.

  4. The KDC returns a session ticket to the client for AcsSerivce.

  5. The client sends a PATH message that is intercepted by the PDP. The PATH message includes the Kerberos ticket for AcsService without Kerberos authdata (the authdata is not needed, requested, or used, in this implementation). Included in the PATH message is the user DN, which is encrypted using the session key.

  6. Acting as the PDP, the Windows 2000 ACS, extracts the Kerberos ticket, decodes it, and uses the session key to decrypt the user's DN (using the GSSAPI call GSS_unwrap.). The DN is used for a LDAP search of the DS to retrieve the user's policy for RSVP.

    The PDP returns the policy decision to the PEP. If the PDP has accepted this PATH message then the PEP configures the RSVP state for this PATH message and then forwards the PATH request onto the network. After the request is processed, it is forwarded to the next hop, toward the destination system. For the router to be able to process the identity in the PATH request, it has these alternatives:

    • Have a PDP running internally in the router. This PDP would have to use the same Kerberos principal name as other ACSs in the domain and participate in password synchronization.

    • Send the PATH message to the PDP to retrieve the policy for the user. The PDP would be running with the ACS identity.

The preceding description is between the end system and the first policy-aware hop. A different encryption key can be used beyond this hop. This key can be pre-shared, a public key, or obtained using a trusted third party.

For more details on the Kerberos authentication scheme, read RFC 1510 "The Kerberos Network Authentication Service."

RSVP Identity Representation

Before a Windows 2000 RSVP process sends out an RSVP request, it first inserts an Identity PE into the PATH or RESV message3. The identity PE consists of two sub-objects: the user's encrypted DN, which is the attribute data for the Policy Locator attribute and the Kerberos ticket, which is the attribute data for the Credential attribute. A summary of the Identity Policy Element, using Kerberos AUTH_DATA is shown in Figure 2, below:

+--------------+--------------+--------------+--------------+
| Length                      | P-type = AUTH_USER          |
+--------------+--------------+--------------+--------------+
| Length                      |POLICY_LOCATOR| Encrypted DN |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...               |
+--------------+--------------+--------------+--------------+
| Length                      | CREDENTIAL   | KERBEROS_TKT |
+--------------+--------------+--------------+--------------+
| OctetString (Kerberos Session Ticket) ...                 |
+--------------+--------------+--------------+--------------+

Figure 2 Policy element wire format

For more information about policy elements, consult the Internet Draft titled "Application and Sub Application Identity Policy Element for Use with RSVP."

The sample code included in this document focuses on processing this wire format. Methods for extracting the PE out of a PATH or RESV message are beyond the scope of this paper and are left for PDP implementation writers.

Sample Code Abstract Data Types

The sample code included in this document defines two ADTs: User Identity and Kerberos Server. It also shows how a PDP implementation can process the Policy Element, extract the Kerberos session ticket, and decrypt a user's DN. The relationships between the two ADTs are shown in Figure 3, below:

Bb742505.rsvpke02(en-us,TechNet.10).gif

Figure 3: Sample code ADTs

The circles represent the interfaces (.h files) and the blocks represent the implementation details (.c files).

User Identity ADT

The User Identity interface consists of four functions, shown below.

typedef struct {
    // implementation details
} RSVP_USER_IDENTITY, *P_RSVP_USER_IDENTITY; 
int user_id_init (P_RSVP_USER_IDENTITY p_user_id);
int user_id_decap(P_RSVP_USER_IDENTITY p_user_id, P_CBYTE p_buffer, UINT 
buffer_length);
int user_id_auth (P_RSVP_USER_IDENTITY p_user_id, char* p_service_name, 
char* p_realm_name, char* p_password);
void user_id_close(P_RSVP_USER_IDENTITY p_user_id);

The user_id_decap() function takes a pointer to a PE (See Figure 2) and extracts the policy locator (whose attribute data is the encrypted user DN) and the Kerberos session ticket. The user_id_auth() function takes a user's credentials (that is, the user name, password, and domain/realm name4), extracts the session ticket, then decodes it and prints the user's DN.

Kerberos Server ADT

The Kerberos Server ADT provides an abstract interface for a simple Kerberos Server. It consists of four methods, shown below:

int k_server_init(char* p_service_name, char* p_realm_name, char* 
p_password);
int k_server_crack(void* p_k_ticket, unsigned int k_ticket_length);
int k_server_decrypt(void*  p_encrypted_data, 
                     unsigned int encrypted_data_length, 
                     char** p_decrypted_data, 
                     unsigned int* p_decrypted_data_length);
void k_server_close(void);

Both the GSSAPI implementation (tested on a Solaris 2.5 system5) and the SSPI implementation shared the same Kerberos Server interface. The sole purpose of this polymorphic ADT is to free the User Identity ADT from having to accommodate implementation differences between the Windows 2000 operating environment and the UNIX/Solaris operating environment.

Using the User Identity ATD

The following code fragment shows how the User Identity ADT can be used:

RSVP_USER_IDENTITY user_id;
P_CBYTE p_buffer;
UINT buffer_length
user_id_init(&user_id);
// set p_buffer to point to the beginning of a Policy Element
// set buffer_length to the length of the Policy Element
if (user_id_decap(&user_id, p_buffer, buffer_length) != 0)
{
    // the Policy Element is malformed; handle this error and return
}
if (user_id_auth(&user_id, "AcsService", "TESTACS.MICROSOFT.COM", 
"???") != 0)
{
    // failed to authenticate user; handle this error and return
}

In the UNIX/Solaris environment, it is unnecessary to supply the password for the service account when using the user_id_auth() function because it is available from the Kerberos5 keytab file (described later in this paper). Methods for securely storing the service account credential in the Windows 2000 environment are beyond the scope of this paper.

If the user_id_auth() function is successful, it will print the DN of the user in a format similar to the one shown below:

CN=Multi1,OU=Pepsi,DC=testacs,DC=microsoft,DC=com

This is the user identity that a PDP implementation uses to check against its policy database.

Building Sample Data Files

To build the ADTs in the Windows 2000 environment using SSPI, the following files should be included:

Usre_id.h
User_id.c
K_server.h
sspi_k_server.c

For users of the Microsoft Visual C++® development system, this program can be built as a Win32® API console application. For access to SSPI, the secur32.lib needs to be linked in.

The following files are needed for building in the Solaris environment, using the Kerberos 5 GSSAPI:

Usre_id.h
User_id.c
K_server.h
Gssapi_k_server.c

Using the GNU GCC compiler, the command line should be:

%gcc -c PDP.c6 user_id.c Gssapi_k_server.c –lgssapi_krb5 –lkrb5

MIT's Kerberos 5, Version 1.0 Reference Implementation

This reference implementation supports the Data Encryption Standard (DES) algorithm as of version 1.0.6. Because simple DES has documented weaknesses, a typical secure network environment will deploy stronger algorithms. The Windows 2000 default is RC4, which is documented in:

http://www.ietf.org/ids.by.wg/krb-wg.html.

When the KDC is a Windows 2000 Domain Controller, and the PDP is running on a non-Windows 2000 system, check the "DES-Only" check box through the user account manager for the AcsService user account.

For more information on MIT's Kerberos implementation, visit their web site at http://web.mit.edu/kerberos/www/index.html.

Configuration for MIT's Kerberos on UNIX/Solaris Systems

UNIX systems using MIT's Kerberos implementation need some special configurations to be able to participate in a Windows 2000 domain using Kerberos authentication.

For Solaris systems, an administrator first needs to configure Kerberos by creating a text file named krb5.conf under the /etc directory. The file should look like this:

[libdefaults]
default_realm = TESTACS.MICROSOFT.COM
[realms]
TESTACS.MICROSOFT.COM = {
kdc = qos28.testacs.microsoft.com:88
        }

This file tells the Solaris Kerberos whose domain it belongs to and the name of its KDC.

The system administrator must then use a Windows 2000 utility called ktpass.exe to:

  • Generate a keytab file.

  • Securely transport the file to a Solaris machine.

  • Import the keytab file into the Kerberos5 database.

The keytab file contains credential for a particular service account. The following example shows how to configure a Solaris system to have access to the AcsService account of the TESTACS.MICROSOFT.COM domain.

  1. From the DC of TESTACS.MICROSOFT.COM domain, run:

    C:\> Ktpass /princ AcsService@TESTACS.MICROSOFT.COM -mapuser 
     AcsService 
    
  2. -pass <AcsService password> -out AcsService.keytab

  3. Securely transport the AcsService.Tab file to the Solaris.

  4. From the Solaris, run:

    % ktutil
     ktutil: rkt AcsService.keytab
     ktutil: list
     The output should appear similar to the following:
     slot KVNO Principal
     ---- ---- ---------
        1    1 AcsService@TESTACS.MICROSOFT.COM 
    ktutil: wkt /etc/krb5.keytab
     ktutil: q
    

The Kerberos configuration utilities, including ktpass.exe, are available on the Windows 2000 distribution media, in the \support\reskit\netmgmt\security folder.7.

Windows 98 Clients Interoperability

Windows 98 clients do not support Kerberos authentication. A user on this platform appears to the ACS as an unauthenticated user.

Terminology

ACS - Admission Control Service
AD - Active Directory, the Windows 2000 implementation of a directory service
ADT – Abstact Data Type
DC - Windows 2000 Domain Controller
DES - Data Encryption Standard
DN - Distinguished Name
DS - Directory Service
GSSAPI - Generic Security Service Application Program Interface
KDC - Key Distribution Center
PATH - RSVP message that follows the data path
PDP - Policy Decision Point
PE – Policy Element
PEP - Policy Enforcement Point
QoS - Quality of Service
RESV - RSVP reservation request message
RSVP – Resource Reservation Protocol
SSPI – Security Support Interface

References

The Kerberos Network Authentication Service (V5). Kohl J., Neuman, C. RFC 1510, available at:

http://www.ietf.org/rfc/rfc1510.txt

Windows 2000 RC4-HMAC Kerberos encryption, M.Swift, J.Brezak, Internet Draft, available at:

http://www.ietf.org/ids.by.wg/krb-wg.html

Application and Sub Application Identity Policy Element for Use with RSVP, Bernet, Internet Draft, available at:

http://www.ietf.org/rfc/rfc2872.txt

1The RSVP Process is an essential component of the QoS implementation in Windows 2000 implementation, and follows the Identity representation as outlined in the Internet Draft draft-ietf-rap-rsvp-identity-05.txt.
2For a list of Kerberos terms, read RFC 1510.
3If the Policy Element is missing, the user must be treated as an unauthenticated user.
4In this paper, we assume the Windows 2000 domain controller is also the Kerberos realm.
5Sample code compiled using GNU GCC version 2.8.1.
6PDP implementation code.
7Another useful tool is kinit.exe, which can be used to log on to a Windows 2000 domain. This is usually located in /usr/bin.
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft