Re: [KAML] Re: Chicago bar-BOF summary

"Henry B. Hotz" <> Fri, 14 September 2007 01:58 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IW0Rf-00006D-8g; Thu, 13 Sep 2007 21:58:11 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IW0Rd-000066-Md for; Thu, 13 Sep 2007 21:58:09 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1IW0Rd-00037f-1r for; Thu, 13 Sep 2007 21:58:09 -0400
Received: from ( []) by (Switch-3.2.6/Switch-3.2.6) with ESMTP id l8E1w4E3023553; Thu, 13 Sep 2007 18:58:04 -0700
Received: from [] ( []) by (Switch-3.2.6/Switch-3.2.6) with ESMTP id l8E1w2GB007257; Thu, 13 Sep 2007 18:58:02 -0700
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <>
Content-Transfer-Encoding: 7bit
From: "Henry B. Hotz" <>
Subject: Re: [KAML] Re: Chicago bar-BOF summary
Date: Thu, 13 Sep 2007 18:57:59 -0700
To: "Douglas E. Engert" <>
X-Mailer: Apple Mail (2.752.3)
X-Source-IP: []
X-AUTH: Authorized
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about SAML and Kerberos intersections <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Anyone know the compatibility of the PAC with other authorization  
data?  DCE authN data is, I presume, ASN1 encoded.  I think the PAC  
is just a memory dump.  A SAML token is XML.

Even if we ignore DCE, can we guarantee that an XML blob and the PAC  
can coexist if needed?  I think I'm seeing some provisions for that,  
but want to confirm.

 ><I don't have anything to add to Doug's comments.>>

On Sep 13, 2007, at 2:24 PM, Douglas E. Engert wrote:

> Gerald Beuchelt wrote:
>> It is my understanding (and I am also no lawyer!) that the article  
>> by John Brezak carries a patent license regarding the actual  
>> content of the document itself.
>> Now, this document specifies the PAC for Windows 2000, with the  
>> exception of 18 reserved fields. What it also does not specify is  
>> any PAC changes in XP, 2003, Vista, or 2008. It also does not  
>> specify any backend infrastructure (e.g. discovery or resolution  
>> services, policy tools, or data storage, etc.) that might or might  
>> not be covered by patents or other intellectual property rights.  
>> Also, some of the default SIDs in the Windows implementation that  
>> are required for evaluating group membership (e.g. EVERYONE, etc.)  
>> are also not included in this document.
> There was also the IETF:
> draft-brezak-win2k-krb-authz-01.txt
> from October 2002, I still have a copy, but does not address XP, 2003
> or Vista.
> Samba has been working on using the PAC created by Windows, and trying
> to get XP to use a Samba/Heimdal created PAC. So they may have  
> addressed
> a lot of these issues.
>> In addition, I do seem to remember that Microsoft at some time  
>> offered a complete description (purportedly including the 18  
>> reserved fields) of the PAC that came with a license explicitly  
>> prohibiting implementation. Since I did not touch this document, I  
>> cannot speak to its actual content.
>> So, as I am not a lawyer, I am quite paranoid when it comes to  
>> other people's IPR and license terms. Therefore I am just  
>> cautioning the use of these specifications, since they are (i) old  
>> (Windows 2000), (ii) not peer-reviewed, and (iii) not published by  
>> an established standards organization with a clear IPR regime.
>> Sorry to be such a pain, but if the majority of this group is  
>> intend on pursuing the NT PAC path, I would suggest that someone  
>> approaches Microsoft to get clarification about the status of the  
>> spec.
> I don't think trying to add something to the Microsoft PAC is a  
> good idea.
> But if they add something "Level of assurance" to the PAC using it is
> another story.
> Adding another auth_data element of SAML does not require the  
> Microsoft PAC.
>> Best,
>> Gerald
>> Henry B. Hotz wrote:
>>> On Sep 13, 2007, at 12:32 PM, Gerald Beuchelt wrote:
>>>> However, note that there is no patent covenant or even simple  
>>>> licensing terms for the backend infrastructure, so while  
>>>> implementing these data structures might be covered *to the  
>>>> extend that they are documented here), the necessary backend  
>>>> infrastructure might require additional licensing and royalties.
>>> I'm not sure what you mean.  Can you give an example of something  
>>> that might require a license?  In my mind (I'm not a lawyer) an  
>>> implementation is either independent, or not.  Since Microsoft  
>>> doesn't publish actual code for any of this an implementation is  
>>> either pirated from unpublished code, or it's independent, isn't it?

The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government., or

KAML mailing list