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

Gerald Beuchelt <> Thu, 13 September 2007 19:32 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IVuQN-0006j4-Fa; Thu, 13 Sep 2007 15:32:27 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IVuQM-0006iv-1l for; Thu, 13 Sep 2007 15:32:26 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1IVuQK-0001Fp-C5 for; Thu, 13 Sep 2007 15:32:25 -0400
Received: from ([]) by (8.13.6+Sun/8.12.9) with ESMTP id l8DJWND2021833 for <>; Thu, 13 Sep 2007 19:32:23 GMT
Received: from by (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <> (original mail from for; Thu, 13 Sep 2007 13:32:23 -0600 (MDT)
Received: from [] by (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <>; Thu, 13 Sep 2007 13:32:12 -0600 (MDT)
Date: Thu, 13 Sep 2007 15:32:46 -0400
From: Gerald Beuchelt <>
Subject: Re: [KAML] Re: Chicago bar-BOF summary
In-reply-to: <>
To: "Henry B. Hotz" <>
Message-id: <>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
References: <> <> <> <> <> <> <> <>
User-Agent: Thunderbird (Windows/20070728)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8
Cc: "Taylor, Dennis C. \(GSFC-720.0\)\[INDUS\]" <>,
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: <>, <>
Content-Type: multipart/mixed; boundary="===============1400395595=="

Yes, this has been out for a while. If I remember correctly, they even 
posted a document that describes all the holes in the PAC that were not 
covered by this article or the old (expired) draft.


        PAC Credential Information (PAC_LOGON_INFO)

    PAC_INFO_BUFFERs of type PAC_LOGON_INFO contain the credential
    information for the client of the Kerberos ticket. The data itself
    is contained in a KERB_VALIDATION_INFO structure, which is NDR
    encoded. The output of the NDR encoding is placed in the
    PAC_INFO_BUFFER structure of type PAC_LOGON_INFO.

    typedef struct _KERB_VALIDATION_INFO {
        FILETIME Reserved0;
        FILETIME Reserved1;
        FILETIME KickOffTime;
        FILETIME Reserved2;
        FILETIME Reserved3;
        FILETIME Reserved4;
        UNICODE_STRING Reserved5;
        UNICODE_STRING Reserved6;
        UNICODE_STRING Reserved7;
        UNICODE_STRING Reserved8;
        UNICODE_STRING Reserved9;
        UNICODE_STRING Reserved10;
        USHORT Reserved11;
        USHORT Reserved12;
        ULONG UserId;
        ULONG PrimaryGroupId;
        ULONG GroupCount;
        [size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds;
        ULONG UserFlags;
        ULONG Reserved13[4];
        UNICODE_STRING Reserved14;
        UNICODE_STRING Reserved15;
        PSID LogonDomainId;
        ULONG Reserved16[2];
        ULONG Reserved17;
        ULONG Reserved18[7];
        ULONG SidCount;
        [size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids;
        PSID ResourceGroupDomainSid;
        ULONG ResourceGroupCount;
        [size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP ResourceGroupIds;

    Reserved fields are not defined in this document and are not used in
    the construction of access control tokens.


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.



Henry B. Hotz wrote:
> Jeffrey Altman just posted a link on the krbdev list.  I guess it's no 
> longer even nominally proprietary.
> On Sep 12, 2007, at 12:12 AM, Leif Johansson wrote:
>>> I would be happier with this solution if the PAC format were at least
>>> an informational RFC.  The format is now well known and widely
>>> implemented, but AFAIK the description document isn't available
>>> without all the old warnings.  People have also found in practice that
>>> the PAC scales to an unpleasant size in many real deployments.
>> What we are trying to do here is probably a bit more general than PAC 
>> which afaik contains information about group membership. By 
>> comparison a SAML attribute assertion is far more portable, based on 
>> published standards and equiped with more expressive power. In 
>> addition SAML is a very short stretch for MSFT to implement at least 
>> technically.
>>     Cheers Leif
> ------------------------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
>, or
> _______________________________________________
> KAML mailing list
KAML mailing list