Subject: [radext] #168: Remaining issues for dynamic-discovery draft

From: "radext issue tracker" <[email-masked]>
Date: Wed, 03 Jul 2013 14:20:20 -0000

#168: Remaining issues for dynamic-discovery draft

 This ticket captures the remaining comments on the ML that need to be
 worked on:

 1) NAIRealm certificate extension

 1.1 allocation of an OID is pending
 1.2 Comment by JS: "Are you sure you want NAIRealms to be IA5String and
 not UTF8String?  This is an I18N question."
 1.3 Comment by JS: "This text would appear to say that foo.*.bar is a
 legal wildcard NAI realm. Is that what you want?"

 2) Privacy (JS)

 "Should there be a potential privacy concern noted in this document
 surrounding the question of what information can leak based on the
 domain(s)
 being queried?  I am not sure that there is any usable information leaking
 here but this is not even close to my forte."

 3) subsequent lookup steps (JS)

 "In section 2.3.3 - May want to be a bit more detailed here about the
 subsequent lookup steps.  Presumably this is not starting with step 8 but
 I
 could be wrong.  I.e. do we take the set of result names and go back to
 step
 4 with new values of R?"

 These will be dealt with after -07 is out.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-radext-
  [email-masked]           |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  dynamic-discovery        |    Version:  1.0
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/168>
radext <http://tools.ietf.org/radext/>

---

From: Stefan Winter <[email-masked]>
Date: Thu, 04 Jul 2013 15:34:41 +0200

Hi,

>  1.1 allocation of an OID is pending

I'll send a notification about -07 to the pkix list to keep the ball
rolling.

>  not UTF8String?  This is an I18N question."

I didn't think much during copy&paste - which was probably a mistake :-)

I want things to be aligned with the new NAI document. After all, the
purpose of the certificate extension is to compare it to the original
NAI of a user request; they should naturally be in the same format.

Since the NAI document allows UTF-8 input which is not restricted to the
ASCII subset, the certificate extension should allow that, too.

Just before submitting -07 I realised that, so -07 now speaks of UTF8String.

>  legal wildcard NAI realm. Is that what you want?"

It is what I wanted. But I have to say that this area is not my
preferred; I keep hearing from DNS people that wildcard names are
generally evil and that they should either be forbidden (but I think
they are necessary in our case to allow for proxy operation) or
lobotomised as much as possible.

If there is consensus on lobotomising the wildcard names so that left of
a star component is either another star component or nothing -
preventing the foo.*.example construct - , then I'm fine with changing
it that way.

>  here but this is not even close to my forte."

I can't think of any (and in eduroam we are traditionally extremely
excited about privacy preservation, so not being able to think of
privacy concerns for an eduroamer means something :-) ).

The algorithm only processes a domain name; anything left of the @ is
stripped before the first query. Also, the domain name is not vetted in
any way.

If someone were to observe the DNS traffic coming out of the RADIUS
forwarding server which executes the algorithm, he could only deduce
"someone who claims to belong to domain x.y wants to authenticate".

On the other end of the DNS queries, a DNS operator will see that
queries come in from a particular source, and will be able to conclude
"someone who claims to belong to my domain is near that querying server".

I find none of those two very exciting information; but this is of
course subject to discussion.

>  could be wrong.  I.e. do we take the set of result names and go back to

In -07 I am now referring directly to the S-NAPTR RFC, which has more
detailed provisions for the lookup steps.

I believe you were aiming at non-terminal lookups (empty FLAG field)?

These yield a new label to lookup NAPTR for, that's true. This is not
"going back" to a previous step though, it's just part of the normal
descendence on a NAPTR -> SRV/A/AAAA branch. I.e. the next query will
then be another NAPTR query for the new label, which will either be yet
another non-terminal (more NAPTRs to follow), or a "S" or a "A" NAPTR.

The initial value of R always needs to be retained for the server
identity and handshake verification.

Or maybe I mis-understood your comment.

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

---

From: Stefan Winter <[email-masked]>
Date: Tue, 16 Jul 2013 14:53:18 +0200

Hi,

I'm currently assembling a slide deck (yes, I know, I'm too early ;-) )
for IETF87, and am wondering which of these issues deserve some airtime
during the Berlin meeting.

In summary, my idea of those issues is:

1) NAIRealm certificate extension
---------------------------------
get an OID for UTF8String; no opinion about intermediate wildcards
(foo.*.bar)

2) Privacy (JS)
---------------
Suggest: no text update needed.

3) subsequent lookup steps (JS)
-------------------------------
Scheduled for discussion in detail on slide deck, including input from
Brian Julin.

All, especially Jim, if you're happy about the no-text action on issue
2, please let me know.

And if anyone has strong feelings about the wildcard thing - please do
hit the Reply button.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473