Hi Alan, I am suspecting some radius setting on my server because free radius on other server is responding and authentication and accounting is successful. On May 24, 2013 7:56 PM, <freeradius-users-request@lists.freeradius.org> wrote:
Send Freeradius-Users mailing list submissions to freeradius-users@lists.freeradius.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.freeradius.org/mailman/listinfo/freeradius-users or, via email, send a message with subject or body 'help' to freeradius-users-request@lists.freeradius.org
You can reach the person managing the list at freeradius-users-owner@lists.freeradius.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Freeradius-Users digest..."
Today's Topics:
1. AES-GCM (Pieter Hulshoff) 2. Re: AES-GCM (Phil Mayers) 3. Re: AES-GCM (Pieter Hulshoff) 4. Re: AES-GCM (Phil Mayers) 5. Re: AES-GCM (Pieter Hulshoff) 6. Re: issue with radius accounting (Alan DeKok) 7. Re: Failure authenticate using IPv6 (Alan DeKok) 8. Re: Retrieving eDirectory VLAN attributes (Alan DeKok)
----------------------------------------------------------------------
Message: 1 Date: Fri, 24 May 2013 12:44:02 +0200 From: Pieter Hulshoff <phulshof@xs4all.nl> To: freeradius-users@lists.freeradius.org Subject: AES-GCM Message-ID: <2687107.xyZuJZ1fbJ@spaceballsml> Content-Type: text/plain; charset="us-ascii"
Hello all,
Does FreeRADIUS support AES-GCM in EAP-TLS? I couldn't find the term in the documentation, the wiki or the mailinglist archives, but perhaps I'm looking in the wrong place?
Kind regards,
Pieter Hulshoff
------------------------------
Message: 2 Date: Fri, 24 May 2013 12:21:47 +0100 From: Phil Mayers <p.mayers@imperial.ac.uk> To: freeradius-users@lists.freeradius.org Subject: Re: AES-GCM Message-ID: <519F4D4B.4080000@imperial.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 24/05/13 11:44, Pieter Hulshoff wrote:
Hello all,
Does FreeRADIUS support AES-GCM in EAP-TLS? I couldn't find the term in the documentation, the wiki or the mailinglist archives, but perhaps I'm looking in the wrong place?
Typically this is down the TLS libraries; it's not usually the case that the application needs to do anything.
That said, EAP-TLS is typically TLS 1.0. AIUI, AEAD ciphers require TLS 1.2 - see section 4 of RFC 5288. But again, FreeRADIUS doesn't involve itself in this level of detail - that's an aspect of the TLS library (OpenSSL) we use, and whatever the EAP-TLS client is using.
Note also that EAP-TLS (unlike other TLS-based EAP methods, such as PEAP or TTLS) never actually sends any data over the TLS session; essentially, it consists solely of the handshake. In TLS terms, EAP-TLS never sends any TLS records of type=23 (application data). So, the negotiated cipher is not used for very much.
PEAP and TTLS have "inner" EAP exchanges, that are protected with the TLS session, and sent as TLS type=23 records.
Slightly OT, there seems to be some degree of uncertainty about GCM in general, and whether it's a sensible cipher mode - for example, see http://www.imperialviolet.org/2013/01/13/rwc03.html
------------------------------
Message: 3 Date: Fri, 24 May 2013 13:47:36 +0200 From: Pieter Hulshoff <phulshof@xs4all.nl> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: AES-GCM Message-ID: <2024766.p6x3QSbeB1@spaceballsml> Content-Type: text/plain; charset="us-ascii"
On Friday, May 24, 2013 12:21:47 PM Phil Mayers wrote:
On 24/05/13 11:44, Pieter Hulshoff wrote:
Hello all,
Does FreeRADIUS support AES-GCM in EAP-TLS? I couldn't find the term in the documentation, the wiki or the mailinglist archives, but perhaps I'm looking in the wrong place?
Typically this is down the TLS libraries; it's not usually the case that the application needs to do anything.
It seems I have a lot to learn yet about what is and is not a part of FreeRADIUS. My apologies for pushing (slightly) OT subjects onto the mailinglist.
That said, EAP-TLS is typically TLS 1.0. AIUI, AEAD ciphers require TLS 1.2 - see section 4 of RFC 5288. But again, FreeRADIUS doesn't involve itself in this level of detail - that's an aspect of the TLS library (OpenSSL) we use, and whatever the EAP-TLS client is using.
I guess that if we want to use AEAD cyphers we'll need to find another TLS library or adapt/contribute to OpenSSL?
Note also that EAP-TLS (unlike other TLS-based EAP methods, such as PEAP or TTLS) never actually sends any data over the TLS session; essentially, it consists solely of the handshake. In TLS terms, EAP-TLS never sends any TLS records of type=23 (application data). So, the negotiated cipher is not used for very much.
The EAP-TLS Finished (type=20) are secured/signed with this negotiated cipher though, correct?
Slightly OT, there seems to be some degree of uncertainty about GCM in general, and whether it's a sensible cipher mode - for example, see http://www.imperialviolet.org/2013/01/13/rwc03.html
Interesting article nontheless. I guess I've been working as a hardware engineer for too long; I haven't been bothered by timing side-channel attacks too much. :) It's something to take into consideration though.
Kind regards,
Pieter Hulshoff
------------------------------
Message: 4 Date: Fri, 24 May 2013 13:06:11 +0100 From: Phil Mayers <p.mayers@imperial.ac.uk> To: freeradius-users@lists.freeradius.org Subject: Re: AES-GCM Message-ID: <519F57B3.9030800@imperial.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 24/05/13 12:47, Pieter Hulshoff wrote:
I guess that if we want to use AEAD cyphers we'll need to find another TLS library or adapt/contribute to OpenSSL?
I think they're supported as of OpenSSL 1.0.1, so merely compiling against that should be sufficient, but both ends then need to use TLS v1.2 and, as I say, most do not.
(I'm also not sure if FreeRADIUS explicitly forces a specific TLS version - it might, check the source code)
The EAP-TLS Finished (type=20) are secured/signed with this negotiated cipher though, correct?
Off the top of my head, everything after the change cipher spec is encrypted with the negotiated symmetric cipher, yes.
------------------------------
Message: 5 Date: Fri, 24 May 2013 14:09:35 +0200 From: Pieter Hulshoff <phulshof@xs4all.nl> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: AES-GCM Message-ID: <4017853.IFDhid4HjM@spaceballsml> Content-Type: text/plain; charset="us-ascii"
On Friday, May 24, 2013 01:47:36 PM Pieter Hulshoff wrote:
I guess that if we want to use AEAD cyphers we'll need to find another TLS library or adapt/contribute to OpenSSL?
It seems some people are way ahead of me:
http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations#Encryption_Al... Support for AES-GCM was added in v1.0.1
Kind regards,
Pieter Hulshoff
------------------------------
Message: 6 Date: Fri, 24 May 2013 09:53:08 -0400 From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: issue with radius accounting Message-ID: <519F70C4.7060604@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1
Arvind Bahuguni wrote:
Hi, Need help in resolving radius issues. My radius server is not processing accounting packets, radius server is sending access-accept but not proceeding further with accounting, it will send access-accept and start waiting for another request.
This is in the FAQ. Read it.
Looks like some radius server setting issues, please help me .
So... the RADIUS server doesn't receive packets, and you blame it?
How about blaming the system which *sends* the accounting packets?
Alan DeKok.
------------------------------
Message: 7 Date: Fri, 24 May 2013 09:56:59 -0400 From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Failure authenticate using IPv6 Message-ID: <519F71AB.6090407@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1
Stefan Winter wrote:
I don't *know* why this doesn't work, but it does with our global-scope addresses just fine, so I'm guessing it's the address type.
Especially since link-local addresses are only valid with an interface scope.
Exactly.
is the valid address. I don't know if the FreeRADIUS address parser is prepared to handle such interface-scoped addresses. There's not much use case for this.
FreeRADIUS calls getaddrinfo, which *should* parse link-local addresses. I guess...
Alan DeKok.
------------------------------
Message: 8 Date: Fri, 24 May 2013 10:17:33 -0400 From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Retrieving eDirectory VLAN attributes Message-ID: <519F767D.5030704@deployingradius.com> Content-Type: text/plain; charset=UTF-8
Dan Lietz wrote:
I?m pretty much a noob when it comes to freeradius as I still don?t completely understand what files are used for authorization and authentication and where to put different certain pieces of configuration.
Rule 1: don't touch anything. The configuration is complicated, but it mostly works.
The "files used for authorization" are the virtual servers. See raddb/sites-enabled. Those files reference other configuration. But it's all reasonably well abstracted.
i.e. you don't need to know anything about the "mschap" module configuration to use it. You don't even need to know *where* its configuration lives. But if you run the server in debugging mode, it will tell you.
The "where to put configuration" issue largely depends on what you want to do. Edit a virtual server? See raddb/sites-enabled. A module? raddb/modules.
I?m trying to set up dynamic vlans for a wireless network with a Ruckus Zone Director backend and a freeradius backend authenticating via LDAP to eDirectory running on the same box. So far I?ve managed to configure 802.11x authentication using PEAP and that is working well.
That's good.
Now I want to be able to retrieve the radius attribute in eDirectory for the vlan tag so the Ruckus Zone Directory will automatically place the user on the correct vlan once they are authenticated.
OK.
I did some initial testing without using LDAP by adding the following lines to my users file:
DEFAULT Tunnel-Type = VLAN, Tunnel-Medium-Type = 802, Tunnel-Private-Group-ID = 85, Fall-Through=Yes
Yes, that works. It's a good first step.
By changing the value of ?Tunnel-Private-Group-ID? (set to 85 in the above example) the Zone Director will move users to the vlan ID I specify here, but it is obviously static and does not change based on the user. The next step is to configure FreeRadius to pull the info from eDir via LDAP and that?s the part I?m not getting.
The "ldap.attrmap" file is in the "raddb" directory. It contains mappings from LDAP to RADIUS. It's also documented in the comments at the top of the file.
Part of my problem is that I don?t know which attributes mappings are built in and which aren?t.
See ldap.attrmap.
According to this document: Integrating Novell eDirectory with FreeRadius < https://www.netiq.com/documentation/edir_radius/radiusadmin/?page=/documenta...
the listed radius attributes are available for use, but does that mean I don?t need to add them to ldap.attr or the dictionary file at all? Or that I don?t need to add an LDAP attribute map to the LDAP Group object in iManager?
The LDAP to RADIUS map is defined in ldap.attrmap. And ONLY in ldap.attrmap. Go look there. If a mapping isn't there, it isn't mapped. If it is there, the LDAP attribute (if any) is mapped to the RADIUS equivalent.
The other thing I don?t understand is where (i.e. what file) to put the ldap call for said attributes and what the syntax would look like.
See raddb/sites-available/inner-tunnel, and "default". Look for "ldap". Read the comments there.
I?ve configured my eap.conf to include ?copy_request_to_tunnel = yes? and ?use_tunneled_reply = yes?
That's correct for your setup.
Alan DeKok.
------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
End of Freeradius-Users Digest, Vol 97, Issue 80 ************************************************