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

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

There are a few reasons I have not commented on this.

One is that NASA is the one concerned, but other agencies will have
the same problem. Good to see Henry responded.

Another is the concern Henry has below with Microsoft, i.e. getting
them to add anything we do to their KDC.

A third is I am not sure if SAML is the way to do this. I am not saying
it is not a good idea, but it may be complicated for the immediate problem.

The immediate problem is with the use of a PIV smartcard, and how to
prove to the service that it was used for the authentication. In addition
the certificate might contain additional information that is not of use
to the KDC, but is needed by the service. For example the FASC-N.

So in the case of PKINIT, I would like to see the KDC pass on the
certificate.

In a more general case, if a proxy certificate chain was used  (RFC 3820)
pass on the chain as well. A proxy certificate may have a ProxyPolicy:
    "The proxyPolicy field specifies a policy on the use of this
    certificate for the purposes of authorization."

The ProxyPolicy may not have any relevance for the KDC that is doing
authentication, but may for the final service which is doing the authorization.

The approach of passing on the certificate (and chain) keeps changes
to a minimum in the KDC.  Some may say that this emasculates Kerberos as
it is just passing on X509, but thats what makes it look so attractive,
it keeps the KDC changes and policy decisions to a minimum, and passes
on any additional authorization data the user/cert may have provided
to the final service.


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

-- 

  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