[ogsa-wg] Draft, Informational, Security Profile

[Duane Merrill III]

Sorry, the 2nd to last line in my response should read:

"there must be agreement between the EPR's address field and any such server subject-(alt-)names in embedded EPR key/cert information that is specified for transport endpoint verification"

-Duane
  ----- Original Message ----- 
  From: Duane Merrill III 
  To: Frank Siebenlist ; Blair Dillaway 
  Cc: ogsa-wg at ggf.org 
  Sent: Friday, March 09, 2007 12:28 PM
  Subject: Re: [ogsa-wg] Draft, Informational, Security Profile


  ----- Original Message ----- 
  From: "Frank Siebenlist" <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>
  >> 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.)  

  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20070309/6094fd51/attachment.htm