logo_kerberos.gif

Difference between revisions of "Projects/VerifyAuthData"

From K5Wiki
Jump to: navigation, search
(→‎Architecture)
Line 7: Line 7:
 
The goals of this project are to:
  
The goals of this project are to:
   
−
* change the behaviour of krb5_rd_req() to always verify known authorization data types
 +
* change the behaviour of krb5_rd_req() to always verify known authorization data elements
−
* provide an interface to indicate which authorization data types have been verified
 +
* provide an attribute-based GSS interface for extracting authorization information (draft-ietf-kitten-gssapi-naming-exts)
−
* potentially add a plug-in interface for new authorization data verification functions
 +
* provide a vendor-extensible plug-in interface for verifying and extracting authorization data elements
−
+
* eventually, use this interface to allow authorization data elements to be submitted in KDC and AP requests
−
This is a first step towards supporting draft-ietf-kitten-gssapi-naming-exts.
  
   
 
==Architecture==
  
==Architecture==
   
−
Verification of known authorization data types will be performed by krb5_rd_req_decoded_opt() (which assures that the auth data will always be verified, and avoids the potential expense of scanning the keytab twice).
  
  +
A new opaque type, an authorization data context (krb5_authdata_context) provides an attribute-based accessor onto a set of authorization data elements. The operations which one can perform on this context roughly mirror those specified in draft-ietf-kitten-gssapi-naming-exts.
   
−
We will add an argument to krb5_rd_req_decoded_opt() to indicate whether auth data should be verified, and perhaps another to indicate which types were verified (although the extent to which that is exposed at higher levels is undecided).
  
  +
An authorization data context is always created and authenticated by krb5_rd_req(). Using the new krb5_rd_req_extended() function, the application has access to this context, although the only public interface is through GSS.
   
−
There will also be an API for enumerating the auth data types for which verification is supported, and potentially for registering new verification functions (although it's more likely that this will be done via a plugin interface, as for preauth plugins).
  
  +
The authorization data context encapsulates a set of authorization data <i>systems</i>, each which provide support for one or more authorization data types. Each system is instantiated as a <i>module</i>, one for each authorization data type. This is modelled closely on the client-side preauthentication SPI. The set of systems is extensible at runtime through a plug-in interface.
   
−
Note: we don't wish to (yet) change the behaviour of krb5_rd_req() in the KDC, when handling a TGS-REQ. The authorization data interface in the KDC has been designed on the presumption that plugins and/or the backend will manage authorization data. To avoid API changes, we may overload krb5_rd_req_decoded_anyflag() (used by the KDC) to imply that the authorization data is not verified.
  
  +
An authorization data system for the Windows 2000 PAC is built into libkrb5, as a wrapper around the krb5_pac APIs introduced in MIT Kerberos 1.7. Plug-ins have preference over internal systems, so a vendor that wishes to expose inner PAC fields (such as SIDs) as attributes could do so by registering the appropriate plug-in. (In the PAC case, this would avoid the overhead of building a NDR parser into libkrb5. Moreover, it is a generalised interface that should encourage the use of authorization data for other purposes.)
  +
  +
This interface is not designed to be used for authorization data construction or verification within the KDC, at least at this stage. The existing authorization data SPI contributed by Apple and Novell should be used for this.
   
 
==Implementation==
  
==Implementation==
   
−
===krb5int_verify_authdata===
  
  +
===libkrb5===
   
−
===krb5_get_verifiable_authdata_types===
  
  +
===GSS===
   
−
===plugins===
 +
==Example==
  +
  +
<pre>
  +
% ./t_namingexts test.keytab
  +
Target name: host/test.de.padl.com@DE.PADL.COM
  +
init module "mspac", ad_type 128, flags 00000004
  +
init module "mspac", ad_type 128, flags 00000004
  +
Source name: host/test.de.padl.com@DE.PADL.COM
  +
  +
Attribute mspac: Authenticated Complete
  +
  +
050000000000000001000000b001000058000000000000000a00000034000000
  +
...
  +
  +
Attribute mspac:logon-info Authenticated Complete
  +
  +
01100800cccccccca001000000000000000002002caaea1ebc24ca01ffffffff
  +
...
  +
  +
Attribute mspac:client-info Authenticated Complete
  +
  +
8089662f7925ca012a0068006f00730074002f00720061006e0064002e006400
  +
...
  +
  +
Attribute mspac:upn-dns-info Authenticated Complete
  +
  +
2a00100016004000000000000000000068006f00730074002f00720061006e00
  +
...
  +
  +
Attribute mspac:server-checksum Authenticated Complete
  +
  +
10000000ff41c35408ef41128530200a
  +
  +
Attribute mspac:privsvr-checksum Authenticated Complete
  +
  +
76ffffffdfb93706e991880236aa70130e1e87a9
  +
</pre>
   
 
==Status==
  
==Status==
  +
  +
Code is in the users/lhoward/authdata branch.

Revision as of 09:39, 25 August 2009

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.



Background

The goals of this project are to:

  • change the behaviour of krb5_rd_req() to always verify known authorization data elements
  • provide an attribute-based GSS interface for extracting authorization information (draft-ietf-kitten-gssapi-naming-exts)
  • provide a vendor-extensible plug-in interface for verifying and extracting authorization data elements
  • eventually, use this interface to allow authorization data elements to be submitted in KDC and AP requests

Architecture

A new opaque type, an authorization data context (krb5_authdata_context) provides an attribute-based accessor onto a set of authorization data elements. The operations which one can perform on this context roughly mirror those specified in draft-ietf-kitten-gssapi-naming-exts.

An authorization data context is always created and authenticated by krb5_rd_req(). Using the new krb5_rd_req_extended() function, the application has access to this context, although the only public interface is through GSS.

The authorization data context encapsulates a set of authorization data systems, each which provide support for one or more authorization data types. Each system is instantiated as a module, one for each authorization data type. This is modelled closely on the client-side preauthentication SPI. The set of systems is extensible at runtime through a plug-in interface.

An authorization data system for the Windows 2000 PAC is built into libkrb5, as a wrapper around the krb5_pac APIs introduced in MIT Kerberos 1.7. Plug-ins have preference over internal systems, so a vendor that wishes to expose inner PAC fields (such as SIDs) as attributes could do so by registering the appropriate plug-in. (In the PAC case, this would avoid the overhead of building a NDR parser into libkrb5. Moreover, it is a generalised interface that should encourage the use of authorization data for other purposes.)

This interface is not designed to be used for authorization data construction or verification within the KDC, at least at this stage. The existing authorization data SPI contributed by Apple and Novell should be used for this.

Implementation

libkrb5

GSS

Example

% ./t_namingexts test.keytab
Target name:	host/test.de.padl.com@DE.PADL.COM
init module "mspac", ad_type 128, flags 00000004
init module "mspac", ad_type 128, flags 00000004
Source name:	host/test.de.padl.com@DE.PADL.COM

Attribute mspac: Authenticated Complete 

050000000000000001000000b001000058000000000000000a00000034000000
...

Attribute mspac:logon-info Authenticated Complete 

01100800cccccccca001000000000000000002002caaea1ebc24ca01ffffffff
...

Attribute mspac:client-info Authenticated Complete 

8089662f7925ca012a0068006f00730074002f00720061006e0064002e006400
...

Attribute mspac:upn-dns-info Authenticated Complete 

2a00100016004000000000000000000068006f00730074002f00720061006e00
...

Attribute mspac:server-checksum Authenticated Complete 

10000000ff41c35408ef41128530200a

Attribute mspac:privsvr-checksum Authenticated Complete 

76ffffffdfb93706e991880236aa70130e1e87a9

Status

Code is in the users/lhoward/authdata branch.

Retrieved from "https://k5wiki.kerberos.org/wiki?title=Projects/VerifyAuthData&oldid=2190"