Re: TCP/TLS - radsec / application
> > > >I am a little concerned about the 'save some EAP stuff that I'm not using >and was able >to disable around' - you will need to ensure that OpenSSL-devel packages >are installed >so that you can compile in the TLS support. The EAP stuff was related to EAP-Pwd or something. It was a runtime problem (bug), not a compile problem. I have no use for the EAP-Pwd option in my environment and can't test, so I'll leave that to someone else to report/repair. I was able to get the TCP/TLS working as expected with the provided sample certs. Thanks for pointing me in the right direction. It was pretty simple once I saw a working example. Jason Rohm - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: TCP/TLS - radsec / application
Hi, > I've been doing some research and it seems like there has been a lot of > talk about radsec and some movement on the IETF standardization front, but > I'm unclear about the state of radsec within the freeradius codebase. I've > downloaded the current master source as of a few days ago and successfully > compiled it on CentOS 6.2 64bit. Everything seems to work save some EAP > stuff that I'm not using and was able to disable around, but I can't > figure out if the radsec is there and not documented or if it isn't in > there at all. the 'RADSEC' (RADIUS over TLS/TCP) support is in the master branch: git clone git://git.freeradius.org/freeradius-server.git (read http://git.freeradius.org/) the stuff you are looking for is in the 'tls' virtual server - which isnt enabled by default IIRC - so just put a link from it int sites-enabledand read the 'tls' virtual server carefully. I am a little concerned about the 'save some EAP stuff that I'm not using and was able to disable around' - you will need to ensure that OpenSSL-devel packages are installed so that you can compile in the TLS support. once you have it running, simply get a 'CA' that your RADIUS servers all trust (I'd go for a private self-signed one) and sign the servers with itet voila! you can now do RADSEC (oh, with the caveat that all yoru servers will have to have the TCP 2083 port open and firewalls between sites sorted out etcbut i'd assume that work would get done) alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: TCP/TLS - radsec / application
> Jason Rohm wrote: > I'm unclear about the state of > radsec within the freeradius codebase. I've downloaded the > current master source as of a few days ago and successfully > compiled it on CentOS 6.2 64bit. Everything seems to work > save some EAP stuff that I'm not using and was able to > disable around, but I can't figure out if the radsec is there > and not documented or if it isn't in there at all. > -Is the radsec code included in the mainline git repo? > -If not, where do I get it? The repository code has it, I have it up and working to our federation server, where they run radiator. Over the last few weeks some bugs have surfaced, but some have been patched already and I suspect the rest of the patches should land in the repository before too long. > -If so, does anyone have any quick and dirty doc somewhere or > a working example? The docs don't plaster the word "RadSec" everywhere it is just setting the protocol on home servers or listen directives to TCP and setting some additional options, as documented in etc/raddb/sites-available/tls (in the git tree, of course) (Dealing with the cert stuff is the most fiddly part of it and will help to have openssl expertise on hand.) > -Am I nuts for even trying this? Only if your timeline does not allow several months for performance and long-term stability testing/patching, because you'll be bleeding edge at this point. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
TCP/TLS - radsec / application
I've been doing some research and it seems like there has been a lot of talk about radsec and some movement on the IETF standardization front, but I'm unclear about the state of radsec within the freeradius codebase. I've downloaded the current master source as of a few days ago and successfully compiled it on CentOS 6.2 64bit. Everything seems to work save some EAP stuff that I'm not using and was able to disable around, but I can't figure out if the radsec is there and not documented or if it isn't in there at all. I'm asking because I have a specific use-case that is somewhat similar to how edu-roam is doing that I want to implement and was hoping someone can steer me in the right direction. I'm looking to implement a multi-tier radius hierarchy to deploy centralized user logins to managed network devices in a number of my managed IT customers (I'm the service provider). What I want to accomplish is something similar to: (pardon the ASCII Visio) [NAS (Typically Cisco Router/Switch)] --Standard Radius Auth--> [Onsite FreeRadius as proxy/realm selector] --Standard Radius Auth--> @customer.domain [Customer's Server (typically MS IAS/NPS) Or --TCP/TLS Radius Auth--> @service_provider.domain [Internet facing FreeRadius] --Standard Radius Auth or LDAP--> [Our backend user database (currently AD)] Right now our solution is to implement the same hierarchy but to use standard UDP radius over SSH/socat tunnels for the onsite to off-site communication. A radsec solution would be cleaner and probably more reliable. So my questions are: -Is the radsec code included in the mainline git repo? -If not, where do I get it? -If so, does anyone have any quick and dirty doc somewhere or a working example? -Am I nuts for even trying this? Jason Rohm Communications Architect SRC Technologies Inc. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: proxy server goes deaf after "Client has closed connection" (RadSec to home server)
Alan DeKok Wrote > Brian Julin wrote: > > The latter makes me wonder why or if request_proxy_anew works at all. > > It was tested at one point. But the code has changed since then. Given the complexity of RADIUS state management, automating a comprehensive test suite for it would be a very interesting endeavor. It might even be worthy of a GSoC project proposal, to get an aspiring coder to flesh out src/tests, firing up test servers and VMs/fragrouters to really work the corner cases and cover previous issues from the ML/git-log against regressions. Not sure how far they would get, but they'd sure learn a lot about application internetworking by trying, and the resulting framework would probably be applicable to other heavily-interfaced server suites. > It's nice to know that code was understandable. That... took a while. I even had to draw pictures. :-) If I ever do that again, maybe I'll finish them enough to submit them as devel docs. Thanks again for holding it all together, Alan. -- Brian - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: proxy server goes deaf after "Client has closed connection" (RadSec to home server)
Brian Julin wrote: > request_proxy_anew was assuming its argument would be installed in the > proxy_list, which wasn't the case, so it was removing it twice causing > .num_outgoing counters to roll over. Then, request_proxy was not expecting > the case where the argument was already in the proxy_list (put there by > request_proxy_anew) and was failing when attempting to add it a second > time. The latter makes me wonder why or if request_proxy_anew works at all. It was tested at one point. But the code has changed since then. It's nice to know that code was understandable. The state machine in process.c is complicated enough that I try not to touch it too much. > The attached patch seems to do the trick. Some caveats: > > This bypasses (for certain situations) the attempts to make sure that > a duplicate packet does not reuse the proxy_list ID of its predecessor. > Not knowing the reasoning behind that, I don't know if that's important > or not. It's not important. > request_proxy has a "retransmit" flag as a parameter, which might be the > better test to avoid inserting the entry twice, or might not be. I think that flag is independent of the issue you found. > Off topic, JOOC, while reading through the source I was left wondering what > prevents proxy_wait_for_reply from entering master-only functions from a > non-master thread when it falls through the DUP case into the TIMER case. Whoops. You're right. I'll go commit a fix for that. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: proxy server goes deaf after "Client has closed connection" (RadSec to home server)
Alan DeKok [al...@deployingradius.com] wrote:
> Sent: Friday, March 09, 2012 3:25 AM
> Brian Julin wrote:
> > This keeps the server listening, but there are some lingering issues:
>
> Well, fixes are welcome.
>
> I don't have time to look into this for a few weeks at least.
request_proxy_anew was assuming its argument would be installed in the
proxy_list, which wasn't the case, so it was removing it twice causing
.num_outgoing counters to roll over. Then, request_proxy was not expecting
the case where the argument was already in the proxy_list (put there by
request_proxy_anew) and was failing when attempting to add it a second
time. The latter makes me wonder why or if request_proxy_anew works at all.
The attached patch seems to do the trick. Some caveats:
This bypasses (for certain situations) the attempts to make sure that
a duplicate packet does not reuse the proxy_list ID of its predecessor.
Not knowing the reasoning behind that, I don't know if that's important
or not.
request_proxy has a "retransmit" flag as a parameter, which might be the
better test to avoid inserting the entry twice, or might not be.
Off topic, JOOC, while reading through the source I was left wondering what
prevents proxy_wait_for_reply from entering master-only functions from a
non-master thread when it falls through the DUP case into the TIMER case.
diff --git a/src/main/process.c b/src/main/process.c
index 4b5f084..f3b0c3f 100644
--- a/src/main/process.c
+++ b/src/main/process.c
@@ -1596,7 +1596,7 @@ static void remove_from_proxy_hash_nl(REQUEST *request)
request->proxy_listener = NULL;
/*
- * Got from YES in hash, to NO, not in hash while we hold
+ * Go from YES in hash, to NO, not in hash while we hold
* the mutex. This guarantees that when another thread
* grabs the mutex, the "not in hash" flag is correct.
*/
@@ -2264,7 +2264,7 @@ static int request_proxy(REQUEST *request, int retransmit)
/*
* We're actually sending a proxied packet. Do that now.
*/
- if (!insert_into_proxy_hash(request)) {
+ if (!request->in_proxy_hash && !insert_into_proxy_hash(request)) {
radlog_request(L_PROXY, 0, request, "Failed to insert initial packet into the proxy list.");
return -1;
}
@@ -2298,9 +2298,13 @@ static int request_proxy_anew(REQUEST *request)
/*
* Keep a copy of the old Id so that the
* re-transmitted request doesn't re-use the old
- * Id.
+ * Id. Note that in certain cases (socket crash)
+ * there is no Id as they have been purged from
+ * proxy_list, but there should still be a leftover
+ * packet hung off this request.
*/
RADIUS_PACKET old = *request->proxy;
+ int old_hash = request->in_proxy_hash;
home_server *home;
home_server *old_home = request->home_server;
#ifdef WITH_TCP
@@ -2327,7 +2331,7 @@ static int request_proxy_anew(REQUEST *request)
}
/*
- * Don't free the old Id on error.
+ * Don't free the old Id (if any) on error.
*/
if (!insert_into_proxy_hash(request)) {
radlog_request(L_PROXY, 0, request, "Failed to insert retransmission into the proxy list.");
@@ -2335,16 +2339,18 @@ static int request_proxy_anew(REQUEST *request)
}
/*
- * Now that we have a new Id, free the old one
+ * Now that we have a new Id, free the old one (if any)
* and update the various statistics.
*/
PTHREAD_MUTEX_LOCK(&proxy_mutex);
- fr_packet_list_yank(proxy_list, &old);
- fr_packet_list_id_free(proxy_list, &old);
- old_home->currently_outstanding--;
+ if (old_hash) {
+ fr_packet_list_yank(proxy_list, &old);
+ fr_packet_list_id_free(proxy_list, &old);
+ old_home->currently_outstanding--;
#ifdef WITH_TCP
- if (listener) listener->count--;
+ if (listener) listener->count--;
#endif
+ }
PTHREAD_MUTEX_UNLOCK(&proxy_mutex);
/*
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: proxy server goes deaf after "Client has closed connection" (RadSec to home server)
Brian Julin wrote: > This keeps the server listening, but there are some lingering issues: Well, fixes are welcome. I don't have time to look into this for a few weeks at least. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: proxy server goes deaf after "Client has closed connection" (RadSec to home server)
Alan DeKok [al...@deployingradius.com] wrote > Sent: Wednesday, March 07, 2012 3:52 AM > To: FreeRadius users mailing list > Subject: Re: proxy server goes deaf after "Client has closed connection" > (RadSec to home server) > > Brian Julin wrote: >> (at this point the server does not see any additional requests sent to it, >> so we kill it to see if it is hanging out anywhere interesting... really >> should >> do this several times more to verify... maybe try a kill -9 next time...) > > It's hanging because it's trying to lock the proxy mutex twice. > That's a no-no. > > I'll push a fix later today. This keeps the server listening, but there are some lingering issues: 10:40:31 : Info: (18) Proxying request to home server XXX.XXX.XXX.XXX port 2083 10:40:31 : Debug: Proxy is writing 123 bytes to SSL 10:40:31 : Debug: Thread 1 waiting to be assigned a request 10:40:31 : Debug: Proxy SSL socket has data to read 10:40:31 : Debug: Client has closed connection 10:40:31 : Info: ... closing socket proxy (YYY.YYY.YYY.YYY, 39314) -> home_server (XXX.XXX.XXX.XXX, 2083) 10:40:31 : Debug: Waking up in 0.3 seconds. 10:40:31 : Debug: Waking up in 0.4 seconds. 10:40:31 : Debug: Waking up in 29.1 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 51126, id=247, length=147 10:40:34 : Debug: Opening new proxy (YYY.YYY.YYY.YYY, 0) -> home_server (XXX.XXX.XXX.XXX, 2083) 10:40:34 : Debug: Trying SSL to port 2083 10:40:34 : Debug: Requiring Server certificate 10:40:34 : Debug: Listening on proxy (YYY.YYY.YYY.YYY, 41712) -> home_server (XXX.XXX.XXX.XXX, 2083) 10:40:34 : Debug: No Post-Proxy-Type Fail: ignoring 10:40:34 : Debug: Waking up in 26.8 seconds. (... resends from the client don't work... This may or may not be time-window related...) rad_recv: Access-Request packet from host 127.0.0.1 port 51126, id=247, length=147 10:40:40 : Proxy: (18) Failed to insert entry into proxy list. 10:40:40 : Proxy: (18) Failed to insert initial packet into the proxy list. 10:40:40 : Debug: No Post-Proxy-Type Fail: ignoring 10:40:40 : Debug: Waking up in 20.9 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 51126, id=247, length=147 10:40:52 : Proxy: (18) Failed to insert entry into proxy list. 10:40:52 : Proxy: (18) Failed to insert initial packet into the proxy list. 10:40:52 : Debug: No Post-Proxy-Type Fail: ignoring 10:40:52 : Debug: Waking up in 8.9 seconds. 10:41:01 : Debug: Waking up in 4.9 seconds. 10:41:06 : Info: (18) Cleaning up request packet ID 247 with timestamp +4879 10:41:06 : Info: Ready to process requests. (...this next set of requests succeeds...) rad_recv: Access-Request packet from host 127.0.0.1 port 51126, id=251, length=147 10:48:06 : Debug: Waking up in 0.3 seconds. 10:48:06 : Debug: Thread 4 got semaphore 10:48:06 : Debug: Thread 4 handling request 19, (10 handled so far) (...) 10:48:06 : Info: (27) Finished request 27. 10:48:06 : Debug: Thread 2 waiting to be assigned a request 10:48:06 : Debug: Waking up in 0.1 seconds. 10:48:07 : Debug: Waking up in 4.1 seconds. 10:48:11 : Info: (19) Cleaning up request packet ID 251 with timestamp +5334 10:48:11 : Info: (20) Cleaning up request packet ID 177 with timestamp +5334 10:48:11 : Info: (21) Cleaning up request packet ID 59 with timestamp +5334 10:48:11 : Info: (22) Cleaning up request packet ID 56 with timestamp +5334 10:48:11 : Debug: Waking up in 0.1 seconds. 10:48:11 : Info: (24) Cleaning up request packet ID 183 with timestamp +5334 10:48:11 : Info: (25) Cleaning up request packet ID 243 with timestamp +5334 10:48:11 : Info: (26) Cleaning up request packet ID 134 with timestamp +5334 10:48:11 : Info: (27) Cleaning up request packet ID 128 with timestamp +5334 10:48:11 : Info: Ready to process requests. (...however, this can now happen on subsequent requests, or sometimes out of the blue. It doesn't always...) 10:56:37 : Debug: Proxy SSL socket has data to read 10:56:37 : Debug: Client has closed connection 10:56:37 : Info: ... closing socket proxy (YYY.YYY.YYY.YYY, 41712) -> home_server (XXX.XXX.XXX.XXX, 2083) 10:56:37 : Error: Fatal error removing socket: (unknown error) [Thread 0x74f94700 (LWP 24568) exited] [Thread 0x75995700 (LWP 24567) exited] [Thread 0x76d97700 (LWP 24565) exited] [Thread 0x76396700 (LWP 24566) exited] (...That one above was "from out of the blue". This one I put a breakpoint in and it happened while processing a request..) Breakpoint 1, event_new_fd (this=0x805790) at process.c:3715 3715 radlog(L_ERR, "Fatal error removing socket: %s", (gdb) bt #0 event_new_fd (this=0x805790) at process.c:3715 #1 0x0043c718 in proxy_tls_recv (listener=0x805790) at tls_listen.c:499 #2 0x00430a9a in event_socket_handler (xel=, fd
Re: proxy server goes deaf after "Client has closed connection" (RadSec to home server)
Brian Julin wrote: > (at this point the server does not see any additional requests sent to it, > so we kill it to see if it is hanging out anywhere interesting... really > should > do this several times more to verify... maybe try a kill -9 next time...) It's hanging because it's trying to lock the proxy mutex twice. That's a no-no. I'll push a fix later today. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
proxy server goes deaf after "Client has closed connection" (RadSec to home server)
It appears there was another layer to my latest issue. Sometimes a server using RadSec to proxy to a home server ends up just waiting around unable to see any more incoming requests, and not having completed the current request. In this case the server is 3.0, and is sandwiched between our internal instance and our federation server (doing radsecproxy-ish stuff.) This may only happen in a corner case when the federation server is taking a while to reply, perhaps in this case where it exceeds our internal instance's response_window. I'm testing now whether using an immense response_window on the internal instance works as a workaround (assuming the federation server doesn't have any prolonged issues, of course) which would help support that theory. Info: (32) Proxying request to home server XXX.XXX.XXX.XXX port 2083 Tue Mar 6 13:59:08 2012 : Debug: Proxy is writing 122 bytes to SSL Tue Mar 6 13:59:08 2012 : Debug: Thread 3 waiting to be assigned a request Tue Mar 6 13:59:08 2012 : Debug: Proxy SSL socket has data to read Tue Mar 6 13:59:08 2012 : Debug: Client has closed connection (though, the client is UDP which has no transport layer connection, so... maybe that's talking about the home server, not a client? Not sure if that's coming from listen.c or tls_listen.c) (at this point the server does not see any additional requests sent to it, so we kill it to see if it is hanging out anywhere interesting... really should do this several times more to verify... maybe try a kill -9 next time...) Program received signal SIGINT, Interrupt. 0x003c7520dff4 in __lll_lock_wait () from /lib64/libpthread.so.0 #0 0x003c7520dff4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003c75209328 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x003c752091f7 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0042bb54 in remove_from_proxy_hash (request=0x805170) at process.c:1579 #4 0x0042d4f5 in request_done (request=, action=) at process.c:532 #5 0x0042f42d in remove_all_proxied_requests ( ctx=, data=) at process.c:1540 #6 0x77de7822 in WalkNodeInOrder (X=, callback=0x42f400 , context=0x7fffec003710) at rbtree.c:551 #7 0x00431354 in event_new_fd (this=0x7fffec003710) at process.c:3553 #8 0x0043c648 in proxy_tls_recv (listener=0x7fffec003710) at tls_listen.c:499 #9 0x00430a8a in event_socket_handler (xel=, fd=, ctx=0x7fffec003710) at process.c:3309 #10 0x77deddfb in fr_event_loop (el=0x7d0b10) at event.c:415 #11 0x00422534 in main (argc=, argv=) at radiusd.c:413 Just one of those occasions where the grass looks greener on the SEGV side of the fence :-) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: RadSec FR3.0 to Radiator: "Received packet will be too large"
> -Original Message- > From: > freeradius-users-bounces+bjulin=clarku@lists.freeradius.or > g > [mailto:freeradius-users-bounces+bjulin=clarku.edu@lists.freer > adius.org] On Behalf Of Alan DeKok > Sent: Thursday, February 23, 2012 10:31 AM > Subject: Re: RadSec FR3.0 to Radiator: "Received packet will > be too large" > > Oops. Do a "git pull", and I think it should be fixed. That seems to have done the trick. I also tested the codepath that prints an error when fragment_size is too small, and that works fine, too. Thanks, again, very much. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RadSec FR3.0 to Radiator: "Received packet will be too large"
Brian Julin wrote: > After merging this (and a bunch of other stuff that had built up) and > rebuilding, this happens: Oops. Do a "git pull", and I think it should be fixed. Thanks for the GDB backtrace. That helped. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: RadSec FR3.0 to Radiator: "Received packet will be too large"
Thanks for looking into this, Alan. After merging this (and a bunch of other stuff that had built up) and rebuilding, this happens: Thu Feb 23 10:02:13 2012 : Debug: Opening new proxy (, 0) -> home_server (XXX, 2083) Thu Feb 23 10:02:13 2012 : Debug: Trying SSL to port 2083 Thu Feb 23 10:02:13 2012 : Debug: Requiring Server certificate Thu Feb 23 10:02:14 2012 : Debug: Listening on proxy (YY, 59751) -> home_server (XXX, 2083) Sending Access-Request of id 51 to port 2083 User-Name = "UU" NAS-IP-Address = NAS-Identifier = Airespace-Wlan-Id = V Framed-MTU = 1300 EAP-Message = Message-Authenticator = Proxy-State = 0x313433 Proxy-State = 0x3735 Thu Feb 23 10:02:14 2012 : Info: (0) Proxying request to home server port 2083 Thu Feb 23 10:02:14 2012 : Debug: Proxy is writing 150 bytes to SSL Thu Feb 23 10:02:14 2012 : Debug: Thread 4 waiting to be assigned a request Thu Feb 23 10:02:14 2012 : Debug: Waking up in 0.4 seconds. Program received signal SIGSEGV, Segmentation fault. 0x0043c6a7 in proxy_tls_recv (listener=0x700024d0) at tls_listen.c:478 478 if (!sock->data) sock->data = rad_malloc(listener->tls->fragment_size); Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.47.el6.x86_64 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6_2.1.x86_64 libcom_err-1.41.12-11.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-20.el6.x86_64 zlib-1.2.3-27.el6.x86_64 (gdb) print sock $1 = (listen_socket_t *) 0x700047a0 (gdb) print sock->data $2 = (uint8_t *) 0x0 (gdb) print listener $3 = (rad_listen_t *) 0x700024d0 (gdb) print listener->tls $4 = (fr_tls_server_conf_t *) 0x0 From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.org [freeradius-users-bounces+bjulin=clarku@lists.freeradius.org] On Behalf Of Alan DeKok [al...@deployingradius.com] Sent: Thursday, February 23, 2012 4:12 AM To: FreeRadius users mailing list Subject: Re: RadSec FR3.0 to Radiator: "Received packet will be too large" Brian Julin wrote: > We're piloting RadSec as a federation server uplink. They use Radiator. > When we first attempted to connect we'd get > a "Received packet will be too large!" carp from main/tls.c. They checked on > their end and say they have no fragment > size option for RadSec TLS connections, only for EAP-TLS connections. > > So we applied the below as a test and it works, but I was wondering as to the > wisdom of it... I've pushed a more functional fix. It now allocates the receive buffer based on fragment_size. If the RadSec connection sends too much data, the server prints out an error saying: ... set fragment_size=16384 Or whatever value will allow it to receive the data. I've also updated the comments about fragment_size in raddb/sites-available/tls Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RadSec FR3.0 to Radiator: "Received packet will be too large"
Brian Julin wrote: > We're piloting RadSec as a federation server uplink. They use Radiator. > When we first attempted to connect we'd get > a "Received packet will be too large!" carp from main/tls.c. They checked on > their end and say they have no fragment > size option for RadSec TLS connections, only for EAP-TLS connections. > > So we applied the below as a test and it works, but I was wondering as to the > wisdom of it... I've pushed a more functional fix. It now allocates the receive buffer based on fragment_size. If the RadSec connection sends too much data, the server prints out an error saying: ... set fragment_size=16384 Or whatever value will allow it to receive the data. I've also updated the comments about fragment_size in raddb/sites-available/tls Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RadSec FR3.0 to Radiator: "Received packet will be too large"
Stefan Winter wrote: > The RADIUS/TLS wrapper around those datagrams is not size-limited at all The TLS protocol sends data in packets with headers. Those packets can be up to 64K in length. The TLS code in FreeRADIUS was originally based on the EAP-TLS code. The EAP-TLS packets run over ethernet, which means that the encoded RADIUS + EAP + TLS packets must fit within an ethernet frame. i.e. about 1K. The TLS code in FreeRADIUS still has that limitation. > My guess is that main/tls.c "thinks" it operates within a EAP context > and tries to warn of too big data chunks, while there is actually > nothing to warn about. Yeah. The warning is just that the code doesn't handle more than 1K of TLS data at a time. It's easy enough to fix, though. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RadSec FR3.0 to Radiator: "Received packet will be too large"
Alan Buxey wrote: > interesting....a RADSEC packet can be much bigger than that too - 2048 gives > some room for a big > certificate - but not if its double-chained with intermediate and its got a > nice security size > instead of being a little 512bit RSA one. typically EAP-TLS can be > fragmented on the server due > to it going through to the end-clients ..and being UDP things get a little > nasty...whereas with RADSEC > theres no reason why a single TCP request couldnt be quite large and needing > to be fragmented > by the routers That is hidden from the server. It's just receiving a stream of data, not packets. IIRC, the TLS "packets" over TCP can be up to 64K in length. So I suppose that the server should handle that. Oh well... more changes. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RadSec FR3.0 to Radiator: "Received packet will be too large"
Hi, We're piloting RadSec as a federation server uplink. They use Radiator. When we first attempted to connect we'd get a "Received packet will be too large!" carp from main/tls.c. They checked on their end and say they have no fragment size option for RadSec TLS connections, only for EAP-TLS connections. The above doesn't make much sense to me... there are size limits in RADIUS, but not regarding the TLS stream around them. The limits in question are: - EAP-Message total length must be <= MTU between NAS and device (EAP cannot be fragmented on layer 2) - RADIUS datagram total length 4096 Bytes (arbitrary RFC limit) The RADIUS/TLS wrapper around those datagrams is not size-limited at all - it carries streams on "n" RADIUS datagrams. The TCP stack will take care of sending the data in chunks like with any other TCP based protocol. My guess is that main/tls.c "thinks" it operates within a EAP context and tries to warn of too big data chunks, while there is actually nothing to warn about. Greetings, Stefan Winter So we applied the below as a test and it works, but I was wondering as to the wisdom of it... interestinga RADSEC packet can be much bigger than that too - 2048 gives some room for a big certificate - but not if its double-chained with intermediate and its got a nice security size instead of being a little 512bit RSA one. typically EAP-TLS can be fragmented on the server due to it going through to the end-clients ..and being UDP things get a little nasty...whereas with RADSEC theres no reason why a single TCP request couldnt be quite large and needing to be fragmented by the routers alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RadSec FR3.0 to Radiator: "Received packet will be too large"
Hi, > We're piloting RadSec as a federation server uplink. They use Radiator. > When we first attempted to connect we'd get > a "Received packet will be too large!" carp from main/tls.c. They checked on > their end and say they have no fragment > size option for RadSec TLS connections, only for EAP-TLS connections. > > So we applied the below as a test and it works, but I was wondering as to the > wisdom of it... interestinga RADSEC packet can be much bigger than that too - 2048 gives some room for a big certificate - but not if its double-chained with intermediate and its got a nice security size instead of being a little 512bit RSA one. typically EAP-TLS can be fragmented on the server due to it going through to the end-clients ..and being UDP things get a little nasty...whereas with RADSEC theres no reason why a single TCP request couldnt be quite large and needing to be fragmented by the routers alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RadSec FR3.0 to Radiator: "Received packet will be too large"
Hello again, We're piloting RadSec as a federation server uplink. They use Radiator. When we first attempted to connect we'd get a "Received packet will be too large!" carp from main/tls.c. They checked on their end and say they have no fragment size option for RadSec TLS connections, only for EAP-TLS connections. So we applied the below as a test and it works, but I was wondering as to the wisdom of it... diff --git a/src/main/tls.c b/src/main/tls.c index 10caec4..947409f 100644 --- a/src/main/tls.c +++ b/src/main/tls.c @@ -2709,7 +2709,7 @@ int proxy_tls_recv(rad_listen_t *listener) size_t length; listen_socket_t *sock = listener->data; char buffer[256]; - uint8_t data[1024]; + uint8_t data[2048]; RADIUS_PACKET *packet; RAD_REQUEST_FUNP fun = NULL; - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radsec support on FR?
Hi, > Many others too have suspected that Dr Buxey's loyalties might not be > aligned appropriatelywe could spread malicious rumors suggesting he > butters his bread with MS IAS or Cisco ACS :) ;-) if this is RADIUS users anonymous then hi, my name is Alan and I admitt to having to use other RADIUS products :-( alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radsec support on FR?
Alan DeKok wrote: > > Alan Buxey wrote: > >> when its done(TM) is there a reason for rush? Theres RADSecProxy >> which you can happily use with FreeRADIUS (we've been using it in >> production for a year.) > > Pushing another RADIUS server on this list? Hmm... > Many others too have suspected that Dr Buxey's loyalties might not be aligned appropriatelywe could spread malicious rumors suggesting he butters his bread with MS IAS or Cisco ACS :) Cheers -- Alexander Clouter .sigmonster says: Marriage, n.: The evil aye. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radsec support on FR?
Hi, > Pushing another RADIUS server on this list? Hmm... Its just a proxy (well, it might be a bit more but it certainly doesnt have all the features and abilities of FreeRADIUS) - think of it as a simple 'hook' to add functionality to a 2.0.x or 2.1.x server - much like the special EAP hooks etc to add features which arent native :-) ..the alternative to using such a dumb proxy is much worse Alan alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radsec support on FR?
Alan Buxey wrote: > when its done(TM) is there a reason for rush? Theres RADSecProxy which you > can happily > use with FreeRADIUS (we've been using it in production for a year.) Pushing another RADIUS server on this list? Hmm... Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Radsec support on FR?
Thank you Alan^2 for your reply! Cheers, Panos Ps. it's good to know that RADSecProxy works fine and is stable.. > -Original Message- > From: freeradius-users- > bounces+panos=comp.lancs.ac...@lists.freeradius.org [mailto:freeradius- > users-bounces+panos=comp.lancs.ac...@lists.freeradius.org] On Behalf Of > Alan Buxey > Sent: 28 February 2011 20:17 > To: FreeRadius users mailing list > Subject: Re: Radsec support on FR? > > Hi, > > > Judging from the website and the archives in the > mailing > >list, native support for Radsec is planned on FR. Is there anyone > actively > >working on this? Is there any timescale for this to be streamed on > the > >main codebase? > > when its done(TM) is there a reason for rush? Theres RADSecProxy which > you can happily > use with FreeRADIUS (we've been using it in production for a year.) > > alan > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radsec support on FR?
Hi, > Judging from the website and the archives in the mailing >list, native support for Radsec is planned on FR. Is there anyone actively >working on this? Is there any timescale for this to be streamed on the >main codebase? when its done(TM) is there a reason for rush? Theres RADSecProxy which you can happily use with FreeRADIUS (we've been using it in production for a year.) alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radsec support on FR?
Panagiotis Georgopoulos wrote: > Judging from the website and the archives in the mailing > list, native support for Radsec is planned on FR. Is there anyone > actively working on this? Is there any timescale for this to be streamed > on the main codebase? Early summer. It won't be in 2.1.x. It requires large changes to the code base, which means major changes to internal APIs. It's likely now that RadSec will be released as part of 3.0, which includes (and will include) many other enhancements. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Radsec support on FR?
Hello there, Judging from the website and the archives in the mailing list, native support for Radsec is planned on FR. Is there anyone actively working on this? Is there any timescale for this to be streamed on the main codebase? Thanks a lot in advance, Panos - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Does freeRADIUS support RadSec
Hi, > I found this draft "draft-dekok-radext-dtls-02.txt". Does freeRADIUS support > RadSec feature? Is there any guidance for RadSec feature? not yet. thats why there isnt a doc to read alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Does freeRADIUS support RadSec
John wrote: > I found this draft "draft-dekok-radext-dtls-02.txt". Does freeRADIUS > support RadSec feature? Is there any guidance for RadSec feature? If it supported radsec, the configuration files would have examples. Radsec support should be added this year. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Does freeRADIUS support RadSec
I found this draft "draft-dekok-radext-dtls-02.txt". Does freeRADIUS support RadSec feature? Is there any guidance for RadSec feature? Best regards. John - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: First steps towards RadSec support
Alexander Clouter wrote: > To me, the proxying of requests, especially EAP, made with FreeRADIUS > fits in perfectly with SCTP built in multiplexingof course it would > run against the grain probably with all the UDP session handling > malarkey in there already. The issue is RADIUS session handling, not UDP session handling. RADIUS can only have 256 packets between any (src ip/port, dst ip/port) key. This is the same for TCP. Since SCTP adds the concept of "connections", where an end host may have multiple addresses, this actually makes things *worse* for RADIUS, because of the 256 packet limit. > Of course, someone needs to produce patches...RFCs...and so on. As that > person is not me...I'll leave that along side with all my other > ponderings...like why the IEEE decided that not using Token Ring-esque > stuff for wifi was a Good Idea(tm)[1] :-/ All of the SCTP docs I've read say that converting a TCP application to SCTP is about as simple as replacing TCP with SCTP in the source code. Since FR now has TCP transport... SCTP might not be that difficult. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: First steps towards RadSec support
Arran Cudbard-Bell wrote: > > On 17/09/2009 20:11, Alan DeKok wrote: >> Alexander Clouter wrote: >>> Just thinking out loud, but RADIUS over SCTP I would have thought would >>> be been more appropriate than TCP (as RFC3436 describes SCTP with TLS) >>> with the multiplexing of sessions being built in? >> >> Yes. But that's even more work >> >>> Would mean your ID field limitation could be removed... >> >> We could do that with RADIUS over TCP. But that's another story... > > Wasn't one of the points in the RFC that TCP is mature and implemented > properly in most modern operating systems... > So because something is new we should overlook that it was designed to avoid some of the pitfuls of TCP (for example one session per connection, with SCTP you get the multiplexing for free) and instead we should just ignore it? I have heard (making statements without references) that SCTP is pretty handy in the cases of VoIP and gaming. To me, the proxying of requests, especially EAP, made with FreeRADIUS fits in perfectly with SCTP built in multiplexingof course it would run against the grain probably with all the UDP session handling malarkey in there already. Of course, someone needs to produce patches...RFCs...and so on. As that person is not me...I'll leave that along side with all my other ponderings...like why the IEEE decided that not using Token Ring-esque stuff for wifi was a Good Idea(tm)[1] :-/ Just thinking out loud... :) Cheers [1] along a similar vain I guess folk thought "well Ethernet is simpler and more 'mature' than Token Ring"'yay' :-/ -- Alexander Clouter .sigmonster says: BOFH excuse #130: new management - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: First steps towards RadSec support
Arran Cudbard-Bell wrote: > Wasn't one of the points in the RFC that TCP is mature and implemented > properly in most modern operating systems... The "RADIUS over TCP" document is really just an into to RadSec, which is RADIUS over SSL over TCP. Using RADIUS over TCP all by itself is really not a good idea. For NAS to server communication, there isn't enough traffic to keep TCP happy. For inter-server proxying, it has no more security and privacy than normal RADIUS. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: First steps towards RadSec support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/09/2009 20:11, Alan DeKok wrote: > Alexander Clouter wrote: >> Just thinking out loud, but RADIUS over SCTP I would have thought would >> be been more appropriate than TCP (as RFC3436 describes SCTP with TLS) >> with the multiplexing of sessions being built in? > > Yes. But that's even more work > >> Would mean your ID field limitation could be removed... > > We could do that with RADIUS over TCP. But that's another story... Wasn't one of the points in the RFC that TCP is mature and implemented properly in most modern operating systems... - -- Arran Cudbard-Bell , Systems Administrator (AAA), Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqzdkcACgkQcaklux5oVKIqQwCfUw9ghYeL+exfrdeWIHDePvXH RYEAn37h17mwPvV//FKTvQsE5KklfU4R =8nkg -END PGP SIGNATURE- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: First steps towards RadSec support
Alexander Clouter wrote: > Just thinking out loud, but RADIUS over SCTP I would have thought would > be been more appropriate than TCP (as RFC3436 describes SCTP with TLS) > with the multiplexing of sessions being built in? Yes. But that's even more work > Would mean your ID field limitation could be removed... We could do that with RADIUS over TCP. But that's another story... Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: First steps towards RadSec support
Hi, Alan DeKok wrote: > > Now that version 2.1.7 has been released, the git repository has been > updated with the first step to RadSec support. > > For now, it only provides RADIUS transport over TCP, as per the > following document: > > http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-01 > > Using "bare" TCP without TLS is't a good idea in most cases. But it's > useful for testing, and can help with the transition to RadSec. > Just thinking out loud, but RADIUS over SCTP I would have thought would be been more appropriate than TCP (as RFC3436 describes SCTP with TLS) with the multiplexing of sessions being built in? Would mean your ID field limitation could be removed... However, as I do not plan on submitting patches, do ignore me :) Cheers -- Alexander Clouter .sigmonster says: If God is One, what is bad? -- Charles Manson - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
First steps towards RadSec support
Now that version 2.1.7 has been released, the git repository has been updated with the first step to RadSec support. For now, it only provides RADIUS transport over TCP, as per the following document: http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-01 Using "bare" TCP without TLS is't a good idea in most cases. But it's useful for testing, and can help with the transition to RadSec. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RadSec
Hi! > is RadSec implemented in FreeRadius? or it is planned to be done? Not yet, but since it is of some importance for some roaming infrastructures (specifically eduroam, www.eduroam.org), we'll hopefully be able to hire someone doing the work. Stefan Winter -- Stefan WINTER Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche - Ingénieur de recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RadSec
=?ISO-8859-1?Q?Manuel_S=E1nchez_Cuenca?= <[EMAIL PROTECTED]> wrote: > is RadSec implemented in FreeRadius? or it is planned to be done? It's not implemented in FreeRADIUS. It may be done in 2.0, if someone is willing to do the work, or motivate others to do the work. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RadSec
Hello all, is RadSec implemented in FreeRadius? or it is planned to be done? Thanks in advance. -- - Manuel Sanchez Cuenca Departamento de Ingenieria de la Informacion y las Comunicaciones Facultad de Informatica. Universidad de Murcia Campus de Espinardo - 30080 Murcia (SPAIN) Tel.: +34-968-364644Fax: +34-968-364151 email: [EMAIL PROTECTED] | [EMAIL PROTECTED] url: http://libra.inf.um.es/~lolo - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
apparently we do agree. thanks to Josh for his comment. just one thing: Alan DeKok wrote: Josh Howlett <[EMAIL PROTECTED]> wrote: I think the point the original poster was making was that Diameter allows arbitrary conversations between NASes and servers that are initiated by either party, via "applications", in an extensible manner. Yup. Which clients support diameter? I can't think of any. Until Cisco starts shipping diameter clients in their boxes, all of this discussion is wishful thinking. see? as i said: now you _started_ talking about God :-) ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
hi just a small preamble: i perfectly understand your position and i do not expect you to start a diameter implementation tomorrow :-) for me it's merely a strategic discussion. Alan DeKok wrote: Artur Hecker <[EMAIL PROTECTED]> wrote: well, from my perspective the main arguments would be: ... Those are all nice arguments for diameter, and good reasons why the protocol was designed. But I keep coming back to: Where are the client implementations? There are few to none client implementations. perfect, apparently we've just closed the circle: i started this conversation by the statement "what are the manufacturers waiting for?" adding that we might be missing interesting opportunities (as a cause of manufacturers not integrating diameter). you asked which features i was talking about :-) and now you ask about devices. circle completed. according to this funny newsgroups discussion study, that's probably the point where we start talking about god (since we have reached the convergence). - reliability (especially for accounting) radsec from the NAS to the RADIUS server would solve this. only partly, i think, since the reliability of accounting depends on more than just on the reliability of transmissions. there are things to specify in the implementations, especially when we start talking about multi-party-accounting. you have to think about accountability, integrity and non-repudiation. the fact that accounting support is not obligatory in radius does not exactly help here. udp is generally not very handy when you want more control over the NAS, even if i understand the initial motivation to base radius on it. however, today you run in all those problems with NAT, session initiation in firewalled environments, reliability, security and so on. radsec solves this, too. that's probably true. but, citing you: where are the client implementations? do you know of any radsec-cacable 802.11 access point? that would interest me personally. and what is radsec anyway? it is not an RFC standard track and why would i implement proprietary solutions when the sense is to enable a multi-domain operation? - server-initiated messaging the strict client-server design of radius (imho amplified by the use of the conn-less UDP) does not allow for server-initiated commands such as "disconnect" or "force re-authorization on profile changes" (very important with PBM) Huh? See the "disconnect request" packets. Radclient even supports this! hmmm?? well... PoD is probably the ugliest hack ever. imho, PoD is not a solution but a proof that things have been badly overseen during the Radius-design and especially re-design phases. and anyway it only partially answers my question. disconnect is just ONE possible application. what about a complete PBM solution? - NAS management radius-typical fqdn/shared secret based security simply does not scale. it is too complicated to manage NAS in this manner and often results in network-wide radius passwords. radsec with per-NAS certificates solves this. true and same as above: not a standard, no NAS. - security with proxying in Radius proxies can modify packets. this is often not a good thing to do. diameter has a far better and more extensive support for TLS, especially for roaming scenarios. security might not be an issue in the way radius is typically used, but its security definitions are completely obsolete (strange md5-based hashing is not exactly the state of the art, and right now ipsec support is as improbable with NAS as diameter-support itself :-)). radsec doesn't support this, but there was a radius + kerberos draft which did. Recent opinions in the radius working group indicate that dropping this might have been a mistake. *provoke* why talking about drafts when we have a standard track protocol which supports this? :-) radius+kerberos: if it used used radius as a trusted third party, then it does not surprise me that it has been abandoned... ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
Josh Howlett <[EMAIL PROTECTED]> wrote: > I think the point the original poster was making was that Diameter > allows arbitrary conversations between NASes and servers that are > initiated by either party, via "applications", in an extensible manner. Yup. Which clients support diameter? I can't think of any. Until Cisco starts shipping diameter clients in their boxes, all of this discussion is wishful thinking. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
On Thu, 14 Jul 2005, Alan DeKok wrote: > Artur Hecker <[EMAIL PROTECTED]> wrote: > > - server-initiated messaging > > the strict client-server design of radius (imho amplified by the use of > > the conn-less UDP) does not allow for server-initiated commands such as > > "disconnect" or "force re-authorization on profile changes" (very > > important with PBM) > > Huh? See the "disconnect request" packets. Radclient even supports > this! I think the point the original poster was making was that Diameter allows arbitrary conversations between NASes and servers that are initiated by either party, via "applications", in an extensible manner. Sure, the original RADIUS spec has been hacked around retrospectively to provide some server-initiated functionality, but it's never been very elegant. josh. Josh Howlett, Networking & Digital Communications, Information Systems & Computing, University of Bristol, U.K. 'phone: 0117 928 7850 email: [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
Artur Hecker <[EMAIL PROTECTED]> wrote: > well, from my perspective the main arguments would be: ... Those are all nice arguments for diameter, and good reasons why the protocol was designed. But I keep coming back to: Where are the client implementations? There are few to none client implementations. > - reliability (especially for accounting) radsec from the NAS to the RADIUS server would solve this. > udp is generally not very handy when you want more control over the NAS, > even if i understand the initial motivation to base radius on it. > however, today you run in all those problems with NAT, session > initiation in firewalled environments, reliability, security and so on. radsec solves this, too. > - server-initiated messaging > the strict client-server design of radius (imho amplified by the use of > the conn-less UDP) does not allow for server-initiated commands such as > "disconnect" or "force re-authorization on profile changes" (very > important with PBM) Huh? See the "disconnect request" packets. Radclient even supports this! > - NAS management > radius-typical fqdn/shared secret based security simply does not scale. > it is too complicated to manage NAS in this manner and often results in > network-wide radius passwords. radsec with per-NAS certificates solves this. > - security with proxying > in Radius proxies can modify packets. this is often not a good thing to > do. diameter has a far better and more extensive support for TLS, > especially for roaming scenarios. security might not be an issue in the > way radius is typically used, but its security definitions are > completely obsolete (strange md5-based hashing is not exactly the state > of the art, and right now ipsec support is as improbable with NAS as > diameter-support itself :-)). radsec doesn't support this, but there was a radius + kerberos draft which did. Recent opinions in the radius working group indicate that dropping this might have been a mistake. > well, we have seen a lot of implementations (especially in the hotspot > management area) where people use HTTP from server to NAS to trigger > radius-requests to be sent towards the server (!). it's nonsense. Yup. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
hi alan sorry for the delay. you might be right. yet i think that we might ignore some opportunities which would be possible/supported by diameter. Like... what? well, from my perspective the main arguments would be: - reliability (especially for accounting) in every related implementation we always had to tweak around the timeouts etc. just because you can't be sure that the accounting-stop arrives correctly when the user is disconnected. especially in an environment with a lot of connects and disconnects, this results in "stalled" sessions which have to be explicitly treated and where the relation to the real network usage is principally lost. this is boring. udp is generally not very handy when you want more control over the NAS, even if i understand the initial motivation to base radius on it. however, today you run in all those problems with NAT, session initiation in firewalled environments, reliability, security and so on. - server-initiated messaging the strict client-server design of radius (imho amplified by the use of the conn-less UDP) does not allow for server-initiated commands such as "disconnect" or "force re-authorization on profile changes" (very important with PBM) - NAS management radius-typical fqdn/shared secret based security simply does not scale. it is too complicated to manage NAS in this manner and often results in network-wide radius passwords. - security with proxying in Radius proxies can modify packets. this is often not a good thing to do. diameter has a far better and more extensive support for TLS, especially for roaming scenarios. security might not be an issue in the way radius is typically used, but its security definitions are completely obsolete (strange md5-based hashing is not exactly the state of the art, and right now ipsec support is as improbable with NAS as diameter-support itself :-)). that's what bothers me personally, in this order. i think there are much more of those in the diameter RFC. i really believe that current usage produces demand in the same manner as demand influences the usage. using additional web-based "touches" to trigger server solicitations by the client is indeed quite ridiculous. I'm not sure what you're referring to here. well, we have seen a lot of implementations (especially in the hotspot management area) where people use HTTP from server to NAS to trigger radius-requests to be sent towards the server (!). it's nonsense. It shouldn't be too hard to write a radsec implementation. Ideally, it could leverage the TLS code in rlm_eap. that wouldn't be enough for roaming cases. ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
Artur Hecker <[EMAIL PROTECTED]> wrote: > you might be right. yet i think that we might ignore some opportunities > which would be possible/supported by diameter. Like... what? > i really believe that current usage produces demand in the same > manner as demand influences the usage. using additional web-based > "touches" to trigger server solicitations by the client is indeed > quite ridiculous. I'm not sure what you're referring to here. > the main problem with radius is IMHO its client-server nature. it > inherently lacks control. also TCP in dimaeter and defined TLS in proxy > mode might be advantageous. It shouldn't be too hard to write a radsec implementation. Ideally, it could leverage the TLS code in rlm_eap. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
Stefan Winter <[EMAIL PROTECTED]> wrote: > > see also "open diameter". it even does EAP... > > Well, it does packet handling, providing only a library for the > server. But in order to really use it, you must first wrap daemon > glue code around the libraries, and you must be able to do something > with the credentials you get from that server. Which leads to > missing backends again. It shouldn't be that hard to take "wire diameter", and have it convert all diameter messages to RADIUS. At that point, you've got a real server doing the work. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
> Alan DeKok wrote: > > See "wire diameter", from Taiwan. I recall it's a student project, > > but it does give a minimal diameter server. I took a look at it two months ago or so. It may implement the Diameter protocol, but does not have any backends on board, so the use case I mentioned (AD) or a simple MySQL backend just aren't available. Plus, I mailed the author at the time and asked him several questions about WIRE Diameter and never got a reply. > Artur Hecker wrote: > see also "open diameter". it even does EAP... Well, it does packet handling, providing only a library for the server. But in order to really use it, you must first wrap daemon glue code around the libraries, and you must be able to do something with the credentials you get from that server. Which leads to missing backends again. Greetings, Stefan Winter -- Stefan WINTER Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingénieur de recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: [EMAIL PROTECTED] tél.: +352 424409-1 http://www.restena.lu fax: +352 422473 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
you might be right. yet i think that we might ignore some opportunities which would be possible/supported by diameter. i really believe that current usage produces demand in the same manner as demand influences the usage. using additional web-based "touches" to trigger server solicitations by the client is indeed quite ridiculous. the main problem with radius is IMHO its client-server nature. it inherently lacks control. also TCP in dimaeter and defined TLS in proxy mode might be advantageous. ciao artur Alan DeKok wrote: Artur Hecker <[EMAIL PROTECTED]> wrote: well, that's not the point since diameter would be backwards compatible to radius... but i do ask myself what the manufacturers are waiting for. it could be at least an option. Diameter will be interesting ole when manufacturers ship millions of boxes with diameter. Why don't they? Let's look at what they need from RADIUS or diameter: 1) username/password authentication. Yup, RADIUS does this. 2) EAP->AAA for wireless. Yup, RADIUS does this. The nice thing about RADIUS is that it's so easy to implement. In contrast, diameter is 1000x more complicated than RADIUS, and it only solve .1% more problems than RADIUS. Diameter is not going to be widely deployed. Ever. see also "open diameter". it even does EAP... Not as many EAP methods as FreeRADIUS. :) Adding EAP-FAST to FreeRADIUS may not be too hard, either. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
Artur Hecker <[EMAIL PROTECTED]> wrote: > well, that's not the point since diameter would be backwards compatible > to radius... but i do ask myself what the manufacturers are waiting for. > it could be at least an option. Diameter will be interesting ole when manufacturers ship millions of boxes with diameter. Why don't they? Let's look at what they need from RADIUS or diameter: 1) username/password authentication. Yup, RADIUS does this. 2) EAP->AAA for wireless. Yup, RADIUS does this. The nice thing about RADIUS is that it's so easy to implement. In contrast, diameter is 1000x more complicated than RADIUS, and it only solve .1% more problems than RADIUS. Diameter is not going to be widely deployed. Ever. > see also "open diameter". it even does EAP... Not as many EAP methods as FreeRADIUS. :) Adding EAP-FAST to FreeRADIUS may not be too hard, either. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
Alan DeKok wrote: See "wire diameter", from Taiwan. I recall it's a student project, but it does give a minimal diameter server. But again, can you think of *one* client implementation of diameter? I can't. well, that's not the point since diameter would be backwards compatible to radius... but i do ask myself what the manufacturers are waiting for. it could be at least an option. see also "open diameter". it even does EAP... ciao artur - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radius, Radsec, Diameter [was: Silly question - secure Radius?]
Stefan Winter <[EMAIL PROTECTED]> wrote: > Speaking of a radar - is an implementation of the Diameter protocol > something you have on that radar as well? Why the heck would we do that? > To my knowledge, no real usable implementation exists. The only > serious thing on Open Source side I have seen is opendiameter > (www.opendiameter.org), but they are only providing libraries for > Diameter internals so far. If you want to do a real, practical task, > like "I would like to authnuse Active Directory as a backend > authentication and TTLS-PAP for the credential transport" you are > pretty much on your own right now. See "wire diameter", from Taiwan. I recall it's a student project, but it does give a minimal diameter server. But again, can you think of *one* client implementation of diameter? I can't. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Radius, Radsec, Diameter [was: Silly question - secure Radius?]
Hi! > radsec? It addresses the server->server problem, not the supplicant > login problem. > Sure, it's on the radar, but so far there hasn't been much > *practical* interest in implementing it. Speaking of a radar - is an implementation of the Diameter protocol something you have on that radar as well? To my knowledge, no real usable implementation exists. The only serious thing on Open Source side I have seen is opendiameter (www.opendiameter.org), but they are only providing libraries for Diameter internals so far. If you want to do a real, practical task, like "I would like to authnuse Active Directory as a backend authentication and TTLS-PAP for the credential transport" you are pretty much on your own right now. Greetings, Stefan Winter -- Stefan WINTER Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingénieur de recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: [EMAIL PROTECTED] tél.: +352 424409-1 http://www.restena.lu fax: +352 422473 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
