Thanks for the quick response. Comments inline, with sections that do not appear to need further content removed.
On Apr 30, 2014, at 8:38 PM, Alan DeKok <al...@deployingradius.com> wrote: > Ben Campbell wrote: >> -- 3.2, last paragraph: >> >> I'm still confused about how this is a bid down attack. >> >> [The author replied that, when secure and insecure packets are allowed from >> the same client, a >> malicious or broken client can choose the insecure one. That's bad, >> when the intent is to use DTLS.] >> >> While I agree that's bad, I don't see how it qualifies as a bid-down attack. >> One assumes a malicious client already has access to the cleartext messages. >> Are we talking about an MiTM "client"? Are there attacks where a third party >> can induce the client or server to send unprotected packets, even with no >> signaled negotiation? I can imagine one for the specific case where a node >> falls back to clear text if DTLS packets fail; an attacker could induce >> failures for DTLS packets, but that is covered elsewhere. >> Comment not addressed. > > The point of DTLS isn't just to protect from malicious clients. It's > to protect clients and servers from malicious third parties. Those > parties can read all RADIUS/UDP traffic now. They will not be able to > read RADIUS/DTLS traffic. > > These third parties could actively cause DTLS to fail, and force the > client and server to use an insecure transport. This sounds like a > downbidding attack to me. > > Do you have another definition for downbidding which you are using? > Or would another term be acceptable here? I tend to think of a bid-down attack as one in which security parameters are negotiated, and an attacker removes a more secure security mechanism to force endpoints to fall back to a less secure. But an outright failure of the DTLS handshake is more likely something less subtle--an outright impersonation attack, or a MiTM modification of content. > >> -- 6, 2nd and 3rd paragraph: >> >> The RECOMMENDation to allow administrative entry of keys and to derive keys >> from a PRNG seem contradictory. >> >> >> [The author responded that it's a requirement that implementors allow >> administrators to enter >> strong keys. but I don't get that from the text, which both RECOMMENDS that >> the interface allow people to enter human readable hex strings, and that >> keys should be derived from a PRNG instead of letting administrators make up >> keys. How can it be both? > > Because the administrators have to enter the same key on both the > client and server. If one machine auto-generated a secure pseudo-random > number, it would still have to be transported to the other, and entered > in an administration UI... via the method suggested in the document. I think it's reasonable to say that good administration practices involve random key generation, and that the interface should not prevent the entry of arbitrary hex strings. But the text says things like "When creating keys, it is RECOMMENDED that keys be derived from a cryptographically secure pseudo-random number generator (CSPRNG) instead of allowing administrators to invent "secure" keys on theur [sic--add that as an editorial comment] own." That part seems to say explicitly that the implementation shouldn't let admins enter their own keys. (Which makes the bit about entering the key on the peer seem difficult.) > >> I don't see how an interface could prevent administrators from entering >> better keys. Perhaps the intent is to offer or interface with tools for >> random generation, or to scan entered keys for things with insufficient >> entropy?] > > Have you ever entered a password in a poorly designed on-line form? > "special characters like !, %, &, $, etc. are not allowed". Vendors do > this today with RADIUS systems, for the shared secret. Such idiocy > should be discouraged. I accept that, and my real concern is not about allowing the admin to enter arbitrary hex strings. My concern is that it also says the admin should not be able to enter their own keys (see above.) How do you expect the interface to prevent the use of "invented on their own" keys, while allowing arbitrary hex strings? [...] >> -- 10.4 5th and 6th paragraphs: >> >> Paragraph 5 says credentials should be manually configured, and strongly >> tied to a host name. It is not clear to me from the text whether using a >> certificate (perhaps issued by a trusted CA) to bind the credentials to the >> hostname is permissible. The use of "manual" would seem to disallow that. >> But paragraph 6 talks about configuring trusted CAs. >> >> [The author commented that dynamic discovery was out of scope--but I don't >> think anything about this implies dynamic discovery. (e.g. configuring a >> client to talk to foo.example.com, then using using a CA to validate that a >> server certificate to ensure that that server really is foo.example.com is >> not the same as dynamic discovery.] > > I'm not sure what the objection here is. > > The point is that when a client connects to a server, the server uses > the source IP to determine which set of credentials to use. There is no > "binding" of a certificate to a hostname. The system is configured to > verify that "when you see packets from IP X, they must be using > certificate C". Are you explicitly recommending against doing client authentication in the DTLS handshake? That seems inconsistent with the 3rd paragraph, that says "Any authentication credentials for that client are then determined solely from the client identity, and not from an IP address." But, my concern was not just about servers authenticating clients. Paragraph 5 says: "authentication credentials for that relationship should also be statically configured. That is, a client connecting to a DTLS server SHOULD be pre-configured with the servers credentials (e.g. PSK or certificate)." That seems to exclude the possibility of the client being pre-configured with a host name for the server, then the server presents a certificate issued from a trusted CA that includes that host name. This is a common TLS/DTLS use case. Now, maybe you consider that to still be static configuration of credentials, since the host name and the trust anchor need to be statically configured. But your statement that there is no (as in never?) binding of a certificate to a host name makes me think otherwise. (Or at least confused me.) I assume you expect to do something with trusted CAs, since paragraph 6 talks about their configuration. > > This configuration is independent of the certificate contents. > >> -- 10.5, last paragraph: >> >> This seems to be making normative statements about RADIUS/UDP. It's not >> appropriate to make those statements here unless this draft normatively >> updates RADIUS/UDP. (Which and experimental rfc shouldn't do.) > > The consensus of the WG was that the text belonged. I think we must be talking past each other. I read this to say that you expect people who are implementing/deploying RADIUS/UDP, who may not have seen any reason to read this experimental spec in the first place, to honor normative statements in this draft? In general, it does not make sense for a given protocol to make normative statements about implementations that don't implement that protocol. If the working group wants to make this sort of statement, there are avenues to do so. But I don't think an experimental RFC is the right place. [...] _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
