Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad

From: "radext issue tracker" <[email-masked]>
Date: Wed, 26 Jun 2013 13:16:08 -0000

#148: Review of dynamic-discovery by Jim Schaad

Comment (by [email-masked]):

 > 1) In section 2.3.3, step 4 - what is to be considered an error at this
 point.  For example, there are a number of odd conditions that can be
 returned from DNSSEC, specifically the "indeterminate" state.

 I've added text in my working copy which white-lists two sorts of replies
 as good, and everything else as an error. Hope that is adequate and
 removes all ambiguity:

 "2.3.3.  Definitions

    Where the algorithm states "name resolution returns with an error",
    this shall mean that either the DNS request timed out, or every
    response except a) the RR queried for and b) the positive
    acknowledgement that the record queried for does not exist (i.e.
    status: NXDOMAIN)."

 > 2) In section 2.3.4 - Given that the above algorithm does not return a
 TTL value in the event of an empty set or define how to know the TTL value
 - what is the TTL value to be used in in paragraph 2 "negative TTL"?

 I'll have to modify the return value to be a tuple with the second element
 being the place to put a negative TTL into (either as learned from an
 NXDOMAIN reply or configured in case of an absence of any reply). I'll
 keep this TRAC ticket open for this sub-issue.

 > 3) In section 2.3.5 - Does it make sense to return a result, but to
 continue the algorithm and store the result after the timeouts for later
 use?

 We discussed this in the last meeting. It's generally a bad idea (end-
 users can enter bogus DNS data and DoS the server by trying to login with
 corresponding realms). An implementation could be brave and do that
 anyway, so I've added text to Security Considerations explaining the
 issues with it. Implementations can then do a judgment call whether they
 want to take this risk. The text is:

 "   The algorithm has a fixed completion time-out of three seconds.
    Implementations might be tempted to continue their attempt to resolve
    DNS records even after the timeout has passed; a subsequent request
    for the same realm might benefit from retrieving the results anyway.
    Doing so exposes the server to a Denial-of-Service risk: an attacker
    might intentionally craft bogus DNS zones which take a very long time
    to reply (e.g. due to a particularly byzantine tree structure, or
    artificial delays in responses).  If an attacker generates enough
    Access-Requests for a number of such zones, it may deplete server
    sockets or other server resources."

 > 4) I find the security considerations to be completely inadequate for
 this document.
 > Use of a certificate is only going to be valid if the original realm
 name that is the input the validation routine is what is found and matched
 in the certificate.  In this case I would not know where in the name or
 alt name fields of the certificate it would be found.  You cannot validate
 to the final DNS name as that is now an untrusted value.

 We discussed on the list that an MTI validation mechanism which works in
 the absence of DNSSEC is needed (sigh!). I'll work on corresponding text
 soon. I'll keep this TRAC ticket open until the text is ready.

 > The suggestion of out-of-band validation methods ignores the existence
 of DANE.
 >
 > The NAI document suggests that the RADIUS peer is pre-configured with
 information about certificates or TLS validation data.  The suggested text
 works in the case that the table says do dynamic lookup and here is the
 TLS configuration data.  But in other cases it is completely unclear how a
 TLS-PSK would be found for a dynamic lookup.

 These were both discussed on the list; DANE is clumsy/not usable in its
 current state; TLS-PSK is not in scope for this document.

 Greetings,

 Stefan Winter

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

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/148#comment:1>
radext <http://tools.ietf.org/radext/>

---

From: Stefan Winter <[email-masked]>
Date: Wed, 26 Jun 2013 16:19:26 +0200

Hi,

> I strongly favor the first.  I agree that it means that you need to have
> a field in the cert that contains the realm's name.
> There are fairly obvious ways this can be done in a SAN.
> RFc 4985 is an example of how microsoft does this.
> My concern with the dnssec approach is that while it's easy to specify,
> 
> I'm concerned that dnssec APIs are not widely available enough at
> userspace levels outside the resolver that I'd have confidence
> radsecproxy or freeradius or other radsec implementations could actually
> implement dnssec validation in the radius proxy right now.

My current working copy defines NAIRealm as a new otherName. At least I
hope that's what it does; I mostly copy&pasted from RFC 4985 and
replaced the strings.

I had to pick an integer for the object identifier; but couldn't find
the registry which holds all the assigned values. So I had to guess - I
picked { id-on 9 }. Beat me with a club if I stole someone's ID. Does
the usage of this pobject ID need to be registered with IANA? If so, let
me know and I'll add a note to IANA considerations.

I also copied the 1993 ASN syntax (assuming that we really don't have to
bother the 1988 one?) into an appendix A.

The text now reads:

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

   This specification retrieves IP addresses and port numbers from the
   Domain Name System which are subsequently used to authenticate users
   via the RADIUS/TLS protocol.  Since the Domain Name System is not
   necessarily trustworthy (e.g. if DNSSEC is not deployed for the
   queried domain name), it is important to verify that the server which
   was contacted is authorized to service requests for the user which
   triggered the discovery process.

   The input to the algorithm is a NAI realm as specified in the next
   section.  As a consequence, the X.509 certificate of the server which
   is ultimately contacted for user authentication needs to be able to
   express that it is authorized to handle requests for that realm.

   Current subjectAltName fields do not semantically allow to express an
   NAI realm; the field subjectAltName:dNSName is syntactically a good
   match but would inappropriately conflate DNS names and NAI realm
   names.  Thus, this specification defines a new subjectAltName field
   to hold either a single NAI realm name or a wildcard name matching a
   set of NAI realms.

   This section defines the NAIRealm name as a form of otherName from
   the GeneralName structure in SubjectAltName defined in [RFC5280].

      id-on-nai OBJECT IDENTIFIER ::= { id-on 9 }

      NAIRealm ::= IA5String (SIZE (1..MAX))

   The NAIRealm, if present, MUST contain an NAI realm as defined in
   TODO: the new NAI document.  It may substitute labels on all dot-
   separated parts of the NAI with the character "*" to indicate a
   wildcard match for "all labels in this part".

   Appendix A contains the ASN.1 definition of the above objects."

And that appendix is:

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

      PKIXServiceNameSAN93 {iso(1) identified-organization(3) dod(6)
          internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
          id-mod-dns-srv-name-93(40) }

      DEFINITIONS EXPLICIT TAGS ::=

      BEGIN

      -- EXPORTS ALL --

      IMPORTS

         id-pkix
               FROM PKIX1Explicit88 { iso(1) identified-organization(3)
               dod(6) internet(1) security(5) mechanisms(5) pkix(7)
               id-mod(0) id-pkix1-explicit(18) } ;
                -- from RFC 3280 [N2]

      -- In the GeneralName definition using the 1993 ASN.1 syntax
      -- includes:

      OTHER-NAME ::= TYPE-IDENTIFIER

      -- Service Name Object Identifier

      id-on   OBJECT IDENTIFIER ::= { id-pkix 8 }

      id-on-nai OBJECT IDENTIFIER ::= { id-on 9 }

      -- Service Name

      naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-nai }}

      NAIRealm ::= IA5String (SIZE (1..MAX))

      END"

The text specifying that checking for this name is MTI is not written
yet; please wait for day++.

Stefan

-- 
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: Sam Hartman <[email-masked]>
Date: Wed, 26 Jun 2013 12:58:13 -0400

Why didn't you just use RFC 4985?
You already have a service tag.

---

From: Stefan Winter <[email-masked]>
Date: Thu, 27 Jun 2013 13:30:44 +0200

Hi,

> You already have a service tag.

The algorithm encounters SRV records only in the middle of the
(untrusted) discovery process. If the first-step NAPTR is counterfeit by
an attacker, it can point to its own SRV, for which it may well have a
valid certificate. That makes using SRV entries and corresponding
SRVName entries from RFC4985 unfit for this purpose.

What the algorithm really needs to do is compare the actual input,
before asking any untrustworthy DNS servers, to the end result of the
discovery process. So it needs to compare the NAI it used to trigger
discovery to the server cert - and the server cert needs to have the NAI
realm(s) it is authoritative for encoded within.

Overloading RFC 4985 syntax also doesn't work (let alone it being a bad
idea); it mandates a syntax of _service.name - and the _service
construct is not part of NAI realms.

So unless I'm seriously mistaken in the above, I think we need a new
otherName which matches the NAI realm semantics.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Thu, 27 Jun 2013 15:21:15 -0400

I'd recommend coordinating with the pkix working group to get OIDs.
I think Russ manages the registry.

---

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

Hi,

> I think Russ manages the registry.

I triggered that on the pkix mailing list now. Thanks for the pointer!

Stefan

Tel: +352 424409 1
Fax: +352 422473