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

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Stefan Winter
> Sent: Wednesday, June 26, 2013 7:19 AM
> To: Sam Hartman
> Cc: [e-mail]
> Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad
> 
> 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))

Are you sure you want NAIRealms to be IA5String and not UTF8String?  This is
an I18N question.

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

This text would appear to say that foo.*.bar is a legal wildcard NAI realm.
Is that what you want?

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