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

[Stefan Winter <[e-mail]>]

Hi,

>  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

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

>  1.2 Comment by JS: "Are you sure you want NAIRealms to be IA5String and
>  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.

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

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.

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

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.

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

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: [phone]
Fax: [phone]