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

"Henry B. Hotz" <hotz@jpl.nasa.gov> Fri, 07 September 2007 01:23 UTC

Return-path: <kaml-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITSZ2-0007oG-Tr; Thu, 06 Sep 2007 21:23:16 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITSZ1-0007o9-HF for kaml@ietf.org; Thu, 06 Sep 2007 21:23:15 -0400
Received: from nmta1.jpl.nasa.gov ([137.78.160.214]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITSZ0-0006Ak-Gv for kaml@ietf.org; Thu, 06 Sep 2007 21:23:15 -0400
Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111]) by nmta1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l871N9fg029116; Thu, 6 Sep 2007 18:23:09 -0700
Received: from [137.78.61.96] (laphotz.jpl.nasa.gov [137.78.61.96]) by xmta3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l871N7i8018971; Thu, 6 Sep 2007 18:23:07 -0700
In-Reply-To: <9B9324ACE4CA354EAF122E7D0E0673B64BDF23@NDMSEVS22.ndc.nasa.gov>
References: <46DE5CC1.10204@it.su.se> <8158D751-0EE0-4D58-81DB-549C4A413B68@jpl.nasa.gov> <9B9324ACE4CA354EAF122E7D0E0673B64BDF23@NDMSEVS22.ndc.nasa.gov>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D80F0FFA-D9FF-48F1-B410-75078B40E8D7@jpl.nasa.gov>
Content-Transfer-Encoding: 7bit
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Subject: Re: [KAML] Re: Chicago bar-BOF summary
Date: Thu, 6 Sep 2007 18:22:54 -0700
To: "Taylor, Dennis C. (GSFC-720.0)[INDUS]" <Dennis.C.Taylor@nasa.gov>
X-Mailer: Apple Mail (2.752.3)
X-Source-IP: laphotz.jpl.nasa.gov [137.78.61.96]
X-Source-Sender: hotz@jpl.nasa.gov
X-AUTH: Authorized
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
Cc: kaml@ietf.org
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

On Sep 6, 2007, at 3:24 PM, Taylor, Dennis C. (GSFC-720.0)[INDUS] wrote:

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

So you just want another group added to the PAC to indicate whether  
the PIV card was used or not?  This would not seem to require any  
protocol changes, just a PAC implementation update.

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

So you're preferring kdc-determined SAML assertions (if the above  
isn't sufficient);  Doug's preferring just forwarding the original  
cert;  and I'm voting both ways at once.  ;-)

I don't suppose you have a use case that doesn't just boil down to  
"did they use the PIV card to get these credentials?"?

> I am just tied up a bit--apologies in advance for being quiet.
>
> Dennis Taylor
> NCAD Project
> Ph: 301 286-4290; Fax: 301 286-2086
>
>
>> -----Original Message-----
>> From: Henry B. Hotz [mailto:hotz@jpl.nasa.gov]
>> Sent: Thursday, September 06, 2007 3:30 PM
>> To: kaml@ietf.org
>> 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 <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

------------------------------------------------------------------------
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://www1.ietf.org/mailman/listinfo/kaml