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

["Taylor, Dennis C. (GSFC-720.0)[INDUS]" <[e-mail]>]

Henry,

I am monitoring the list and can speak to the other NASA perspective,
perhaps sans JPL.  Sorry for the slow response, we are mostly all tied
up around activities related to card issuance--deadline this Oct.

NASA is AD centric in our plans for authentication.  It is the majority
case.  The other method is Sun Access Manager.  It is unclear whether
authentication within AM will be TLS to the card, SPNEGO to AD, or both.

I am back to speaking with Microsoft on getting a representation of the
LoA for authentication to be stored in their PAC.  This may be the best
near term approach for us.  NASA has approximately 5000 applications.
If LoA needs for many of them can be meet by a simple ACL addition then
that's the best path for us.  Around that path is the question about how
LoA is represented.  We think security group representation is probably
best...there are still issues about when, in the life an authentication
transaction, the group logic is implemented.

But this is all internal looking--long term I know we have to look at
external partners.  So, I am interested in the longer term approaches
concerning SAML, or having PKINIT populate the certificate in the TGT.
But of these, in general we don't want our owners/developers of the 5000
applications going anywhere near X.509 or other mechanisms...we will
probably internalize things, one way or another, so that some form of
group membership is available for inspection, and try to keep LoA
enforcement as simple as it can be.

I am just tied up a bit--apologies in advance for being quiet.

Dennis Taylor
NCAD Project
Ph: 301 286-4290; Fax: [phone]


> -----Original Message-----
> From: Henry B. Hotz [mailto:[e-mail]]
> Sent: Thursday, September 06, 2007 3:30 PM
> To: [e-mail]
> Subject: [KAML] Re: Chicago bar-BOF summary
> 
> Do we have anyone else from NASA on this list?  JPL is an FFRDC, not
> a civil service lab.  We may have different perspectives on this.
> Also I know some of the push to do this came from other NASA concerns.
> 
> We want to create applications that may specifically require that the
> user authenticated with a smart card.  Based on NIST SP800-63 they
> may be medium-security applications where the card may have been used
> to get Kerberos credentials, or they may be high-security
> applications where the card has to be in the reader and used
> directly.  The bulk of the applications we need to worry about will
> be "medium".
> 
> I'm not sure I can comment on item 3.  I think that "we" think we can
> configure Sun Access Manager to do what we need there, and new
> standards are not immediately necessary.
> 
> I see 1, and 2 as not being necessarily different.  I think our goal
> is to come up with a way to represent authorization information, like
> what 800-63 specifies, in a portable, extensible manner.  I will take
> it on faith (for now) that SAML has the necessary flexibility for the
> job.  So what are the issues that need discussing?
> 
> Or do we just start discussing how to put SAML tokens into the
> authorization data field and what constraints we impose on how the
> tokens are encrypted/validated.
> 
> I need to know that there is an API path for getting that information
> out of the ticket and inspecting/querying it.  I also need to know
> that will be possible on *nix as well as Windows.  That means that
> whatever we propose needs to get implemented in at least one of the
> open-source Kerberos packages as well as in Windows.  That would seem
> to drag the GSSAPI folks back into the discussion at some point.  If
> we come up with a standard that solves NASA's problem, then I think
> Microsoft is likely to implement it.
> 
> Begin message:
> 
> > From: Leif Johansson <[e-mail]>
> > Date: September 5, 2007 12:37:37 AM PDT
> > To: "Henry B. Hotz" <[e-mail]>
> > Subject: [Fwd: [KAML] Chicago bar-BOF summary]
> >
> > you didn't see this?
> >
> >     cheers Leif
> >
> > From: Leif Johansson <[e-mail]>
> > Date: August 22, 2007 1:10:31 PM PDT
> > To: [e-mail]
> > Subject: [KAML] Chicago bar-BOF summary
> >
> >
> >
> > Hello and welcome to the kaml list. This list is the result of a
> > bar-BOF
> > at the last IETF meeting in Chicago were a few SAMListas and well-
> > known members of the kerberos wg met and tried to come up with a
> > list of use-cases which might involve both SAML and kerberos.
> >
> > Let me first say that we are clearly talking about several rather
> > loosely connected use-cases. This is probably not a complete
> > list of things we discussed in Chicago and I hope everyone will
> > contribute stuff of their own.
> >
> > The use-cases:
> >
> > 1. Was a smart-card used?
> >
> > This is my interpretation of problems posed by Douglas Engert
> > of ANL and Henry Hotz of Nasa.
> >
> > The problem is to determine exactly how authentication was done
> > at a relying party, for instance if pkinit with a smart-card was
used.
> > In general the RP may be at the end of a chain of (say) clients
using
> > a gssapi-based protocol with credentials delegation, for instance a
> > SOAP-based service  sitting behind a web-application, both using
> > NTLM/Negotiate for authentication. In this case the RP has no way
> > to make decisions about how the initial authentication was done.
> >
> > In SAML parlance this may be framed both in terms of the concept
> > of Level of Assurance and the SAML Authentication Context.
> >
> > It seems clear that any analysis of this use-case would need to span
> > both Kerberos and GSS-API. In kitten there has been discussion
> > about how to represent authz-data. This would clearly be related.
> >
> > 2. The standarized PAC
> >
> > An AD domain controller includes data about the groups a user is
> > a member of in the PA-DATA field of the KDC-REP. A generalization
> > of this concept might be to include a SAML authentication response
> > in the PA-DATA. This could be used together with anonymous
> > kerberos to control which identity information is made available
> > to the RP.
> >
> > 3. WebSSO kerberos n-tier.
> >
> > A web-application using the SAML Web SSO profile needs a kerberos
> > ticket for accessing kerberized backend services. This kerberos
ticket
> > needs to be produced by the Identity Provider and made available to
> > the Relying Party (or Service Provider).
> >
> > Hope this is enough to get things started. I know the smart-card
use-
> > case was discussed on the heimdal list (although possibly not in the
> > generality I presented above). Other use-cases have been discussed
> > on other lists.
> >
> >        Cheers Leif
> >
> > _______________________________________________
> > KAML mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/kaml
> >
> >
> 
> 
> _______________________________________________
> KAML mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/kaml

_______________________________________________
KAML mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/kaml