(RADIATOR) 2.18.3 & EAP

Anne Bennett anne at alcor.concordia.ca
Fri Sep 7 12:39:07 CDT 2001


Hi, Hugh.

>> the wireless base station points to the ACS/Windows
>> box, which then points to Radiator running on my Unix box, and Radiator
>> authenticates based on flat file information.
>>
>> Plain old flat file authentication works as expected based on tests
>> with radpwtst from "localhost".  What I need to know is whether Radiator
>> will be able to respond correctly to the queries sent by the ACS/Windows
>> box on behalf of the wireless base station, and if so, what additional
>> configuration items are needed for that client (or the associated realm).
> 
> Radiator should work correctly in the manner you describe, but if you send me
> a trace 4 debug from Radiator together with your configuration file (no 
> secrets), I will be happy to take a look.

OK; that would be great.  See end of message for that material.

> Here is part of the configuration that you will need:
> 
> # define Client clauses
> 
> <Client your.acs.box>
> 	Secret somesecret
> 	.....
> </Client>

Yup, had that, with a DefaultRealm though.

> <Client localhost>
> 	Secret mysecret
> 	DupInterval 0
> 	.....
> </Client>

Had that too, as it happens, and also with a (different) DefaultRealm,
since that was what I was testing authentication on, but I'm curious as
to why that matters for this, i.e., why a localhost client would be
needed to do the LEAP authentication with the ACS box.

> # define AuthBy clauses
> 
> <AuthBy FILE>
> 	Identifier CheckFile
> 	Filename %D/users
> 	.....
> </AuthBy>
> 
> # define Realm(s) or Handler(s)
> 
> <Realm>
> 	AuthBy CheckFile
> 	......
> </Realm>

Well, instead I have:

  <Realm xxxxxxxxx>
    <AuthBy FILE>
      Filename ....
    </AuthBy>
  </Realm>

which should be equivalent, right?

So there is no special configuration needed to support the LEAP stuff?


I append my config file, with comments removed and secrets X'd out.  Then
I append the trace output you requested.  In both files I have edited
the names and IP addresses of hosts, since this list is archived, and
there's no reason for the world to know where our network infrastructure
hosts are without even bothering to scan. :-)

In the trace showing the ACS box's connection, we get "Bad EAP
Message-Authenticator".  Just for fun, yesterday we tried pointing
the access point at Radiator directly, even though I believe that is
not supposed to work.  Oddly enough, it got further: Radiator sent an
Access-Challenge back, though there's no record of a response to
that challenge from the access point.

Anyway, back to the case we're supposed to be solving, where we
authenticate requests from the ACS box: that box is running ACS 2.6.
It is configured to consider my "radhost" a type "RADIUS" (as opposed
to "TACACS+" or "CiscoSecure ACS for Windows 2000/NT"), with traffic
type "inbound/outbound".

The access point authenticates with "RADIUS (Cisco Aironet)", as opposed
to "TACACS+ (Cisco IOS)", "RADIUS (IETF)", "RADIUS (Cisco IOS/PIX)",
"RADIUS (Cisco VPN 5000)", "RADIUS (Cisco VPN 3000)", or "RADIUS
(Ascend)".  It shares a secret key with the ACS which is different from
the secret key shared between the ACS and my "radhost".

I wondered if "Bad EAP Message-Authenticator" was the result of
a secret mismatch.  I tried again with the client entry for the
access-point commented out, in case it was somehow interfering with
selecting the correct secret to use -- no change, still got "Bad EAP
Message-Authenticator".  I rechecked the secrets, and they seem to match.

Any ideas?


Anne.
-- 
Ms. Anne Bennett, Senior Analyst, IITS, Concordia University, Montreal H3G 1M8
anne at alcor.concordia.ca                                        +1 514 848-7606
----------------------------------------------------------------------------
CONFIG FILE:
----------------------------------------------------------------------------
Foreground
LogStdout
Trace    4
AuthPort 1645
AcctPort 1646
LogDir /tmp/radius/log
DbDir /tmp/radius/db
LogFile %L/logfile
UsernameCharset a-zA-Z0-9\.\-_@
<Client name_of_router.concordia.ca>
  Secret XXXXXXXXXXX
  DefaultRealm hse.concordia.ca
</Client>
<Client radhost.concordia.ca>
  Secret XXXXXXXXXXX
  DefaultRealm wireless.concordia.ca
  DupInterval 0
</Client>
<Client localhost>
  Secret XXXXXXXXXXX
  DefaultRealm wireless.concordia.ca
  DupInterval 0
</Client>
<Client name_of_acs.concordia.ca>
  Secret XXXXXXXXXXX
  DefaultRealm alcor.concordia.ca
</Client>
<Client name_of_access_point.concordia.ca>
  Secret XXXXXXXXXXX
  DefaultRealm wireless.concordia.ca
</Client>

<Realm wireless.concordia.ca>
  RejectHasReason
  RewriteUsername      s/\@wireless.concordia.ca$//
  <AuthBy FILE>
    Filename /path/to/NEG/WIRELESS.users
  </AuthBy>
</Realm>
<Realm alcor.concordia.ca>
  RejectHasReason
  RewriteUsername      s/\@alcor.concordia.ca$//
  <AuthBy FILE>
    Filename /path/to/SSG/ALCOR.users
  </AuthBy>
</Realm>
<Realm hse.concordia.ca>
  RejectHasReason
  <AuthBy FILE>
    Filename /path/to/NEG/HSE.users
  </AuthBy>
</Realm>
<Realm>
</Realm>
<Realm DEFAULT>
</Realm>
----------------------------------------------------------------------------
TRACE 4 OF ACS BOX TRYING TO AUTHENTICATE A USER:
----------------------------------------------------------------------------

# ./radiusd -config_file /tmp/radius/db/radconf
Fri Sep  7 11:52:01 2001: DEBUG: Reading users file /path/to/NEG/WIRELESS.users
Fri Sep  7 11:52:01 2001: DEBUG: Reading users file /path/to/SSG/ALCOR.users
Fri Sep  7 11:52:04 2001: DEBUG: Reading users file /path/to/NEG/HSE.users
This Radiator license will expire on 2002-01-01
This Radiator license will stop operating after 1000 requests
To purchase an unlimited full source version of Radiator, see 
http://www.open.com.au/radiator/ordering.html
To extend your evaluation period, contact admin at open.com.au

Fri Sep  7 11:52:05 2001: INFO: Server started: Radiator 2.18.3 on radhost (DEMO)
Fri Sep  7 11:55:50 2001: DEBUG: Packet dump:
*** Received from 132.205.[acs-IP] port 2211 ....
Code:       Access-Request
Identifier: 1
Authentic:  _ot*zv<23>D<18>v%<209>[<199>b?
Attributes:
        User-Name = "wtest1"
        NAS-IP-Address = 132.205.[access-point-IP]
        Called-Station-Id = "004096589265"
        Calling-Station-Id = "004096417803"
        NAS-Identifier = "name_of_access_point.concordia.ca"
        Framed-MTU = 1400
        NAS-Port-Type = 19
        EAP-Message = <2><1><0>!<1>wtest1 at wireless.concordia.ca
        Message-Authenticator = <217><159><146><3>0H<240><21><210>g<151><212>3<26><168>)
        Proxy-State = CISCO:8

Fri Sep  7 11:55:50 2001: WARNING: Bad EAP Message-Authenticator
Fri Sep  7 11:55:50 2001: WARNING: Bad authenticator in request from name_of_acs.concordia.ca (132.205.[access-point-IP])

[then another identical listing one second later, then two more with
 Authentic:  d<16>j<13>qa^2X<163>0o_<193>\<171>
 Identifier: 2
 Message-Authenticator = Q<20><216><132><162><194>uv<216><8>+<169><15>_<234><149>
35 and 36 seconds later.  Then I stopped it.]
----------------------------------------------------------------------------
TRACE 4 OF ACCESS POINT TRYING TO AUTHENTICATE A USER DIRECTLY:
----------------------------------------------------------------------------
Wed Sep  5 17:00:22 2001: DEBUG: Packet dump:
*** Received from 132.205.[access-point-IP] port 5001 ....
Code:       Access-Request
Identifier: 58
Authentic:  5<255>=Sz<192>"<11><10><173>F<12>@<230>(<188>
Attributes:
        User-Name = "wtest1"
        NAS-IP-Address = 132.205.[access-point-IP]
        Called-Station-Id = "004096589265"
        Calling-Station-Id = "004096417803"
        NAS-Identifier = "name_of_access_point.concordia.ca"
        Framed-MTU = 1400
        NAS-Port-Type = 19
        EAP-Message = <2>K<0><11><1>wtest1
        Message-Authenticator = ?<14>r<209>R+<215>"<8>.!<11><143><217><190><147>

Wed Sep  5 17:00:22 2001: DEBUG: Handling request with Handler 'Realm=wireless.concordia.ca'
Wed Sep  5 17:00:22 2001: DEBUG: Rewrote user name to wtest1
Wed Sep  5 17:00:22 2001: DEBUG:  Deleting session for wtest1, 132.205.[access-point-IP], 
Wed Sep  5 17:00:22 2001: DEBUG: Handling with Radius::AuthFILE: 
Wed Sep  5 17:00:22 2001: DEBUG: Radius::AuthFILE looks for match with wtest1
Wed Sep  5 17:00:22 2001: DEBUG: Handling with EAP
Wed Sep  5 17:00:22 2001: DEBUG: EAP code 2, 75, 11
Wed Sep  5 17:00:22 2001: DEBUG: Response type 1
Wed Sep  5 17:00:22 2001: DEBUG: Radius::AuthFILE CHALLENGE: EAP MD5-Challenge
Wed Sep  5 17:00:22 2001: DEBUG: Access challenged for wtest1: EAP MD5-Challenge
Wed Sep  5 17:00:22 2001: DEBUG: Packet dump:
*** Sending to 132.205.[access-point-IP] port 5001 ....
Code:       Access-Challenge
Identifier: 58
Authentic:  5<255>=Sz<192>"<11><10><173>F<12>@<230>(<188>
Attributes:
        EAP-Message = <1><26><0><27><4><16><188><213>'<176><30><133><128><136>0<199><1>Re<5>0<142>radhost
        Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
        Framed-IP-Address = 132.205.[wtest1-IP-from-users-file]

----------------------------------------------------------------------------
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


More information about the radiator mailing list