Subject: [radext] Comments on draft-ietf-radext-dynamic-discovery-05

From: "Jim Schaad" <[email-masked]>
Date: Sun, 20 Jan 2013 16:04:21 -0800

First let me say that I probably don't understand all of the circumstances
that this document is aimed at, so some of my comments may be way off base.

1.  In the Abstract - it says that "It can be used in conjunction with..."
>From what I have seen, it is only used in conjunction with one or the other,
it cannot be used without one of them being there.  Am I wrong?  If so then
suggest "It is used in conjunction with either RADIUS/TLS or RADIUS/DTLS."

2.  Please fill in some introduction - even if it is as bad as just copying
the abstract.  A problem statement about what you are trying to solve would
be even better.

3.  In section 2.1 - I am unclear what the correct behavior would be if I
have one user session open and I receive a new user Access-Request message.
Should I re-resolve or use the cached information?

4.  In section 2.2 - example b - you need to remove the quotes on the last
field of the example.

5.  In section 2.2. - I am lost on terminology -  Just after Figure 3 you
say "the label used for".  I am unclear in this context what you mean by
label.  This may be a deficiency of background for me.  However are we
talking about the realm in the user name, the  field in the SRV or NAPTR
records?

6. In section 2.3.1 - This is purely personal preference.  I find it hard to
locate the "variables" of the algorithm when they are a single character in
text.  This is especially true with I as it is visually close to a great
number of other characters.  I request they get widened in some fashion to
be more distinguishable.  If you choose to ignore this, I can easily live
with it.

7.  In section 2.3.1 - not explicitly stated but implied by the pattern is
that user cannot be the empty string.

8.  In section 2.3.1 - the list of possible errors include "Usage of
multiple @ separators", however this is covered in the first paragraph and a
deterministic algorithm is provided for dealing with it.

9. In section 2.3.2 - s/set of the tuple/set of tuples/  Current text can be
read as the set being the tuple not being a setup of the tuples.

10.  In section 2.3.3, step 4 - suggest s/O = { }/O= { empty set }/

11.  In section 2.3.3, step 4 - what is to be considered an error at this
point.  For example, there are a number of odd conditions that can be
returned from DNSSEC, specifically the "indeterminate" state.

12. In section 2.3.3, step 6 - suggest s/no result/no records found/

13.  In section 2.3.3, step 7 - text is unclear - is the set for all lookup
results or just for all hostnames in the final lookup result?  Also, should
secondary lookups do just NAPTR lookups or should they be doing SRV lookups
as well?

14.  In section 2.3.3, step 9 - text is unclear if I can do the lookup with
each of the prefixes or just with one.  As text is written I can only use
one prefix and can't do both.

15.  In section 2.3.3, step 13 - What subsequent lookup steps am I supposed
to be performing?   According to RFC 3958 section 5.1, SRV provides a single
layer of indirection; the outcome of an SRV lookup is a new domain name for
which the A RR is to be found.

16. In section 2.3.4 - Does the validity period of the TTL apply to a
currently open user validation session?  Do you close that or do you just
re-run the algorithm when a new ACCESS-REQUEST comes in for the realm?

17.  In section 2.3.4 - Given that the above algorithm does not return a TTL
value in the event of an empty set or define how to know the TTL value -
what is the TTL value to be used in in paragraph 2 "negative TTL"?

18.  In section 2.3.4 - This question is due to a lack of knowledge on my
part - Is there a specific error that should be returned at the RADIUS level
for the last two paragraphs in section 2.3.4 to indicate that I can't find
the path, but somebody else might be able to?

19.  In section 2.3.5 - Does it make sense to return a result, but to
continue the algorithm and store the result after the timeouts for later
use?

20.  I find the security considerations to be completely inadequate for this
document.  

Use of a certificate is only going to be valid if the original realm name
that is the input the validation routine is what is found and matched in the
certificate.  In this case I would not know where in the name or alt name
fields of the certificate it would be found.  You cannot validate to the
final DNS name as that is now an untrusted value.

The suggestion of out-of-band validation methods ignores the existence of
DANE

The NAI document suggests that the RADIUS peer is pre-configured with
information about certificates or TLS validation data.  The suggested text
works in the case that the table says do dynamic lookup and here is the TLS
configuration data.  But in other cases it is completely unclear how a
TLS-PSK would be found for a dynamic lookup.

21 - In the IANA consideration section - do you want to reserve the string
"_radiusdtls" as well as "_radiustls" as Service labels?