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

From: "Jim Schaad" <[email-masked]>
Date: Mon, 1 Jul 2013 13:31:51 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of radext issue tracker
> Sent: Wednesday, June 26, 2013 6:16 AM
> To: [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad
> 
> #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)."

I wish I knew enough DNSSEC to say for sure, however this is a good step in
the right direction.

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

I am not sure that the DOS risk would be significantly larger between a 3
and a 6 second time out.  It would just require half as many requests.  A
better way of addressing the specific problem you have shown here would
involve black-listing of DNS queries and I don't see anything in this text
or the algorithm which talks about doing black listing of any type.

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

Great  - please state this in the introduction material

Jim

> 
>  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/>
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 1 Jul 2013 13:36:02 -0700

> Of Stefan Winter
> Sent: Wednesday, June 26, 2013 7:19 AM
> To: Sam Hartman
> Cc: [email-masked]
> 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: +352 424409 1
> Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 03 Jul 2013 16:07:50 +0200

Hi,

> I wish I knew enough DNSSEC to say for sure, however this is a good step in

After more feedback in anothe thread, I've refined the text even more. I
believe we are getting somewhere now :-)

> or the algorithm which talks about doing black listing of any type.

I've added more text which suggests rate-limiting (but want to leave the
details to implementations).

> Great  - please state this in the introduction material

There's actually a better place for this: the S-NAPTR RFC requires me to
wreite a section on "Server Identification and Handshake" anyway.

My current working copy has text to explain why TLS-PSK is bad, suggests
the NAIRealm certificate property (MTI), and has a non-MTI explanation
of what we do in eduroam.

As I thought more about DANE, I think we were actually a bit unfair: the
algorithm discovers a /server/. The identification and handshake
therefore only need to deal with server identification.

It's true that the contacted RADIUS server at some point also has to
make a determination whether it wants to talk to the RADIUS client, but
this doesn't have to be determined on the same grounds as the
server-side identification.

That's actually the same as with NAIRealm: this (MTI!) mechanism only
takes one through the server-side identification, the client auth is
left unspec'ed.

In that light, I think it's fair to add DNSSEC+DANE as one of the
mechanisms. I've added stub text about it; if there is sufficient
interest in the topic then this can be expanded.

I've added a remark that the discovery spec only concerns itself with
the server-side identification.

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

---

From: "radext issue tracker" <[email-masked]>
Date: Wed, 03 Jul 2013 14:12:16 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 My working copy now also contains text for the two remaining sub-issues
 above. I'll submit -07 probably by tomorrow; now closing this TRAC item as
 resolved fixed.

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

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