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

From: Stefan Winter <[email-masked]>
Date: Mon, 25 Feb 2013 16:42:48 +0100

Hi,

> 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.

The new text for your issue 2 will hopefully give sufficient context.

> 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."

Fixed, thanks.

> 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.

How about this text:

1.  Introduction

   RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TLS,
   RADIUS/DTLS) requires manual configuration of all peers (clients,
   servers).

   Where RADIUS forwarding servers are in use, the number of realms to
   be forwarded and the corresponding number of servers to configure may
   be significant.  Where new realms with new servers are added or
   details of existing servers change on a regular basis, maintaining a
   single monolithic configuration file for all these details may prove
   too cumbersome to be useful.

   Furthermore, in cases where a roaming consortium consists of
   independently working branches, each with their own forwarding
   servers, and who add or change their realm lists at their own
   discretion, there is additional complexity in synchronising the
   changed data across all branches.

   These situations can benefit significantly from a distributed
   mechanism for storing realm and server reachability information.
   This document describes one such mechanism: storage of realm-to-
   server mappings in DNS.

   This document does not specify how to verify that server information
   which was retrieved from DNS was from an authorised party; e.g.  an
   organisation which is not at all part of a given roaming consortium
   may alter its own DNS records to yield a result for its own realm.

   RADIUS/TLS and RADIUS/DTLS have their own ways how to verify that a
   contacted peer is authorised (e.g.  by presenting PKIX certificates
   from a agreed-upon CA).

> 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?

That's what the tracking of TTL for results is good for: if a new
request comes in, and an existing session to a home server exists, and
the TTL for discovering that connection has not expired, then the
connection should be re-used.

This is (meant to be) expressed in section 2.3.4.

Shall I add a forward-reference to 2.3.4 in 2.1?

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

Fixed, thanks.

> 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?

SRV and NAPTR. I've updated the text to be more explicit.

> 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.

I prefer to see if later stages of review find that difficult as well
(my choice of O could of course be confused with a 0; that would be bad).

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

RADIUS attributes must be at least one byte long; so this case is not
possible.

> 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.

Right, thanks. I took that entry out of the "unspecified" list for -06.

> 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.

Fixed, thanks.

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

I've replaced all occurences of { } with your suggestion, thanks.

> 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.

This needs a more thorough answer than I have time before the cutoff :-)

I'm creating a TRAC ticket so that this doesn't get forgotten.

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

Changed.

> 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?

That depends on what the NAPTR record returned.

If the result was a "s" NAPTR - the next step is to query that SRV (and
then A/AAAA on the resulting hostnames).

If the result was an "a" NAPTR - the next step is to query for the
A/AAAA record directly.

If the result was a "u" NAPTR, well, do what's inside the regex [I've
never really understood that voodoo].

IOW, for the purposes of this draft, the initial NAPTR record provides
the first step in a path that will *eventually* yield a A/AAAA and port.
The exact steps how to perform the subsequent lookups is "normal DNS
business" and is not/doesn't have to covered here.

Do you think this should have text in the document itself? I had hoped
the wording of step 7 was concise and yet understandable enough (the
text looks really ugly with a huge text in this one step).

> 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.

It's a non-XOR OR. :-) If the entity which executes the algorithm
supports only one of the two, it would only make the query which fits.
If it supports both, it could attempt both (the order to use would be a
configuration item, like "preferred_transport = dtls").

Does this need extra text?

> 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.

Right; since it's only one layer, the SRV record of course results in
hostnames immediately. Sorry about that, I'll purge step 13 from the
face of the earth.

> 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?

When it's the same realm, the connection should be re-used. I've
clarified that for -06 now.

> 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"?

Hm. That would indeed require an overloading of the result set to either
contain the tuple, or the negative TTL. I prefer to do that (if
overloading is a good idea?) after the cutoff. I'm adding this issue to
TRAC.

> 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?

RADIUS has a very simple operational model; failure is failure :-)

The best guess here would be to have a statically configured DEFAULT
target with a lower priority than the dynamic discovery. Which in fact,
we use in eduroam quite successfully (because NAPTR is not ubiquitous in
all realms yet).

However, this document describes only the algorithm; an empty set does
not mean the user is rejected - it only means that DNS didn't give
sufficient hints to find the destination. The RADIUS configuration in
the server may well have other ways to forward requests.

> 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?

Possibly. I'll craft some text around that; but again I'll put it into
TRAC to think about first.

> 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.

There are different trust models than just matching of
CN/SubjectAltName:DNS. Something for further discussion -> TRAC.

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

DANE is indeed an alternative; we're currently thinking about this in
eduroam. I believe it's worthwhile to add text to that effect.

> 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.

I'm arguing TLS-PSK cipher suites are not suitable for use in this
context. The Trust Router people have some wonderful ideas about using
TLS-PSK in a dynamic context though (but it doesn't involve DNS IIRC).

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

I do :-)

Fixed, thanks.

Stefan

> 
> 
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
> 

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473