Subject: [radext] Review comments for draft-ietf-radext-dynamic-discovery-08

From: "Jim Schaad" <[email-masked]>
Date: Thu, 5 Dec 2013 10:53:22 -0800

Here are a set of comments on the most recent draft:

1.  Here is a question out of ignorance, is there going to be a potential
problem with DIME about the service tags that are being requested?  These
concepts are used for Diameter as well and we are trying to reserve them as
being RADIUS specific in this context.

2.  In section 2.1.1.2 paragraph 4 - it is not clear to me if it would be
legal for me to retry a TLS handshake if I had a second credential that the
server might find acceptable.  The current language appears to say no it
would not be.

3.  In section 2.1.1.3 paragraph 1 -   Suggested sentence #2
   Since the dynamic discover algorithm does not have provisions to
establish confidential keying material between the RADIUS/TLS client (i.e.
the server which executes the discovery algorithm) and the RADIUS/TLS server
which was discovered, TLS-PKS ciphersuites cannot be used for in the
subsequent TLS handshake.

4.  In section 2.1.1.3.1 paragraph 3 - Section 2.2 should/does have the
comparison rules for dealing with NAIrealms as an other name.  Remove the
re-statement here as it is not a clear statement of the algorithm.   Move
the table of examples to section 2.2 as part of the description there on how
to do the comparisons.

5.  In section 2.1.1.3.2 s/is:/is to/

6.  In section 2.1.1.3.2 last paragraph:  It is not clear to me what
shortcomings can and cannot be mitigated by this method.  The TLS tunnel to
the RADIUS server is not part of the system so that the hostile server could
just reflect to the real server and the EAP would be happy while the hostile
server can both snoop and change answers and questions in the middle.  Can
you be more explicit about what you think this addresses?

7.  In section 2.1.1.3.4:  I think that a section name along the lines of
"Client Authentication Issues" is much more informative than "Remark"  

8.  In section 2.1.2: I think that the last two sentences would be better
either in a common section or stated separately in the appropriate sections
for SRV and NAPTR records respectively.

9.  Section 2.1.3 - the section title could be more descriptive of what you
are saying in this section

10. Section 2.2 - Move the comparison rules to this section.  I believe that
they can be stated much more clearly if you put them as decompose into dot
separated items.  Compare the items on a byte-by-byte comparison. A star in
the first decomposed item matches all, a star in any other location is a
match failure. (Although better written than that.)

11.  I have attached an ASN.1 module that uses the RFC 5912 2002 ASN.1
modules and would request that you use that instead.  I note that you think
you have  a module number but not a other-name number.  I would be surprised
if this is the case and would have expected that both were issued at the
same time.

12.  Section 3.1 - Not sure that I understand the reasoning for item b.

13.  In Section 3.4.3  step 13 - should the 'or' be 'and/or' as it would
seem that one could do a lookup for both _tcp and _udp if desired.  An input
or output to the algorithm may need to be if udp or tcp is the desired
mechanism to use.  (I don't see a comparable selection in the NAPTR
processing.)

14.  In section 4 paragraph 1/2 - It is not clear to me if these paragraphs
are saying that DNS is required.  If this is not the case then you should be
more explicit about what being trusted means for an output.  From the "even
if" sentence it would appear nothing.

15.  In section 5 - I am having a problem with the fact that you are saying
that big clearing houses are no longer a problem.  On the mailing list you
have explicitly stated that this is still a standard configuration that will
exist.  It is also going to be unknown to either the user and to operators
if a clearing house is being used.

16. In section 5 - it is not clear which of the benefits are from just using
TLS/DTLS and which are actually from dynamic discovery.  (Passive observers
is just a TLS/DTLS benefit and can be done for classic as well.) 

17.  In section 5 - there probably needs to be made a statement that these
benefits only accrue to the link for which the dynamic discovery was done.
Other links may not have the same protection.

Jim

---

From: Stefan Winter <[email-masked]>
Date: Tue, 17 Dec 2013 17:22:48 +0100

Hi Jim,

> Here are a set of comments on the most recent draft:

Thanks a lot for this next round of in-depth review. Way to go!

> being RADIUS specific in this context.

The development of the RADIUS draft was done in sync with the Diameter
one. The service tags are fed from a disjoint pool of service denominations:

aaa+ is a common prefix
{ auth, acct, dynauth } is the suffix set used in RADIUS
ap[Diameter Application Integer code] is the suffix used in Diameter

So where RADIUS has constructs like "aaa+auth", Diameter has
"aaa+ap123"; there are no clashes. See RFC6408 section 3 for details.

> server might find acceptable.  The current language appears to say no it

Well... generally, this case would not happen; RFC6614 RECOMMENDS that
the other side of the TLS negotiation should indicate which CAs it
trusts, so that the respective other side will be able to pick a fitting
certificate on first try.

However, where that SHOULD is not implemented, or where the client has
multiple certs from the same CA, some suitable, some not, there may
arise situations where a retry is unavoidable.

I've changed my working copy to state:

" ... Such TLS handshake failures are permanently fatal and not eligible
for retry, unless the connecting client has more X.509 certificates to
try; in this case, a retry with the remainder of its set of certificates
SHOULD be attempted."

> subsequent TLS handshake.

Sounds clearer than my wording - I've updated my working copy with that
sentence. Thanks!

> the table of examples to section 2.2 as part of the description there on how

Good point. Removed from 2.1.1.3.1 and moved examples in my working copy.

> 5.  In section 2.1.1.3.2 s/is:/is to/

Changed. I used the same construct in 2.1.1.3.1 - changed that one, too.

> you be more explicit about what you think this addresses?

Using EAP allows the authenticating entity to detect if the final
destination was changed; i.e. if we arrived at a different EAP peer than
he should.

Using EAP does not prevent the "reflection" that you bring up in your
remark.

If such a reflection is put in place, EAP at least assures that the
hostile server can't see the user's password (and username, if anon
outer IDs are used). Some personal information may leak anyway if it's
transported in otherwise unprotected RADIUS attributes (say,
Calling-Station-Id).

I guess I should put those same explanations into the draft. :-) Here's
my go on a text describing it:

"The shortcomings in server identification can be partially mitigated by
using the RADIUS infrastructure only with authentication payloads which
provide mutual authentication and credential protection (i.e. EAP types
passing the criteria of [RFC4017]): using mutual authentication prevents
the hostile server from mimicking the real EAP server (it can't
terminate the EAP authentication unnoticed because it does not have the
server certificate from the real EAP server); protection of credentials
prevents the impersonating server from learning usernames and passwords
of the ongoing EAP conversation (other RADIUS attributes pertaining to
the authentication, such as the EAP peer's Calling-Station-ID, can still
be learned though)."

> "Client Authentication Issues" is much more informative than "Remark"  

I've changed it to "Client Authentication and Authorisation"

Is that okay?

> for SRV and NAPTR records respectively.

They are stated in their respective sections already; they are listed in
2.1.1 because the S-NAPTR requires them there; they are referenced in
2.1.2 because they also make sense in this other context.

To be honest, I think that moving "Definition of Conditions for
Retry/Failure" and "Server Identification and Handshake" may look
cleaner from text design perspective, but ultimately make the reading
for implementers harder. If I wanted to implement 2.1.1 NAPTR lookups,
I'd be happy to have everything confined in that section.

It's just word-smithing anyway - if folks on the list tell me that I'm
odd and Jim's suggestion makes way more sense, please let me know and
I'll merrily change it.

> are saying in this section

I've changed the section name to "Optional name mangling"; this should
capture the content more accurately.

> match failure. (Although better written than that.)

I now basically copied in what was previously in 2.1.something:

"  The comparison of a NAIRealm to the NAI realm as derived from user
   input with this algorithm is a byte-by-byte comparison, except for
   the optional leftmost dot-separated part of the value whose content
   is a single "*" character; such labels match all strings in the same
   dot-separated part of the NAI realm.  If at least one of the
   sAN:otherName:NAIRealm values matches the NAI realm, the server is
   considered authorized; if none matches, the server is considered
   unauthorized."

> if this is the case and would have expected that both were issued at the

Ehh. Rright. Probably :-) I don't know enough about ASN.1 and module vs
otherName numbers. I'll merrily copy&paste your definition. :-)

I can't help but notice that there are still mentions of SRVName in it
(PKIXServiceNameSAN93, id-mod-dns-srv-name-93(40) ). Could it be that I
initally forgot to replace them with NAIRealmName equivalents, and you
kept them in by c&p?

I guess we should take another close look at the *exact* bytes of this
ASN.1 definition after the next rev...

> 12.  Section 3.1 - Not sure that I understand the reasoning for item b.

Routing of DynAuth packets is asynchronous to that of authentication
requests; and the DynAuth Server which can handle DynAuth packets could
be different from the authentication server in that domain.

So, both need to be configurable and be discovered independently. They
both take an input in form of a domain name though, so by using two
different service tags, they can both use the same algorithm to discover
their respective targets:

a) to discover RADIUS servers which can authenticate users

b) to discover DynAuth servers for a domain which can receive DynAuth
packets to alter user sessions.

Should I maybe reference RFC5176 for clarity regarding b) ? I do in the
service tag table, but a little more verbosity here may not hurt. Please
let me know.

> mechanism to use.  (I don't see a comparable selection in the NAPTR

Yes; it's a non-exclusive OR. It depends on the capabilities of the
RADIUS client which executes the algorithm... if it only implements
TCP/TLS, it would only query for _tcp; if it supports both, it could try
both labels (which one it prefers is out of scope though).

NAPTR doesn't need this decision point - the NAPTR RR authoritatively
tells the querying entity which variant to try in which order.

> if" sentence it would appear nothing.

DNS - trust neither the resulting IP/port nor infer authorisation
DNSSEC - trust the IP/port, but still don't inter authorisation

(So, use DNSSEC or not, you still have to do extra work afterwards)

Actually, the section would read more clearly if I'd simply remove the
first para - it's redundant because the first sentence of para 2 says it
all.

I've removed the first para, does this clear up the ambiguity?

> if a clearing house is being used.

I don't think I'm saying that they are not a problem any more. The
section states that discovery can technically make them obsolete if the
operators in a consortium really want that.

There may be reasons unrelated to discovery which make them not want
that. That's a pity, but nothing this draft can help with (and the
second bullet makes clear that proxies are likely to remain in existence).

Packet inspection by all kinds of intermediates is big topic these days,
and I'm all for eliminating such snooping points. The TLS part does its
share, IP nodes can't read stuff any more; the discovery part can do its
part by taking away 0 or more intermediate RADIUS proxies.

This doesn't solve all problems in the space; including that the
existence of a proxy or not is not known to the end user. It also
doesn't tehcnically eliminate the possibility to deploy proxies at all.

If you are looking for that, we're talking of a different draft (but
that is such a complex problem that I have no idea what to write into
that one ;-) )

> is just a TLS/DTLS benefit and can be done for classic as well.) 

That's right,the first bullet of benefits comes from RFC6614 /
draft-dtls and is unrelated to dynamic discovery. I'm removing that brag
right by deleting the para.

I've added this though to compensate:

   o  Even where intermediate proxies continue to be used for reasons
      unrelated to dynamic discovery, the number of such intermediates
      may be reduced by removing those proxies which are only deployed
      for pure request routing reasons.  This reduces the number of
      entities which can inspect the RADIUS traffic.

> Other links may not have the same protection.

I've added:

   o  Since dynamic discovery operates on a RADIUS hop-by-hop basis,
      there is no guarantee that the RADIUS payload is not transmitted
      between RADIUS systems which do not make use of this algorithm,
      and possibly using other transports such as RADIUS/UDP.  On such
      hops, the enhanced privacy is jeopardized.

And this concludes my actions on your review. Phew!

I'm planning to publish a roundup -09 on Friday. If you have comments
before that, I'll try to get them in, if not, it's either a -10 or maybe
IETF LC (as I hope we are now nearing zero bugs :-) ).

Greetings,

Stefan Winter

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

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 30 Dec 2013 16:45:43 -0800

> -----Original Message-----
> From: Stefan Winter [mailto:[email-masked]]
> Sent: Tuesday, December 17, 2013 8:23 AM
> To: [email-masked]; Jim Schaad
> Subject: Re: [radext] Review comments for draft-ietf-radext-dynamic-
> discovery-08
> 
> Hi Jim,
> 
> > modules and would request that you use that instead.  I note that you
> > think you have  a module number but not a other-name number.  I would
> > be surprised if this is the case and would have expected that both
> > were issued at the same time.
> 

The process of getting OIDs assigned is being changed.  I will create a new
module and IANA section to deal with this and send it to you by the end of
the week.

> different service tags, they can both use the same algorithm to discover
their
> respective targets:
service
> tag table, but a little more verbosity here may not hurt. Please let me
know.

It would seem to me that this should then be the case of accounting as well.
It might be better to say that it needs to be unique for each service and
then state that new conversations would be needed for each service.  Is
DynAuth always a single round trip?

> > 13.  In Section 3.4.3  step 13 - should the 'or' be 'and/or' as it
> > would seem that one could do a lookup for both _tcp and _udp if
> > desired.  An input or output to the algorithm may need to be if udp or
> > tcp is the desired mechanism to use.  (I don't see a comparable
> > selection in the NAPTR
> > processing.)
> 
> Yes; it's a non-exclusive OR. It depends on the capabilities of the RADIUS
> client which executes the algorithm... if it only implements TCP/TLS, it
would
> only query for _tcp; if it supports both, it could try both labels (which
one it
> prefers is out of scope though).
> 
tells
> the querying entity which variant to try in which order.

That makes sense.  However the question does arise if the mechanism then
needs to be an output.

tuples {hostname; port; protocol; order/preference; Effective TTL}

> 
> > 14.  In section 4 paragraph 1/2 - It is not clear to me if these
> > paragraphs are saying that DNS is required.  If this is not the case
> > then you should be more explicit about what being trusted means for an
> > output.  From the "even if" sentence it would appear nothing.
> 
> DNS - trust neither the resulting IP/port nor infer authorisation DNSSEC -
> trust the IP/port, but still don't inter authorisation
> 
first
> para - it's redundant because the first sentence of para 2 says it all.
> 

Yes that does make it better

> 
> > 15.  In section 5 - I am having a problem with the fact that you are
> > saying that big clearing houses are no longer a problem.  On the
> > mailing list you have explicitly stated that this is still a standard
> > configuration that will exist.  It is also going to be unknown to
> > either the user and to operators if a clearing house is being used.
> 
> I don't think I'm saying that they are not a problem any more. The section
> states that discovery can technically make them obsolete if the operators
in a
> consortium really want that.
> 
> that. That's a pity, but nothing this draft can help with (and the second
bullet
> makes clear that proxies are likely to remain in existence).
> 
and I'm
> all for eliminating such snooping points. The TLS part does its share, IP
nodes
> can't read stuff any more; the discovery part can do its part by taking
away 0
> or more intermediate RADIUS proxies.
> 
> This doesn't solve all problems in the space; including that the existence
of a
> proxy or not is not known to the end user. It also doesn't tehcnically
> eliminate the possibility to deploy proxies at all.
> 
> If you are looking for that, we're talking of a different draft (but that
is such a
> complex problem that I have no idea what to write into that one ;-) )

I still find this paragraph somewhat confusing.  How about:

This protocol allows for RADIUS clients to identify and directly connect to
the RADIUS home server.  This can eliminate the use of clearinghouses to do
forwarding of requests, it also eliminates the ability of the clearinghouse
to then aggregate the user information that flows through it.  However,
there exist reasons why clearinghouses might still be used.  One reason to
keep a clearinghouse is to act as a gateway for multiple backends in a
company.

- I would rather talk about your issue in Eduroam as the reason as that is
probably more interesting, but I don't remember the details anymore.

Jim

> before that, I'll try to get them in, if not, it's either a -10 or maybe
IETF LC (as I
> hope we are now nearing zero bugs :-) ).
> 
> Greetings,
> 
> Stefan Winter
> 
> --
> 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
> 
recipient's key
> is known to me