This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/go/artf6092?nav=1 at Thu, 03 Nov 2022 23:44:53 GMT SourceForge : artf6092: comments on 27 Nov draft

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin

Glance

Calendar
Search Tracker
Project: OGSA-WG     Trackers > SP - Secure Communication > View Artifact
Artifact artf6092 : comments on 27 Nov draft
Tracker: SP - Secure Communication
Title: comments on 27 Nov draft
Description:
Pg 5, Line 152 – “In of itself, this document….”  Did you mean “By itself”

Pg 5, Line 99 – ” Unfortunately there is no provisioning…” should be “provision”

Pg 10, Line 307 – “referencable” should be “referenceable” 

Pg 15, Line 465 – not clear to me why you define SSL 3.0 ciphersuites here and in Table 4 since the remainder of this 
section only defines mechanisms using TLS

Pg 16, Line 493 & Line 509; Pg 17, Line 532 & Line 548 – “A transport ciphersuite of either TLS_RSA_WITH_AES_256_CBC_SHA or 
SSL_RSA_WITH_AES_256_CBC_SHA” .  Why isn’t AES_128 encryption supported?  Even the Gov’ts Suite B requirements state 
AES_128 is adequate to support encryption of info at the Secret classification level.

I note the normative policies defined in Appendix B are also restricted to use of TLS and AES_256. I suggest AES_128 
should be the base requirement. Also I think you need to either: 1) clearly indicate SSL is not supported or 2) add text
 to indicate SSL 3.0 may be used as an alternative to TLS.

Pg 18, 7.0 – From earlier discussion, I was under the impression use of password authentication was only being 
recommended when used with a TLS encrypted, server authenticated, channel. That seems to be lost in this version. If it 
is your intent to allow initiator password authentication without a TLS channel, then additional security considerations
 should be added to indicate the potential dangers.

Pg 18, 7.2 – Shouldn’t there be a note that this policy should only be used with a SERVER_TLS policy to prevent clear-
text transmission of a password? At a minimum you should add a  security considerations statement.

Pg 18, 7.3 – As above, if you assume SERVER_TLS when using password msg authN then the rationale for supporting this is
 weak. This digest algorithm protects against cut&paste replay attacks and slows down password guessing attacks. Those 
aren’t really an issue if you’re inside a TLS channel.  If your intent is too support this outside a TLS channel, then
 you should add that this is the only recommended method for doing initiator password authN over an unencrypted channel.


Appendix A – Also defines allowed SSL 3.0 ciphersuites, but the spec doesn’t seem to allow SSL use?
Submitted By: Blair Dillaway
Submitted On: 12/03/2007 5:33 PM EST
Last Modified: 12/27/2007 4:24 PM EST
Closed: 12/27/2007 4:24 PM EST

Status / Comments Change Log Associations Attachments  
Status  
Group: *
Status:* Closed
Category: *
Customer: *
Priority: * 2
Assigned To: * Duane Merrill
Reported in Release: *
Fixed in Release: *
Estimated Hours: * 0
Actual Hours: * 0
Comments
Duane Merrill: 12/27/2007 4:24 PM EST
  Comment:
Fixed as per version 007.

It was always our intent to support SSL 3.0.  What we call "SSL" and "TLS" are essentially different versions of the same IETF protocol (with "SSL 3.0
" being version 3.0 and "TLS 1.0" being version 3.1).  I've included extra requirements and descriptive text within the transport-layer section of the
 document to indicate that the TLS/SSL handshake should negotiate, at a minimum, SSL 3.0.  

You are right about the 128-bit symmetric encryption: it's "good enough for government work" and it's also what is recommended in Section 3.2.2 of the
 WS-I BSP 1.0.  I've updated the referenceable policy documents to indicate support for both 256 and 128-bit symmetric encryption.

As you mentioned, we had envisioned the Username-token policy being applied in conjunction with either a transport-level or message-level policy 
mandating encryption of all communication (or, at a minimum, the <wsse:UsernameToken> elements).  I updated section 7.2 to include this requirement: 
that it "makes sense" for a policy-dependency in this case.  

As for recommending that the UsernameDigest policy NOT be applied in conjunction with a TLS/SSL transport policy, we discussed this on telecon.  There
 are many permutations of policy documents that "don't make sense", and we felt that addressing the suitableness of nonsensical combinations was out 
of scope of the document.
  Action: Update
Closed set to 12/27/2007
Status changed from Resolved to Closed
Andreas Savva: 12/06/2007 10:05 AM EST
  Comment:
See minutes Dec. 6.
  Action: Update
Status changed from Open to Resolved
Blair Dillaway: 12/03/2007 5:33 PM EST
  Action: Create


 
 
 
< Previous
 
 
Next >
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/go/artf6092?nav=1 at Thu, 03 Nov 2022 23:44:59 GMT