[2498] in Kerberos_V5_Development
Windows NT "Kerberos" information.
daemon@ATHENA.MIT.EDU (Christopher Blizzard)
Wed Sep 3 09:53:44 1997
To: krbdev@MIT.EDU
Cc: Matt Hanley <mwhanley@appliedtheory.com>,
Christopher Blizzard <blizzard@appliedtheory.com>,
jreed@appliedtheory.com, Scott Stansbury <scotts@appliedtheory.com>,
Lisa Blake <lmblake@appliedtheory.com>
Date: Wed, 03 Sep 1997 09:53:04 -0400
From: Christopher Blizzard <blizzard@appliedtheory.com>
Digging through some NT security information I found a reference to the
following URL:
http://www.microsoft.com/ntserver/info/aasecurwp.htm
It contains a little information about Kerberos in the new NT preview
release. Here are some of the jucier parts. I hope it's useful to people
here. :)
--Chris
------------
Kerberos Integration
The Kerberos protocol is fully integrated with the Windows NT security
architecture for authentication and access control. The initial Windows NT
domain logon is provided by WinLogon. WinLogon uses the Kerberos security
provider to obtain an initial Kerberos ticket. Other operating system
components, such as the Redirector, use the SSPI interface to the Kerberos
security provider to obtain a session ticket to connect to the SMB server
for remote file access.
The Kerberos Version 5 protocol defines an encrypted field in session
tickets to carry Authorization Data, but use of the field is left up to
the applications. Windows NT uses the Authorization Data in Kerberos
tickets to carry Windows NT Security IDs representing the user and group
membership. The Kerberos security provider on the server-side of a
connection uses the Authorization Data to build a Windows NT security
access token representing the user on that system. The server follows the
Windows NT security model of impersonating the client, using the access
token representing the client, before attempting to access local resources
protected by Access Control Lists (ACLs).
Delegation of authentication is supported in the Kerberos Version 5
protocol using proxy and forwarding flags in session tickets. Windows NT
uses the delegation feature to allow servers to obtain a another session
ticket to connect to remote servers on behalf of the client.
Kerberos Interoperability
The Kerberos Version 5 protocol is implemented for a variety of systems
and is used to provide a single authentication service in a distributed
network. Kerberos interoperability provides a common protocol that allows
a single (possibly replicated) account database for authenticating users
on all enterprise computing platforms to access all services in a
heterogeneous environment. Kerberos interoperability is based on the
following characteristics:
o A common authentication protocol used to identify the end user or
service by the principal name in a network connection.
o The ability to define trust relationships between Kerberos realms and to
generate ticket referral requests between realms.
o Implementations that support the Interoperability Requirements defined
in RFC 1510 regarding encryption and checksum algorithms, mutual
authentication, and other ticket options.
o Support for Kerberos Version 5 security token formats for context
establishment and per-message exchange as defined by the IETF Common
Authentication Technology working group.
The principal name in a Kerberos ticket is used to authenticate the user's
identity while additional authorization information might be managed on
the local system for access control. Identity-based authentication
provides a high degree of interoperability for systems that support the
Kerberos Version 5 protocol, however, it does not support user
authorization. The Kerberos protocol provides for transport of
authorization data but the contents of this field is considered specific
to the application service.
Microsoft's implementation of the Kerberos protocol supports the
interoperability characteristics sufficient for identity-based
authentication. In addition, Microsoft integrates authorization data in
the form of Windows NT group memberships in Kerberos tickets to convey
access control information to Windows NT services. The native
representation of the authorization data is the Windows NT Security IDs.
Windows NT services have services accounts defined in the Windows NT
Directory Service that defines the shared secret used by the KDC to
encrypt session tickets. Clients attempting to connect to Windows NT
services obtain session tickets to the target server from the KDC in the
domain where the service account is defined. The Kerberos security
provider supporting a Windows NT service will expect to find authorization
data in the session tickets used to build a security access token. The
Windows NT service will impersonate the security context of the client,
based on the authorization data provided in the session ticket.
Clients that obtain initial Kerberos TGT tickets from KDCs on non-Windows
NT-based systems will use the Kerberos referral mechanism to request a
session ticket from the KDC in the Windows NT Service domain. The referral
ticket is created by interrealm trust relationships between the KDCs. The
ticket requests originating from an MIT Kerberos authentication service
are not likely to contain authorization data. In the case where session
tickets do not contain authorization data, the Kerberos security provider
on Windows NT will try to use the principal name in the ticket and create
a security access token for a designated user account, or use a default
account defined for this purpose. Microsoft is still investigating some of
the interoperability issues with different Kerberos configurations and
will continue to work to find solutions for Kerberos interoperability.
The DCE Security Services are also layered on the Kerberos protocol. DCE
authentication services use RPC representation of Kerberos protocol
messages. In addition, DCE uses the authorization data field in Kerberos
tickets to convey Privilege Attribute Certificates (PACs) that define user
identity and group membership. The DCE PAC is used in a similar manner as
Windows NT Security IDs for user authorization and access control. Windows
NT services will not be able to translate DCE PACs into Windows NT user
and group identifiers. This is not an issue with Kerberos
interoperability, but rather an issue of interoperability between DCE and
Windows NT access control information. In the future, Microsoft will
investigate ways to map DCE authorization to the Windows NT security
model.
Kerberos Extensions for Public Key
Windows NT will also implement extensions to the Kerberos protocol to
support authentication based on private/public-key pairs in addition to
shared secret keys. The public-key authentication extensions allow clients
to request an initial TGT using a private key, while the KDC verifies the
request using the public key obtained from an X.509 certificate stored in
the user object in the Windows NT Directory Service. The user's
certificate could be issued by a third-party Certificate Authority, such
as VeriSign's Digital IDs, or from the Windows NT Certificate Services.
After the initial private-key authentication, standard Kerberos protocols
for obtaining session tickets are used to connect to network services.
A proposal to extend the Kerberos protocol specification to provide a
method for using public-key cryptography for initial authentication is
submitted to the IETF working group for review. Microsoft is participating
in the IETF standards process and intends to support the standard protocol
extensions for public key.
Public-key authentication extensions to the Kerberos protocol provides a
foundation for network authentication using smart card technology. In the
future, there will be many options for obtaining certificates for end
users depending on their organization affiliation or job requirements.
Windows NT will provide a Certificate Server for organizations that want
to issue public-key certificates to their users without depending on
commercial CA services. The certificate policy is
straightforward-certificates are issued to users authenticated using valid
Domain account credentials. The next section describes how those
certificates can be used for intranet and Internet access to resources on
Windows NT.
------------
Christopher Blizzard
AppliedTheory Communications, Inc.
http://odin.appliedtheory.com/
blizzard@appliedtheory.com
------------
