Here are some long overdue comments on these drafts.  I’ve been travelling almost the entire month of May and just couldn’t get to this sooner. I hope you find these helpful.

Regards,

Blair Dillaway

Use Cases for Grid Architectures

This document is a good start, but is too high-level and unfocused to properly motivate and justify the mechanisms developed in the other specifications.  Ideally, the use-cases should reflect functionality the target audience for these specification deems critical and requiring interoperable solutions. I believe more detail will be required to achieve that goal. Of course, it would be best to get input, and/or incorporate already documented use-cases, from groups such as HPC Profile, ByteIO, etc..

The use-case discussion should also highlight the specific functional requirements that drive the mechanism in the draft specs. In particular: why is a discovery mechanisms for authN and communication security requirements  needed; what authN mechanisms are required ; what protocols must be supported; why are message integrity and encryption mandatory; is communications security only needed point-to-point or  must it span processing intermediaries? The current doc is quite weak in this area.

Specific comments:

-  Fundamental Use-cases – This seems primarily definitional. Implies mutual AuthN, integrity, and confidentiality are always required but doesn’t really describe the environment or threats that lead to this conclusion. I find the discussion of authZ, non-repudiation and audit confusing since these are out-of-scope of the express authentication effort.

- Application use-cases – These are good concrete examples, but there isn’t enough discussion about the target environment/threats to help me understand what required, what is optional, what is unnecessary to meet grid needs. For example, in 3.1 is asks what client authN a ByteIO service might require? It would be better to describe a specific environment where the functionality in the express authentication specs is the answer. The firewall traversal discussion is interesting as it describes a firewall as an explicit message processing intermediary. How does this interplay with the requirements described in the secure SOAP messaging document?

- Mechanism-driven use-cases – These start to start to identity some important and specific requirements such as one-way communication, delegation, and so forth. However, I’m having a hard time relating this discussion to what has been spec’d in the other documents.

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.

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.

Some specific comments on Section 4:

- You should identify the specific TLS & SSL versions supported

- C0400 – I have a problem with the wording ”CONSUMER SHOULD perform one or both of the following…”. If I remember correctly, TLS/SSL client authentication requirements are specified in a Server generated handshake message.  So shouldn’t this be a consumer must support X.509-based authN when required by the server and must support authN using messaging security otherwise?

- R0401 –“authentication alternatives specified in R0319” Where is R0319?

- Section 4.3 lists no mandatory cipher suites, R0402 – R0405 all say if a cipher suite is supported, it should be used. If you want to ensure interop there should be mandatory to implement ciphers.

- Section 4.4 – I’m not a fan of yet another list of weak ciphers folks shouldn’t use. Can’t this just indicate briefly that cipher suites which don’t support authN, are subject to man-in-the-middle-attacks, etc. must not be used.  I would also point out that since this profile always requires server authN you can’t use the listed ciphers and be compliant anyway.

- Section 4.5 I have the same problem with the list of prohibited ciphers. I would much rather you indicate which ‘must’ and ‘may’ be implemented as the basis for interoperability.

- R408 – ‘must not use a ciphersuite with a hash algorithm known to be insecure”. Please state what must and may be implemented for interoperability instead.

SP 2.0 – Secure SOAP Messaging

As above, I suggest removing the secure addressing sections of this spec. The biggest problem I have with this spec is that it is quite difficult to parse all the requirements and understand what behaviors are being mandated.  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.

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.

- 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.

- 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.

- 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 SENDERs authenticating to RECIEVERs using Username Token credentials…… R0702 – Message SENDERs MUST place the UsernameToken credential in the message header in accordance with the WSS UTP and Section 11 of the WS-I BSP.”

From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Duane Merrill
Sent: Thursday, May 03, 2007 8:23 AM
To: OGSA WG
Subject: [ogsa-wg] Strawman "OGSA Express Authentication Profile" Security Profiles

All,

I would like to share with you the attached strawman profile documents regarding OGSA secure communication.  Collectively these three strawman documents comprise what, up until now, we've been colloquially referring to as the "OGSA Express Authentication Profile."  (Other suggestions for what to name this trio, or for the profile documents themselves, are welcome.)

The three profile documents are intended to be complementary:

• OGSA Security Profile 2.0 - Secure Addressing document profiles the disclosure of secure communication requirements (and ancillary tokens/data) within endpoint references.  Many of the ideas and mechanisms in this document have been adapted from (and therefore should provide semantic compatibility with) the OGSA Basic Security Profile 1.0 - Core and Liberty Alliance ID-WSF security documents.

• OGSA Security Profile 2.0 - Secure Transport document profiles the use of transport layer security within the OGSA context.  Many of the ideas and mechanisms in this document have been adapted from (and therefore should provide semantic compatibility with) the OGSA Security Profile 1.0 - Secure Channel.

• OGSA Security Profile 2.0 - Secure SOAP Messaging document profiles the use of message layer security within the OGSA context.  This document is primarily an extension and refinement of the WS-I Basic Security Profile 1.0.  A crucial characteristic of this document is the extensibility provisioning for additional message-level authentication tokens/schemes.

Also attached is a OGSA secure-communication use-case document that motivates the requirements and capabilities afforded by these profiles.

Looking forward to discussing these with everyone next week!

Regards,

Duane

____________________________
Duane Merrill
dgm4d@cs.virginia.edu
UVa Computer Science Department