Re: [KAML] latest status

"Henry B. Hotz" <> Fri, 18 September 2009 21:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 785DC3A67DD for <>; Fri, 18 Sep 2009 14:50:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SwDj+yvYMAms for <>; Fri, 18 Sep 2009 14:50:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F21B73A67F6 for <>; Fri, 18 Sep 2009 14:50:36 -0700 (PDT)
Received: from ( []) by (Switch-3.4.1/Switch-3.3.2mp) with ESMTP id n8ILpUcp014224; Fri, 18 Sep 2009 21:51:30 GMT
Received: from ( []) by (Switch-3.2.6/Switch-3.2.6) with ESMTP id n8ILpSNj016169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Sep 2009 14:51:28 -0700
Message-Id: <>
From: "Henry B. Hotz" <>
To: "Taylor, Dennis C. (GSFC-750.0)[INDUS CORPORATION]" <>
In-Reply-To: <>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 18 Sep 2009 13:58:01 -0700
References: <> <> <>
X-Mailer: Apple Mail (2.936)
X-Source-IP: []
X-AUTH: Authorized
Cc: "" <>, "Hotz, Henry B. \(JPL-173G\)\[JPL\]" <>
Subject: Re: [KAML] latest status
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussions about SAML and Kerberos intersections <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Sep 2009 21:50:38 -0000

Do you see a generalization of that suitable for standardization?

On Sep 18, 2009, at 12:30 PM, Taylor, Dennis C. (GSFC-750.0)[INDUS  

> Henry,
> FYI, about the LoA in the Microsoft PAC part...NASA did make that  
> request about 2 years ago.  We had some follow-up and we asked for  
> the capability to map a certificate issuance OID to a security group  
> dynamically.
> Windows 2008 R2 does now have this capability.  Some information  
> about this is described here:
> I briefly piloted a demo in May with one of the prerelease builds.   
> I was able to map id-fpki-common-authentication (from the PIV Auth  
> certificate) to security group "PIV Authentication LOA 4", a  
> security group of my choosing.  I was then able to create standard  
> Windows ACLs to restrict access to only users that authenticated  
> with the PIV smartcard.
> There are some limitations. Microsoft does not yet have the  
> capability to create ACL logical expressions, e.g. "Launch Control  
> Team" and "PIV Authentication LOA 4".  There are some work-arounds  
> though.
> Dennis Taylor
>> -----Original Message-----
>> From: [] On  
>> Behalf Of
>> Henry B. Hotz
>> Sent: Friday, September 18, 2009 2:41 PM
>> To: James Ryan
>> Cc:
>> Subject: Re: [KAML] latest status
>> On Sep 18, 2009, at 7:13 AM, James Ryan wrote:
>>> I have been unplugged on this topic for a few years.  Could someone
>>> give the latest status?
>>> thanks!!
>> The short answer is that we failed to reach consensus and petered
>> out.  Of course that doesn't mean the issues have gone away.  I'm not
>> sure I recall all the solutions people were proposing any more.   
>> There
>> were some reasonable attempts at summaries near the end of what
>> exchanges did happen on-list.
>> The concept that defined the name of this list was to include a SAML
>> token in a ticket.  I personally opposed that because I thought it
>> undesirable to mix ASN.1 and XML in the same thing.  (It's possible  
>> my
>> objections are Quixotic.)
>> Many (most) of us wanted a way to pass on information from or about
>> the original cert used in a PKINIT exchange.  Probably the simplest
>> proposal of that type was Doug Engert's that the cert itself just be
>> included, but people apparently felt that was excessive, and/or
>> excessively distant from the information desired.
>> My own desire was for a way to label a ticket according to the US
>> Government level of assurance that was used to acquire it.  A  
>> standard
>> mechanism ought to be more general than a US standard of course.
>> Unfortunately, that created unwanted complexities in defining what
>> ought to be in the ticket, if it wasn't necessarily a US LOA.
>> The Microsoft PAC was not considered a good basis for a solution, but
>> everyone wanted to remain compatible with it if it was present.
>> Off-list I have second- or third-hand information (unreliable
>> information in other words) that NASA asked Microsoft to include the
>> US LOA in the PAC as a dynamic group membership, and they agreed.  I
>> also have possibly-contradictory information that Microsoft told NASA
>> to work through the IETF and the Kerberos Consortium to define how  
>> the
>> LOA information should be handled and they would conform to and
>> implement whatever was agreed on.
>> Absent a better consensus, I proposed that we create a framework
>> document covering how multiple representations of authorization data
>> should coexist and their degree of consistency.  There did not seem  
>> to
>> be any interest.
>> I think there is interest in solving the authorization problem in a
>> way that scales better than the MS PAC.  There's interest on
>> Microsoft's part as well.  Nobody's come up with a solution that
>> enough people find attractive though.
>> ------------------------------------------------------
>> The opinions expressed in this message are mine,
>> not those of Caltech, JPL, NASA, or the US Government.
>>, or
>> _______________________________________________
>> KAML mailing list

The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government., or