[ogsa-wg] Draft, Informational, Security Profile

[Frank Siebenlist]

Duane Merrill III wrote:
> ----- Original Message -----
> From: "Frank Siebenlist" <franks at mcs.anl.gov <mailto:franks at mcs.anl.gov>>
>> * Blair mentioned it already, but just to clarify that the embedding of
>> key-info in the EPR allows one to use normal user-certs for ssl/tls
>> servers and to enforce an equivalent authorization on the to-be-expected
>> server's subject(-alt)-name. Section 2.1.i seems to hint at the same in
>> the BSP-core discussion.
>  
>>> ----- Original Message -----
>>> From: "Blair Dillaway" <blaird at microsoft.com
> <mailto:blaird at microsoft.com>>
>>> 1. I have discussed the motivating use cases for OGSA-BSP Core with
>>> Frank Siebenlist. This was developed to support validation of the
> desired
>>> TLS/SSL server where the server cert doesn't contain info corresponding
>>> to the service location. I happen to think standardizing on such a
>>> mechanism may be more important when using message-level security,
>>> but that may require some additional work as you mention.
>  
> 
> Very interesting.  I had no idea that the OGSA BSP-Core was specifically
> motivated for SSL/TLS transport level security.  I had just assumed that
> the profile was primarily addressing an intuitive approach for
> communicating key/certificate information to clients for use in SOAP
> message-level secure commmunication.  (The words "SSL" or "TLS" never
> appear in the document, and "transport" appears once in line 107 in a
> manner that would appear to be descriptive of the OGSA BSP-SC profile,
> rather than the Core profile.) 


I agree that this is not clearly evident from the docs - the idea is
that the BSP-SC profile leverages and depends on the BSP-Core, and not
the other way around - so the BSP-Core should not discuss SSL/TLS.

More use case descriptions would indeed make it more palatable - right
now the legalese is almost unbearable for mere mortals...

-Frank.


> In fact, it seems that the OGSA HPC Basic Profile document made the same
> initial assumption that I did, as it reads:
> 
>     /Note: The OGSA Basic Security Profile 1.0 - Core specification is
>     not used as that addresses the binding of key information to an
>     endpoint reference [in WS-Addressing], which is not relevant when
>     using transport layer security./
> 
> This further evidences the need for more specificity in the BSP-Core
> profile for the intent-of-use of the embedded key (cert) information. 
> (For example, a client may want to see /two/ certificates within the
> endpoint references that it consumes: one to verify the SSL/TLS
> endpoint, and the other to authenticate the individual, possibly-mobile,
> remote resource.)  We would suggest that the OGSA BSP-SC be updated to
> explicitly reflect this interaction with the (proposed updates to the)
> BSP-Core; specifically that there must be agreement between any such
> server subject-(alt-)names in embedded EPR key/cert information that is
> specified for transport endpoint verification.  By doing this, the
> application of these two profiles would explicitly address your original
> tranport security motivations.
>  
> -Duane

-- 
Frank Siebenlist               franks at mcs.anl.gov
The Globus Alliance - Argonne National Laboratory