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

["Douglas E. Engert" <[e-mail]>]

Henry B. Hotz wrote:
> 
> 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.  ;-)

Well, I could argue both ways too... If the addition of a LOA group membership
solves your problem, and Microsoft is willing to add it, great, but
unfortunately is a Microsoft only solution.

If one would like to see Kerberos forward on authorization information
that may be in certs or a cert chain, which might be useful to applications
like Sun Access Manager or useful in grid applications, then passing on the
cert chain should be easy.

This would also be useful for anonymous Kerberos, which could accept any
cert from a trusted CA and pass on the cert to the final application,
which could use the cert for authorization.

> 
> 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?"?

What if you need the FASC-N from the cert? the SubjectAltName with
the OID=2.16.840.1.101.3.6.6?


> 
>> 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
> 
> ------------------------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> [e-mail], or [e-mail]
> 
> 
> 
> _______________________________________________
> KAML mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/kaml
> 
> 

-- 

  Douglas E. Engert  <[e-mail]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  [phone]

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