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

[Gonzalo Camarillo <[e-mail]>]

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