[KAML] Re: Chicago bar-BOF summary

"Henry B. Hotz" <hotz@jpl.nasa.gov> Thu, 06 September 2007 19:30 UTC

Return-path: <kaml-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITN3I-0000WX-5O; Thu, 06 Sep 2007 15:30:08 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITN3H-0000WO-5s for kaml@ietf.org; Thu, 06 Sep 2007 15:30:07 -0400
Received: from nmta.jpl.nasa.gov ([] helo=nmta1.jpl.nasa.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITN3F-0000CM-Mc for kaml@ietf.org; Thu, 06 Sep 2007 15:30:07 -0400
Received: from xmta2.jpl.nasa.gov (xmta2.jpl.nasa.gov []) by nmta1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l86JU3rl011580 for <kaml@ietf.org>; Thu, 6 Sep 2007 12:30:03 -0700
Received: from [] (laphotz.jpl.nasa.gov []) by xmta2.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l86JU2hh014441 for <kaml@ietf.org>; Thu, 6 Sep 2007 12:30:02 -0700
Mime-Version: 1.0 (Apple Message framework v752.3)
References: <46DE5CC1.10204@it.su.se>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <8158D751-0EE0-4D58-81DB-549C4A413B68@jpl.nasa.gov>
Content-Transfer-Encoding: 7bit
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Date: Thu, 6 Sep 2007 12:29:48 -0700
To: kaml@ietf.org
X-Mailer: Apple Mail (2.752.3)
X-Source-IP: laphotz.jpl.nasa.gov []
X-Source-Sender: hotz@jpl.nasa.gov
X-AUTH: Authorized
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
Subject: [KAML] Re: Chicago bar-BOF summary
X-BeenThere: kaml@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about SAML and Kerberos intersections <kaml.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/kaml>, <mailto:kaml-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/kaml>
List-Post: <mailto:kaml@ietf.org>
List-Help: <mailto:kaml-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/kaml>, <mailto:kaml-request@ietf.org?subject=subscribe>
Errors-To: kaml-bounces@ietf.org

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 <leifj@it.su.se>
> Date: September 5, 2007 12:37:37 AM PDT
> To: "Henry B. Hotz" <hotz@jpl.nasa.gov>
> Subject: [Fwd: [KAML] Chicago bar-BOF summary]
> you didn't see this?
>     cheers Leif
> From: Leif Johansson <leifj@it.su.se>
> Date: August 22, 2007 1:10:31 PM PDT
> To: kaml@ietf.org
> 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
> KAML@ietf.org
> https://www1.ietf.org/mailman/listinfo/kaml

KAML mailing list