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.
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_Algorithms
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=/documentation/edir_radius/radiusadmin/data/bv8m2ll.html>
> 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
************************************************