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

From: Stefan Winter <[email-masked]>
Date: Mon, 01 Jul 2013 14:38:10 +0200

Hi Stefan,

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

That's the point: the SRV can usually be verified because it is the RR
that is looked up in DNS; i.e. the label to look for is trusted. The
result of the lookup can then be untrusted, because the cert property
can be verified against the label that was queried for.

That is not the case in my draft: the RR being looked up is a NAPTR
record; it may subsequently lead to a SRV, or it may not.

The unpleasant thing is: in the absence of DNSSEC, this initial NAPTR
could be altered to point to a /different/ SRV than expected. An
attacker may have a certificate which authorises him to serve that other
SRV; it's just not where the request was supposed to end up.

Example:

genuine lookup
--------------
Algo input: realm = good.example
First query:
   Label: good.example;
   RR: NAPTR;
   response: "s" _service._sctp.good.example
second query:
   Label: _service._sctp.good.example
   RR: SRV
   response: port 12345, server.good.example

-> SRV label == SRVName in cert
-> traffic gets sent to server.good.example

NAPTR altered by attacker (who has a certificate for the host
server.bad.example, authorising it to serve _service._sctp.bad.example)
-------------------------
Algo input: realm = good.example
First query:
   Label: good.example;
   RR: NAPTR;
   response: "s" _service._sctp.bad.example
second query:
   Label: _service._sctp.bad.example
   RR: SRV
   response: port 54321, server.bad.example

-> SRV label == SRVName in cert
-> traffic gets sent to server.bad.example

As you see, the altered lookup by the attacker will be undetected later:
DNS states that _service._sctp.bad.example is the service to go to; and
the server being contacted has a certificate authorizing it for that
service's delivery. This would look like an "all green" situation -
while in fact the target is not the correct server.

IOW, the SRVname + DNS RR SRV protection is annuled because an earlier
DNS resolution step (NAPTR) cannot be verified with any certificate
property.

That's why I initially wrote "in the middle of"; sorry for the tense
language.

Also note that NAPTR entries can be of type "a" which do not generate an
intermediate SRV result at all; they immediately lead to a hostname.
SRVName is of no particular use there.

The attack above could be mitigated by having a certificate property
listing which NAPTR entries might ultimately lead to a server, so that a
CA could embed that. That would be a rather generic solution, but in
fact so generic that I don't fully overlook its complexity (there are
many categories of NAPTR usage) and also frankly I do not have much of
an appetite for work on it.

The attack can also be mitigated by the NAIRealm property I requested
initially; this is a specific solution for the AAA routing problem we're
looking at. That one I am keen on solving :-)

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

The draft specifically needs to consider that a server may be authorized
to receive traffic for /some/ realms in a roaming consortium, but not
others. Such an "inside attacker" would have a valid certificate from an
accredited CA etc., and have SRVNames for one or more of the domains in
the roaming consortium; but it may decide to manipulate NAPTR DNS
entries to have another realm point via the wrong NAPTR to its own SRV
entry.

I hope this explains things a little better.

Greetings,

Stefan

> 
> /Stefan
> 
> 
> On 6/28/13 11:22 AM, "Stefan Winter" <[email-masked]> 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