Erik, thanks for the reply and questions. The situations that I describe for comparison are derived from automated grid processing environments, in which it is not unusual to have tens of thousands of processes start at once and also to need a very fast locally-based system for authorization based on strong identity.
The classic grid security infrastructure (GSI) works by use of limited-lifetime extended attribute certificate proxies obtained in advance of the operation from authorization servers operated by virtual organizations (VOs). Authorization occurs locally, based on a pre-defined list of DNs kept up to date out of band to establish membership in a VO. To make this work, a certificate can be obtained from any CA within the trust network, but must be registered ahead of use into the VO membership server (called a VOMS server) to establish that the DN of that certificate is in the authorized list. Prior to use in an X.509 secured environment, the user obtains a limited-lifetime proxy by presenting the certificate to the VOMS server and getting back a proxy containing the EAC fields. When the proxy is presented to the end-point of use, the list of authorized DNs for that proxy is checked, along with the validity of the EAC fields. This allows a cryptographically strong assurance that the DN is in the authorized list for operations on that endpoint. Subtleties that have evolved over time allow expression of groups and roles to be carried by the proxy, so that a given certificate by itself can be associated with different operations at different end points. Thus not only membership in the VO, but what that particular DN is allowed to assert that it can do, can all be controlled with very fast local verification of authorization based on the proxy presented. Overall this is essentially as fast as presenting a straight X.509 certificate, but allows much finer control over local authorization for particular operations by that DN. I think it is one option among many that might work in your environment. There are also options in which the proxy is generated and/or held on behalf of the user by an intermediary server, called a MyProxy server, that can be deployed in various environments to simplify the proxy operations on behalf of a certificate holder (either human or automated); and there are also options in which the entire X.509 infrastructure can be handled automatically or tied into other secure identity systems, but the above captures the basic workflow with regard to how membership and local authorization can be handled quickly through the X.509 components. In point of practice, most local authorization servers communicate with the resources in their vicinity using XACML over SAML to handle local assertions at speed, which works well in environments up to many tens of thousands of local relying resources. The communication between these local authorization servers and the central VOMS server to update membership lists is also done securely at low update rates (typically a few to many times per day) to synchronize the DNs, groups and roles for the VO membership lists. A starting point for learning more on this might be http://www.ogf.org/documents/GFD.78.pdf -- the Grid Security Infrastructure Message Specification. You may also wish to read http://www.ogf.org/documents/GFD.189.pdf -- Relying Party Defined Namespace Constraints Policies in a Policy Bridge PKI Environment, http://www.ogf.org/documents/GFD.125.pdf -- the Grid Certificate Profile (shortly to be revised to GFD.225 with recent updates), and http://www.ogf.org/documents/GFD.182.pdf -- the VOMS Attribute Certificate Format. These are just my opinions but are intended to answer your questions and I hope will provide background for my suggestion that a local authorization system based on strong authentication can work to meet your needs in a distributed environment. Feel free to contact me offline and best regards, Alan On Aug 6, 2014, at 11:19 AM, Erik Andersen <[email protected]<mailto:[email protected]>> wrote: Hi Alan, Thanks for your comments. My proposal is a very initial proposal. I was just eager to see reaction to the general approach. I has primarily been concerned with the case where a RP only have 1-2 ms to validate a received a PDU, meaning that the validation has to happen a thousand times faster than in a traditional Web environment. I will be very happy to receive some of the solutions you have seen work in practice. I am always open to new ideas. Kind regards, Erik Fra: Sill, Alan [mailto:[email protected]] Sendt: 31. juli 2014 23:17 Til: Erik Andersen Cc: Sill, Alan; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Emne: Re: [pkix] X.509 whitelist proposal Erik, With the desire to wind this discussion back to its actual content and avoid for the present further discussion of procedures, let me say that the use case proposed is a familiar one in the world of extended use of PKI as an authentication piece of access control systems in distributed infrastructure environments. The solution invariably is to implement a separate authorization layer that can work with the existing certificate infrastructure, which is out or scope as a work item for any of the proposed groups. My personal belief is that this is not worth pursuing in its present form. I would be happy, off-list or on an individual basis, to pass on some of the solutions that I have seen work in practice in distributed computational, storage and other related control settings, some of which can be achieved within the existing X.509 settings through the use, for example, of time limited or otherwise membership-limited extended attribute certificates. My suggestion, with great respect and due deference to its proposers, is to drop the referenced proposal until exploration of appropriate authorization technologies has been done and again offer to have that discussion off these lists or on a different one. Alan Sill, TTU VP of Standards, Open Grid Forum On Jul 18, 2014, at 12:49 AM, Tony Rutkowski <[email protected]<mailto:[email protected]>> wrote: Hi Steve, The note below was distributed earlier on the ITU-T SG17 sub-group Q11/17 list by the group's rapporteur. It might be useful to gauge industry reaction in IETF and CA/B Forum venues. Note that although the document appears on an ITU-T template, it has not been submitted. In addition, although the source is indicated as "Denmark," it is not apparent that the source is any other than than the rapporteur himself, who is identified as the contact. Lastly, although the note asserts that "IEC TC57 WG15 (smart grid security) has requested the inclusion of whitelist support in X.509," there is no apparent liaison to this effect. --tony -------- Original Message -------- Subject: [T17Q11] X.509 whitelist support Date: Thu, 17 Jul 2014 14:43:30 +0200 From: Erik Andersen <[email protected]><mailto:[email protected]> To: Directory list <[email protected]><mailto:[email protected]>, SG17-Q11 <[email protected]><mailto:[email protected]> CC: SG17-Q10 <[email protected]><mailto:[email protected]> IEC TC57 WG15 (smart grid security) has requested the inclusion of whitelist support in X.509. A preliminary proposal for such a feature may be found as http://www.x500standard.com/uploads/extensions/whitelistInX509.pdf The feature may in some way be combined with the trust broker concept, which probably will involve a number of changes. As it is quite important that we have workable solution, any comment is welcome. I hope you will find the time to review the proposal before it is submitted to ITU-T. Kind regards, Erik <whitelistInX509.pdf>_______________________________________________ pkix mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/pkix
_______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
