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
- Re: [KAML] Chicago bar-BOF summary Leif Johansson
- [KAML] Re: Chicago bar-BOF summary Henry B. Hotz
- [KAML] Chicago bar-BOF summary Leif Johansson
- RE: [KAML] Chicago bar-BOF summary Josh Howlett
- Re: [KAML] Chicago bar-BOF summary Leif Johansson
- RE: [KAML] Chicago bar-BOF summary Josh Howlett
- Re: [KAML] Re: Chicago bar-BOF summary Tom Scavo
- Re: [KAML] Re: Chicago bar-BOF summary Douglas E. Engert
- Re: [KAML] Re: Chicago bar-BOF summary Douglas E. Engert
- Re: [KAML] Re: Chicago bar-BOF summary Tom Scavo
- Re: [KAML] Re: Chicago bar-BOF summary Henry B. Hotz
- Re: [KAML] Re: Chicago bar-BOF summary Henry B. Hotz
- RE: [KAML] Re: Chicago bar-BOF summary Taylor, Dennis C. (GSFC-720.0)[INDUS]
- Re: [KAML] Re: Chicago bar-BOF summary Douglas E. Engert
- Re: [KAML] Re: Chicago bar-BOF summary Henry B. Hotz
- Re: [KAML] Re: Chicago bar-BOF summary Scott Cantor
- Re: [KAML] Re: Chicago bar-BOF summary Leif Johansson
- Re: [KAML] Re: Chicago bar-BOF summary Henry B. Hotz
- RE: [KAML] Re: Chicago bar-BOF summary Scott Cantor
- Re: [KAML] Re: Chicago bar-BOF summary Leif Johansson
- Re: [KAML] Re: Chicago bar-BOF summary Douglas E. Engert
- Re: [KAML] Re: Chicago bar-BOF summary Henry B. Hotz
- Re: [KAML] Re: Chicago bar-BOF summary Leif Johansson
- Re: [KAML] Re: Chicago bar-BOF summary Henry B. Hotz
- Re: [KAML] Re: Chicago bar-BOF summary Gerald Beuchelt
- Re: [KAML] Re: Chicago bar-BOF summary Henry B. Hotz
- Re: [KAML] Re: Chicago bar-BOF summary Gerald Beuchelt
- Re: [KAML] Re: Chicago bar-BOF summary Douglas E. Engert
- Re: [KAML] Re: Chicago bar-BOF summary Henry B. Hotz
- Re: [KAML] Re: Chicago bar-BOF summary Gerald Beuchelt
- Re: [KAML] Re: Chicago bar-BOF summary Gerald Beuchelt
- Re: [KAML] Re: Chicago bar-BOF summary Douglas E. Engert