Kerberos Feature Request

[Tim Alsop]

Henry,

Thankyou for the examples. This helps understand your requirements. Comments below prefixed with Tim> 

-----Original Message-----
From: Henry B. Hotz [mailto:hotz at jpl.nasa.gov] 
Sent: 11 February 2004 23:01
To: Tim Alsop; krbdev at mit.edu; heimdal-discuss at sics.se; darwin-development at lists.apple.com
Cc: Dj Byrne
Subject: RE: Kerberos Feature Request

Use case 1:  I need to control access to some information based on ITAR (US Export) regulations.  There is an existing LDAP attribute listing whether each kerberos user is a "US Person".
	KDC queries LDAP for each ticket request for that attribute to see if it's true.  If so put the info in the authorization data. 
If not, or if LDAP is down, then leave it blank or set it false. 
Services that care need to check it.

Tim> The KDC does not have to query the LDAP directory - this can be done after authentication has taken place using a pam module (for example) or an authorisation exit/module in the application/service. This approach is commonly used thoughout the Kerberos community. The confusion is introduced because Microsoft have chosen to transport authorisation data inside Kerberos tickets, but this has disadvantages and is not considered by some as being the best architecture. We find that most people want to use Kerberos to authenticate a user to an applicationk and then once they know who the user is, they should determine whether that user can access the application by using a standard LDAP lookup ... If the LDAP directory supports Kerberos binding (ie. SASL/GSS/Kerberos) then the forwarded Kerberos credentials available at the application can be used to bind with the directory to securely read the authorisation attributes.

Use case 2:  I'm required by Government regulation to use AES-256 encryption and CRYPTOcard hardware authentication with my windows domain.
	Set up a windows server.  Set up the Kerberos server to support those things and, in addition to query the appropriate attributes from windows.  Package the windows info appropriately and include it for compatibility.
	(Actually that may be a bad choice of Kerberos features. 
Just pick something that MS doesn't support, but might be necessary and easy to implement.)

Tim> I think somebody else responded to your email earlier on this subject - This can be done today using cross-realm trust between a non-MS (UNIX based) KDC and the Active Directory KDC. The user account is created on non-MS KDC and user authenticates, but when PAC data is needed by an application an additional cross-realm TGT will be requested from MS AD that will contain the authorisation data.

Use case 3:  I don't want to pay Microsoft all the fees for their server.
	Tap into all the open information about how to set up the windows information on an open LDAP server.  Then proceed as in case 2.  (Alternatively you could construct a PAC attribute ahead of time on the LDAP side and just copy it into the ticket.)

Tim> This is a clear potential requirement, but as I commented before - do you realy think Microsoft would allow such a product to exist ? If it did, then they would loose sales of Active Directory and would likely do their best to kill the product concerned ??? Just my opinion - maybe being over cautious !!

Does this help?  All three of these cases are at least close to something I might actually have to do.

At 9:09 PM +0000 2/11/04, Tim Alsop wrote:
>Henry,
>
>I am now confused. Can you explain a 'use case' so that we can 
>understand better why you would want to access MS account authorisation 
>data stored in AD ?
>
>When referencing PAC data - this refers to the authorisation data 
>stored inside Kerberos tickets. It sounds like you are not looking for 
>a non-MS KDC to access this information or populate tickets with this 
>information. So, what are you looking for ?
>
>Thanks, Tim.
>
>-----Original Message-----
>From: Henry B. Hotz 
>[<mailto:hotz at jpl.nasa.gov>mailto:hotz at jpl.nasa.gov]
>Sent: 11 February 2004 21:03
>To: Tim Alsop; krbdev at mit.edu; heimdal-discuss at sics.se; 
>darwin-development at lists.apple.com
>Cc: Dj Byrne
>Subject: RE: Kerberos Feature Request
>
>Multiple issues here.  All good points, but one at a time:
>
>1)  I am not requesting that anybody support Microsoft PAC for 
>authorization.  I am only requesting a general interface for inserting 
>authorization data.  As noted by Paul W. Nelson a complete solution 
>also needs a good API for a client service to pull that authorization 
>data out and inspect it (including parsing routines, etc.).
>
>2)  I am requesting that the general interface be usable to distribute 
>Microsoft PAC information, but only if other out-of-scope work is done 
>to ensure that data is compatible with what Microsoft wants.
>
>3)  The format of the PAC data is claimed to be proprietary and trade 
>secret by Microsoft, and is subject to unilateral change by Microsoft.  
>However Microsoft has built an infrastructure based on the PAC data.  
>They aren't going to break backward compatibility if they don't have 
>to.
>
>4)  I note that organizations or people who have agreed to Microsoft's 
>license on their description of the PAC data may have to abide by their 
>agreements.  However I've discussed the issue with JPL's legal 
>department and I'm satisfied that *I* do not have to worry about that.  
>The PAC format is readily available from multiple sources (see Google) 
>and you don't have to agree to anything in order to get the 
>information.  Some fraction (I won't say how much) of Microsoft's legal 
>claims on that information are based on the information being a "trade 
>secret".  It's no longer a secret, trade or otherwise.
>
>Usual disclaimer:  I'm not a lawyer, I don't even play one on TV (or in 
>the UK ;-).
>
>At 8:53 AM +0000 2/11/04, Tim Alsop wrote:
>>Henry,
>>
>>The PAC format is a Microsoft propriatory standard that they have 
>>documented for vendors to use if they wish. If Microsoft decide to
>  >change this, they can - they will then inform all MSDN members that
>>changes have been made.
>>
>>To implement your proposal - each KDC would have to construct that PAC 
>>field and place this into the appropriate tickets. The KDC would also 
>>have to manage principals such as ldap/host.name at REALM and 
>>cifs/server.name at REALM. The additional service principals would need 
>>to be created when a workstation becomes a member of a domain etc. I 
>>am sure there are many other complex implications here. Effectively 
>>what you are asking for is a non-MS kdc that is usable instead of MS 
>>AD for workstation user logon ?
>>
>>One big issue, IMHO - What do you think Microsoft would think if it 
>>was possible to use a UNIX server with an LDAP server instead of 
>>Active Directory ? They would clearly not like this and they might 
>>decide to change licensing of PAC data (or some other action) to stop 
>>the UNIX KDC vendors from being able to offer this functionality ... 
>>Do you agree ?
>>
>>Cheers, Tim.
>>
>>-----Original Message-----
>>From: Henry B. Hotz
>>[<<mailto:hotz at jpl.nasa.gov>mailto:hotz at jpl.nasa.gov><mailto:hotz at jpl.
>>nasa.gov>mailto:hotz at jpl.nasa.gov]
>>Sent: 11 February 2004 01:29
>>To: Tim Alsop; krbdev at mit.edu; heimdal-discuss at sics.se; 
>>darwin-development at lists.apple.com
>>Cc: Dj Byrne
>>Subject: RE: Kerberos Feature Request
>>
>>I want to enable that.
>>
>>I'm suggesting that it would be nice if there were a MIT-independent 
>>and KTH-independent (and CyberSafe-independent ;-) mechanism that 
>>allowed you to do that.  Given a KDC-neutral enabling mechanism I 
>>expect that an open-source project or 10 would spontaneously form to 
>>bridge the gap between the conformant KDCs and the LDAP server of your 
>>choice (including true blue AD).
>>
>>I'd be happy if the agreement/standard/whatever just said that you do 
>>an ldap query for the "pac" attribute from the unique ID that matches 
>>the principal, with the obvious REALM to DC= translation.
>>
>>Jeffrey Altman objects that I want an API, not an RFC, so IETF 
>>shouldn't be involved, but I think the example I just gave would be an 
>>RFC.  I'm trying to limit my care-about's though.  I just want a 
>>general way to make use of the feature, which is currently pretty 
>>inaccessible.
>>
>>At 11:41 PM +0000 2/10/04, Tim Alsop wrote:
>>>Henry,
>>>
>>>Are you proposing that the non-Microsoft KDC issues tickets 
>>>containing PAC data and gets the group membership information from 
>>>the Active Directory using LDAP ?
>>>
>>>Thanks, Tim.
>>>
>>>-----Original Message-----
>>>From: Henry B. Hotz
>>>[<<<mailto:hotz at jpl.nasa.gov>mailto:hotz at jpl.nasa.gov><mailto:hotz at jpl.nasa.gov>mailto:hotz at jpl.nasa.gov><<mailto:hotz at jpl>mailto:hotz at jpl.
>>>nasa.gov><mailto:hotz at jpl.nasa.gov>mailto:hotz at jpl.nasa.gov]
>>>Sent: 10 February 2004 18:27
>>>To: krbdev at mit.edu; Tim Alsop; heimdal-discuss at sics.se; 
>>>darwin-development at lists.apple.com
>>>Cc: Dj Byrne
>>>Subject: Kerberos Feature Request
>>>
>>>I probably should send this to the IETF group, but I'm not on their 
>>>mailing lists.  (Apologies if the cross-posting causes problems.) It 
>>>would be *nice* if all Kerberos distributions added this feature the 
>>>same way.
>>>
>>>One of the famous things that Microsoft did in their AD Kerberos 
>>>implementation is added authorization data to the (supposedly
>>>
>>>optional) PAC field that is necessary when using certain other 
>>>Microsoft functionality.  AFAIK all of the information added is also 
>>>contained in the LDAP directory that AD also provides.
>>>
>>>I do not think it makes any sense for a (non-Microsoft) Kerberos 
>>>server to directly maintain this data.  Rather it should have a 
>>>mechanism for acquiring the data from an external source, such as an 
>>>LDAP directory.
>>>
>>>My request is that the Kerberos community agree on a standard 
>>>external interface to get that data.  If the interface itself were 
>>>standardized then the work of connecting that interface to the 
>>>appropriate AD attributes could be done independently of any Kerberos 
>>>server, and could be updated as Microsoft updates their schema 
>>>independent of Kerberos versions.  It would also make the use of PAC 
>>>data in non-Microsoft environments much easier to consider.
>  >>
>>>--
>>>The opinions expressed in this message are mine, not those of 
>>>Caltech, JPL, NASA, or the US Government.
>>>Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
>>
>>
>>--
>>The opinions expressed in this message are mine, not those of Caltech, 
>>JPL, NASA, or the US Government.
>>Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
>
>
>--
>The opinions expressed in this message are mine, not those of Caltech, 
>JPL, NASA, or the US Government.
>Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu


--
The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu