gmane.comp.freeradius.devel

Re: default certificates: add a useless CRL distribution point?

Phil Mayers — 2013-05-25T21:47:44

Oh FFS...


Are you sure about that? What if the client tries to check the CRL once 
it *has* a connection and fails? Will Windows 8Phone eventually decide 
the CA is to be untrusted?

That would obviously be pretty disastrous for "fake" CAs; but the 
Microsoft cert stuff does some funny things.


I think that would be a serious error; "Netgear & UW NTP" springs to 
mind. Better put "http://127.0.0.1" if you're going to put something fake.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

default certificates: add a useless CRL distribution point?

Stefan Winter — 2013-05-25T19:56:47

Hi,

the bootstrap script adds EKU "TLS Web Server" because that makes most
of the Windows editions happy.

Folks in eduroam have now discovered something ... odd ... with Windows
Phone 8.

It requires that the *server* certificate that comes in during EAP
contains the "CRL Distribution Point" extension.

This is rather useless of course, because the client can't actually
consult the CRL because he has no network while he's trying to
authenticate. As an effect of that, it does not matter at all whether
the URL in the CDP extension actually serves a CRL. It's just an extra
annoyance to be aware of.

I'm wondering: should the bootstrap scripts add a CDP pointing to a
non-existing URL? It would improve the compatibility with these devices.
It would make the certs look stranger though, as that is just added
junk. Maybe a URL like "http://www.freeradius.org/silly/cert/extension/"
would make that clear for anyone who cares to take a look at the
generated certs.

Note that I don't know if the CA and/or intermediates also need that
extension present. I can find out if need be (and I'm sure Tomasz and
Maja are reading this list themselves anyway :-) ).

Greetings,

Stefan Winter
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Commit report for master branch

The git bot — 2013-05-24T22:00:01

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server)

======
if len==0, buff may be NULL

Alan T. DeKok< at >2013-05-24T16:25:14Z
Files modified:
* src/main/xlat.c

Commit diff:
https://github.com/FreeRADIUS/freeradius-server/commit/0e58905fed2bd3e5177e8d235e6b6cfa28d2e7da
====== 
The "opaque" data belongs to handler, not to reply

Alan T. DeKok< at >2013-05-24T15:54:26Z
Files modified:
* src/modules/rlm_eap/types/rlm_eap_md5/rlm_eap_md5.c

Commit diff:
https://github.com/FreeRADIUS/freeradius-server/commit/c6bcb93d55501336bb1f12f74ff8ec64dcb52e10
====== 
Allow forcible empty expansions

Alan T. DeKok< at >2013-05-24T15:48:49Z
Files modified:
* src/main/xlat.c

Commit diff:
https://github.com/FreeRADIUS/freeradius-server/commit/d2e58bbb94dff280600f289c8be95e96d33e447c
======

Commit report for master branch

The git bot — 2013-05-23T22:00:02

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server)

======
Merge pull request #295 from leprechau/master

fix compilation error in rlm_ruby

Arran Cudbard-Bell< at >2013-05-23T01:45:57Z
Files modified:
* src/modules/rlm_ruby/rlm_ruby.c

Commit diff:
https://github.com/FreeRADIUS/freeradius-server/commit/9e8ef869ba8b23bfa7100856ce33236be1d521d4
====== 
fix compilation error

Aaron Hurt< at >2013-05-22T06:48:07Z
Files modified:
* src/modules/rlm_ruby/rlm_ruby.c

Commit diff:
https://github.com/FreeRADIUS/freeradius-server/commit/0ddad94652b0b91f7e3fd36efa026a07d5d5a698
======

Re: PEAP/EAP-MSCHAPv2 module modification problem

Alan DeKok — 2013-05-23T14:17:18

  As I said, your design is wrong.

  The EAP module SHOULD NOT be doing password lookups to external systems.

  And the server really isn't set up for things like "try authentication
1, if it fails, try authentication 2".


  Keeping systems in sync is really outside of FreeRADIUS.  But you can
do what you want in the default configuration.  All you need is to
create a module which looks up passwords in (1) or in (2).


  You don't.  That's why the git "head" has a connection pool API.  See
rlm_sql, rlm_ldap, rlm_redis, etc.


  You're asking the wrong question.  You SHOULD be doing this in the
"inner-tunnel" virtual server:

authorize {
...
lookup_password_in_1
...

eap
...

}

authenticate {
...
Auth-Type MS-CHAP {
mschap {
reject = 1
}
if (reject) {
update reply {
MS-CHAP-Error !* 0x00
}

lookup_password_in_2
mschap
}
}
}


  That will fix the problem.  It will also ensure that your module will
*continue* working when the server is upgraded.  You won't need
source-code patches.

  And you won't be fighting with the internals of the EAP module.  The
whole reason you're having issues is because the module isn't *designed*
to support what you're doing.  Because it's wrong.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Re: PEAP/EAP-MSCHAPv2 module modification problem

Ivan Ostres — 2013-05-23T13:55:43

Hi Alan,

thanks for answering - I indeed have a weird setup here - I have 2 
external authentication systems:

(1) fast one acting as cache (that means it could have stale password info)
(2) slow one which always have a right password

The thing is that I need to use (1) whenever possible so I can do the 
lookup in (1) while in rlm_eap and simply do 
"pairmake_config("NT-Password",....). Then in eap-mschapv2 handler I 
need to check whether this password is ok (I can do that by checking 
response from peer and then if password appear to be wrong I need to 
contact (2) to check whether password is really wrong or just  (1) was 
wrong. If password in (2) is correct, I need to update record in (1).

Since I don't want to open new connection to (1) and (2) for every 
authentication I wanted to keep connections open in rlm_eap module 
instead in eap-mschapv2 handler but somehow I need to know whether 
password from (1) or (2) was eventually used to update (1) if needed - 
that;s why I asked how can I propagate info from eap-mschapv2 handler 
back to rlm_eap.

BR,
iostres
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Re: PEAP/EAP-MSCHAPv2 module modification problem

Alan DeKok — 2013-05-23T12:59:09

  You should do that ONLY if the password store does MS-CHAP.

  Otherwise, you should write a module to pull the password from the
store, and let FreeRADIUS do the rest.


  As Phil said, you need to set "use_tunneled_reply" in the PEAP module.

  Or, since you're already hacking the code, just access
request->parent->reply directly.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Re: PEAP/EAP-MSCHAPv2 module modification problem

Phil Mayers — 2013-05-23T11:41:25


Sorry, I don't understand what you mean. Why would you want to do that?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Re: PEAP/EAP-MSCHAPv2 module modification problem

Ivan Ostres — 2013-05-23T11:34:28

Hi!

I actually set that one...the real question is -> how to send/receive 
pairs between rlm_eap and handler (rlm_eap_mschapv2)?

This communication part is the real problem.

BR,
iostres


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Re: PEAP/EAP-MSCHAPv2 module modification problem

Phil Mayers — 2013-05-23T11:24:43

It sounds like you need:

use_tunneled_reply = yes

...in your "peap {}" block. Attributes from the inner access-accept 
should be copied to the outer if this is set.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Re: PEAP/EAP-MSCHAPv2 module modification problem

Ivan Ostres — 2013-05-23T11:00:56

Forgot to mention - if I put this AVP in rlm_eap.c (line 439) under:

        if ((request->reply->code == PW_AUTHENTICATION_ACK) &&
             request->username) {

This VSA is contained in outgoing access-accept. But the problem is that 
this VSA value should be set in eap-mschapv2. How to transfer value from 
EAP-MSCHAPv2 to rlm_eap?

BR,
iostres

On 5/23/13 12:45 PM, Ivan Ostres wrote:

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

PEAP/EAP-MSCHAPv2 module modification problem

Ivan Ostres — 2013-05-23T10:45:21

Hello list,

I am using PEAP-EAP-MSCHAPv2 combo with freeradius. I modified 
EAP-MSCHAPv2 rlm to use a weird password store system and authentication 
works fine. There is one thing I am missing - I need to add a specific 
VSA to access-accept (depending on the user) and am trying to do it this 
way:

#define VENDOR_CISCO 9
#define CISCO_SSG_ACCOUNT_INFO 250

VALUE_PAIR *myvsa;
myvsa = radius_paircreate(request, &request->reply->vps, 
CISCO_SSG_ACCOUNT_INFO, VENDOR_CISCO);
if (myvsa == NULL)
    RDEBUG("MYVSA == NULL");
const char *mystr="AINTERNET";
pairmemcpy(myvsa, (const uint8_t *)mystr,4);

this is done under

case PW_MSCHAP2_SUCCESS: (line ~180) in rlm_eap_mschapv2.c module.

There is no error but I never see this output on access-accept sent to 
BRAS. What am I doing wrong? Is there a better way to achieve this?

BR,
iostres
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

pull request < at >292 discusstion requirement

yuanlinyu — 2013-05-23T07:55:32

hi, all guys and administrators,
I have a pull request #292 about ipv6 issue on master brach

src/lib/misc.c, fr_ipaddr_cmp()


|
|  #ifdef HAVE_STRUCT_SOCKADDR_IN6 |
|    case AF_INET6: |
| -    if (a->scope < b->scope) return -1; |
| -    if (a->scope > b->scope) return +1; |
| - |
|      return memcmp(&a->ipaddr.ip6addr, |
|
|

this fix according to my test configuration,
1. problem

1.1 /usr/local/etc/raddb/clients.conf, add link local client
client fe80::/16 {
    secret = cameo
    shortname = atgs950
}

1.2 /usr/local/etc/raddb/sites-available/default, open ipv6 auth and acct:
ipv6addr = :: # any. ::1 == localhost

1.3 client send auth request, server debug info as below:
Wed May 22 11:18:57 2013 : Error: Ignoring request to auth interface eth0 address :: port 1812 as server default from unknown client fe80::290:c0ff:fe82:1630 port 49153 proto udp

2. I realy think scope is not necessary as a rb-tree key, for ip address will be unique and represent the scope "global", "link", "site", and it's transport issue
3. I also found no place to parse configured address's scope id

anyone can tell me if it's code issue or not?

please help review pull request, thanks

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Commit report for master branch

The git bot — 2013-05-21T22:00:08

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server)

======
Updates

Alan T. DeKok< at >2013-05-21T19:05:13Z
Files modified:
* share/dictionary.telkom

Commit diff:
https://github.com/FreeRADIUS/freeradius-server/commit/5113475ce044b03bbd5bd941828d10d7ca514c9f
====== 
removed old comment

Alan T. DeKok< at >2013-05-21T17:04:31Z
Files modified:
* src/tests/condition.txt

Commit diff:
https://github.com/FreeRADIUS/freeradius-server/commit/03783354d0a38aa09e296bf4fb20200b5b5537bf
====== 
Infinite loops are bad.

foo {
...
}

authorize = ${foo}

will add "foo" to the parent section, by appending it to the end
of the list.  But foo is already in the section, so we create
a loop inside the linked list of children.  That's bad.

Alan T. DeKok< at >2013-05-21T16:49:41Z
Files modified:
* src/main/conffile.c

Commit diff:
https://github.com/FreeRADIUS/freeradius-server/commit/41380536131ec10baecf429acb73ff829245fa5a
======

Commit report for v2.x.x branch

The git bot — 2013-05-21T22:00:04

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server)

======
Updates

Alan T. DeKok< at >2013-05-21T19:04:37Z
Files modified:
* share/dictionary.telkom

Commit diff:
https://github.com/FreeRADIUS/freeradius-server/commit/2fa057297c910d0b0eb7c108d63c9c6e9d30f29a
====== 
Merge pull request #293 from fajarnugraha/v2.x.x-suse-20130510

Fix suse package to build and run cleanly for current v2.x.x branch

Alan DeKok< at >2013-05-21T15:10:57Z
Files modified:
* suse/freeradius.spec

Commit diff:
https://github.com/FreeRADIUS/freeradius-server/commit/e2706906bd7a0932d753974e479c66b85a147d7b
====== 
suse: build fixes

* Bump version to 2.2.1
* Only requires sqlite3-devel and libpcap-devel on Suse 11.x and above
* README was renamed to README.rst

Fajar A. Nugraha< at >2013-05-21T11:05:48Z
Files modified:
* suse/freeradius.spec

Commit diff:
https://github.com/FreeRADIUS/freeradius-server/commit/504f188078e0a58c3720a6619af1d22b4d4eab11
======

Commit report for master branch

The git bot — 2013-05-17T22:00:07

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server)

======
A better way of getting empty alternations

Alan T. DeKok< at >2013-05-17T17:26:06Z
Files modified:
* src/main/xlat.c

Commit diff:
https://github.com/FreeRADIUS/freeradius-server/commit/25b6fdd66ac5144610e805d6476b4286c09e9a04
======

Re: More additions to unlang

Arran Cudbard-Bell — 2013-05-17T15:47:15

On 17 May 2013, at 08:33, Alan DeKok <aland< at >deployingradius.com> wrote:


*sigh*, please no, no pointless variations, this isn't Perl.


and the new xlat parser may eventually allow pre-compilation of static expressions so the performance hit should go down significantly.

Arran Cudbard-Bell <a.cudbardb< at >freeradius.org>
FreeRADIUS Development Team

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Re: ASSERT FAILED

Maja Wolniewicz — 2013-05-17T14:13:38

W dniu 16.05.2013 23:44, Alan DeKok pisze:
Today with last git version the sever dies while parsing it.

Maja

Re: More additions to unlang

Alan DeKok — 2013-05-17T12:33:13

  Yeah.


  That's hard.  Mostly because the configuration file parser is bad.


  Hmm... that may be easier to do.


  Sure... but regex matches work for now.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Re: More additions to unlang

Jakob Hirsch — 2013-05-17T08:05:44

Alan DeKok, 16.05.2013 23:51:

Is there any difference (functional or performance-wise) between this
and the previously posted form with the ampersand, i.e. "if
(&Session-Timeout < ..."?


So it seem there's quite a lot of good stuff coming :)

Btw, if you are still looking for more ideas, what about this:

- ternary logic, like C's "condition ? yes : no"
This would save a bunch of lines, because instead of

if (some condition) {
  update reply {
    Some-Attribute := "foo"
    Session-Timeout := 600
  }
}
else {
  update reply {
    Some-Attribute := "bar"
    Session-Timeout := 600
  }
}

we could do a simple and short

update reply {
  Some-Attribute := (some condition) ? "foo" : "bar"
}

Not sure how easy this is to parse, though. Maybe something like
"%{cond ? true : false}" would be better.


- regex-like comparison operators
E.g. =^ and =$ would be true if the LHS starts/ends with the RHS string.
I.e.,

( "foobar" =^ "foo") -> true
( "foobar" =^ "bar") -> false
( "foobar" =$ "foo") -> false
( "foobar" =$ "bar") -> true

This would elimate the need for a lot of regex matches.


I never looked into the unlang code, but if I find the time, I could try
to implement it myself, but probably not for 2.x, now that 3.x is upcoming.



Regards
Jakob

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Re: More additions to unlang

Arran Cudbard-Bell — 2013-05-16T22:08:59

On 16 May 2013, at 17:51, Alan DeKok <aland< at >deployingradius.com> wrote:


The idea being that you can reference other things in your conditions
like environmental variables, or other configuration items and enable
or disable blocks of policy code.

Regular expressions should work too, as should all of the casting 
previously discussed.

The idea is to allow something like:

if (<cidr>$ENV{HOSTNAME} == 192.168/24) {
// slight variation in policy
} else if (<cidr>$ENV{hostname} == 172.0/24) {
// other slight variation in policy
}

or

if ($ENV{HOSTNAME} =~ /*.[.]cluster_x.example.org$/) {
// slight variation in policy
} else if ($ENV{hostname} =~ /*.[.]cluster_y.example.org$/) {
// other slight variation in policy
}

So if you're deploying the same OS image to multiple virtual machines
or multiple clusters, and require slight variations in policy, you can
now do that extremely efficiently.

HUP will cause the config to be re-read, re-parsed and so re-evaluate
all the pre-evaluated conditions.

Arran Cudbard-Bell <a.cudbardb< at >freeradius.org>
FreeRADIUS Development Team

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html