Re: public secret and public radius server. Is it secure?

2006-06-04 Thread Alan DeKok
sophana <[EMAIL PROTECTED]> wrote:
> Both the Access Request and Accounting Request MUST have the  
> NAS-IP-Address 
>  attribute or 
> a NAS-Identifier  
>  attribute 
> (or both).
> Does this mean that ALL packets sent from client contains at least one 
> of these 2 attributes?

  Yes.

> So does this mean that the radius server could lookup in its database a 
> secret according to one of these attributes instead of the ip address?

  In theory, yes.  In practice, this permits additional attacks that
can compromise your server.

  Please read clients.conf, and implement my suggestion for using
shared secrets for an entire network.  It's by far and away the best
choice.

  Alan DeKok.

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


Re: public secret and public radius server. Is it secure?

2006-06-04 Thread sophana

Alan DeKok wrote:


sophana <[EMAIL PROTECTED]> wrote:
 

In my project, I don't own the hotspots, and don't know about the 
hotspots ISPs.

The hotspots communicate to the radius server though the internet.
   



 I would suggest using another method to get a secure connection to
the hotspot.  Maybe IPSec.

 Barring that, each hotspot has a dynamic IP within a small network
range.  So you can list the network in "clients.conf", and at least
have one shared secret per hotspot location.  This *is* documented in
clients.conf, please read it.

 

I don't want to do that, because it is too complex to setup. My users 
setup their hotspot by themself (at least at the beginning)
Setting up a vpn is too complicated. I just want the setup as simple as 
possible.


Ok. I don't know much about the radius protocol details, maybe you could 
help me understanding how secure would be a solution where the secret is 
know by everybody.
   



 I thought I said it WOULDN'T be secure.  What part of my response
was unclear?

 


Now, once a user is authenticated, how does the nas send accounting info?
   



 Read the documentation.  That's what it's there for.

 


Ok sorry for asking. I finally read the RFC2866.
I saw that the accounting request authenticator only depends on the 
famous secret, not on the authentication.

I am now convinced that the secret must remain secret.

But I think there is a solution for having dynamic ip that could be 
implemented.

Please tell me if I'm wrong.
Both the Access Request and Accounting Request MUST have the  
NAS-IP-Address 
 attribute or 
a NAS-Identifier  
 attribute 
(or both).
Does this mean that ALL packets sent from client contains at least one 
of these 2 attributes?
So does this mean that the radius server could lookup in its database a 
secret according to one of these attributes instead of the ip address?

That would definitly solve the dynamic ip address problem wouldn'it?

I need security, because I will use accounting info to perform 
facturation...
   



 Facturation isn't an english word.

 


Sorry, facturation is the french word for billing.

Regards

Sophana KOK

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


Re: Freeradius-Users Digest, Vol 14, Issue 14

2006-06-04 Thread Gilbert Lo
I am on holiday between June 3 to June 10. I will return to my office on
June 11. 

See you soon.
Thanks,
Gilbert Lo

helpdesk at St. George's School


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


Re: How the hell do you use multiple NOT values with rlm_checkval and sql??

2006-06-04 Thread Mike Jakubik

Alan DeKok wrote:

Mike Jakubik <[EMAIL PROTECTED]> wrote:
  
If there is a way to accomplish this outside of SQL, im quite open to 
suggestions. As long as i can refer to the groups which are in SQL. 
Basically, i need to be able to restrict certain user groups from 
dialing certain numbers.



  Use rlm_passwd to map many dial-in numbers to one dial-in group.
Then, do:

DEFAULT SQL-Group == "foo", Dial-in-group == "bar", Auth-Type := Reject

  And repeat for the combinations of SQL groups & dial-in groups.
  


Uhm, in that case cant i just specify called-station-id in the user 
file? In any case, is SQL-Group a valid attribute? I cant find it in the 
documentation. I tried a simple :


DEFAULT SQL-Group == "restricted",
   Called-Station-Id == "number",
   Auth-Type := Reject


Restarted radius, and dialed "number", nothing happened, i logged in 
just fine.


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


Re: freeradius rlm_sql driver problem-need help

2006-06-04 Thread Abul Monsur Mannan

Hello Edvin

I'm sorry for my ignorance

Please respond.




On 6/3/06, Abul Monsur Mannan <[EMAIL PROTECTED]> wrote:

Hello Edvin,

> In your sql.conf file - you should enter only "rlm_sql_mysql" under "driver"
> option - not the whole path ! If this is entered, be sure that you have
> compiled mysql-driver.
>

My driver option is ok as you said.
Since I'm  new in the linux area, I don't understand how to compile
the mysql-driver.

Please show me the way.I'll be grateful to you.


> On 6/1/06, Seferovic Edvin <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > how did you "installed" it? From an RPM ? or have you compiled and
> installed
> > it from source? Are your mysql libraries available?
> >
> > Regards,
> >
> > Edvin
> >
> > -Original Message-
> > From:
> [EMAIL PROTECTED]
> >
> [mailto:[EMAIL PROTECTED]
> > g] On Behalf Of Abul Monsur Mannan
> > Sent: Donnerstag, 01. Juni 2006 08:12
> > To: FreeRadius users mailing list
> > Subject: freeradius rlm_sql driver problem-need help
> >
> > Hello FR Users
> >
> > Can anybody here help me out of this problem?
> > I installed freeradius version 1.1.1 with mysql on RH Linux Enterprise 4
> ed.
> > I've got this result
> >
> > [EMAIL PROTECTED] ~]# radiusd -X
> > Starting - reading configuration files ...
> >
> > reread_config:  reading radiusd.conf
> > Config:   including file: /usr/local/etc/raddb/proxy.conf
> > Config:   including file: /usr/local/etc/raddb/clients.conf
> > Config:   including file: /usr/local/etc/raddb/snmp.conf
> > Config:   including file: /usr/local/etc/raddb/eap.conf
> > Config:   including file: /usr/local/etc/raddb/sql.conf
> >  main: prefix = "/usr/local"
> >  main: localstatedir = "/usr/local/var"
> >  main: logdir = "/usr/local/var/log/radius"
> >  main: libdir = "/usr/local/lib"
> >  main: radacctdir = "/usr/local/var/log/radius/radacct"
> >  main: hostname_lookups = no
> >  main: max_request_time = 30
> >  main: cleanup_delay = 5
> >  main: max_requests = 1024
> >  main: delete_blocked_requests = 0
> >  main: port = 0
> >  main: allow_core_dumps = no
> >  main: log_stripped_names = no
> >  main: log_file = "/usr/local/var/log/radius/radius.log"
> >  main: log_auth = no
> >  main: log_auth_badpass = no
> >  main: log_auth_goodpass = no
> >  main: pidfile = "/usr/local/var/run/radiusd/radiusd.pid"
> >  main: user = "(null)"
> >  main: group = "(null)"
> >  main: usercollide = no
> >  main: lower_user = "no"
> >  main: lower_pass = "no"
> >  main: nospace_user = "no"
> >  main: nospace_pass = "no"
> >  main: checkrad = "/usr/local/sbin/checkrad"
> >  main: proxy_requests = yes
> >  proxy: retry_delay = 5
> >  proxy: retry_count = 3
> >  proxy: synchronous = no
> >  proxy: default_fallback = yes
> >  proxy: dead_time = 120
> >  proxy: post_proxy_authorize = no
> >  proxy: wake_all_if_all_dead = no
> >  security: max_attributes = 200
> >  security: reject_delay = 1
> >  security: status_server = no
> >  main: debug_level = 0
> > read_config_files:  reading dictionary
> > read_config_files:  reading naslist
> > Using deprecated naslist file.  Support for this will go away soon.
> > read_config_files:  reading clients
> > read_config_files:  reading realms
> > Using deprecated realms file.  Support for this will go away soon.
> > radiusd:  entering modules setup
> > Module: Library search path is /usr/local/lib
> > Module: Loaded exec
> >  exec: wait = yes
> >  exec: program = "(null)"
> >  exec: input_pairs = "request"
> >  exec: output_pairs = "(null)"
> >  exec: packet_type = "(null)"
> > rlm_exec: Wait=yes but no output defined. Did you mean output=none?
> > Module: Instantiated exec (exec)
> > Module: Loaded expr
> > Module: Instantiated expr (expr)
> > Module: Loaded PAP
> >  pap: encryption_scheme = "crypt"
> > Module: Instantiated pap (pap)
> > Module: Loaded CHAP
> > Module: Instantiated chap (chap)
> > Module: Loaded MS-CHAP
> >  mschap: use_mppe = yes
> >  mschap: require_encryption = no
> >  mschap: require_strong = no
> >  mschap: with_ntdomain_hack = no
> >  mschap: passwd = "(null)"
> >  mschap: authtype = "MS-CHAP"
> >  mschap: ntlm_auth = "(null)"
> > Module: Instantiated mschap (mschap)
> > Module: Loaded eap
> >  eap: default_eap_type = "md5"
> >  eap: timer_expire = 60
> >  eap: ignore_unknown_eap_types = no
> >  eap: cisco_accounting_username_bug = no
> > rlm_eap: Loaded and initialized type md5
> > rlm_eap: Loaded and initialized type leap
> >  gtc: challenge = "Password: "
> >  gtc: auth_type = "PAP"
> > rlm_eap: Loaded and initialized type gtc
> >  mschapv2: with_ntdomain_hack = no
> > rlm_eap: Loaded and initialized type mschapv2
> > Module: Instantiated eap (eap)
> > Module: Loaded preprocess
> >  preprocess: huntgroups = "/usr/local/etc/raddb/huntgroups"
> >  preprocess: hints = "/usr/local/etc/raddb/hints"
> >  preprocess: with_ascend_hack = no
> >  preprocess: ascend_channels_per_line = 23
> >  preprocess: with_ntdomain_hack = no
> >  preprocess: with_specialix_jetstream_hack = no
> >  preprocess: with_

RP-pppoe

2006-06-04 Thread Mordor Networks
Hello list!I wonder if someone used the RP-Upstream-Speed-Limit and RP-Downstream-Speed-Limit ATTRIBUTES from roaring pangiun "rp-pppoe" with mysql , if so can someone please tell me how to add the ATTRIBUTES to freeradius sql table "radreply"?
thanks 
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: revoking ca certificates

2006-06-04 Thread K. Hoercher

On 6/1/06, sumi thra <[EMAIL PROTECTED]> wrote:

Any body knows how to revoke the certificates?  what changes needs to be
done in the freeradius eap.conf file.


No possible changes there will help you in that purpose. Having said
that, I'd like to provide some details I found while digging around
out of curiosity.

Unless mentioned otherwise I'm speaking of freeradius-1.1.1 (.deb
built using released debian subdir) and openssl 0.9.8b (debian/sid).
freeradius uses X509_V_FLAG_CRL_CHECK in
src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c which will only
check a crl for the last entity in a certificate chain according to
http://www.mail-archive.com/openssl-users@openssl.org/msg42197.html .

I didn't find any spec/rfc/etc that commands this behaviour, but I
think of Dr Henson as being quite authoritative on that issue :)

So I tested an added (better: ORed) X509_V_FLAG_CRL_CHECK_ALL and got
the behaviour the OP wanted: checked crls for (all) CAs in a chain.
PEM ones worked.

While I'm not convinced that this makes sense for a (explicitly
trusted) root-CA (the revoked-to-be cert signs the revocation) I do
see a valid use case for honoring revoked intermediate CAs. Despite
RFC2716 6.1 speaking about revoked client certificates only, I think
it would be desirable to incorporate the rationale behind the whole
TLS stuff (RFC2246 D.3). Up to now I didn't look much further for
updated/contradicting related specifications. Any hints?

A quick look into 1.1.2 left me with the impression that nothing would
prevent the same modification there. But before eventually filing some
wishlist bug with a more detailed patch, I'd like to read some
comments on the whole issue, esp. concerning the following:


openssl ca -gencrl -keyfile ./privatekey.pem  -cert  cacert.pem  revoke
cacert.pem -out crl.pem


Not sure what OP is exactly doing here.
Presuming X509_V_FLAG_CRL_CHECK_ALL shall be used, should it also
honor crls for  root CAs (as it would do out of the box)? configurable
choice maybe?

Furthermore hash-linked crls for all possible CAs must be provided in
CA_path otherwise TLS will fail regardless of validity of offered
certs.


1. copied ca & crl to ./ directory( my ca & crl files are in current
directory )
2. c_rehash ./

tls {
...
CA_file = ./cacert.pem
CA_path = ./
check_crl = yes
}


I was too lazy to check if relative paths do work here. Checking with
absolute ones led to the following caveat: if you combine the needed
cr's in one file by concatenating c_rehash does only generate one
hashname link by virtue of 'openssl crl [...] -hash' providing only
(the first?) one. Adding the appropriately named missing ones manually
does work.

regards
K. Hoercher
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Freeradius-Users Digest, Vol 14, Issue 13

2006-06-04 Thread Gilbert Lo
I am on holiday between June 3 to June 10. I will return to my office on
June 11. 

See you soon.
Thanks,
Gilbert Lo

helpdesk at St. George's School


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