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

[Gerald Beuchelt <[e-mail]>]

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 
anything.

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 
presentation: 
http://www.idealliance.org/proceedings/xml05/slides/beuchelt.pdf

Maybe some of that is still recoverable.

Best,

Gerrt


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.
>>
>> http://samba.org/ftp/unpacked/trunk-cluster/source/libads/authdata.c
>> referes to KERB_VALIDATION_INFO
>>
>>
>>
>>> 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.
> [e-mail], or [e-mail]
>
>

_______________________________________________
KAML mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/kaml