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

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.

<snip>

        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;
    } KERB_VALIDATION_INFO;

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

</snip>

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.

Best,

Gerald

Henry B. Hotz wrote:
> Jeffrey Altman just posted a link on the krbdev list.  I guess it's no 
> longer even nominally proprietary.
>
> http://msdn.microsoft.com/library/en-us/dnkerb/html/MSDN_PAC.asp
>
> 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.
> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
>
>
>
> _______________________________________________
> KAML mailing list
> KAML@ietf.org
> https://www1.ietf.org/mailman/listinfo/kaml