This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf6092?nav=1&selectedTab=associations at Sun, 06 Nov 2022 09:03: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  
Date Association Posted By Comment Association Type
No results found.

 
 
 
< 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/sfmain/do/go/artf6092?nav=1&selectedTab=associations at Sun, 06 Nov 2022 09:03:53 GMT