Subject: [pkix] Registration of a new sAN:otherName (NAIRealm)

From: Stefan Winter <[email-masked]>
Date: Fri, 28 Jun 2013 11:22:29 +0200

Hello,

over in the RADIUS Extensions working group we are working on a
discovery mechanism for RADIUS/TLS authentication servers. The algorithm
makes use of DNS, -SEC is optional; in the absence of DNSSEC an X.509
certificate of the discovered server needs to yield information whether
it is authoritative for a NAI realm (i.e. "the 'domain' part of a
User-Name attribute, in the form of user@realm").

The discovery starts with a NAPTR for the service in question, and then
may traverse a set of SRVs or not, to eventually end up at an A/AAAA
record of the discovered hostname.

Determination of the authoritativeness needs to be a part of the
certificate; in a way analogous to SRVName. We cannot use SRVName
directly though, since a possible SRV record occurs in the middle of a
potentially untrusted lookup; if an attacker modified the initial NAPTR
response, he can divert further SRV resolution steps to his own server.

For that reason, we think we need a new sAN:otherName registration which
allows us to compare that realm part of a User-Name (the actual,
known-correct input to the algorithm) to the NAIRealm property of the
certificate of the server that came out of the discovery process.

In short:

1) Input: [email-masked]

2) discovery algorithm yields output:
   please contact A.B.C.D:2083 with RADIUS/TLS

3) TLS handshake verification: does X.509 cert contain
   sAN:otherName:NAIRealm == myrealm.example

I have a new draft rev of
https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ on
my disk, which registers otherName:NAIRealm just like RFC4985 did (in
fact, it is copy&paste :-) .

I noticed that I need an integer in the "otherName" registry; RFC4985
uses id-on-dnsSRV = 7; and I wonder who to approach and where to get my
own integer for

     id-on-nai OBJECT IDENTIFIER ::= { id-on XXX??? }

from.

I appreciate any thoughts on the overall approach, and on the allocation
of that new integer.

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: Russ Housley <[email-masked]>
Date: Fri, 28 Jun 2013 10:46:19 -0400

Stefan:

I suggest that you write a one or two page I-D that specifies the proposed alt name, and then bring it to this mail list for review.

Russ

On Jun 28, 2013, at 5:22 AM, Stefan Winter wrote:

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

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 29 Jun 2013 16:14:33 +0200

Hi,

I suspect you have made a misinterpretation of the service name SAN
defined in RFC 4985.

When you say:
"We cannot use SRVName
directly though, since a possible SRV record occurs in the middle of a
potentially untrusted lookup;"

Then I suspect you miss the whole pint with RFC 4985.

The whole point is the the SRV record from DNS is not, or may not be,
trusted. It's just used for lookup.
Once you found a potential service host through DNS lookup, you can verify
that it is authorised to actually provide this service using its
certificate.
What the service name defined in RFC 4985 provides is precisely this, a
means to authenticate that a particular server/host is actually authorised
to provide a particular service.

The assertion in the cert is not made by DNS, it is made by a
certification authority (CA) that you presumably trust to make this
assertion.
The similarity of name form used in the service name SAN is just to make
it easy to compare this name with information obtained from the DNS.

I could be missing something, but, following your draft the the example
given below, what prevents you from providing a service name SAN in
accordance with RFC 4985 with the value:

_radiustls.myrealm.example.com

This would provide an assertion independent of DNS, that this host is
authorised to provide RADIUS/TLS for the myrealm.example.com domain.

/Stefan