Re: [radext] [Gen-art] Gen-Art Early Review of draft-ietf-radext-dtls-07

[Alan DeKok <[e-mail]>]

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.