Ben Campbell wrote: > Version 08 partially addresses this by changing "NOT RECOMMENDED" to lower > case. I don't think that's sufficient; it's not a good idea to rely on case > alone to distinguish normative from non-normative text. I propose changing > the sense of the statement to something along the lines of "The author > recommends...".
OK. I'll word-smith it. > The text to which I refer says "It is RECOMMENDED that all RADIUS clients and > servers implement this specification, or [RFC6614]." That seems to to apply a > new normative statement to all RADIUS clients and servers, and does not in > any way seem scoped to "RADIUS/DTLS clients and servers". OK. I'll word-smith it. >>> -- General: It might be worth some text on why this is experimental rather >>> than informational. Is there any plan to evaluate the implementation >>> results? Is there an expectation that a future RADIUS/DTLS spec could >>> become standards-track? Is there any plan to evaluate the outcome of this >>> document? >> It's probably easiest to reference Section 1.3 of RFC 6614. The >> issues are the same. > > I don't think that's the best approach. That discussion is specific to 6614. > Referencing it would leave the reader to infer how that discussion would > apply to this draft. I think it would be better to include a similar > discussion here. OK. I'll do that. >>> -- Section 1, 2nd paragraph: >>> >>> Isn't this true for almost any use of IPSec? Is there some specific reason >>> this is worse for RADIUS than for other protocols? >> It's true for most protocols. > > It's worth mentioning that. OK. > [...] > >>> The firewall rule recommendations in the 3rd sentence seems odd, since it >>> seems like any protocol over DTLS would pass. Also, does this imply a >>> recommendation that firewalls with DPI be used in the first place, since >>> the absence of such a firewall has the same effect as having one that >>> doesn't enforce the protocol? (Is there a reason a protocol spec should >>> recommend firewall rules in the first place, other than to mention places >>> where certain firewall rules might prevent interfere with operation?) >> I'll clarify it, and move it to the Security Considerations section. > > The clarification added at the end of section 10 in version 08 mostly > addresses this. But I assume that the point is to make sure no one sends > non-protected RADIUS over that port, but it doesn't prevent someone from > sending some other protocol over DTLS over the same port, correct? If so, I > think that's worth a mention. Well... I can connect to port 443 via TLS, and then send random data. I don't see why this issue needs to be called out for this protocol. But sure. > The text seems to say something to the effect of " Some RADIUS clients have > historically been implemented as multiple independent processes, therefore > [all] RADIUS clients should use a local proxy". I think you mean to say > something more like "Some RADIUS clients have historically been implemented > as multiple independent processes; clients that are implemented that way > should use a local proxy." Sure. It already says that later, but I'll word-smith it. >> When security is OK and the tunneled data is RADIUS, it's OK to >> silently drop the unexpected RADIUS packets. Doing so doesn't cause any >> problems. > > It would be helpful to add a couple of sentences to that effect. OK. >>> -- 5.1.1, 4th paragraph: >>> >>> This paragraph rephrases 2119 normative language with more normative >>> language. That creates confusion about which text is authoritative. I >>> suggest either keeping the second paragraph and deleting the first, or make >>> the second non-normative. >> I'm not sure what you mean here. The two paragraphs discuss different >> things, so deleting one isn't possible. > > The opening sentence of the second paragraph says, "The above paragraph can > be rephrased more generically", then appears to go on to do so. That makes it > sound like the second paragraph asserting effectively the same normative > requirements in more general terms. If you intend each paragraph to stand > alone, then I suggest deleting that sentence. OK. >>> -- 5.1.1, 6th paragraph: "The timestamp SHOULD be updated ..." >>> >>> Why not MUST? >> The granularity could be 1 second, with packets being received 1000's >> of times per second. >> > > It would be helpful to elaborate on that in the text. Your comment makes me > thing it would be also worth having some guidance on a reasonable resolution > for the time stamp. > > If you really expect 1 second resolutions, then it might be better to say > something like "The timestamp MUST be updated if a valid message or heartbeat > is received during the last time interval." OK. >>> The RECOMMENDation to allow administrative entry of keys and to derive keys >>> from a PRNG seem contradictory. >> The idea is that admins shouldn't be entering "0xabababab" as a key. >> Instead, they get secure keys from a secure location. People are >> notoriously bad at creating randomness. >> > > So paragraph 3 is a requirement on the administrator, rather than on the > implementor? Or do you mean to say the implementation should provide tools > for random key generation? It's a requirement that implementors allow administrators to enter strong keys. > [...] > > >>> -- 9 >>> >>> Why not choose a new port? Is there absolute certainty this won't conflict >>> with the previous usage? I do note that 6414 made the same choice, so I >>> guess consistency with radius/TLS has some value. But that draft talks >>> about compatibility between radsec and radius/tls, which is not mentioned >>> here. >> No one is using UDP/2083 for anything. Re-using it is OK. > > Does that mean that RadSec is not used at all by anyone? or that this draft > is compatible with it? RadSec is RADIUS over TLS on TCP port 2083. No one uses UDP port 2083 for anything. >>> It would be helpful to have guidance on how to match a certificate to a >>> client or server identity, >> I'll add a note to see RFC 6614 Section 2.5. > > I see you added that to section 10.3, 3rd paragraph. But does that contradict > the statement in 2.2.1 that 6614 section 2.5 does not apply to RADIUS/DTLS? It's a typo. The reference should be to 6614 Section 2.4. >>> This is redundant with previous normative requirements. (Also >>> contradictory, since the previous text said "SHOULD", and contradictory >>> guidance on what to do when the limit is exceeded.) >> I've fixed the text to be consistent. > > The paragraph is still redundant with the new text in 5.1.1 (which says you > MUST either drop old sessions or limit creation of new ones.) I'm OK with that. The Security Considerations section can re-iterate security issues. > [ re: source IP filtering ] > > I agree it makes sense to point out that IP filtering might be helpful. But I > think a normative SHOULD is excessive. I disagree. >> The recommendation is a SHOULD so that it does not conflict with >> dynamic discovery. >> > If it stays normative, It would be worth mentioning that as an example of why > it's a SHOULD rather than a MUST. Which it says. > The whole point of a certificate is to bind a key pair to an identity (often, > a name.) > > Example: I enter the name "trusted-peer.example.com" in a table. If a > (perhaps dynamically discovered) peer presents certificate with a CN or SAN > that matches "trusted-peer.example.com", and that certificate is issued by a > CA that I trust, then I trust that peer. This document doesn't do dynamic discovery for peers. So it's OK to suggest that statically configuring relationships is a good idea. >>> Paragraph 6 seems to entirely contradict paragraph 5 by recommending >>> private CAs, and accepting any peer that presents a cert signed by that CA. >>> That's pretty much the opposite of statically configured credentials. >>> (Paragraph 8 also seems to contradict the static configuration part.) >> Both client and server still need to be configured with the private >> CA. The alternative is to allow anyone to connect with any credentials, >> which seems odd. >> > > That's static configuration of your trusted CA(s). That's not the same thing > as static configuration of peer credentials, and it doesn't imply the static > relationship between clients and servers mentioned in paragraph 5. We're getting into the weeds here. I view dynamic discovery of servers as an issue for the dynamic discovery document. Therefore, credentials should be statically configured. However, a *server* can allow clients who present the correct credentials. This is not dynamic discovery of clients. > [...] > >>> -- 10.4: >>> >>> The guidance in the last paragraph does not make sense. The section seems >>> to say that NATs will break radius/dtls, so you should use dtls when behind >>> a NAT. >> RADIUS/UDP clients should not be behind a NAT. I'll clarify. > > Do you mean RADIUS/UDP or RADIUS/DTLS? If the former, then that brings back > the problem of making normative statements about the base protocol. I mean RADIUS/UDP. It's not really changing RADIUS/UDP. RADIUS/UDP was designed before NATs were in wide-spread use, and with the intention of using it in a flat / open network. So it's silent on the issue of NATs, and many other topics. > Also, I'm still confused by the fact the the 2nd sentence of the last > paragraph says "If clients are located behind a NAT gateway, then a secure > transport such as DTLS MUST be used." Given that the previous paragraph seems > to say that RADIUS/DTLS has issues over NAT, I'm surprised to see it listed > as mitigating NATs. Yes. DTLS helps avoid some problems of NATs, but not all. This is the nature of a NAT: they screw with the traffic and make life harder for the application behind a NAT. >>> Redundant normative requirements (This is at least the third time the >>> separate process issue and local proxy guidance has been described.) >> It's a security considerations section, and needs to mention this. It >> refers to Section 6.1, and adds new text explaining the security >> benefits of the approach. > > I agree it should be reiterated, but not _normatively_. In generally, you > don't want to have the same normative requirement stated more than once. It > makes sense for the security consideration section to say something like > "Section XX recommends that clients use a local proxy" But it's best to > avoid any language that obscures which bit of text is authoritative for a > given normative requirement. (There can be only one...) I'll take a look at word-smithing it. > I also notice the language here also fails to account for the fact that the > requirement only applies to clients implemented as multiple independent > instances. This could be fixed by something really simple like saying "... > such clients ..." instead of "... clients... " in the second paragraph. I'll update it. Alan DeKok. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
