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

["Henry B. Hotz" <[e-mail]>]

On Sep 6, 2007, at 1:14 PM, Douglas E. Engert wrote:

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

Yeah, it's NASA, not JPL/Caltech, that's asking for the capability  
ATM.  The NASA PIV infrastructure solution is a bit more AD-centric  
than ours (as currently planned).

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

As I understand it NASA asked Microsoft to add a PAC-like attribute  
that explicitly listed the 800-63 assurance level.  MS said no, but  
they would implement a similar capability if it passed the standards  
process.  This is pure rumor, and not binding on Microsoft you  
understand.

We've both said this is a concern, now, but I think we can put it  
aside for the time being.

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

For this list, let me reiterate my feelings:  speaking for myself, I  
agree with you.  The fact that X509 and Kerberos share ASN1 as  
infrastructure is part of what made it possible to implement so much  
X509 functionality in Heimdal.  If we shift to XML encoding for SAML  
data then we are adding significantly to the infrastructure needed to  
provide a complete solution.  If we just forward the original cert,  
then it provides the necessary information, but doesn't require any  
additional infrastructure (even if we need to parse extra cert  
attributes).

Question:  Is it possible to create valid SAML tokens in XER?

Now I can speculate as to what JPLs position might be.  There are a  
significant number of developers in at least two organizations that  
are really heavy into all the SOA/XML services stuff.  We also have  
an official rep to OASIS.  I suspect that those guys would strongly  
advocate using real SAML tokens.  They probably have some use cases  
that would benefit from SAML-in-Kerberos.

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

Does anyone have any use cases that demonstrate a SAML (KAML)  
solution is better/easier than just including the cert?  It's a  
classic question of how much processing do you put in the server vs  
the client.  A pre-evaluated SAML assertion should be simpler for the  
client, but would prohibit unanticipated uses of the original  
certificate data.

My own use case is a bit degenerate.  I think if PKINIT was used to  
get the ticket then I'm OK for medium-level authenticated access.  I  
could use some API improvements to make it easier to check that, but  
I don't actually think I need any protocol extensions yet.

> 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

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