Re: [KAML] latest status

"Taylor, Dennis C. (GSFC-750.0)[INDUS CORPORATION]" <> Fri, 18 September 2009 19:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69A5F3A6800 for <>; Fri, 18 Sep 2009 12:30:07 -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 gvLFjuUvtGBZ for <>; Fri, 18 Sep 2009 12:30:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C98633A6837 for <>; Fri, 18 Sep 2009 12:30:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6F65C328094; Fri, 18 Sep 2009 14:30:55 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id n8IJUsKJ031023; Fri, 18 Sep 2009 14:30:54 -0500
Received: from ([]) by ([]) with mapi; Fri, 18 Sep 2009 14:30:55 -0500
From: "Taylor, Dennis C. (GSFC-750.0)[INDUS CORPORATION]" <>
To: "Hotz, Henry B. (JPL-173G)[JPL]" <>, James Ryan <>
Date: Fri, 18 Sep 2009 14:30:54 -0500
Thread-Topic: [KAML] latest status
Thread-Index: Aco4kFs8cpV8zxKJSP2xnz1SIqU5aQAA5Xpg
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-09-18_11:2009-09-17, 2009-09-18, 2009-09-18 signatures=0
Cc: "" <>
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 19:30:07 -0000


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