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

From: Stefan Winter <[email-masked]>
Date: Mon, 01 Jul 2013 16:00:19 +0200

Hi,

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

Please find attached a pre-print copy of
draft-ietf-radext-dynamic-discovery-07; I'm still working on it and this
is not offcially submitted.

Still, it contains the relevant items for the PKIX discussion. Please
take a look at:

2.1.1.3.  Server Identification and Handshake
2.1.1.3.1.  Mandatory-to-implement mechanism: Trust Roots + NAIRealm

For the usage of the new otherName.

2.2.  Definition of the X.509 certificate property
      SubjectAltName:otherName:NAIRealm

Contains explanations why sRVName and dNSName are not good fits, plus
the placeholder OID registration.

Appendix A.  Appendix A: ASN.1 Syntax of NAIRealm

contains the 1993 ASN.1 definition of the new object. (I omitted 1988,
hoping that it is obsolete?!)

Greetings,

Stefan Winter

> 
> Russ
> 
> 
> 
> On Jun 28, 2013, at 5:22 AM, Stefan Winter wrote:
> 
>> 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
> 
> 
> 
>> _______________________________________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
> 
> 

-- 
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: Fri, 05 Jul 2013 16:26:33 +0200

Hello,

> is not offcially submitted.

-07 is now published:

https://www.rfc-editor.org/internet-drafts/draft-ietf-radext-dynamic-discovery-07.txt

> hoping that it is obsolete?!)

The section numbers are still the same. There is one change in content:
It's not an IA5String but a UTF8String. The value in the cert needs to
be compared with the NAI realm; and that realm is itself UTF-8. So to
enable byte-by-byte comparison of non-ASCII realms, it's got to be
UTF8String.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: [email-masked] (Martin Rex)
Date: Fri, 5 Jul 2013 21:07:18 +0200 (CEST)

> enable byte-by-byte comparison of non-ASCII realms, it's got to be

Uh-oh!

Comparisons for the purpose of authentication (or endpoint identification)
require clear and strict canonicalization and comparison rules
(e.g. case-sensitivity).

UTF8String might turn out to be a royal PITA for comparisons
at this software layer.  Have you carefully considered the ramifications?

For names that are also used as DNS labels, the (most recent revision) of
the TLS extension spec has this for the TLS extension Server Name Indication:

  http://tools.ietf.org/html/rfc6066#page-7

   Currently, the only server names supported are DNS hostnames;
   however, this does not imply any dependency of TLS on DNS, and other
   name types may be added in the future (by an RFC that updates this
   document).  The data structure associated with the host_name NameType
   is a variable-length vector that begins with a 16-bit length.  For
   backward compatibility, all future data structures associated with
   new NameTypes MUST begin with a 16-bit length field.  TLS MAY treat
   provided server names as opaque data and pass the names and types to
   the application.

   "HostName" contains the fully qualified DNS hostname of the server,
   as understood by the client.  The hostname is represented as a byte
   string using ASCII encoding without a trailing dot.  This allows the
   support of internationalized domain names through the use of A-labels
   defined in [RFC5890].  DNS hostnames are case-insensitive.  The
   algorithm to compare hostnames is described in [RFC5890], Section
   2.3.2.4.

   Literal IPv4 and IPv6 addresses are not permitted in "HostName".

-Martin

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 5 Jul 2013 14:34:09 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Rex
> Sent: Friday, July 05, 2013 12:07 PM
> To: Stefan Winter
> Cc: [email-masked]
> Subject: Re: [pkix] Registration of a new sAN:otherName (NAIRealm)
> 
> Stefan Winter wrote:
> >
> > > draft-ietf-radext-dynamic-discovery-07; I'm still working on it and
> > > this is not offcially submitted.
> >
> > -07 is now published:
> >
> > > 2.1.1.3.  Server Identification and Handshake 2.1.1.3.1.
> > > Mandatory-to-implement mechanism: Trust Roots + NAIRealm
> > >
> > > Contains explanations why sRVName and dNSName are not good fits,
> > > plus the placeholder OID registration.
> > >
> > > contains the 1993 ASN.1 definition of the new object. (I omitted
> > > 1988, hoping that it is obsolete?!)
> >
> require clear and strict canonicalization and comparison rules (e.g. case-
> sensitivity).

In this case the ramifications are being considered in the document
describing NAIs (http://datatracker.ietf.org/doc/draft-ietf-radext-nai/) and
we have been beating this issue around for a long time.

Jim

> 
> 
> UTF8String might turn out to be a royal PITA for comparisons at this
> software layer.  Have you carefully considered the ramifications?
> 
>

---

From: [email-masked] (Martin Rex)
Date: Sat, 6 Jul 2013 00:56:47 +0200 (CEST)

> we have been beating this issue around for a long time.

The draft you mention properly describes the underlying problem:

                                                  We RECOMMEND that the
   owner of the realm pre-provision all proxies with the "utf8-realm"
   portion of the NAI, along with the value returned from passing the
   "utf8-realm" to the ToAscii function.  This key-value pair can then
   be placed into the logical AAA routing table discussed above.  Having
   only one entity perform the ToAscii function ensures that the result
   returned by that function are considered as canonical by all other
   participants in a AAA network.

For the TLS extension ServerNameIndication this means, that
the certifcate (sAN-DNSName) *MUST* contain the A-label
(which is also necessary since it is limited to IA5String),
and the TLS extension SNI conveys the A-label, and the Server
does a binary matching of the server name conveyed through
TLSextSNI to the DNSName-sANs of his server certificates.

In the TLSextSNI scenario, the "only one entity" doing the ToAscii
is the TLS Client (more likely the application caller on top of it),
so that what the client will use to perform ServerEndpointIdentification
with the Server's Certificate is the exact same A-Label that is sent
in TLSextSNI and the exact same A-Label that the server uses for
choosing the most appropriate server certificate.

Admittedly, I haven't check this draft, but storing an
UTF8String in a certificate sAN is very likely to cause multiple
independent entities having to compare user input to that sAN,
and the trouble-maker that the above paragraph warns about.

-Martin

---

From: Stefan Winter <[email-masked]>
Date: Mon, 08 Jul 2013 11:41:45 +0200

Hi,

>    participants in a AAA network.

i18n has a long (but not very pretty) history in radext/EAP/802.1X. The
text you quote is basically the least of many evils in that area.

You're of course invited to read up on the history of i18n by looking at
the last 4 years worth of threads about the topic on the radext list;
but here's a short recap of how things are, and why they are basically
fubar'ed as defined in RFC3092, section 2.3.

RADIUS requires User-Name to be UTF-8 (but makes no provisions regarding
a canonicalised format).

EAP makes no reservations at all about encoding of an EAP Identity.

IEEE 802.1X requires that EAP Identities are taken as input, and put
into a AAA protocol User-Name attribute (such as RADIUS). The entity
doing that is a "pass-through authenticator", and the mapping is done by
copying EAP-Identity byte-by-byte into the User-Name.

Here's the catch: the EAP peer, not required to use UTF-8 nor a
canonicalised format, also does not know that his next-hop pass-through
authenticator is going to use RADIUS as a AAA protocol; and he can't be
signaled any such thing either.

So the EAP peer can "rightfully" send his EAP identity in any
representation, say, latin-1. The pass-through authenticator will need
to copy that into User-Name byte-by-byte. The result is a malformed
packet; User-Name MUST be UTF-8 - but isn't.

There is also no way for the pass-through authenticator to be clever and
convert the incoming latin-1 to UTF-8 encoding: the string sent inside
the EAP-Identity response does not contain character set information.

This may mean that e.g. a RADIUS server serves authoritatively a realm
"éducation.example" (i.-e. terminates EAP for that realm and acts as EAP
server); and has it in its config with its NFC normalised UTF-8 form. If
a client decides to send that same realm in a non-canonical form, the
RADIUS server will figure out "I know nothing about that realm, go
away." The authentication will fail.

Not being able to impose rules on the original input from EAP-Identity,
the conclusion in radext at some point was that this situation is "too
bad" and unfixable.

The only fix, or more like "behavioural workaround" we saw was to
mandate that EAP peer and RADIUS/EAP server operator sit together and
see which representations of the realm are expected to show up on the
wire, and consequently configure all these respresentations on the
RADIUS server, so that the incoming request would be correctly
identified as belonging to that server.
Ways to get this done probably include helpdesk traffic, because some
user will bring along an EAP implementation doing strange things, and
debugging needs to be done figure this yet-another-new-representation of
an i18n'ed realm.

The text in the draft you quote only makes a RECOMMENDATION that two
such forms would be a UTF-8 one and a ToASCII one. We have to live with
the deployed reality that anything else can be in there though.

All of the above does not speak about intermediate proxies at all.

If you add proxies to the mix, the requirement to configure all expected
representations of the realm on the RADIUS server extends to all the
proxies which may want to deliver authentication requests to that
server. Being out-of-sync regarding configured representations in such a
scenario can lead to nasty surprises; e.g. if one of the peers has a
DEFAULT route, there's an easy way to introduce a routing loop:

Server A is configured to forward auth requests for realm X in the
following three representations: X, X', X'' to server B.

Server B is authoritative for realm X, and configured to recognise the
representations X and X'; for guest users from any other realm it has a
DEFAULT route pointing to server A.

A user comes along and uses X''. Server A will forward to B, B will
forward to A, A will forward to B. And so on.

BTW, RADIUS has no loop detection. (Some argue that it is a sufficient
loop detection that each proxy adds a Proxy-state attribute which will
at some point crack the absolute packet size boundaries and make the
request fail).

The operational complexity of handling this is significant.

All of the above does not consider using DNS as the "configuration"
source, nor the NAIRealm validation.

The reason why I went down the path of UTF8String is that I believe the
same transpiring of the various representations of the User-Name (and
with it NAI realm) that happens to proxies in general also needs to
happen in the DNS discovery case: There is a RADIUS proxy sitting in the
middle, which gets "some string" and needs to see if that "some string"
is handled authoritatively by a discovered server. The proxy doesn't
earn any bonus points for gratiutously converting to NFC and using NFC
to lookup the NAIRealm cert property: maybe both EAP peers and the
authoritative server operator choose not to use NFC; that is their
business alone and it's undue for a proxy to deny forwarding to the
proper server just because it has its own opinion on how the string
should be formed.

In that light, an even more relaxed definition of NAIRealm should also
allow non-UTF-8 input, in case both EAP peer and the authoritative
server want to use $STRANGE_ENCODING_HERE.

I don't know enough about the OID data types for that. I guess something
like a "binaryBlob" would then be an appropriate data type.

> choosing the most appropriate server certificate.

The good thing about TLS is that you don't typically deal with
content-inspecting proxies, right? (Unless you're part of the PRISM
programme)

That of course removes a whole lot of complexity from the problem.

> and the trouble-maker that the above paragraph warns about.

That's why the only supported comparison is byte-by-byte (with a simple
wildcard support). The proxy in the middle only verifies that the
ultimate origin (EAP supplicant on end-user machine) uses the same
representation of the string that the destination (discovered server)
advertises as a supported representation. The fact that the proxy might
have transformed the input into punycode, and looked up a different
string in DNS to get an IP address to contact, is irrelevant for the
string comparison.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473