Description of problem: Currently RADIUS plugin permits pppd to perform PAP, CHAP, MS-CHAP and MS-CHAPv2 authentication against a RADIUS server. But in conjuction with PPTPd server all of these methods have big security weaknesses. So the solution for this problem is using of EAP-TLS or any other TLS enabled EAP method like EAP-PEAP, EAP-TTLS or so on. But currently there is only supported EAP-TLS (through local PPPd EAP authentication) with which is difficult to deploy PKI to clients (installing client certificates, managing crl and so on). The solution is using EAP-PEAP which is supported by default on windows clients which requires only certificate of certification authority to be installed on windows clients, client authenticates itself through mschapv2 inside the TLS tunnel. So my enhancement request is to append support to perform another authentication methods against a RADIUS server for RADIUS plugin. Mainly EAP-PEAP, additionally EAP-TLS (for centralized login management), EAP-TTLS or other. I have spending a lot of time looking for any existing solution/patch for my request, but without success. The only one solution that I've found is "ppp-heiart-despace-stripnum.tar.bz2" from http://radeapsrp.sourceforge.net/ which provides support for performing EAP-TLS, EAP-TTLS against RADIUS support. But still missing EAP-PEAP. thanks
Adding more EAP implementation (PEAP, EAP-TTLS etc) to the ppp code base will be a substantial effort. Code could be taken from wpa_supplicant, which supports most EAP implementations already, but it will need to be rewritten to fit into the non-modular ppp framework. If EAP-TTLS is working with the above patch (which is very interesting, BTW!) then rewriting that to PEAP should not be too much work. However, I do not have the time (nor the immediate interest) to do so.
I have closely looked on "ppp-heiart-despace-stripnum.tar.bz2" but besides the information on that webpage "radeapsrp.sourceforge.net" that this ppp includes EAP-TTLS patch, I haven't found any EAP-TTLS code nor switch to enable TTLS support like in case of EAP-TLS (in file pppd/plugins/radius/Makefile.linux), maybe is TTLS is somehow included in EAPTLS. Only TTLS string that I have found is definition of EAP TTLS type in eap.h. Yes, youre right Jan, wpa_supplicant support a couple of EAP methods and it will be perfect for using it as framework toward RADIUS if it is possible (if you mean using it in that way).
I have a current requirement which needs the EAP-PEAP patch, so can i know that status of the above enhancement?? Its a pretty useful and secured way of assigning IP addresses. Thanks is advance.
(In reply to comment #3) > I have a current requirement which needs the EAP-PEAP patch, so can i know that > status of the above enhancement?? > Hi, I'm currently not able to promise any action in the near future due to time schedule.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
FYI if you need PEAP(type 25) MSCHAPV2, I have created a patch for ppp http://rustyside.blogspot.ru/2012/11/ppp-patch-implementing-peap-ms-chap-v2.html It requires a GnuTLS library though You use this patch as a workaround until you get an official implementation in ppp source code
Great news! :) I will test it in my environment if few days. Thanks!
Successfully compiled inside my current pppd version (2.4.5) which allready includes eap-tls patch from janjust. But authentification with EAP-PEAP method (used within IPSec/L2TP VPN from Windows 7) is not recognized: Nov 28 00:11:33 vpn02 pppd[24987]: rcvd [EAP Response id=0xfb Identity <Name "username">] Nov 28 00:11:33 vpn02 pppd[24987]: EAP: unauthenticated peer name "username" Nov 28 00:11:33 vpn02 pppd[24987]: getting eaptls secret Nov 28 00:11:33 vpn02 pppd[24987]: MTU = 1386 Nov 28 00:11:33 vpn02 pppd[24987]: sent [EAP Request id=0xfc TLS --S] Nov 28 00:11:33 vpn02 pppd[24987]: rcvd [EAP Response id=0xfc Nak <Suggested-type 19>] Nov 28 00:11:33 vpn02 pppd[24987]: EAP: peer requesting unknown Type 25 is there any compilation flag/parameter needed to be defined? It is possible that both EAP methods (EAP-TLS and EAP-PEAP) are in collision in this case?
the remote end (Windows 7 VPN client) is identifying itself as 'username' to the IP-Sec/PPP server. If you add an option remotename username to your pppd config then the pppd code should accept this request.
Thanks, I will try it, but then there is another question: can I use this PEAP extension on server side (VPN concentrator) to which will be different users connected?
what I meant was to add *literally* remote username to the pppd config; don't fill in the username here, but use this special name. The real user auth is then done via EAP-PEAP against the Radius backend. I must add that I've never tried this myself.
ah so. I meant that I need to add "remote login_of_vpn_user" :) Ok, understand now. Thanks!
patch modifies default setup location, from /usr/local to /usr so make sure you run a proper pppd here is some part of config for peer: name login remotename login and chap file # client server secret IP addresses login * password * if you specify a login in different manner(without @) you'll get a segmentation fault, I didn't have much time to implement proper error checking, so it's like a band aid =).
Still without success. I've addedd "remotename username" as configuration option, now the output is longer: Nov 28 17:14:52 vpn02 pppd[21538]: pppd 2.4.5 started by root, uid 0 Nov 28 17:14:52 vpn02 pppd[21538]: using channel 89 Nov 28 17:14:52 vpn02 pppd[21538]: Starting negotiation on /dev/pts/1 Nov 28 17:14:52 vpn02 pppd[21538]: sent [LCP ConfReq id=0x1 <mru 1410> <asyncmap 0x0> <auth eap> <magic 0x360409d3> <pcomp> <accomp> <mrru 1410> <endpoint [MAC:56:09:f8:18:39:cc]>] Nov 28 17:14:52 vpn02 pppd[21538]: rcvd [LCP ConfReq id=0x0 <mru 1400> <magic 0x34ad7f1e> <pcomp> <accomp> <callback CBCP> <mrru 1614> <endpoint [local:db.0b.13.21.ef.7d.4c.64.aa.aa.e2.09.2c.34.b8.51.00.00.00.02]>] Nov 28 17:14:52 vpn02 pppd[21538]: sent [LCP ConfRej id=0x0 <callback CBCP>] Nov 28 17:14:52 vpn02 pppd[21538]: rcvd [LCP ConfReq id=0x1 <mru 1400> <magic 0x34ad7f1e> <pcomp> <accomp> <mrru 1614> <endpoint [local:db.0b.13.21.ef.7d.4c.64.aa.aa.e2.09.2c.34.b8.51.00.00.00.02]>] Nov 28 17:14:52 vpn02 pppd[21538]: sent [LCP ConfAck id=0x1 <mru 1400> <magic 0x34ad7f1e> <pcomp> <accomp> <mrru 1614> <endpoint [local:db.0b.13.21.ef.7d.4c.64.aa.aa.e2.09.2c.34.b8.51.00.00.00.02]>] Nov 28 17:14:55 vpn02 pppd[21538]: sent [LCP ConfReq id=0x1 <mru 1410> <asyncmap 0x0> <auth eap> <magic 0x360409d3> <pcomp> <accomp> <mrru 1410> <endpoint [MAC:56:09:f8:18:39:cc]>] Nov 28 17:14:55 vpn02 pppd[21538]: rcvd [LCP ConfNak id=0x1 <mrru 1500>] Nov 28 17:14:55 vpn02 pppd[21538]: sent [LCP ConfReq id=0x2 <mru 1410> <asyncmap 0x0> <auth eap> <magic 0x360409d3> <pcomp> <accomp> <mrru 1410> <endpoint [MAC:56:09:f8:18:39:cc]>] Nov 28 17:14:55 vpn02 pppd[21538]: rcvd [LCP ConfNak id=0x2 <mrru 1500>] Nov 28 17:14:55 vpn02 pppd[21538]: sent [LCP ConfReq id=0x3 <mru 1410> <asyncmap 0x0> <auth eap> <magic 0x360409d3> <pcomp> <accomp> <mrru 1410> <endpoint [MAC:56:09:f8:18:39:cc]>] Nov 28 17:14:55 vpn02 pppd[21538]: rcvd [LCP ConfNak id=0x3 <mrru 1500>] Nov 28 17:14:55 vpn02 pppd[21538]: sent [LCP ConfReq id=0x4 <mru 1410> <asyncmap 0x0> <auth eap> <magic 0x360409d3> <pcomp> <accomp> <mrru 1410> <endpoint [MAC:56:09:f8:18:39:cc]>] Nov 28 17:14:55 vpn02 pppd[21538]: rcvd [LCP ConfNak id=0x4 <mrru 1500>] Nov 28 17:14:55 vpn02 pppd[21538]: sent [LCP ConfReq id=0x5 <mru 1410> <asyncmap 0x0> <auth eap> <magic 0x360409d3> <pcomp> <accomp> <mrru 1410> <endpoint [MAC:56:09:f8:18:39:cc]>] Nov 28 17:14:55 vpn02 pppd[21538]: rcvd [LCP ConfNak id=0x5 <mrru 1500>] Nov 28 17:14:55 vpn02 pppd[21538]: sent [LCP ConfReq id=0x6 <mru 1410> <asyncmap 0x0> <auth eap> <magic 0x360409d3> <pcomp> <accomp> <endpoint [MAC:56:09:f8:18:39:cc]>] Nov 28 17:14:56 vpn02 pppd[21538]: rcvd [LCP ConfAck id=0x6 <mru 1410> <asyncmap 0x0> <auth eap> <magic 0x360409d3> <pcomp> <accomp> <endpoint [MAC:56:09:f8:18:39:cc]>] Nov 28 17:14:56 vpn02 pppd[21538]: getting eaptls secret Nov 28 17:14:56 vpn02 pppd[21538]: MTU = 1386 Nov 28 17:14:56 vpn02 pppd[21538]: sent [EAP Request id=0x7d TLS --S] Nov 28 17:14:56 vpn02 pppd[21538]: rcvd [LCP Ident id=0x2 magic=0x34ad7f1e "MSRASV5.20"] Nov 28 17:14:56 vpn02 pppd[21538]: rcvd [LCP Ident id=0x3 magic=0x34ad7f1e "MSRAS-0-ABRAKADABRA"] Nov 28 17:14:56 vpn02 pppd[21538]: rcvd [LCP Ident id=0x4 magic=0x34ad7f1e "\n?y?\37777777750\37777777612FJ\37777777600\37777777633\37777777735\37777777646\37777777660\37777777726\020\37777777646"] Nov 28 17:14:56 vpn02 pppd[21538]: rcvd [EAP Response id=0x7d Nak <Suggested-type 19>] Nov 28 17:14:56 vpn02 pppd[21538]: EAP: peer requesting unknown Type 25 Nov 28 17:15:07 vpn02 pppd[21538]: rcvd [LCP TermReq id=0x5 "4\37777777655\177\036\000<\37777777715t\000\000\000\000"] ..but at the end it is with same error (EAP: peer requesting unknown Type 25). rustylife: if I understand from your last message: - this plugin is not an extension to PPP RADIUS plugin, but it is standalone PPP PEAP authentication method (like EAP-TLS patch from janjust) - and also user database is within local files only Questions: - is possible to somehow interconnect this PEAP method with PPP RADIUS plugin so we can use RADIUS as authentication server instead of PPP plugin itself? - my idea/goal is to authenticate VPN users via PEAP method toward RADIUS server (== toward central user database). - you proposed configuration in previous email: but it is complete? I think that PEAP needs for authentication server (I guess that in this case it is PPP daemon) a SSL server certificates (similar like RADIUS needs SSL certs for PEAP/TLS/TTLS methods). Where they need to be configured? thanks! my current configuration: require-eap ca /etc/pki/tls/certs/ca-ss-rbk-users.crt cert /etc/pki/tls/certs/ppp-server.crt key /etc/pki/tls/private/ppp-server-pass.key remotename username
Patch only implements PEAP client functionality, when you connect to Microsoft 2008R2 RAS server, and it looks like you are looking for PEAP server implementation in pppd.
exactly, I am looking for server-side implementation of EAP-PEAP. Ideally within pppd radius plugin as I think this is most useful usage scenario.
Created attachment 678423 [details] RADIUS EAP-TLS/EAP-TTLS Patch Hello I've just manually exctracted all EAP-TLS/-TTLS changes (from pppd code and from radius plugin as well) that was applied to package "ppp-heiart-despace-stripnum.tar.bz2" (http://downloads.sourceforge.net/radeapsrp/ppp-heiart-despace-stripnum.tar.bz2?use_mirror=osdn) and created patch file that I am giving here for testing and debugging. The good news are here: - I have successfully compiled latest el6 pppd package (without standalone EAP-TLS patch from Jan Just) patched with this eap-tls-ttls patch. - I have successfully tested all old functionality (MPPE, MPPC, MSCHAP auth methods) - PPPd RADIUS plugin successfully recognizes EAP auth method and initiates connection with RADIUS server for establishing EAP-TLS session - but unfortunatelly pppd crashes before finalizing session itself: Jan 14 21:25:22 vpn01 pppd[27726]: sent [EAP Request id=0x4c Identity <Message "Name">] Jan 14 21:25:22 vpn01 pppd[27726]: rcvd [LCP Ident id=0x2 magic=0x363372c "MSRASV5.20"] Jan 14 21:25:22 vpn01 pppd[27726]: rcvd [LCP Ident id=0x3 magic=0x363372c "MSRAS-0-COMPUTERNAME"] Jan 14 21:25:22 vpn01 pppd[27726]: rcvd [LCP Ident id=0x4 magic=0x363372c "\027>q\37777777655\010<\37777777646H\37777777655h\37777777762\t\37777777645\37777777611\37777777774\37777777642"] Jan 14 21:25:22 vpn01 pppd[27726]: rcvd [EAP Response id=0x4c Identity <Name "SuperAdmin">] Jan 14 21:25:22 vpn01 pppd[27726]: EAP: unauthenticated peer name "SuperAdmin" Jan 14 21:25:22 vpn01 pppd[27726]: rc_map2id: can't find tty /dev/ in map database Jan 14 21:25:22 vpn01 pppd[27726]: RADATTR plugin wrote 3 line(s) to file /var/run/radattr.. Jan 14 21:25:22 vpn01 pppd[27726]: Vendor '-1' Attr 'EAP-Message', Code '79' ==> Val '\001M' Jan 14 21:25:22 vpn01 pppd[27726]: Vendor '-1' Attr 'EAP-Message-Authenticator', Code '80' ==> Val '&K\012\266Ir]}\322T\214\226\312\016\277<' Jan 14 21:25:22 vpn01 pppd[27726]: Vendor '-1' Attr 'State', Code '24' ==> Val 'p\016<<pC8\246AE)\367K\236d&' Jan 14 21:25:22 vpn01 pppd[27726]: sent [EAP Request id=0x4d MD5-Challenge <Value 35 1b 51 38 27 f8 96 34 95 7c 64 35 36 d4 03 b7> <No name>] Jan 14 21:25:22 vpn01 pppd[27726]: rcvd [EAP Response id=0x4d Nak <Suggested-type 0d (TLS)>] Jan 14 21:25:22 vpn01 pppd[27726]: rc_map2id: can't find tty /dev/ in map database Jan 14 21:25:22 vpn01 pppd[27726]: RADATTR plugin wrote 3 line(s) to file /var/run/radattr.. Jan 14 21:25:22 vpn01 pppd[27726]: Vendor '-1' Attr 'EAP-Message', Code '79' ==> Val '\001N' Jan 14 21:25:22 vpn01 pppd[27726]: Vendor '-1' Attr 'EAP-Message-Authenticator', Code '80' ==> Val '\037\004\337\226\012\227\016\301\331\250\255#\333#\232\220' Jan 14 21:25:22 vpn01 pppd[27726]: Vendor '-1' Attr 'State', Code '24' ==> Val 'p\016<<q@1\246AE)\367K\236d&' Jan 14 21:25:22 vpn01 pppd[27726]: sent [EAP Request id=0x4e TLS 20] Jan 14 21:25:22 vpn01 pppd[27726]: rcvd [EAP Response id=0x4e TLS...] Jan 14 21:25:22 vpn01 pppd[27726]: rc_map2id: can't find tty /dev/ in map database Jan 14 21:25:22 vpn01 pppd[27726]: *** buffer overflow detected ***: /usr/sbin/pppd terminated Jan 14 21:25:22 vpn01 pppd[27726]: Fatal signal 6 Jan 14 21:25:22 vpn01 pppd[27726]: RADATTR plugin removed file /var/run/radattr.. Jan 14 21:25:22 vpn01 pppd[27726]: Exit. now the question is if someone is able to look over this overflow and possibly fix this problem with crashing. ps: don't forget to add following two types into radiusclient-ng dictionary: ATTRIBUTE EAP-Message 79 string ATTRIBUTE EAP-Message-Authenticator 80 string thanks!
also this pppd build with this patch is working for me only in conjunction with xl2tpd daemon. when I try to use openl2tpd, pppd crashes after reading an part of of "options.l2tp" configiration file: pppd[18227]: segfault at 0 ip 00007f3979363938 sp 00007fffb8557010 error 4 in pppd[7f397933b000+52000] ------------[ cut here ]------------ WARNING: at include/net/sock.h:472 udp_lib_unhash+0xbf/0xd0() (Not tainted) Modules linked in: pppol2tp pppox authenc esp4 xfrm4_mode_transport arc4 ppp_mppe_mppc nf_conntrack_netlink nfnetlink ip_vs ppp_generic slhc deflate zlib_deflate ctr twofish_x86_64 twofish_common camellia serpent blowfish cast5 des_generic cbc cryptd aes_x86_64 aes_generic xcbc rmd160 sha256_generic tun crypto_null af_key xenfs iptable_mangle iptable_nat nf_nat xt_pkttype nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables xt_MARK ip6table_mangle xt_limit xt_policy nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack xt_multiport ip6table_filter ip6_tables ipv6 xen_netfront ext4 mbcache jbd2 xen_blkfront dm_mirror dm_region_hash dm_log dm_mod [last unloaded: pppox] Pid: 18168, comm: openl2tpd Not tainted 2.6.32-220.4.1.el6.mppc_saref.x86_64 #1 Call Trace: [<ffffffff81069a17>] ? warn_slowpath_common+0x87/0xc0 [<ffffffff81069a6a>] ? warn_slowpath_null+0x1a/0x20 [<ffffffff8148a22f>] ? udp_lib_unhash+0xbf/0xd0 [<ffffffff8141e8f2>] ? sk_common_release+0x32/0xd0 [<ffffffff81488ffe>] ? udp_lib_close+0xe/0x10 [<ffffffff81493df7>] ? inet_release+0x67/0x90 [<ffffffff81418a69>] ? sock_release+0x29/0x90 [<ffffffff81418ae7>] ? sock_close+0x17/0x30 [<ffffffff81177d25>] ? __fput+0xf5/0x210 [<ffffffff81177e65>] ? fput+0x25/0x30 [<ffffffff811738ad>] ? filp_close+0x5d/0x90 [<ffffffff81173985>] ? sys_close+0xa5/0x100 [<ffffffff8100b0f2>] ? system_call_fastpath+0x16/0x1b ---[ end trace 8a3a8d1bc708fc28 ]---
Last thing: I have tried to debug this crashing using gdb, but I have no idea how to attach to pppd process within L2TP/IPSec VPN connection establishing. So there is some work needed, but I think that the most of work is already done by Michael Heiart, <michael.heiart> and Michael Joosten, <michael.joosten>.
Created attachment 678433 [details] EAP-PEAP additional patch for previous one Even more, I am attaching EAP-PEAP patch for RADIUS plugin that I've created analogous like the EAP-TTLS patch is created. Looks like EAP-PEAP method is recognized by freeradius, but authentication is also not finished as pppd daemon crashes. FreeRADIUS recognizing PEAP patch: Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group eap {...} [eap] Request found, released from the list [eap] EAP/peap [eap] processing type peap [peap] processing EAP-TLS TLS Length 95 [peap] Length Included [peap] eaptls_verify returned 11 [peap] (other): before/accept initialization [peap] TLS_accept: before/accept initialization [peap] <<< TLS 1.0 Handshake [length 005a], ClientHello [peap] TLS_accept: SSLv3 read client hello A [peap] >>> TLS 1.0 Handshake [length 0031], ServerHello [peap] TLS_accept: SSLv3 write server hello A [peap] >>> TLS 1.0 Handshake [length 084e], Certificate [peap] TLS_accept: SSLv3 write certificate A [peap] >>> TLS 1.0 Handshake [length 0004], ServerHelloDone [peap] TLS_accept: SSLv3 write server done A [peap] TLS_accept: SSLv3 flush data [peap] TLS_accept: Need to read more data: SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode [peap] eaptls_process returned 13 [peap] EAPTLS_HANDLED ++[eap] returns handled Sending Access-Challenge of id 97 to 172.30.0.90 port 46601 EAP-Message = 0x... EAP-Message = 0x... EAP-Message = 0x... EAP-Message = 0x... EAP-Message = 0x72697479205465616d310f30 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x.. Finished request 2. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 95 with timestamp +9 Cleaning up request 1 ID 96 with timestamp +9 Cleaning up request 2 ID 97 with timestamp +10 WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING: !! EAP session for state 0x4f9f092d4db71040 did not finish! WARNING: !! Please read http://wiki.freeradius.org/Certificate_Compatibility WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Ready to process requests.
Providing backtrace of that buffer overflow: process 30029 is executing new program: /usr/sbin/pppd *** buffer overflow detected ***: /usr/sbin/pppd terminated ======= Backtrace: ========= /lib64/libc.so.6(__fortify_fail+0x37)[0x7ffff7076d47] /lib64/libc.so.6(+0xffc30)[0x7ffff7074c30] /usr/lib/../lib64/pppd/2.4.5/radius.so(rc_avpair_gen+0x10c)[0x7ffff66de8bc] /usr/lib/../lib64/pppd/2.4.5/radius.so(rc_send_server+0x55a)[0x7ffff66e25ea] /usr/lib/../lib64/pppd/2.4.5/radius.so(rc_auth_using_server+0x148)[0x7ffff66df838] /usr/lib/../lib64/pppd/2.4.5/radius.so(+0x568c)[0x7ffff66dd68c] /usr/sbin/pppd(+0x33dfa)[0x7ffff7fe0dfa] /usr/sbin/pppd(+0x343c0)[0x7ffff7fe13c0] /usr/sbin/pppd(main+0xa79)[0x7ffff7fc0809] /lib64/libc.so.6(__libc_start_main+0xfd)[0x7ffff6f93cdd] /usr/sbin/pppd(+0x10c19)[0x7ffff7fbdc19] ======= Memory map: ======== 7ffff5ea1000-7ffff5eb7000 r-xp 00000000 fd:01 2458 /lib64/libgcc_s-4.4.6-20120305.so.1 7ffff5eb7000-7ffff60b6000 ---p 00016000 fd:01 2458 /lib64/libgcc_s-4.4.6-20120305.so.1 7ffff60b6000-7ffff60b7000 rw-p 00015000 fd:01 2458 /lib64/libgcc_s-4.4.6-20120305.so.1 7ffff60b7000-7ffff60cd000 r-xp 00000000 fd:01 28018 /lib64/libresolv-2.12.so 7ffff60cd000-7ffff62cd000 ---p 00016000 fd:01 28018 /lib64/libresolv-2.12.so 7ffff62cd000-7ffff62ce000 r--p 00016000 fd:01 28018 /lib64/libresolv-2.12.so 7ffff62ce000-7ffff62cf000 rw-p 00017000 fd:01 28018 /lib64/libresolv-2.12.so 7ffff62cf000-7ffff62d1000 rw-p 00000000 00:00 0 7ffff62d1000-7ffff62d6000 r-xp 00000000 fd:01 11388 /lib64/libnss_dns-2.12.so 7ffff62d6000-7ffff64d5000 ---p 00005000 fd:01 11388 /lib64/libnss_dns-2.12.so 7ffff64d5000-7ffff64d6000 r--p 00004000 fd:01 11388 /lib64/libnss_dns-2.12.so 7ffff64d6000-7ffff64d7000 rw-p 00005000 fd:01 11388 /lib64/libnss_dns-2.12.so 7ffff64d7000-7ffff64d8000 r-xp 00000000 fd:01 16642 /usr/lib64/pppd/2.4.5/radattr.so 7ffff64d8000-7ffff66d7000 ---p 00001000 fd:01 16642 /usr/lib64/pppd/2.4.5/radattr.so 7ffff66d7000-7ffff66d8000 rw-p 00000000 fd:01 16642 /usr/lib64/pppd/2.4.5/radattr.so 7ffff66d8000-7ffff66e6000 r-xp 00000000 fd:01 16643 /usr/lib64/pppd/2.4.5/radius.so 7ffff66e6000-7ffff68e5000 ---p 0000e000 fd:01 16643 /usr/lib64/pppd/2.4.5/radius.so 7ffff68e5000-7ffff68e7000 rw-p 0000d000 fd:01 16643 /usr/lib64/pppd/2.4.5/radius.so 7ffff68e7000-7ffff68e9000 rw-p 00000000 00:00 0 7ffff68e9000-7ffff68f5000 r-xp 00000000 fd:01 28016 /lib64/libnss_files-2.12.so 7ffff68f5000-7ffff6af5000 ---p 0000c000 fd:01 28016 /lib64/libnss_files-2.12.so 7ffff6af5000-7ffff6af6000 r--p 0000c000 fd:01 28016 /lib64/libnss_files-2.12.so 7ffff6af6000-7ffff6af7000 rw-p 0000d000 fd:01 28016 /lib64/libnss_files-2.12.so 7ffff6af7000-7ffff6b0e000 r-xp 00000000 fd:01 3468 /lib64/libaudit.so.1.0.0 7ffff6b0e000-7ffff6d0d000 ---p 00017000 fd:01 3468 /lib64/libaudit.so.1.0.0 7ffff6d0d000-7ffff6d0e000 r--p 00016000 fd:01 3468 /lib64/libaudit.so.1.0.0 7ffff6d0e000-7ffff6d13000 rw-p 00017000 fd:01 3468 /lib64/libaudit.so.1.0.0 7ffff6d13000-7ffff6d70000 r-xp 00000000 fd:01 3327 /lib64/libfreebl3.so 7ffff6d70000-7ffff6f6f000 ---p 0005d000 fd:01 3327 /lib64/libfreebl3.so 7ffff6f6f000-7ffff6f70000 r--p 0005c000 fd:01 3327 /lib64/libfreebl3.so 7ffff6f70000-7ffff6f71000 rw-p 0005d000 fd:01 3327 /lib64/libfreebl3.so 7ffff6f71000-7ffff6f75000 rw-p 00000000 00:00 0 7ffff6f75000-7ffff70fe000 r-xp 00000000 fd:01 8311 /lib64/libc-2.12.so 7ffff70fe000-7ffff72fe000 ---p 00189000 fd:01 8311 /lib64/libc-2.12.so 7ffff72fe000-7ffff7302000 r--p 00189000 fd:01 8311 /lib64/libc-2.12.so 7ffff7302000-7ffff7303000 rw-p 0018d000 fd:01 8311 /lib64/libc-2.12.so 7ffff7303000-7ffff7308000 rw-p 00000000 00:00 0 7ffff7308000-7ffff733d000 r-xp 00000000 fd:01 21916 /usr/lib64/libpcap.so.1.0.0 7ffff733d000-7ffff753c000 ---p 00035000 fd:01 21916 /usr/lib64/libpcap.so.1.0.0 7ffff753c000-7ffff753f000 rw-p 00034000 fd:01 21916 /usr/lib64/libpcap.so.1.0.0 7ffff753f000-7ffff7541000 r-xp 00000000 fd:01 28012 /lib64/libdl-2.12.so 7ffff7541000-7ffff7741000 ---p 00002000 fd:01 28012 /lib64/libdl-2.12.so 7ffff7741000-7ffff7742000 r--p 00002000 fd:01 28012 /lib64/libdl-2.12.so 7ffff7742000-7ffff7743000 rw-p 00003000 fd:01 28012 /lib64/libdl-2.12.so 7ffff7743000-7ffff774f000 r-xp 00000000 fd:01 5708 /lib64/libpam.so.0.82.2 7ffff774f000-7ffff794f000 ---p 0000c000 fd:01 5708 /lib64/libpam.so.0.82.2 7ffff794f000-7ffff7950000 r--p 0000c000 fd:01 5708 /lib64/libpam.so.0.82.2 7ffff7950000-7ffff7951000 rw-p 0000d000 fd:01 5708 /lib64/libpam.so.0.82.2 7ffff7951000-7ffff7958000 r-xp 00000000 fd:01 9990 /lib64/libcrypt-2.12.so 7ffff7958000-7ffff7b58000 ---p 00007000 fd:01 9990 /lib64/libcrypt-2.12.so 7ffff7b58000-7ffff7b59000 r--p 00007000 fd:01 9990 /lib64/libcrypt-2.12.so 7ffff7b59000-7ffff7b5a000 rw-p 00008000 fd:01 9990 /lib64/libcrypt-2.12.so 7ffff7b5a000-7ffff7b88000 rw-p 00000000 00:00 0 7ffff7b88000-7ffff7b8a000 r-xp 00000000 fd:01 11413 /lib64/libutil-2.12.so 7ffff7b8a000-7ffff7d89000 ---p 00002000 fd:01 11413 /lib64/libutil-2.12.so 7ffff7d89000-7ffff7d8a000 r--p 00001000 fd:01 11413 /lib64/libutil-2.12.so 7ffff7d8a000-7ffff7d8b000 rw-p 00002000 fd:01 11413 /lib64/libutil-2.12.so 7ffff7d8b000-7ffff7dab000 r-xp 00000000 fd:01 5709 /lib64/ld-2.12.so 7ffff7f9f000-7ffff7fa4000 rw-p 00000000 00:00 0 7ffff7fa5000-7ffff7fa6000 rw-p 00000000 00:00 0 7ffff7fa6000-7ffff7fa8000 rw-s 00000000 fd:05 416 /var/run/pppd2.tdb[Switching to process 30029] Breakpoint 1, 0x00007ffff6fa7870 in raise () from /lib64/libc.so.6
Created attachment 678842 [details] RADIUS EAP-TLS/EAP-TTLS Patch v0.2 removed EAP-TLS/-TTLS unrelated code: - internal IP Pools - other code like "stripnum" and "despace" declarations (which is also not in original ppp package)
Created attachment 679094 [details] RADIUS EAP-TLS/EAP-TTLS/EAP-PEAP Patch NEWS: - buffer overflow fixed (invalid AUTH_STRING_LEN length) - increased number transmits (EAP_DEFTRANSMITS) from 10 to 20 (10 is really not enough in data intensive RADIUS communication) - "fixed" errors of "Incorrect key length (32) for MS-MPPE-Recv-Key attribute" and " Incorrect attribute length (50) for MS-CHAP-MPPE-Keys" - only dirty fix, but MPPE is working. - attached original README.eap-tls_plus_addOns and README.eap-tls-client (but needs to be revised as I removed unnecessary code (like ip pools)) summary: - we have now working implementation of EAP-TLS, EAP-TTLS and EAP-PEAP authentication methods for ppp 2.4.5 - I've successfully tested EAP-TLS and EAP-PEAP methods - they are working great! limitations: - not working with openl2tp daemon (still same ppp crash that i've mentioned before and gdb was not helpful in this case). I've tested with xl2tpd instead. :) any chance to review and used in distribution version of ppp? :)
Update: patched ppp with RADIUS EAP extension is able to work in conjunction with openl2tpd. but only if one of following condition is met: - ippool.so plugin must be NOT used within ppp option, OR - just comment out "dump" directive within ppp option file (i.e. do not use dumping within ppp). looks like dumping with enabled ippool plugin caused this crash but this issue have nothing to do with EAP patch itself as this issue is present also in current distribution ppp version.
I've opened bug report to openl2tp project about this problem: https://sourceforge.net/tracker/?func=detail&aid=3601381&group_id=118353&atid=680933 BTW VPN connection establishing with using openl2tpd is pretty faster than with xl2tpd daemon :)
Thank you for the patch, your contribution is very appreciated. I will review the patch in the near future.
Created attachment 718350 [details] EAP-{TLS|TTLS|PEAP} Patch for PPPd RADIUS Plugin including support of "Calling-Station-Id" Update: - implemented improvement that PPPd RADIUS plugin will send "Calling-Station-Id" when EAP-{TLS|TTLS|PEAP} is used as authentication method - with this parameter a real client IP address will be provided to RADIUS server and this behavior will provide better logging of connecting VPN clients (i.e. using some kind of radius postauth script). - this works completely analogously like for CHAP or PAP auth methods. Client's IP address will be determined using "remotenumber" or "ipparam" provided to pppd instance (using ppp option file or direct paramter while calling pppd instance)
(In reply to comment #27) > Created attachment 718350 [details] > EAP-{TLS|TTLS|PEAP} Patch for PPPd RADIUS Plugin including support of > "Calling-Station-Id" > > Update: > - implemented improvement that PPPd RADIUS plugin will send > "Calling-Station-Id" when EAP-{TLS|TTLS|PEAP} is used as authentication > method - with this parameter a real client IP address will be provided to > RADIUS server and this behavior will provide better logging of connecting > VPN clients (i.e. using some kind of radius postauth script). > - this works completely analogously like for CHAP or PAP auth methods. > Client's IP address will be determined using "remotenumber" or "ipparam" > provided to pppd instance (using ppp option file or direct paramter while > calling pppd instance) Currently "ipparam" is forcibly provided by xl2tpd daemon and cannot be overridden by ppp options file - this is causing that default ipv6-up ppp script will fail with retval 1. more about this is in BZ#929447.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.