Subject: [XCON] tsv-dir review of draft-ietf-xcon-bfcp-connection-04

From: [email-masked]
Date: Fri, 23 Mar 2007 20:49:45 -0400

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.

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

In the second paragraph of Section 4, I would change
"can request the use of TLS" to "SHOULD request the use
of TLS".

Section 5.1 specifies that SubjectAltName ideFrom [email-masked] Tue Oct 09 16:56:56 2007
From: [email-masked]
Content-class: urn:content-classes:message
Date: Fri, 23 Mar 2007 20:49:45 -0400
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: [XCON] tsv-dir review of draft-ietf-xcon-bfcp-connection-04

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.

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

In the second paragraph of Section 4, I would change
"can request the use of TLS" to "SHOULD request the use
of TLS".

Section 5.1 specifies that SubjectAltName identities in
certificates are to be preferred to Subject identities.
Is this specific to BFCP or more general?

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.

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.

Thanks, 
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: [email-masked]
Date: Thu, 5 Jul 2007 09:57:21 -0400

Thanks, 
--David

---

From: [email-masked]
Date: Thu, 5 Jul 2007 09:57:21 -0400

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:[email-masked]] 
> Sent: Thursday, July 05, 2007 5:59 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> 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
> 
> [email-masked] 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
> >> -----Original Message-----
> >> From: Gonzalo Camarillo [mailto:[email-masked]] 
> >> Sent: Sunday, June 17, 2007 5:52 AM
> >> To: Black, David
> >> Cc: [email-masked]; [email-masked]; [email-masked]; Cullen Jennings
> >> Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04
> >>
> >> HHAS_MSGID 0, __IMS_MSGID 0,
	__MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
Cc: [email-masked], [email-masked], [email-masked], [email-masked],
	[email-masked]
Subject: [XCON] RE: tsv-dir review of draft-ietf-xcon-bfcp-connection-04

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:[email-masked]] 
> Sent: Thursday, July 05, 2007 5:59 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> 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
> 
> [email-masked] 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
> >> -----Original Message-----
> >> From: Gonzalo Camarillo [mailto:[email-masked]] 
> >> Sent: Sunday, June 17, 2007 5:52 AM
> >> To: Black, David
> >> Cc: [email-masked]; [email-masked]; [email-masked]; Cullen Jennings
> >> Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04
> >>
> >> Hi David,
> >>
> >> thanks for your comments. Answers inline:
> >>
> >> [email-masked] wrote:
> >> Given that such a generic document does not exist, we need to 
> >> give these 
> >> recommendations here.
> >>
> >>
> >> 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.
> >>
> >>
> >> OK, I will fix it.
> >> We got that recommendation from our security adviser. I do 
> not know 
> >> whether this will be documented in a generic document at 
> some point.
> >>
> >> What about performing the following change?:
> >>
> >> OLD:
> >>     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.
> >>
> >>
> >>> paragraph about PSK generation.  The section needs to bi David,
> >>
> >> thanks for your comments. Answers inline:
> >>
> >> [email-masked] wrote:
> >> Given that such a generic document does not exist, we need to 
> >> give these 
> >> recommendations here.
> >>
> >>
> >> 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.
> >>
> >>
> >> OK, I will fix it.
> >> We got that recommendation from our security adviser. I do 
> not know 
> >> whether this will be documented in a generic document at 
> some point.
> >>
> >> What about performing the following change?:
> >>
> >> OLD:
> >>     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.
> >>
> >>
> >> 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 againe
> >> 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
> >  
> 
> 
> 

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