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

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

On Sep 7, 2007, at 12:11 PM, Douglas E. Engert wrote:

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

I would be happier with this solution if the PAC format were at least  
an informational RFC.  The format is now well known and widely  
implemented, but AFAIK the description document isn't available  
without all the old warnings.  People have also found in practice  
that the PAC scales to an unpleasant size in many real deployments.

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

Isn't there a conceptual mis-match between "anonymous Kerberos" and  
including the cert that actually identifies the person anyway?  Not  
sure I understand your use case.

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

We don't use the FASC-N, but the point that a cert may include  
information that you don't know that you need until later is still  
valid.  Just because I don't currently see a need for anything beyond  
whether a smart card was used or not, doesn't mean there isn't such a  
need.  In fact I rather suspect there is.  That would argue for  
including the cert.

OTOH there is probably also a need for some information that's not in  
the cert (which is created by NASA), but *is* in our institutional  
LDAP server.  That would argue that some pre-crunched authZ data is  
sufficient since other information is needed for the authorization  
decision anyway.

----

Let me but this back in more non-US-Gov't terms.

What can we say about what authorization information should be in the  
Kerberos ticket?  Speaking off the top of my head (so I may be wrong)  
I would say:

1) The certificate organization may provide information which the  
Kerberos organization does not believe is useful, but which the  
application service's organization wants.  The Kerberos service needs  
to provide essentially everything from the cert.

2) The application service's organization may want to use information  
from some 4th or 5th party's organization in addition to control  
access.  There will be many deployments that need local  
customization.  There are at least two, and frequently 4 or more  
sources of authorization information.  It's infeasible (and maybe  
literally impossible) to provide all information that might be needed.

3) The fragmentation/federation of information needed for the  
complete authorization decision precludes an efficient centralized  
decision.  However providing what information is centrally available  
in the Kerberos ticket is more efficient than requiring a separate  
query for that information.

I think these design comments don't fully resolve things in my mind,  
but I will now vote for just including the user's PKINIT cert (and  
optionally the cert chain) as authorization info.  That's w.r.t. the  
use cases I have in front of me.  I still think there are other use  
cases though.
------------------------------------------------------------------------
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