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

[Gonzalo Camarillo <[e-mail]>]

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


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