Hi, Whilst trawling my logs to see what new interesting ways in which our userbase has gone and borked their workstations, I noticed that we are proxying realms upstream (to eduroam) that we should not be.....in this case it seems to be realms with spaces in them. If anyone reads the guff I dump out onto this mailing list you might have stumbled onto a policy definition I use to catch completely broken realms: ---- # only needs to be close enough to catch unroutable guff validate_username { if (User-Name !~ /@/ \ || ( \ User-Name !~ /@.*@/ \ && User-Name =~ /^[[:graph:]]*@([-[:alnum:]]+\.)+[[:alpha:]]{2,}$/ \ ) \ ) { ok } else { update reply { Reply-Message := "Invalid User-Name Syntax" } reject } } ---- This pretty such deals with 'double' realms, and badly formed usernames (the NULL realm condition is blocked elsewhere). It is then used as so: ---- authorize { preprocess rewrite.called_station_id <---- sanitiser rewrite.calling_station_id <---- sanitiser rewrite.quirk.wlc <---- sanitiser validate_username suffix .... } ---- The sanitising entries to not touch the User-Name field at all. Now if I fake some of the cruft I see I get: ---- rad_recv: Access-Request packet from host 172.31.3.41 port 1645, id=85, length=242 User-Name = "dsadadasda@Globalsign Root CA" Service-Type = Framed-User Framed-MTU = 1500 Called-Station-Id = "00-19-30-78-60-A5" Calling-Station-Id = "00-12-3F-E5-55-3C" EAP-Message = 0x02010022016473616461646173646140476c6f62616c7369676e20526f6f74204341 Message-Authenticator = 0x1f4ef372e5c3cb6ab4c2354ac9ce36d0 Cisco-AVPair = "audit-session-id=AC1F04BD000019806FAB0F27" NAS-Port-Type = Ethernet NAS-Port = 50133 NAS-Port-Id = "FastEthernet1/0/33" NAS-IP-Address = 172.31.3.41 server dot1x { +- entering group authorize {...} ++[preprocess] returns ok ++- entering policy rewrite.called_station_id {...} [RFCise the Called-Station-ID] ++- policy rewrite.called_station_id returns ok ++- entering policy rewrite.calling_station_id {...} [RFCise the Calling-Station-ID] ++- policy rewrite.calling_station_id returns ok ++- entering policy rewrite.quirk.wlc {...} [RFCise the crap Cisco's WLC 4400 returns] ++- policy rewrite.quirk.wlc returns noop ++- entering policy validate_username {...} +++? if (User-Name !~ /@/ || ( User-Name !~ /@.*@/ && User-Name =~ /^[[:graph:]]*@([-[:alnum:]]+\.)+[[:alpha:]]{2,}$/ ) ) ? Evaluating (User-Name !~ /@/) -> FALSE ?? Evaluating (User-Name !~ /@.*@/) -> TRUE ?? Evaluating (User-Name =~ /^[[:graph:]]*@([-[:alnum:]]+\.)+[[:alpha:]]{2,}$/) -> TRUE +++? if (User-Name !~ /@/ || ( User-Name !~ /@.*@/ && User-Name =~ /^[[:graph:]]*@([-[:alnum:]]+\.)+[[:alpha:]]{2,}$/ ) ) -> TRUE +++- entering if (User-Name !~ /@/ || ( User-Name !~ /@.*@/ && User-Name =~ /^[[:graph:]]*@([-[:alnum:]]+\.)+[[:alpha:]]{2,}$/ ) ) {...} ++++[ok] returns ok +++- if (User-Name !~ /@/ || ( User-Name !~ /@.*@/ && User-Name =~ /^[[:graph:]]*@([-[:alnum:]]+\.)+[[:alpha:]]{2,}$/ ) ) returns ok +++ ... skipping else for request 103: Preceding "if" was taken ++- policy validate_username returns ok [suffix] Looking up realm "Globalsign Root CA" for User-Name = "dsadadasda@Globalsign Root CA" [suffix] Found realm "DEFAULT" [suffix] Adding Realm = "DEFAULT" [suffix] Proxying request from user dsadadasda to realm DEFAULT [suffix] Preparing to proxy authentication request to realm "DEFAULT" ++[suffix] returns updated ---- Okay, maybe my regex is bad...so I tested it: ---- alex@berk:~$ cat moo xwFMNc02QnAbZlQ9wI9tiG@GlobalSignRootCA.test xwFMNc02QnAbZlQ9wI9tiG@GlobalSign Root CA wobble@example.com wibble@example.co.uk alex@berk:~$ grep '[[:graph:]]*@\([-[:alnum:]]\+\.\)\+[[:alpha:]]\{2,\}' moo xwFMNc02QnAbZlQ9wI9tiG@GlobalSignRootCA.test wobble@example.com wibble@example.co.uk ---- Any ideas? Bug? Feature? Cheers -- Alexander Clouter .sigmonster says: They're only trying to make me LOOK paranoid!
Alexander Clouter wrote:
Okay, maybe my regex is bad...so I tested it: ---- alex@berk:~$ cat moo xwFMNc02QnAbZlQ9wI9tiG@GlobalSignRootCA.test xwFMNc02QnAbZlQ9wI9tiG@GlobalSign Root CA wobble@example.com wibble@example.co.uk
alex@berk:~$ grep '[[:graph:]]*@\([-[:alnum:]]\+\.\)\+[[:alpha:]]\{2,\}' moo xwFMNc02QnAbZlQ9wI9tiG@GlobalSignRootCA.test wobble@example.com wibble@example.co.uk ----
Any ideas? Bug? Feature?
FreeRADIUS uses the system regex libraries. grep might be using its own regex implementation. Specifically, I'm not sure [[:alpha:]] and friends are supported by the system regex library. I would suggest writing the rules to sanitize realms in layers: - reject requests containing malformed User-Names (spaces, etc.) - proxy *known* realms to another virtual server to handle them - proxy *other* realms to eduroam. Eduroam should really be creating a routing protocol for RADIUS. I don't think it would be hard: git + ssh + text files. See Section 2.7 of: http://tools.ietf.org/id/draft-dekok-radext-nai-00.txt Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
Alexander Clouter wrote:
Okay, maybe my regex is bad...so I tested it: ---- alex@berk:~$ cat moo xwFMNc02QnAbZlQ9wI9tiG@GlobalSignRootCA.test xwFMNc02QnAbZlQ9wI9tiG@GlobalSign Root CA wobble@example.com wibble@example.co.uk
alex@berk:~$ grep '[[:graph:]]*@\([-[:alnum:]]\+\.\)\+[[:alpha:]]\{2,\}' moo xwFMNc02QnAbZlQ9wI9tiG@GlobalSignRootCA.test wobble@example.com wibble@example.co.uk ----
Any ideas? Bug? Feature?
FreeRADIUS uses the system regex libraries. grep might be using its own regex implementation.
Specifically, I'm not sure [[:alpha:]] and friends are supported by the system regex library.
grep implies it does in the man page, and I am using the *basic* regex mode too. I got those :alpha:-n-chums actually working and tested them with a bunch of test cases; they definitely seem to be doing what I would expect...well unless the realm has a space in it :) Ignoring the 'space', the fact that there is not '.' in the Globalsign realms should have caused it to be rejected, which to me rules out the 'alnum'/'alpha' bits surely?
I would suggest writing the rules to sanitize realms in layers:
- reject requests containing malformed User-Names (spaces, etc.) - proxy *known* realms to another virtual server to handle them - proxy *other* realms to eduroam.
I already do that, it's the malformed and non-routable (EAP-SIM-esque realms) realm's that are the problem.
Eduroam should really be creating a routing protocol for RADIUS. I don't think it would be hard: git + ssh + text files. See Section 2.7 of:
I never understood why eduroam just didn't use SRV records against the realm to find the RADIUS server and a DNS based whitelist to validate which realms were part of the community. :-/ For that tiny amount of effort you get to remove those darn proxy servers and more reliability (large TTL's on realm whitelist), plus when DNSSEC gets rolled out to .ac.uk and where ever...you get that for free too. The only complication I can see is the Message-Authenticator I think, however I would imagine the .ac.uk community can dig into the sofa for some loose change to hire some FreeRADIUS consultant...if he is not too busy lying with his feet kicked up in France with fresh food and good wine :) At this point I would imagine the eduroam world will descend upon me saying "the world is not 'a' FreeRADIUS", to which I reply "then you will not be part of it" if you are too lazy to configure a 'dumb' standalone FreeRADIUS proxy :) However, I am just a network monkey, no one listens to me :) Cheers -- Alexander Clouter .sigmonster says: You're not Dave. Who are you?
Alexander Clouter wrote:
I got those :alpha:-n-chums actually working and tested them with a bunch of test cases; they definitely seem to be doing what I would expect...well unless the realm has a space in it :)
Odd...
Ignoring the 'space', the fact that there is not '.' in the Globalsign realms should have caused it to be rejected, which to me rules out the 'alnum'/'alpha' bits surely?
No idea. I'd have to figure out the regex, and I don't have time for that.
I never understood why eduroam just didn't use SRV records against the realm to find the RADIUS server and a DNS based whitelist to validate which realms were part of the community. :-/
It's hard. Once FreeRADIUS gets SRV support...
The only complication I can see is the Message-Authenticator I think, however I would imagine the .ac.uk community can dig into the sofa for some loose change to hire some FreeRADIUS consultant...if he is not too busy lying with his feet kicked up in France with fresh food and good wine :)
I'm in Canada right now. Cold... wintry... good beer. But RadSec and/or DTLS should solve much of the security issues.
At this point I would imagine the eduroam world will descend upon me saying "the world is not 'a' FreeRADIUS", to which I reply "then you will not be part of it" if you are too lazy to configure a 'dumb' standalone FreeRADIUS proxy :)
However, I am just a network monkey, no one listens to me :)
You said something? Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
Alexander Clouter wrote:
I got those :alpha:-n-chums actually working and tested them with a bunch of test cases; they definitely seem to be doing what I would expect...well unless the realm has a space in it :)
Odd...
Glad you do too, means I have not missed something.....hopefully :)
I never understood why eduroam just didn't use SRV records against the realm to find the RADIUS server and a DNS based whitelist to validate which realms were part of the community. :-/
It's hard. Once FreeRADIUS gets SRV support...
I decided, in an imaginary place where I am God and decider of all, it would be better to have a RADIUS-esque proxy brige thingy mcwhatsit. The RADIUS server's would proxy to the 'eduroam proxy' you would run locally, it would then 'eduroam-ise' the request (filter cruft, check the realm is routable etc etc) and then shift the packets themselves off to their destination.
The only complication I can see is the Message-Authenticator I think, however I would imagine the .ac.uk community can dig into the sofa for some loose change to hire some FreeRADIUS consultant...if he is not too busy lying with his feet kicked up in France with fresh food and good wine :)
I'm in Canada right now. Cold... wintry... good beer.
Hmmm, if it is anything like the New England beer I tried a while back, I am not so keen.
But RadSec and/or DTLS should solve much of the security issues.
EAP-TTLS wrapped in TLS eh, I already have the user validating the cert they are sending the credentials to...kinda redundant surely? I hear PKI is meant to 'solve' the realm whitelisting part too...'great' :-/ "This network monkey recommends people realise PKI is stupid", however if the eduroam world were maybe to think about a PGPesque key signing approach, that I would be interested in supporting. Cheers -- Alexander Clouter .sigmonster says: Try to divide your time evenly to keep others happy.
Hi,
Eduroam should really be creating a routing protocol for RADIUS. I don't think it would be hard: git + ssh + text files. See Section 2.7 of:
firstly, its 'eduroam', not 'Eduroam' - minor point but none the less.... :-) secondly - the current system uses a rpoxy heirarchy because that was the lowest common capable denominator when the federation was created and its fairly easy for sites/countries to get connected. there are currently moves underway to investigate/implement moves to using dynamic RADIUS/REALM lookups etc however there are then fundamental changes that need to be undertaken - such as having required 'membership' - eg certificate extension to prove you are a valid eduroam site - couple that with requirements to use eg RADSEC for secure transit (cant used shared secrets with random other sites!) .... and then theres what to do to the countless RADIUS servers in use that dont (and maybe wont) support such features... sure , sure 'RADSecProxy' is a tech answer but I've already approached sites big on Windows servers and IAS/NPS - the thought of running some non-MS software on their server makes them very angry/angsty.... it looks like a proxy system would need to kept into place to keep those sites in (as well as imagine telling them to open ports up to their MS server to the world......) currently, the proxy system doesnt involve even more CA/PKI stuff and it doesnt open system to the world...a lot of sites like that..... :-| ...but anyway..even when the new system becomes functional/proved it will take quite some time for sites to migrate... and I've already proposed that sites can publish the national proxy as their SRV (or whatever method is chosen) record alan
Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Eduroam should really be creating a routing protocol for RADIUS. I don't think it would be hard: git + ssh + text files. See Section 2.7 of:
firstly, its 'eduroam', not 'Eduroam' - minor point but none the less.... :-)
Say's 'eduroam' in my SSID, maybe I'll go and check my 'E-mail' after this posting? ;)
secondly - the current system uses a rpoxy heirarchy because that was the lowest common capable denominator when the federation was created and its fairly easy for sites/countries to get connected.
This is great...it was *built* first then pinned down, as a result it was guaranteed to work. Cheap, easy to join, and quick to discover how useful the whole system actually is. For this, it gets my praise, and everyone elses, it is awesome. It is awesome though as it is dead easy to join for anyone doing anything vaguely 802.1Xy locally (wifi, wired, whatever....).
there are currently moves underway to investigate/implement moves to using dynamic RADIUS/REALM lookups etc however there are then fundamental changes that need to be undertaken - such as having required 'membership' - eg certificate extension to prove you are a valid eduroam site - couple that with requirements to use eg RADSEC for secure transit (cant used shared secrets with random other sites!) .... and then theres what to do to the countless RADIUS servers in use that dont (and maybe wont) support such features... sure , sure 'RADSecProxy' is a tech answer but I've already approached sites big on Windows servers and IAS/NPS - the thought of running some non-MS software on their server makes them very angry/angsty.... it looks like a proxy system would need to kept into place to keep those sites in (as well as imagine telling them to open ports up to their MS server to the world......)
They don't have to, they run it on a separate box and configure they box to blindly send all non-local realmed stuff to a separate nearby RADIUS proxy that does the talking to Eduroam; okay I am now touting the 'separate' proxy...but Eduroam has some pretty unique requirements that *no-one* else does and this is the key point. We need something RADIUS like, you need something like a 'bridge', between RADIUS and Eduroam which could be 98% RADIUS.
currently, the proxy system doesnt involve even more CA/PKI stuff and it doesnt open system to the world...a lot of sites like that..... :-|
So the bar (including the administrative work both for you and the end-sysadmin does) is set low. If RADSEC raises that bar it has failed. It's 2009, it is meant to be *easier* for systems to communicate with one another...if you are implementing something that is more difficult it is the wrong solution. That does not just apply to Eduroam either :) Cheers -- Alexander Clouter .sigmonster says: Does not include installation.
Hi,
proxy that does the talking to Eduroam; okay I am now touting the 'separate' proxy...but Eduroam has some pretty unique requirements that *no-one* else does and this is the key point.
'eduroam' not Eduroam please! ;-)
So the bar (including the administrative work both for you and the end-sysadmin does) is set low. If RADSEC raises that bar it has failed. It's 2009, it is meant to be *easier* for systems to communicate with one another...if you are implementing something that is more difficult it is the wrong solution. That does not just apply to Eduroam either :)
err, no. the current concept would be something like... 1) end site gets connected and asks eduroam for a cert for their server 2) NREN validates request 3) end site gets the cert and adds it to their server thats all easy and requires no skills..agreed? now, the 'technical part' end site reconfigures their RADIUS server so it knows about that cert .... oh, something like radsec_cert = myservercert.der radsec_ca = eduroam-ca.der then they enable the new functionality to do dynamic host lookups...oh, maybe $INCLUDE dynamic-server-discovery.conf or ln -s sites-evailable/dynamic-server sites-enabled/dynamic-server if thats raised the bar then its a tiny tiny raise that even an ant couldnt get under IMHO. okay - some of this might be over simplified for the initial beta-testers of such new functionality but its pretty much what people are visualising as the real-life way of things working...... so, no need for wierd external programs and PERL code...no need for PGP or whitelists. the only thing missign would be sites-enabled/throw-my-stats-to-eduroam-and-NREN ;-) sites-enabled/log-errors-to-NREN-or-eduroam 8-) alan
Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
proxy that does the talking to Eduroam; okay I am now touting the 'separate' proxy...but Eduroam has some pretty unique requirements that *no-one* else does and this is the key point.
'eduroam' not Eduroam please! ;-)
Bah, read that the other way wrong...gah.
So the bar (including the administrative work both for you and the end-sysadmin does) is set low. If RADSEC raises that bar it has failed. It's 2009, it is meant to be *easier* for systems to communicate with one another...if you are implementing something that is more difficult it is the wrong solution. That does not just apply to Eduroam either :)
err, no. the current concept would be something like...
1) end site gets connected and asks eduroam for a cert for their server 2) NREN validates request 3) end site gets the cert and adds it to their server
thats all easy and requires no skills..agreed?
*sigh* Forget RADSEC then, you might aswell use IPsec in transport mode with AH (as hell we are already shifting EAP traffic around so ESP would be pointless) and then you can do it with bog standard RADIUS; although someone will need to sort out the "route straight to domain SRV record" bit.
now, the 'technical part'
end site reconfigures their RADIUS server so it knows about that cert .... oh, something like
radsec_cert = myservercert.der radsec_ca = eduroam-ca.der
So, 'eduroam-ca.der' can be a *group* of Root CA's I hope and there is a way to make sure that when the original CA reaches it's end of life you get *all* the sysadmins involved to update it to have the two CA's for a while and then on a 'd-day' to remove the old one?
if thats raised the bar then its a tiny tiny raise that even an ant couldnt get under IMHO.
Kinda my point is there is no reason why the bar could not be lowered further. The DNS idea was a hair brained idea of mine and I think it is crazy enough to work...plus it is using the *existing* infrastructure; plus finally admitting that edroam is *not* something that can be wholely accepted by an RFC...it is an exception. This is obviously turning into an Alex v's World argument. :-/
okay - some of this might be over simplified for the initial beta-testers of such new functionality but its pretty much what people are visualising as the real-life way of things working...... so, no need for wierd external programs and PERL code...no need for PGP or whitelists. the only thing missign would be
You better hope you are living on a remote inaccessible tropical island when that Root CA implodes. :) RADSEC with the PKI instructure eduroam is touting is a ticking time bomb and knowing the educational world they are going to notice this international trust network and want to shovel their own cruft over it too. When d-day arrives, it is going to break hard....the ides of March I tell you the ides of March. Bah, to hell with you all ;) Cheers -- Alexander Clouter .sigmonster says: Every time I think I know where it's at, they move it.
Hi,
So, 'eduroam-ca.der' can be a *group* of Root CA's I hope and there is a
with a decent system you can just point the CA part to a directory or listing of CAs for it to check. simple extensions can prove 'club' membership for whatever purpose/resource you are happy with
Kinda my point is there is no reason why the bar could not be lowered further. The DNS idea was a hair brained idea of mine and I think it is crazy enough to work...plus it is using the *existing* infrastructure;
i dont think you can claim credit - many of us have had similar ideas and some even went to write things up: http://www.ietf.org/id/draft-ietf-radext-dynamic-discovery-01.txt
Bah, to hell with you all ;)
at maximum cruising speed please! >:-I alan
Hi,
*sigh*
Forget RADSEC then, you might aswell use IPsec in transport mode with AH (as hell we are already shifting EAP traffic around so ESP would be pointless) and then you can do it with bog standard RADIUS; although someone will need to sort out the "route straight to domain SRV record" bit.
People in eduroam have tried RADIUS over IPSec and it was a pest. They gave up on it and switched to RadSec meanwhile. And for RadSec, routing via DNS is known (in a commercial product) since the early 2000s and picked up in the IETF as of 2007. I just saw Alan Buxey referenced the current state of it in his latest mail.
So, 'eduroam-ca.der' can be a *group* of Root CA's I hope and there is a way to make sure that when the original CA reaches it's end of life you get *all* the sysadmins involved to update it to have the two CA's for a while and then on a 'd-day' to remove the old one?
The current plans in eduroam do indeed foresee a group of CAs: one for each National Research Network that's willing to operate its own, and a catch-all CA for the rest. All of which have individual rollover dates. And have their own CRLs which need to be re-loaded regularly (which means that there is no one D-Day). Sounds dreadful to you? Simple: a repository with CAs and CRLs and a cron job to fetch the current state once per day or so, and a HUP to pick it up. Nothing a server operator should be afraid of. CRL reload in OpenSSL is a pest right now, and we're eagerly waiting for OpenSSL 1.0.0 which is claimed to be able to do this properly.
Kinda my point is there is no reason why the bar could not be lowered further. The DNS idea was a hair brained idea of mine and I think it is crazy enough to work...plus it is using the *existing* infrastructure; plus finally admitting that edroam is *not* something that can be wholely accepted by an RFC...it is an exception.
This is obviously turning into an Alex v's World argument. :-/
We've spent tremendous amounts of thinking and taxpayer money to think about this. Without knowing your own flavour of DNS idea: how do you solve the following: - eduroam is for educational use only - microsoft.com sets up a RADIUS server and enters a DNS record for it - eduroam hotspot gets a user login from microsoft.com, looks up server, authenticates, user uses network - damn, we just allowed a commercial user into our network and violated our own AUP and national regulations orders! We think PKI (and certificates that hold accreditation info) comes to the rescue. What rescues you?
RADSEC with the PKI instructure eduroam is touting is a ticking time bomb and knowing the educational world they are going to notice this international trust network and want to shovel their own cruft over it too. When d-day arrives, it is going to break hard....the ides of March I tell you the ides of March.
Without a specific D-Day, your statement above loses much of its sense.
Bah, to hell with you all ;)
Last time I went there, I made it freeze over. Made it lose most of its charm, and I don't plan on going back. 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
Stefan Winter <stefan.winter@restena.lu> wrote:
So, 'eduroam-ca.der' can be a *group* of Root CA's I hope and there is a way to make sure that when the original CA reaches it's end of life you get *all* the sysadmins involved to update it to have the two CA's for a while and then on a 'd-day' to remove the old one?
The current plans in eduroam do indeed foresee a group of CAs: one for each National Research Network that's willing to operate its own, and a catch-all CA for the rest. All of which have individual rollover dates. And have their own CRLs which need to be re-loaded regularly (which means that there is no one D-Day). Sounds dreadful to you? Simple: a repository with CAs and CRLs and a cron job to fetch the current state once per day or so, and a HUP to pick it up. Nothing a server operator should be afraid of.
Consider myself 'slapped down'.
Kinda my point is there is no reason why the bar could not be lowered further. The DNS idea was a hair brained idea of mine and I think it is crazy enough to work...plus it is using the *existing* infrastructure; plus finally admitting that edroam is *not* something that can be wholely accepted by an RFC...it is an exception.
This is obviously turning into an Alex v's World argument. :-/
We've spent tremendous amounts of thinking and taxpayer money to think about this. Without knowing your own flavour of DNS idea: how do you solve the following:
- eduroam is for educational use only - microsoft.com sets up a RADIUS server and enters a DNS record for it - eduroam hotspot gets a user login from microsoft.com, looks up server, authenticates, user uses network - damn, we just allowed a commercial user into our network and violated our own AUP and national regulations orders!
We think PKI (and certificates that hold accreditation info) comes to the rescue. What rescues you?
What I was touting privately to Alan involved maintaining a zone file, akin to what you promoted in you dyndiscovery draft[1] but for for a custom 'root' server list. I compared the PKI approach to mutex locking. Sure you can use it, but the proper way to do things is to build an algorithm that remove the need for mutex's. You dyndiscovery draft touts a PKIless world and thats a *good* thing. None of this matters anyway.
RADSEC with the PKI instructure eduroam is touting is a ticking time bomb and knowing the educational world they are going to notice this international trust network and want to shovel their own cruft over it too. When d-day arrives, it is going to break hard....the ides of March I tell you the ides of March.
Without a specific D-Day, your statement above loses much of its sense.
Indeed it does. Cheers [1] http://www.ietf.org/id/draft-ietf-radext-dynamic-discovery-01.txt -- Alexander Clouter .sigmonster says: Robot, n.: University administrator.
Alexander Clouter wrote:
What I was touting privately to Alan involved maintaining a zone file, akin to what you promoted in you dyndiscovery draft[1] but for for a custom 'root' server list.
If Stefan is talking about a repository with certs && CRL's, adding routing information wouldn't be that hard. i.e. "upstream for foo.edu is bar.com". That addresses a lot of the multi-hop issues that DNS just can't solve. It would *also* solve the i18n problem of non-ascii TLDs. Just put the realm && DNS "punycode" version into the same repository. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
Alexander Clouter wrote:
What I was touting privately to Alan involved maintaining a zone file, akin to what you promoted in you dyndiscovery draft[1] but for for a custom 'root' server list.
If Stefan is talking about a repository with certs && CRL's, adding routing information wouldn't be that hard. i.e. "upstream for foo.edu is bar.com". That addresses a lot of the multi-hop issues that DNS just can't solve.
With a twist it could if I understand the problem correctly. Along side the SRV records you would have to add 'reverse hop' records and follow the chain till the proxy discovers its-self; discover the route path in order from destination to sender. However I am guessing this would be error prone and of course required *everyone* in eduroam adding suitable 'reverse hop' records to their realm; easily monitorable mind you. Cheers -- Alexander Clouter .sigmonster says: Everyone hates me because I'm paranoid.
Alexander Clouter wrote:
With a twist it could if I understand the problem correctly. Along side the SRV records you would have to add 'reverse hop' records and follow the chain till the proxy discovers its-self; discover the route path in order from destination to sender. However I am guessing this would be error prone and of course required *everyone* in eduroam adding suitable 'reverse hop' records to their realm; easily monitorable mind you.
Yes. That's just too complicated. If there's already a system to distribute certs, it should be leveraged to distribute other stuff. Alan DeKok.
participants (4)
-
Alan Buxey -
Alan DeKok -
Alexander Clouter -
Stefan Winter