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

[Stefan Winter <[e-mail]>]

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