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:Gonzalo.Camarillo@xxxxxxxxxxxx] > Sent: Thursday, July 05, 2007 5:59 AM > To: Black, David > Cc: ietf@xxxxxxxx; xcon@xxxxxxxx; tsv-dir@xxxxxxxx; fluffy@xxxxxxxxx > 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 > > Black_David@xxxxxxx 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@xxxxxxx Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > >> -----Original Message----- > >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@xxxxxxxxxxxx] > >> Sent: Sunday, June 17, 2007 5:52 AM > >> To: Black, David > >> Cc: ietf@xxxxxxxx; xcon@xxxxxxxx; tsv-dir@xxxxxxxx; Cullen Jennings > >> Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 > >> > >> Hi David, > >> > >> thanks for your comments. Answers inline: > >> > >> Black_David@xxxxxxx 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf