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

"Douglas E. Engert" <deengert@anl.gov> Mon, 17 September 2007 15:05 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 1IXI9t-00089Y-7c; Mon, 17 Sep 2007 11:05:09 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXI9r-00089S-B8 for kaml@ietf.org; Mon, 17 Sep 2007 11:05:07 -0400
Received: from mailhost.anl.gov ([130.202.113.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXI9q-0000M4-NZ for kaml@ietf.org; Mon, 17 Sep 2007 11:05:07 -0400
Received: from mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id 4545DA7; Mon, 17 Sep 2007 10:05:06 -0500 (CDT)
Received: from [127.0.0.1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id 2E3CBA2; Mon, 17 Sep 2007 10:05:06 -0500 (CDT)
Message-ID: <46EE97A1.5070205@anl.gov>
Date: Mon, 17 Sep 2007 10:05:05 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Subject: Re: [KAML] Re: Chicago bar-BOF summary
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> <46C580CE-5E22-4687-AD3C-AE198FE43156@jpl.nasa.gov>
In-Reply-To: <46C580CE-5E22-4687-AD3C-AE198FE43156@jpl.nasa.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
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


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.

Yes. RFC 4120 section 7.5.4 defines the Authorization Data Types.
There are OSF-DCE(64) SESAME(65), AD_OSF_DCE_PKI_CERTID(66)
AD_WIN2K_PAC(128) and AD_ETYPE_NEGOTAION(129). Others can be added
but the Authorization Data Types are not listed in IANA.

The PAC (128) is wrapped in a AD_IF_RELEVANT(1) which implies it is
optional.

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

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

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