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

Gerald Beuchelt <> Fri, 14 September 2007 12:16 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IWA6S-0005aw-GI; Fri, 14 Sep 2007 08:16:56 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IWA6R-0005aq-CK for; Fri, 14 Sep 2007 08:16:55 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1IWA6P-0003DA-TF for; Fri, 14 Sep 2007 08:16:55 -0400
Received: from ([]) by (8.13.6+Sun/8.12.9) with ESMTP id l8ECGrUk029251 for <>; Fri, 14 Sep 2007 12:16:53 GMT
Received: from by (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <> (original mail from for; Fri, 14 Sep 2007 06:16:53 -0600 (MDT)
Received: from [] ([]) by (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <>; Fri, 14 Sep 2007 06:16:32 -0600 (MDT)
Date: Fri, 14 Sep 2007 08:16:23 -0400
From: Gerald Beuchelt <>
Subject: Re: [KAML] Re: Chicago bar-BOF summary
In-reply-to: <>
To: "Henry B. Hotz" <>
Message-id: <>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
User-Agent: Thunderbird (Windows/20070728)
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
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: <>, <>

One issue we might run into is the actual character encoding - is there 
a reasonable gurantee that UTF-8 is supported? Thinking along the lines 
of ASN.1 and XER encoding, we might at least want to consider FastInfo 
(ITU-T X.891 - ISO/IEC 24824-1) which is a public standard for encoding 
XML in binary form.

As far as combining multiple authdata tokens go: I can see how this 
could possibly work by adding additional data after the NT PAC. But this 
would require the Windows implementation to ignore data appended after 
the PAC itself - one would have to try this out and see if it breaks 

Other than that, I seems to remember Nico Williams' framework for 
stacking payload on top of the existing Kerberos data. What eve happened 
to this?

BTW: Nico and I had been floating a few ideas about a SAML/GSSAPI 
combination in 2005 to some folks in the SAML world, as well as the 
IETF. Here are some slides describing our ideas in an overview 

Maybe some of that is still recoverable.



Henry B. Hotz wrote:
> 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