Hi,

> Did you consider the use of SNI as part of your solution?  This would allow
> for the use a different certificates for each thing you proxy and thus would
> reduce the need to re-issue certificates.  The only thing that would be
> needed is to add a new certificate for each new proxied realm

Back in the day: no :-)

But looking at SNI now sure looks somewhat promising. It's not a clear
winner though:

SNI as per the current RFC6066 definition includes only DNS hostnames.

The discovery algorithm in this draft will at some point end up at a
host which is responsible for a realm - but that does not mean this
hosts' DNS name is identical to the realm that was being queried. If ID
management is outsourced, the realm and the hostname can be completely
unrelated.

In a "dream world" where SNI would allow SAN:othername as an indication,
this might work pretty well though. It could combine Sam's
"SAN:othername realm=whatever " construct and combine it with a
client-side hint in SNI: please show me a certificate with this
SAN:othername included.

This would nicely bond together the realm, and the verification that the
discovered server is authorised for that particular realm (disregarding
the DNS host name).

As you correctly point out, this would *still* be less than practical in
a large-scale deployment, where an aggregation proxy would need to be
issued "hundreds" of certificates by a CA, but it would at least in
principle be a rather clean approach.

That said, the only way to get other names besides DNS names into SNI
would be by updating RFC6066. Certainly not impossible, but a big caliber.

Greetings,

Stefan Winter

> Jim
> 
> 
>> -----Original Message-----
>> From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf
>> Of Stefan Winter
>> Sent: Monday, March 04, 2013 11:05 AM
>> To: radext@ietf.org
>> 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.
>>
>> That's a reasonable concern to have, IMHO. I'd usually agree that the use
> of a
>> SAN is a safer bet right now. Unfortunately, we've burnt our fingers on
> that
>> one in eduroam already, so I'm somewhat reluctant to go down that path.
>> Here's the war story.
>>
>> In an early beta deployment, we also considered the exact mention of the
>> realm name the only safe thing to do. We used SAN:URI and filled it with a
>> URN which contained the realm name (that is probably not the most obvious
>> nor practicable way of doing things, but ... well.. it was an early beta).
>>
>> One of the things which are troublesome about this is that we found that
>> even with dynamic discovery, proxies continued to exist: for most eduroam
>> IdP's, operation of their own RADIUS/TLS enabled server, caring to get
> issued
>> certificates, checking revocation and so on, was seen as too complex.
>> Instead, they put the first-level aggregation server into DNS (with their
>> agreement) to catch all their traffic and use normal RADIUS "routing
> tables"
>> for the last hop to the actual IdP.
>>
>> That reduced the number of servers who needed to be "in the know" about
>> dynamic discovery, and made the whole thing much more easily
>> manageable.
>> Except that all of a sudden, a RADIUS/TLS endpoint served hundreds of
>> RADIUS NAI realms. With each realm required to be in the cert, the cert
>> needs to changed whenever a new realm gets added or deleted. It also
>> needs to remain in sync in near real-time with what the individual IdPs
> put
>> into their DNS.
>>
>> This makes the whole dynamic discovery model a lot less self-service;
> there is
>> always a CA operation involved.
>>
>> Our model of reverting to a generic "eligible eduroam IdP" (read as:
>> "... or proxy for an eligible eduroam IdP") restored the self-service
>> capabilities for the individual IdPs; they could add NAPTRs for their NAI
> realm
>> at any time, and no changes on the certificates would be needed any more.
>>
>> I'm afraid that manageability issues will prevent the SAN approach from
>> scaling to large consortia if any kind of aggregation is in use.
>>
>> Maybe if the SAN could include wildcards things would look better; an
>> aggregation proxy could be given a cert for "*.lu and foo.net" for
> example.
>>
>> This, however, defeats the purpose of impersonation prevention because
>> then that server could take the place of all .lu NAI realms, even if some
> of
>> those want to handle their own business themselves.
>>
>> So... there's pros and cons. I wonder what you think of the reservations
>> above.
>>
>> 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
> 
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
> 


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