Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Thu, 05 July 2007 13:43 UTC
Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Rcf-0000dm-2p; Thu, 05 Jul 2007 09:43:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6O6l-0001SW-Kl; Thu, 05 Jul 2007 05:58:43 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6O6e-0005CB-Tk; Thu, 05 Jul 2007 05:58:43 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4C33020515; Thu, 5 Jul 2007 11:58:36 +0200 (CEST)
X-AuditID: c1b4fb3e-af032bb0000007e1-a6-468cc0cc8530
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 18E362023B; Thu, 5 Jul 2007 11:58:36 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 11:58:35 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 11:58:35 +0200
Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 15A662465; Thu, 5 Jul 2007 12:58:35 +0300 (EEST)
Message-ID: <468CC0CA.7040805@ericsson.com>
Date: Thu, 05 Jul 2007 12:58:34 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: Black_David@emc.com
References: <F222151D3323874393F83102D614E055068B9132@CORPUSMX20A.corp.emc.com> <4675044C.9040004@ericsson.com> <F222151D3323874393F83102D614E055068B96B9@CORPUSMX20A.corp.emc.com>
In-Reply-To: <F222151D3323874393F83102D614E055068B96B9@CORPUSMX20A.corp.emc.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Jul 2007 09:58:35.0331 (UTC) FILETIME=[0D505930:01C7BEEB]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 850245b51c39701e2700a112f3032caa
X-Mailman-Approved-At: Thu, 05 Jul 2007 09:42:59 -0400
Cc: fluffy@cisco.com, tsv-dir@ietf.org, ietf@ietf.org, xcon@ietf.org
Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org
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 Black_David@emc.com 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 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Sunday, June 17, 2007 5:52 AM >> To: Black, David >> Cc: ietf@ietf.org; xcon@ietf.org; tsv-dir@ietf.org; Cullen Jennings >> Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 >> >> Hi David, >> >> thanks for your comments. Answers inline: >> >> Black_David@emc.com 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- tsv-dir review of draft-ietf-xcon-bfcp-connection… Black_David
- RE: [XCON] Re: tsv-dir review of draft-ietf-xcon-… Brian Rosen
- Re: [XCON] Re: tsv-dir review of draft-ietf-xcon-… Eric Rescorla
- Re: tsv-dir review of draft-ietf-xcon-bfcp-connec… Gonzalo Camarillo
- RE: tsv-dir review of draft-ietf-xcon-bfcp-connec… Black_David
- Re: tsv-dir review of draft-ietf-xcon-bfcp-connec… Gonzalo Camarillo
- RE: tsv-dir review of draft-ietf-xcon-bfcp-connec… Black_David
- Re: tsv-dir review of draft-ietf-xcon-bfcp-connec… Cullen Jennings