[ogsa-wg] Strawman "OGSA Express Authentication Profile" Security Profiles

[Duane Merrill]

Thanks for the insightful comments, Blair.  I've embedded some of my 
responses to your comments regarding the three profile documents below; 
I'll see if I can get Andrew to address your considerations regarding 
the use-case document as well. 

Regards,

Duane


Blair Dillaway wrote:
>
>  
>
> SP 2.0 -- Secure Addressing
>
>  
>
> I believe the new mechanism being proposed  for communication 
> authentication and communication security requirements is 
> counterproductive. Major industry players have already invested a lot 
> of time in developing WS-SecurityPolicy (see WS-SecurityPolicy 1.2 ,  
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512) which is on 
> a standards track in OASIS. This makes it unlikely you will find broad 
> interest in developing or implementing the mechanism you propose. I 
> also feel such a mechanism, which is specific to communication as part 
> of an EPR, is too limiting. The flexibility to support other 
> mechanisms such as WSDL, WS-MetadataExchange, etc. are important for 
> broad adoption.
>
>  
>
> I therefore suggest you profile WS-SecurityPolicy for interoperability 
> across the grid use cases of interest. This can include how it should 
> be encoded within an EPR. I would also suggest the interop profile for 
> communicating this information be in one document rather than having 
> pieces spread over three different specs as in these drafts.
>

Interesting point.  WS-SecurityPolicy does appear to provide what we're 
looking to augment the EPR with, in terms of being able to conveying 
secure communication requirements (and ancillary tokens).  Our concern 
with WS-SecurityPolicy has been the ambiguity of its status within the 
WS-SX technical committee. 

Our meta-goal is to establish uniform mechanism for grouping all of the 
required information that one party needs for communication within one 
vehicle.  From our perspective, the EPR is a great fit (it already 
contains an address URI, reference parameters, etc.).  The missing 
piece, with respect to EPRs, is the lack of mechanism for conveying 
secure communication requirements (and ancillary tokens).  Profiling 
WS-SecurityPolicy in a non-EPR-specific manner may help other mechanisms 
(as you mention, WSDL, or WS-MetadataExchange) to serve as means to our 
ends.  Specifics for EPR, WSDL, and WS-MetadataExchange could then 
leverage such common WS-SecurityPolicy requirements.

>  
>
> SP 2.0-Secure Transport
>
>  
>
> I suggest removing the 'secure addressing' parts per my comments 
> above. If that is done, I am concerned this spec comes across as 
> little more than a profile of WS-I BSP transport security that says 
> 'don't use weak cipher suites'.  I fear people may have trouble seeing 
> the value or why OGSA BSP -- Secure Channel isn't adequate. I think 
> you should consider a different approach to packaging these specs  
> and/or including  a very succinct description of the value provided by 
> this spec in the introduction.
>
This separation of this document from the others reflects a separation 
of concerns.  Profiles such as the WS-I BSP have chosen to profile many 
semi-orthogonal specifications within one document.  We argue that this 
is not an ideal approach as maintaining, evolving, and supporting 
profiles for the different components becomes less intuitive for profile 
designers and implementers alike.  (Analogous to OO design principles 
where derived classes are further refinements of their parents, and one 
strives to keep the abstractions coherent.)

Specifically, the Secure Transport document serves to

    * Establish a common identifier for a particular type of transport
      requirement
    * Establish processing rules for an extended form of hostname
      verification
    * Restrict allowable ciphersuites (a feature entirely inherited from
      this document's predecessor, the OGSA Security Profile - Secure
      Channel document.)

 
>
> SP 2.0 -- Secure SOAP Messaging
>
>  
>
> I think a big part of the problem is flipping back and forth between 
> requirements predicated on the presence or absence of 'message 
> forwarding intermediaries'. It might be easier if the material were 
> organized based on the two possible messaging models.
>
Point taken.
>
>  
>
> Some specific comments:
>
> -          Given the behaviors are based on the presence of message 
> forwarding intermediaries, you really need to be precise in defining 
> this. I expect you mean the case where the sender is transmitting a 
> message to an end-point which it knows is not the ultimate recipient 
> for the message body. I suspect you don't consider a transparent 
> firewall or router to be an intermediary.
>
A reasonable request.
>
> -          I strongly suggest you include a brief definition of 
> CRITICAL_SIGNING and CRITICAL_ENCRYPTION. You already mention what 
> should be signed or encrypted and adding the supported algorithms 
> would aid the reader in understanding what is required without having 
> to go find the material in the WS-I BSP.
>
The document defines the CRITICAL_SIGNING and CRITICAL_ENCRYPTION 
conformance targets in the "Conformance Targets" section.  The intent of 
referring the reader to the WS-I BSP for more specifics regarding the 
details for signing/encryption requirements is, again, an intentional 
application of separation of concerns.
>
> -          I question the requirement to encrypt of all messages. I 
> really think you need to articulate the explicit use cases you are 
> supporting that make this essential.
>
By no means does this document require the encryption of all messages.  
Rather, it defines a mechanism for an EPR to convey that a /particular 
/service requires encryption of all messages sent to /it/.  (Many 
services may not have this requirement, and their endpoint references 
will reflect its absence.)
>
> -          Section 7 has seemingly contradictory requirements. I can 
> quess at what you meant, but it would be better if you clarified it. 
> First, you say not to use username tokens " C0701 -- Username Token 
> credentials *SHOULD NOT be used for message level authentication* 
> because they are not cryptographically verifiable. Then 7.2 says to 
> use them for message sender authN "This subsection describes the 
> *secure messaging requirements for message /SENDER/s authenticating* 
> to /RECIEVER/s using Username Token credentials...... R0702 -- Message 
> /SENDER/s MUST place the UsernameToken credential in the message 
> header in accordance with the WSS UTP and Section 11 of the WS-I BSP."
>
Again, these are message processing rules that are to be carried out iff 
the endpoint reference indicates that particular action as a requirement 
for the referenced endpoint.




____________________________
Duane Merrill
dgm4d at cs.virginia.edu <mailto:dgm4d at cs.virginia.edu>
UVa Computer Science Department
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20070605/c1cf5cbd/attachment.html