Subject: [KAML] latest status

From: James Ryan <[email-masked]>
Date: Fri, 18 Sep 2009 10:13:14 -0400

I have been unplugged on this topic for a few years.  Could someone give the
latest status?

thanks!!

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 18 Sep 2009 11:41:00 -0700

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.
[email-masked], or [email-masked]

---

From: "Taylor, Dennis C. (GSFC-750.0)[INDUS CORPORATION]" <[email-masked]>
Date: Fri, 18 Sep 2009 14:30:54 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Henry B. Hotz
> Sent: Friday, September 18, 2009 2:41 PM
> To: James Ryan
> Cc: [email-masked]
> Subject: Re: [KAML] latest status
> 
> _______________________________________________
> KAML mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kaml

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 18 Sep 2009 13:58:01 -0700

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
>

---

From: Luke Howard <[email-masked]>
Date: Sat, 19 Sep 2009 20:05:09 +0200

> enough people find attractive though.

I'm interested in this, when I get some cycles to work on it.  The GSS  
naming extensions and S4U projects recently committed to MIT will  
help, also I've created a couple of placeholder projects at:

	http://k5wiki.kerberos.org/wiki/Projects/SAMLInKerberos
	http://k5wiki.kerberos.org/wiki/Projects/KerberosInSAML

Last I heard from MS (earlier this week), they are moving towards  
claims-based authorisation but are undecided whether they will support  
claims with "legacy" services such as the file server, and thus  
whether they will support claims in the PAC. (This statement was  
couched in very vague terms, so I might be misinterpreting.)

Their whitepapers on Geneva are worth reading, too:

http://www.microsoft.com/downloads/details.aspx?FamilyID=9ca5c685-3172-4d8f-81cb-1a59bdc9f7e3&displaylang=en

-- Luke

---

From: "Josh Howlett" <[email-masked]>
Date: Mon, 21 Sep 2009 10:09:38 +0100

http://www.kerberos.org/software/kerbweb.pdf 

"The authors of this paper have drawn upon their combined experience
with supporting large Kerberos
deployments, writing and developing web-based identity protocols, and
integrating heterogeneous
authentication services in order to produce this paper. Thus the views
expressed herein are not necessarily
those of the MIT Kerberos Consortium or its members.

In this paper we outline the evolution of Web Identity and Services and
describe the issues surrounding this
complex landscape. These issues are captured within a set of more
specific requirements that are deemed
necessary to satisfy the relevant stakeholders; these requirements are
then framed within the context of some
general use cases. We then propose and describe a number of activities
that leverage Kerberos to realize
these improvements, and present an overall strategy and architectural
model for working towards a more
cohesive and widely deployed Kerberos-based Web authentication
infrastructure."

josh.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of James Ryan
> Sent: 18 September 2009 15:13
> To: [email-masked]
> Subject: [KAML] latest status
> 
> I have been unplugged on this topic for a few years.  Could 
> someone give the latest status?
>  
> thanks!!
> 

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG