Device authentication and User+Device authentication
Hi all, Could someone tell me what has to be configured to be able to do Device authentication and User+Device authentication. Thank you! Cristian NOVAC
Cristian Novac wrote:
Could someone tell me what has to be configured to be able to do Device authentication and User+Device authentication.
It all depends how you plan on authenticating the devices and users. i.e. Which authentication protocols are you using? Then.... configure the authentication protocols. Alan DeKok.
CURRENT CONDITIONS: I'm currently using FreeRadius server in a system where the server is authenticating to the client using a server certificate. For now, the client is authenticating through username and password. The method used is EAP-TTLS. ----------------------- THE TARGET is the client to not only use username and password, but a device CERTIFICATE. ----------------------- I assume that I have to include in the etc/raddb/eap.conf file the LIST OF DEVICE ROOT CERTIFICATES. If so, can you tell me how to do that? Otherwise, may you tell me what other things I have to do? I attached my current eap.conf file Thank you! Cristian NOVAC. Alan DeKok wrote:
Cristian Novac wrote:
Could someone tell me what has to be configured to be able to do Device authentication and User+Device authentication.
It all depends how you plan on authenticating the devices and users. i.e. Which authentication protocols are you using?
Then.... configure the authentication protocols.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
# -*- text -*- # # Whatever you do, do NOT set 'Auth-Type := EAP'. The server # is smart enough to figure this out on its own. The most # common side effect of setting 'Auth-Type := EAP' is that the # users then cannot use ANY other authentication method. # # $Id: eap.conf,v 1.4.4.1 2006/01/04 14:29:29 nbk Exp $ # eap { # Invoke the default supported EAP type when # EAP-Identity response is received. # # The incoming EAP messages DO NOT specify which EAP # type they will be using, so it MUST be set here. # # For now, only one default EAP type may be used at a time. # # If the EAP-Type attribute is set by another module, # then that EAP type takes precedence over the # default type configured here. # default_eap_type = ttls # A list is maintained to correlate EAP-Response # packets with EAP-Request packets. After a # configurable length of time, entries in the list # expire, and are deleted. # timer_expire = 60 # There are many EAP types, but the server has support # for only a limited subset. If the server receives # a request for an EAP type it does not support, then # it normally rejects the request. By setting this # configuration to "yes", you can tell the server to # instead keep processing the request. Another module # MUST then be configured to proxy the request to # another RADIUS server which supports that EAP type. # # If another module is NOT configured to handle the # request, then the request will still end up being # rejected. ignore_unknown_eap_types = no # Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given # a User-Name attribute in an Access-Accept, it copies one # more byte than it should. # # We can work around it by configurably adding an extra # zero byte. cisco_accounting_username_bug = no # Supported EAP-types # # We do NOT recommend using EAP-MD5 authentication # for wireless connections. It is insecure, and does # not provide for dynamic WEP keys. # md5 { } # Cisco LEAP # # We do not recommend using LEAP in new deployments. See: # http://www.securiteam.com/tools/5TP012ACKE.html # # Cisco LEAP uses the MS-CHAP algorithm (but not # the MS-CHAP attributes) to perform it's authentication. # # As a result, LEAP *requires* access to the plain-text # User-Password, or the NT-Password attributes. # 'System' authentication is impossible with LEAP. # # leap { # } # Generic Token Card. # # Currently, this is only permitted inside of EAP-TTLS, # or EAP-PEAP. The module "challenges" the user with # text, and the response from the user is taken to be # the User-Password. # # Proxying the tunneled EAP-GTC session is a bad idea, # the users password will go over the wire in plain-text, # for anyone to see. # # gtc { # The default challenge, which many clients # ignore.. #challenge = "Password: " # The plain-text response which comes back # is put into a User-Password attribute, # and passed to another module for # authentication. This allows the EAP-GTC # response to be checked against plain-text, # or crypt'd passwords. # # If you say "Local" instead of "PAP", then # the module will look for a User-Password # configured for the request, and do the # authentication itself. # # auth_type = PAP # } ## EAP-TLS # # To generate ctest certificates, run the script # # ../scripts/certs.sh # # The documents on http://www.freeradius.org/doc # are old, but may be helpful. # # See also: # # http://www.dslreports.com/forum/remark,9286052~mode=flat # tls { # private_key_password = whatever private_key_password = asb#1234 # private_key_file = ${raddbdir}/certs/cert-srv.pem private_key_file = ${raddbdir}/certs/NEW/server-key.pem # If Private key & Certificate are located in # the same file, then private_key_file & # certificate_file must contain the same file # name. # certificate_file = ${raddbdir}/certs/cert-srv.pem certificate_file = ${raddbdir}/certs/NEW/server.pem # Trusted Root CA list # CA_file = ${raddbdir}/certs/demoCA/cacert.pem CA_file = ${raddbdir}/certs/NEW/ca-cert.pem dh_file = ${raddbdir}/certs/NEW/dh random_file = ${raddbdir}/certs/NEW/random # # This can never exceed the size of a RADIUS # packet (4096 bytes), and is preferably half # that, to accomodate other attributes in # RADIUS packet. On most APs the MAX packet # length is configured between 1500 - 1600 # In these cases, fragment size should be # 1024 or less. # fragment_size = 1024 # include_length is a flag which is # by default set to yes If set to # yes, Total Length of the message is # included in EVERY packet we send. # If set to no, Total Length of the # message is included ONLY in the # First packet of a fragment series. # include_length = yes # Check the Certificate Revocation List # # 1) Copy CA certificates and CRLs to same directory. # 2) Execute 'c_rehash <CA certs&CRLs Directory>'. # 'c_rehash' is OpenSSL's command. # 3) Add 'CA_path=<CA certs&CRLs directory>' # to radiusd.conf's tls section. # 4) uncomment the line below. # 5) Restart radiusd check_crl = yes # # If check_cert_cn is set, the value will # be xlat'ed and checked against the CN # in the client certificate. If the values # do not match, the certificate verification # will fail rejecting the user. # # check_cert_cn = %{User-Name} } # The TTLS module implements the EAP-TTLS protocol, # which can be described as EAP inside of Diameter, # inside of TLS, inside of EAP, inside of RADIUS... # # Surprisingly, it works quite well. # # The TTLS module needs the TLS module to be installed # and configured, in order to use the TLS tunnel # inside of the EAP packet. You will still need to # configure the TLS module, even if you do not want # to deploy EAP-TLS in your network. Users will not # be able to request EAP-TLS, as it requires them to # have a client certificate. EAP-TTLS does not # require a client certificate. # ttls { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # TTLS tunnel, we recommend using EAP-MD5. # If the request does not contain an EAP # conversation, then this configuration entry # is ignored. default_eap_type = mschapv2 # default_eap_type = md5 # The tunneled authentication request does # not usually contain useful attributes # like 'Calling-Station-Id', etc. These # attributes are outside of the tunnel, # and normally unavailable to the tunneled # authentication request. # # By setting this configuration entry to # 'yes', any attribute which NOT in the # tunneled authentication request, but # which IS available outside of the tunnel, # is copied to the tunneled request. # # allowed values: {no, yes} copy_request_to_tunnel = yes # The reply attributes sent to the NAS are # usually based on the name of the user # 'outside' of the tunnel (usually # 'anonymous'). If you want to send the # reply attributes based on the user name # inside of the tunnel, then set this # configuration entry to 'yes', and the reply # to the NAS will be taken from the reply to # the tunneled request. # # allowed values: {no, yes} use_tunneled_reply = yes } sim { } # # The tunneled EAP session needs a default EAP type # which is separate from the one for the non-tunneled # EAP module. Inside of the TLS/PEAP tunnel, we # recommend using EAP-MS-CHAPv2. # # The PEAP module needs the TLS module to be installed # and configured, in order to use the TLS tunnel # inside of the EAP packet. You will still need to # configure the TLS module, even if you do not want # to deploy EAP-TLS in your network. Users will not # be able to request EAP-TLS, as it requires them to # have a client certificate. EAP-PEAP does not # require a client certificate. # # peap { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # PEAP tunnel, we recommend using MS-CHAPv2, # as that is the default type supported by # Windows clients. # default_eap_type = mschapv2 # the PEAP module also has these configuration # items, which are the same as for TTLS. # copy_request_to_tunnel = no # use_tunneled_reply = no # When the tunneled session is proxied, the # home server may not understand EAP-MSCHAP-V2. # Set this entry to "no" to proxy the tunneled # EAP-MSCHAP-V2 as normal MSCHAPv2. # proxy_tunneled_request_as_eap = yes #} # # This takes no configuration. # # Note that it is the EAP MS-CHAPv2 sub-module, not # the main 'mschap' module. # # Note also that in order for this sub-module to work, # the main 'mschap' module MUST ALSO be configured. # # This module is the *Microsoft* implementation of MS-CHAPv2 # in EAP. There is another (incompatible) implementation # of MS-CHAPv2 in EAP by Cisco, which FreeRADIUS does not # currently support. # mschapv2 { } }
Cristian Novac wrote:
CURRENT CONDITIONS: I'm currently using FreeRadius server in a system where the server is authenticating to the client using a server certificate. For now, the client is authenticating through username and password. The method used is EAP-TTLS. ----------------------- THE TARGET is the client to not only use username and password, but a device CERTIFICATE. ----------------------- I assume that I have to include in the etc/raddb/eap.conf file the LIST OF DEVICE ROOT CERTIFICATES. If so, can you tell me how to do that? Otherwise, may you tell me what other things I have to do?
Could someone just tell whether my assumption is wright?
I attached my current eap.conf file
Thank you! Cristian NOVAC.
Alan DeKok wrote:
Cristian Novac wrote:
Could someone tell me what has to be configured to be able to do Device authentication and User+Device authentication.
It all depends how you plan on authenticating the devices and users. i.e. Which authentication protocols are you using?
Then.... configure the authentication protocols.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------------------------------------------------
# -*- text -*- # # Whatever you do, do NOT set 'Auth-Type := EAP'. The server # is smart enough to figure this out on its own. The most # common side effect of setting 'Auth-Type := EAP' is that the # users then cannot use ANY other authentication method. # # $Id: eap.conf,v 1.4.4.1 2006/01/04 14:29:29 nbk Exp $ # eap { # Invoke the default supported EAP type when # EAP-Identity response is received. # # The incoming EAP messages DO NOT specify which EAP # type they will be using, so it MUST be set here. # # For now, only one default EAP type may be used at a time. # # If the EAP-Type attribute is set by another module, # then that EAP type takes precedence over the # default type configured here. # default_eap_type = ttls
# A list is maintained to correlate EAP-Response # packets with EAP-Request packets. After a # configurable length of time, entries in the list # expire, and are deleted. # timer_expire = 60
# There are many EAP types, but the server has support # for only a limited subset. If the server receives # a request for an EAP type it does not support, then # it normally rejects the request. By setting this # configuration to "yes", you can tell the server to # instead keep processing the request. Another module # MUST then be configured to proxy the request to # another RADIUS server which supports that EAP type. # # If another module is NOT configured to handle the # request, then the request will still end up being # rejected. ignore_unknown_eap_types = no
# Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given # a User-Name attribute in an Access-Accept, it copies one # more byte than it should. # # We can work around it by configurably adding an extra # zero byte. cisco_accounting_username_bug = no
# Supported EAP-types
# # We do NOT recommend using EAP-MD5 authentication # for wireless connections. It is insecure, and does # not provide for dynamic WEP keys. # md5 { }
# Cisco LEAP # # We do not recommend using LEAP in new deployments. See: # http://www.securiteam.com/tools/5TP012ACKE.html # # Cisco LEAP uses the MS-CHAP algorithm (but not # the MS-CHAP attributes) to perform it's authentication. # # As a result, LEAP *requires* access to the plain-text # User-Password, or the NT-Password attributes. # 'System' authentication is impossible with LEAP. # # leap { # }
# Generic Token Card. # # Currently, this is only permitted inside of EAP-TTLS, # or EAP-PEAP. The module "challenges" the user with # text, and the response from the user is taken to be # the User-Password. # # Proxying the tunneled EAP-GTC session is a bad idea, # the users password will go over the wire in plain-text, # for anyone to see. # # gtc { # The default challenge, which many clients # ignore.. #challenge = "Password: "
# The plain-text response which comes back # is put into a User-Password attribute, # and passed to another module for # authentication. This allows the EAP-GTC # response to be checked against plain-text, # or crypt'd passwords. # # If you say "Local" instead of "PAP", then # the module will look for a User-Password # configured for the request, and do the # authentication itself. # # auth_type = PAP # }
## EAP-TLS # # To generate ctest certificates, run the script # # ../scripts/certs.sh # # The documents on http://www.freeradius.org/doc # are old, but may be helpful. # # See also: # # http://www.dslreports.com/forum/remark,9286052~mode=flat # tls { # private_key_password = whatever private_key_password = asb#1234 # private_key_file = ${raddbdir}/certs/cert-srv.pem private_key_file = ${raddbdir}/certs/NEW/server-key.pem
# If Private key & Certificate are located in # the same file, then private_key_file & # certificate_file must contain the same file # name. # certificate_file = ${raddbdir}/certs/cert-srv.pem certificate_file = ${raddbdir}/certs/NEW/server.pem
# Trusted Root CA list # CA_file = ${raddbdir}/certs/demoCA/cacert.pem CA_file = ${raddbdir}/certs/NEW/ca-cert.pem
dh_file = ${raddbdir}/certs/NEW/dh random_file = ${raddbdir}/certs/NEW/random
# # This can never exceed the size of a RADIUS # packet (4096 bytes), and is preferably half # that, to accomodate other attributes in # RADIUS packet. On most APs the MAX packet # length is configured between 1500 - 1600 # In these cases, fragment size should be # 1024 or less. # fragment_size = 1024
# include_length is a flag which is # by default set to yes If set to # yes, Total Length of the message is # included in EVERY packet we send. # If set to no, Total Length of the # message is included ONLY in the # First packet of a fragment series. # include_length = yes
# Check the Certificate Revocation List # # 1) Copy CA certificates and CRLs to same directory. # 2) Execute 'c_rehash <CA certs&CRLs Directory>'. # 'c_rehash' is OpenSSL's command. # 3) Add 'CA_path=<CA certs&CRLs directory>' # to radiusd.conf's tls section. # 4) uncomment the line below. # 5) Restart radiusd check_crl = yes
# # If check_cert_cn is set, the value will # be xlat'ed and checked against the CN # in the client certificate. If the values # do not match, the certificate verification # will fail rejecting the user. # # check_cert_cn = %{User-Name} }
# The TTLS module implements the EAP-TTLS protocol, # which can be described as EAP inside of Diameter, # inside of TLS, inside of EAP, inside of RADIUS... # # Surprisingly, it works quite well. # # The TTLS module needs the TLS module to be installed # and configured, in order to use the TLS tunnel # inside of the EAP packet. You will still need to # configure the TLS module, even if you do not want # to deploy EAP-TLS in your network. Users will not # be able to request EAP-TLS, as it requires them to # have a client certificate. EAP-TTLS does not # require a client certificate. #
ttls { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # TTLS tunnel, we recommend using EAP-MD5. # If the request does not contain an EAP # conversation, then this configuration entry # is ignored. default_eap_type = mschapv2 # default_eap_type = md5
# The tunneled authentication request does # not usually contain useful attributes # like 'Calling-Station-Id', etc. These # attributes are outside of the tunnel, # and normally unavailable to the tunneled # authentication request. # # By setting this configuration entry to # 'yes', any attribute which NOT in the # tunneled authentication request, but # which IS available outside of the tunnel, # is copied to the tunneled request. # # allowed values: {no, yes} copy_request_to_tunnel = yes
# The reply attributes sent to the NAS are # usually based on the name of the user # 'outside' of the tunnel (usually # 'anonymous'). If you want to send the # reply attributes based on the user name # inside of the tunnel, then set this # configuration entry to 'yes', and the reply # to the NAS will be taken from the reply to # the tunneled request. # # allowed values: {no, yes} use_tunneled_reply = yes }
sim { } # # The tunneled EAP session needs a default EAP type # which is separate from the one for the non-tunneled # EAP module. Inside of the TLS/PEAP tunnel, we # recommend using EAP-MS-CHAPv2. # # The PEAP module needs the TLS module to be installed # and configured, in order to use the TLS tunnel # inside of the EAP packet. You will still need to # configure the TLS module, even if you do not want # to deploy EAP-TLS in your network. Users will not # be able to request EAP-TLS, as it requires them to # have a client certificate. EAP-PEAP does not # require a client certificate. # # peap { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # PEAP tunnel, we recommend using MS-CHAPv2, # as that is the default type supported by # Windows clients. # default_eap_type = mschapv2
# the PEAP module also has these configuration # items, which are the same as for TTLS. # copy_request_to_tunnel = no # use_tunneled_reply = no
# When the tunneled session is proxied, the # home server may not understand EAP-MSCHAP-V2. # Set this entry to "no" to proxy the tunneled # EAP-MSCHAP-V2 as normal MSCHAPv2. # proxy_tunneled_request_as_eap = yes #}
# # This takes no configuration. # # Note that it is the EAP MS-CHAPv2 sub-module, not # the main 'mschap' module. # # Note also that in order for this sub-module to work, # the main 'mschap' module MUST ALSO be configured. # # This module is the *Microsoft* implementation of MS-CHAPv2 # in EAP. There is another (incompatible) implementation # of MS-CHAPv2 in EAP by Cisco, which FreeRADIUS does not # currently support. # mschapv2 { } }
My device authentication worked, but user+device authentication doesn't. May you tell me whether it's possible the server to ask for device certificate during TTLS, as I set client to ask for TTLS method and by default the server doesn't ask this. I would like the user to authenticate by username and password and the device by certificate. Thank you! Alan DeKok wrote:
Cristian Novac wrote:
Could someone tell me what has to be configured to be able to do Device authentication and User+Device authentication.
It all depends how you plan on authenticating the devices and users. i.e. Which authentication protocols are you using?
Then.... configure the authentication protocols.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Cristian Novac wrote:
My device authentication worked, but user+device authentication doesn't. May you tell me whether it's possible the server to ask for device certificate during TTLS, as I set client to ask for TTLS method and by default the server doesn't ask this.
Can you try reading eap.conf, especially the comments in the ttls subsection? Alan DeKok.
Alan DeKok wrote:
Cristian Novac wrote:
My device authentication worked, but user+device authentication doesn't. May you tell me whether it's possible the server to ask for device certificate during TTLS, as I set client to ask for TTLS method and by default the server doesn't ask this.
Can you try reading eap.conf, especially the comments in the ttls subsection?
Are you telling that I just can't have user authenticated with username and password and user device authenticated with certificate during the same authentication process??? Or that I just can't have those two during TTLS? May you suggest me other method to achieve my goal?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Cristian Novac wrote:
Can you try reading eap.conf, especially the comments in the ttls subsection?
Are you telling that I just can't have user authenticated with username and password and user device authenticated with certificate during the same authentication process??? Or that I just can't have those two during TTLS?
I have no idea how you concluded that by reading eap.conf. Please point out which text in eap.conf leads you to believe that using client certificates for TTLS makes it *impossible* to use username/password authentication.
May you suggest me other method to achieve my goal?
Read the documentation, and configure it as instructed? i.e. the text in eap.conf informs you about what is possible. You read it, and interpreted it as saying certain things were impossible. Alan DeKok.
Hello, I would like to ask client to provide certificate during TTLS. I saw in eap.conf that I have to set EAP-TLS-Require-Client-Cert = Yes in the contol items for a request. Does this mean that I have to set this in my users file for the user entry that interests me? Could you provide a little sample of how to be used this setting? Thank you! Cristian Novac.
Cristian Novac wrote:
I would like to ask client to provide certificate during TTLS. I saw in eap.conf that I have to set EAP-TLS-Require-Client-Cert = Yes in the contol items for a request. Does this mean that I have to set this in my users file for the user entry that interests me? Could you provide a little sample of how to be used this setting?
$ man users Or $ man unlang The method of updating a control item is documented. PLEASE read the documentation. It's not that hard. Alan DeKok.
My authentication worked fine, thanks for your help Alan, and I apologize for having bothered you. BR, Cristian Novac. Alan DeKok wrote:
Cristian Novac wrote:
I would like to ask client to provide certificate during TTLS. I saw in eap.conf that I have to set EAP-TLS-Require-Client-Cert = Yes in the contol items for a request. Does this mean that I have to set this in my users file for the user entry that interests me? Could you provide a little sample of how to be used this setting?
$ man users
Or
$ man unlang
The method of updating a control item is documented. PLEASE read the documentation. It's not that hard.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
Cristian Novac