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

"Henry B. Hotz" <hotz@jpl.nasa.gov> Mon, 10 September 2007 21:29 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 1IUqp5-0007ZE-AO; Mon, 10 Sep 2007 17:29:35 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUqp4-0007Yx-8Z for kaml@ietf.org; Mon, 10 Sep 2007 17:29:34 -0400
Received: from nmta1.jpl.nasa.gov ([137.78.160.214]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUqp3-00062J-FR for kaml@ietf.org; Mon, 10 Sep 2007 17:29:34 -0400
Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l8ALTStU020969; Mon, 10 Sep 2007 14:29:28 -0700
Received: from [137.78.61.96] (laphotz.jpl.nasa.gov [137.78.61.96]) by xmta1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l8ALTQE0027908; Mon, 10 Sep 2007 14:29:26 -0700
In-Reply-To: <46E1A274.1080600@anl.gov>
References: <46DE5CC1.10204@it.su.se> <8158D751-0EE0-4D58-81DB-549C4A413B68@jpl.nasa.gov> <9B9324ACE4CA354EAF122E7D0E0673B64BDF23@NDMSEVS22.ndc.nasa.gov> <D80F0FFA-D9FF-48F1-B410-75078B40E8D7@jpl.nasa.gov> <46E1A274.1080600@anl.gov>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D208EBD0-1182-49C6-9A6F-B3210C4627E5@jpl.nasa.gov>
Content-Transfer-Encoding: 7bit
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Subject: Re: [KAML] Re: Chicago bar-BOF summary
Date: Mon, 10 Sep 2007 14:29:10 -0700
To: "Douglas E. Engert" <deengert@anl.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: a8a20a483a84f747e56475e290ee868e
Cc: "Taylor, Dennis C. \(GSFC-720.0\)\[INDUS\]" <Dennis.C.Taylor@nasa.gov>, 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 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.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu



_______________________________________________
KAML mailing list
KAML@ietf.org
https://www1.ietf.org/mailman/listinfo/kaml