[ogsa-wg] Draft, Informational, Security Profile

[Duane Merrill III]

----- Original Message ----- 
From: "Frank Siebenlist" <franks at mcs.anl.gov>
> 
> * 2.2.iii - theoretically, one could use proxy-certs issued on the
> service's authN-key such that there is no round trip required where the
> service has to communicate the newly generated public-key to the client.
> A PC issued on the service's authN-key would then be the equivalent of
> a saml-assertion issued on the service's Id. The advantage of using a PC
> would be that the format and semantics is well defined, while for SAML
> you would need another profile to standardize the equivalent assertion.
> (the GT4.2 trunk includes the code to move the different SAML assertion
> flavors as well as X509ACs in the standardized header elements - thats
> was the easy part - what to do with all the possible assertions on the
> receiving side and how to process them and use them in authZ is left as
> an exercise for the reader... which makes the simplicity of the PC
> approach soon appealing once your head starts spinning...;-) )


Yes.  Theoretically any trust-based credential can be "pre-authorized" for delegation by signing in the delegatee's public AuthN key.  (In fact, we do this for SAML credentials in Genesis II.)  Personally, I am in favor of this "one-way" delegation process; it avoids the round-trip associated with the certificate-signing-request that you mention.  The certificate-signing-request, when performed at the SOAP message level, would require that clients expose listening transport sockets, accept incoming messages, and implement message nonces for correlating incoming certificate-signing-requests with previously-sent outgoing messages.  All of this may be undesirable for complexity, efficiency, firewall, etc. reasons.  (Performing the certificate-signing-request at the SOAP message-level is necessary for per-resource delegation; delegation at the transport-level is not effective for that purpose.)

However, there is a small drawback to this one-way approach to consider.  Under the traditional certificate-signing-request approach, the delegatee can simply "throw-away" the generated private delegation key when it is finished using the delegated credential.  Thus any future compromise of the delegatee would not compromise the credential delegated to it (as the delegation private key no longer exists to be compromised).  In the "one-way" approach, the delegatee can not throw away the delegation private key because it corresponds to its well-known, published AuthN public key.  Therefore the "one-way" approach is slightly more vulnerable to delegatee compromise (assuming that everyone who uses the certificate-signing-request approach "plays nice" and destroys their delegation keys in a timely manner).

An interesting hybrid approach that we are evaluating within Genesis II is to have the delegator generate a new delegation keypair and sign both the new delegation public key as well as the public key of the delegatee into the delegation credential.  Assuming a confidential channel with the delegatee, the delegator sends both the delegation credential and the delegation private key to the delegatee.  (The delegator would then destroy its copy of the delegation private key.)  The delegatee can then be authenticated with the delegation credential by signing its outgoing messages twice: once with its own AuthN private key and again with the delegation private key.  When finished, the delegation private key can be destroyed and the delegation credential is safe from future compromise of the delegatee.  Thus we preserve both the one-way semantic of "pre-authorization" and the marginal benefits of the certificate-signing-request approach where delegatees can be trusted to discard delegation private keys when finished using delegation credentials.  (It is very likely that the common-case will involve limited-lifetime credentials anyway, so any un-enforceable delegation-key-destroying policy would provide marginal benefits at best.)

Of course, delegation credentials are out of scope for our proposed OGSA Basic SOAP Security profile.  The BSSP would ideally be a living document that incorporates external credential profiles (e.g., the security tokens covered in the WSI BSP) as they are developed.  (Developing OGSA delegation credential profiles for X.509 proxy certificates and SAML holder-of-key assertions would be a Good Thing.  Developing OGSA credential profiles for any credential, even if they simply inherit from the WSI BSP would be a Good Thing.)

-Duane








-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20070309/882e0c12/attachment-0001.html