RE: tsv-dir review of draft-ietf-xcon-bfcp-connection-04

[[e-mail]]

Gonzalo,

The -05 draft looks fine, and I have no problem with leaving comment
(1) [whether to say something applicable beyond BFCP on the subjects
of IP address selection and use of SubjectAltName] to the discretion
of the ADs.

Thanks,
--David

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[e-mail]] 
> Sent: Thursday, July 05, 2007 5:59 AM
> To: Black, David
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04
> 
> Hi David,
> 
> I have put together a new revision of the draft that 
> addresses all your 
> comments. Regarding your comment (1), I will send a note to 
> the ADs so 
> that they decide what to do.
> 
> Until the draft appears in the archives, it can be fetched from:
> 
> http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-bfcp-conne
ction-05.txt
> 
> Thanks,
> 
> Gonzalo
> 
> [e-mail] wrote:
> > Gonzalo,
> > 
> > Most of this looks good; I have a few comments:
> > 
> > (1) In the two places where there are general recommendations that
> > 	are not specific to BFCP (IP address selection and use of
> > 	SubjectAltName in certs in preference to Subject), it would
> > 	be good to note that these are general recommendations
> > 	that are not specific to BFCP, **but** please consult your
> > 	AD on whether and how to do this, as these are cross-area
> > 	issues in the IETF.  The existing text is ok.
> > 
> > (2) I would change the sentence about PBKDF2 key strengthening,
> > 	as the use of "security" is questionable: 
> > 
> > OLD:
> >      Because such key derivation functions may incorporate
> >      iteration functions for key strengthening they provide some
> >      additional security against dictionary attacks.
> > NEW: 
> >      Because such key derivation functions may incorporate
> >      iteration functions for key strengthening they provide some
> >      additional protection against dictionary attacks by
> >      increasing the amount of work that the attacker must perform.
> > 
> > (3) Regarding the "obtain" language, I would make the following
> > 	change to explain why the attacks don't apply -
> > 
> > OLD:
> >      When the keys are randomly generated and of sufficient length,
> >      these attacks do not obtain.
> > NEW:
> >      When the keys are randomly generated and of sufficient length,
> >      dictionary attacks are not effective because such keys are
> >      highly unlikely to be in the attacker's dictionary.
> > 
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > [phone]             FAX: [phone]
> > [e-mail]        Mobile: [phone]
> > ----------------------------------------------------
> > 
> >> -----Original Message-----
> >> From: Gonzalo Camarillo [mailto:[e-mail]] 
> >> Sent: Sunday, June 17, 2007 5:52 AM
> >> To: Black, David
> >> Cc: [e-mail]; [e-mail]; [e-mail]; Cullen Jennings
> >> Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04
> >>
> >> Hi David,
> >>
> >> thanks for your comments. Answers inline:
> >>
> >> [e-mail] wrote:
> >>> I've reviewed this document as part of the transport area
> >>> directorate's ongoing effort to review key IETF documents.
> >>> These comments were written primarily for the transport
> >>> area directors, but are copied to the document's authors
> >>> for their information and to allow them to address any
> >>> issues raised.
> >>>
> >>> This is a relatively straightforward draft about how a
> >>> client opens a TCP connection to a BFCP server when it
> >>> has the server's transport address information.
> >>>
> >>> Section 3 ventures into the area of IP address selection -
> >>> it references RFC 3484 (which is good) and then goes on to
> >>> make additional comments and recommendations on usage and
> >>> state of deployment of the techniques specified in RFC 3484.
> >>> While there's nothing technically wrong with this text, the
> >>> additional comments and recommendations are not specific
> >>> to BFCP, and may belong in a more generic document.
> >> Given that such a generic document does not exist, we need to 
> >> give these 
> >> recommendations here.
> >>
> >>
> >>> Section 4 starts with "All BFCP entities implement TLS ..."
> >>> That is correct, as RFC 4582 requires this, but it would be
> >>> better to cite RFC 4582 as part of this statement, e.g.,
> >>> "[RFC 4582] requires that all BFCP entities implement TLS ..."
> >> What about performing the following change?
> >>
> >> OLD:
> >>
> >> All BFCP entities implement TLS [7] and SHOULD use it in all their
> >>     connections.
> >>
> >> NEW:
> >>
> >> [RFC 4582] requires that all BFCP entities implement TLS and
> > recommends 
> >> that they use it in all their connections.
> >>
> >>
> >>> In the second paragraph of Section 4, I would change
> >>> "can request the use of TLS" to "SHOULD request the use
> >>> of TLS".
> >> OK, I will fix it.
> >>
> >>> Section 5.1 specifies that SubjectAltName identities in
> >>> certificates are to be preferred to Subject identities.
> >>> Is this specific to BFCP or more general?
> >> We got that recommendation from our security adviser. I do 
> not know 
> >> whether this will be documented in a generic document at 
> some point.
> >>
> >>> The following text appears to be an oversight:
> >>>
> >>>    If the client knows the server's IP address, the iPAddress
> >>>    subjectAltName must be present in the certificate and must
> >>>    exactly match the IP address known to the client.
> >>>
> >>> The client *always* knows the server's IP address (e.g.,
> >>> DNS returns it).  I think the intended case here is that
> >>> the client contacts the server using the server's IP address
> >>> and as a result does not know the server's hostname.  Rephrasing
> >>> in that sort of fashion would also express a preference for
> >>> hostname as certificate identity, which I believe is desirable.
> >> What about performing the following change?:
> >>
> >> OLD:
> >>     If the client knows the server's IP address, the iPAddress
> >>     subjectAltName must be present in the certificate and 
> must exactly
> >>     match the IP address known to the client.
> >>
> >> NEW:
> >>     If the client does not know the server's hostname and 
> contacts the
> >>     server directly using the server's IP address, the iPAddress
> >>     subjectAltName must be present in the certificate and 
> must exactly
> >>     match the IP address known to the client.
> >>
> >>
> >>> Section 6 disturbingly shifts between "password" and
> >>> "pre-shared key" and appears to get a few things wrong in
> >>> the process.  To begin with, the statement that "TLS PSK mode
> >>> is subject to offline dictionary attacks." is false when
> >>> the PSK is high-entropy.  OTOH, it is correct when the PSK
> >>> is low-entropy (e.g., a password, or derived from a password
> >>> without introduction of additional entropy).  The discussion
> >>> in Section 7.2 of RFC 4279 applies, especially the last
> >>> paragraph about PSK generation.  The section needs to be
> >>> carefully revised to distinguish between "password" and
> >>> "pre-shared key", especially given the mention of use of
> >>> PBKDF2 to generate the latter from the former.
> >> what about performing the following change?:
> >>
> >> OLD:
> >>
> >>     TLS PSK mode is subject to offline dictionary attacks. 
>  In DHE and
> >>     RSA modes, an attacker who can mount a single man-in-the-middle
> >>     attack on a client/server pair can then mount a 
> dictionary attack
> > on
> >>     the password.  In modes without DHE or RSA, an attacker who can
> >>     record communications between a client/server pair can mount a
> >>     dictionary attack on the password.  Accordingly, it is 
> RECOMMENDED
> >>     that where possible clients use certificate-based server
> >>     authentication ciphersuites with PSK in order to defend against
> >>     dictionary attacks.
> >>
> >>     In addition, passwords SHOULD be chosen with enough entropy to
> >>     provide some protection against dictionary attacks.  
> Because the
> >>     entropy of text varies dramatically and is generally 
> far less than
> >>     that of an equivalent random bitstring, no hard and fast rules
> > about
> >>     password length are possible.  However, in general passwords
> > SHOULD
> >>     be chosen to be at least 8 characters and selected from a pool
> >>     containing both upper and lower case, numbers, and special
> > keyboard
> >>     characters (note that an 8-character ASCII password 
> has a maximum
> >>     entropy of 56 bits and in general far lower).  FIPS 
> PUB 112 [11]
> >>     provides some guidance on the relevant issues.  If possible,
> >>     passphrases are preferable to passwords.  In addition, a
> > cooperating
> >>     client and server pair MAY choose to derive the TLS 
> PSK shared key
> >>     from the passphrase via a password-based key 
> derivation function
> > such
> >>     as PBKDF2 [2].
> >>
> >>
> >> NEW:
> >>
> >>     TLS PSK simply relies on a pre-shared key without 
> specifying the
> >>     nature of the key. In practice, such keys have two 
> sources: text
> >>     passwords and randomly generated binary keys. When keys are
> > derived
> >>     from passwords, TLS PSK mode is subject to offline dictionary
> >>     attacks. In DHE and RSA modes, an attacker who can 
> mount a single
> >>     man-in-the-middle attack on a client/server pair can 
> then mount a
> >>     dictionary attack on the password. In modes without 
> DHE or RSA, an
> >>     attacker who can record communications between a client/server
> > pair
> >>     can mount a dictionary attack on the password. 
> Accordingly, it is
> >>     RECOMMENDED that where possible clients use certificate-based
> >>     server authentication ciphersuites with password-derived PSKs,
> >>     in order to defend against dictionary attacks.
> >>
> >>     In addition, passwords SHOULD be chosen with enough entropy to
> >>     provide some protection against dictionary attacks.  
> Because the
> >>     entropy of text varies dramatically and is generally 
> far less than
> >>     that of an equivalent random bitstring, no hard and fast rules
> > about
> >>     password length are possible.  However, in general passwords
> > SHOULD
> >>     be chosen to be at least 8 characters and selected from a pool
> >>     containing both upper and lower case, numbers, and special
> > keyboard
> >>     characters (note that an 8-character ASCII password 
> has a maximum
> >>     entropy of 56 bits and in general far lower).  FIPS 
> PUB 112 [11]
> >>     provides some guidance on the relevant issues.  If possible,
> >>     passphrases are preferable to passwords.  In addition, a
> > cooperating
> >>     client and server pair MAY choose to derive the TLS 
> PSK shared key
> >>     from the passphrase via a password-based key 
> derivation function
> > such
> >>     as PBKDF2 [2]. Because such key derivation functions may
> > incorporate
> >>     iteration functions for key strengthening they provide some
> >>     additional security against dictionary attacks.
> >>
> >>     When the keys are randomly generated and of sufficient length,
> >>     these attacks do not obtain. Where possible, keys SHOULD be
> >>     generated using a strong random number generator as specified
> >>     in RFC 4086 [REF]. A minimum key length of 80 bits 
> SHOULD be used.
> >>
> >>
> >> Thanks,
> >>
> >> Gonzalo
> >  
> 
> 
> 

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf