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

"Henry B. Hotz" <hotz@jpl.nasa.gov> Fri, 14 September 2007 01:58 UTC

Return-path: <kaml-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW0Rf-00006D-8g; Thu, 13 Sep 2007 21:58:11 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW0Rd-000066-Md for kaml@ietf.org; Thu, 13 Sep 2007 21:58:09 -0400
Received: from nmta.jpl.nasa.gov ([137.78.160.108] helo=nmta3.jpl.nasa.gov) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW0Rd-00037f-1r for kaml@ietf.org; Thu, 13 Sep 2007 21:58:09 -0400
Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111]) by nmta3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l8E1w4E3023553; Thu, 13 Sep 2007 18:58:04 -0700
Received: from [137.78.61.96] (laphotz.jpl.nasa.gov [137.78.61.96]) by xmta3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l8E1w2GB007257; Thu, 13 Sep 2007 18:58:02 -0700
In-Reply-To: <46E9AA7B.4040508@anl.gov>
References: <46DE5CC1.10204@it.su.se> <8158D751-0EE0-4D58-81DB-549C4A413B68@jpl.nasa.gov> <9B9324ACE4CA354EAF122E7D0E0673B64BDF23@NDMSEVS22.ndc.nasa.gov> <D80F0FFA-D9FF-48F1-B410-75078B40E8D7@jpl.nasa.gov> <46E1A274.1080600@anl.gov> <D208EBD0-1182-49C6-9A6F-B3210C4627E5@jpl.nasa.gov> <46E79162.2010402@it.su.se> <C5437591-6811-4087-9C89-D7959A6872D4@jpl.nasa.gov> <46E9905E.3040404@sun.com> <370D0C3F-8DBD-4FCD-82EA-D6155EB06F41@jpl.nasa.gov> <46E9A3DB.4040608@sun.com> <46E9AA7B.4040508@anl.gov>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <46C580CE-5E22-4687-AD3C-AE198FE43156@jpl.nasa.gov>
Content-Transfer-Encoding: 7bit
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Subject: Re: [KAML] Re: Chicago bar-BOF summary
Date: Thu, 13 Sep 2007 18:57:59 -0700
To: "Douglas E. Engert" <deengert@anl.gov>
X-Mailer: Apple Mail (2.752.3)
X-Source-IP: laphotz.jpl.nasa.gov [137.78.61.96]
X-Source-Sender: hotz@jpl.nasa.gov
X-AUTH: Authorized
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: kaml@ietf.org
X-BeenThere: kaml@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about SAML and Kerberos intersections <kaml.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/kaml>, <mailto:kaml-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/kaml>
List-Post: <mailto:kaml@ietf.org>
List-Help: <mailto:kaml-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/kaml>, <mailto:kaml-request@ietf.org?subject=subscribe>
Errors-To: kaml-bounces@ietf.org

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.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu



_______________________________________________
KAML mailing list
KAML@ietf.org
https://www1.ietf.org/mailman/listinfo/kaml