Re: [KAML] latest status

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  
CORPORATION] wrote:

> 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: http://technet.microsoft.com/en-us/library/dd378897.aspx
>
> 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
> NCAD
>
>> -----Original Message-----
>> From: kaml-bounces@ietf.org [mailto:kaml-bounces@ietf.org] On  
>> Behalf Of
>> Henry B. Hotz
>> Sent: Friday, September 18, 2009 2:41 PM
>> To: James Ryan
>> Cc: kaml@ietf.org
>> 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.
>> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
>>
>>
>>
>> _______________________________________________
>> KAML mailing list
>> KAML@ietf.org
>> https://www.ietf.org/mailman/listinfo/kaml

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