(RADIATOR) PEAPV1-GTC implementation
Hugh Irvine
hugh at open.com.au
Thu Jun 5 03:24:19 CDT 2008
Hello Tom -
I still need to see a copy of your configuration file.
regards
Hugh
On 5 Jun 2008, at 18:12, SecureW2 ((List)) wrote:
> Hugh,
>
> Sorry about this, it was quite late yesterday and I somehow
> convinced myself
> that my own debug logging was using the ASCII debug log of radiator.
>
> The decrypted packet header is correct, but it is the extended
> response
> packet that is used in PEAPv0
> (http://tools.ietf.org/html/draft-kamath-pppext-peapv0-00 section
> 2.1). I am
> however using PEAPv1 in this particular authentication.
>
> I am not sure if this is correct, but in PEAPv1 I expect a simple
> ACCESS-ACCEPT packet, not the extended response which I would
> expect in
> PEAPv0.
>
> Regards,
>
> Tom
>
>> -----Oorspronkelijk bericht-----
>> Van: Hugh Irvine [mailto:hugh at open.com.au]
>> Verzonden: donderdag 5 juni 2008 10:05
>> Aan: SecureW2 (List)
>> CC: radiator at open.com.au
>> Onderwerp: Re: (RADIATOR) PEAPV1-GTC implementation
>>
>>
>> Hello -
>>
>> The final packet shown in the debug below is a PEAP access challenge,
>> not an access accept.
>>
>> I will need to see your configuration file as well as the trace 4
>> debug.
>>
>> regards
>>
>> Hugh
>>
>>
>> On 5 Jun 2008, at 17:47, SecureW2 ((List)) wrote:
>>
>>> Hi,
>>>
>>> I am having trouble getting my new SecureW2 PEAPV1-GTC
>>> implementation
>>> working with Radiator and I was hoping if you could shed some light
>>> on it.
>>>
>>> It is failing in the ACCESS-ACCEPT send by the inner GTC module:
>>>
>>> ------------------ GTC Response Tunneled in PEAP sent by SecureW2
>>> ----------
>>>
>>> *** Received from 82.75.154.105 port 27803 ....
>>>
>>> Packet length = 180
>>> 01 e7 00 b4 b0 cc 03 df 3e f8 72 e0 38 29 d8 f8 6c d0 5b 65 01 0a
>>> 74 6f 6d
>>> 40 74 74 6c 73 0c 06 00 00 05 78 1e 10 30 30 30 66 2e 38 66 31 64 2e
>>> 37 36 32 30 1f 10 30 30 31 61 2e 37 33 39 31 2e
>>> 37 36 31 30 50 12 54 12 ef 07 bd 38 fa 73 4c f3 ca 68 2d 32 11 27
>>> 4f 39 02
>>> 08 00 37 19 81 00 00 00 2d 17 03 01 00 28 ce be 0d 48 f0 05 18 1f
>>> 71 dc fc
>>> 61 71 04 c7 0e a4 c3 b9 58 99 7e 47 76 24
>>> c5 1b 02 50 ea ab c7 9f 8d 21 74 76 90 b3 dc 3d
>>> 06 00 00 00 13 05 06 00 00 01 5c 06 06 00 00 00
>>> 02 04 06 c0 a8 02 02 20 0d 72 69 78 6f 6d 61 70
>>> 31 31 30 30
>>> Code: Access-Request
>>> Identifier: 231
>>> Authentic: <176><204><3><223>><248>r<224>8)<216><248>l<208>[e
>>> Attributes:
>>> User-Name = "tom at ttls"
>>> Framed-MTU = 1400
>>> Called-Station-Id = "000f.8f1d.7620"
>>> Calling-Station-Id = "001a.7391.7610"
>>> Message-Authenticator =
>>> T<18><239><7><189>8<250>sL<243><202>h-2<17>'
>>> EAP-Message =
>>> <2><8><0>7<25><129><0><0><0>-<23><3><1><0>
>>> (<206><190><13>H<240><5><24><31>q<
>>> 220><252>aq<4><199><14><164><195><185>X<153>~Gv
>>> $<197><27><2>P<234><171><199>
>>> <159><141>!tv<144><179><220>
>>> NAS-Port-Type = Wireless-IEEE-802-11
>>> NAS-Port = 348
>>> Service-Type = Framed-User
>>> NAS-IP-Address = 192.168.2.2
>>> NAS-Identifier = "rixomap1100"
>>>
>>> Wed Jun 4 21:51:08 2008: DEBUG: Handling request with Handler
>>> 'Realm=ttls'
>>> Wed Jun 4 21:51:08 2008: DEBUG: Rewrote user name to tom Wed Jun 4
>>> 21:51:08 2008: DEBUG: Deleting session for tom at ttls, 192.168.2.2,
>>> 348 Wed
>>> Jun 4 21:51:08 2008: DEBUG: Handling with Radius::AuthFILE:
>>> Wed Jun 4 21:51:08 2008: DEBUG: Handling with EAP: code 2, 8, 55
>>> Wed Jun 4
>>> 21:51:08 2008: DEBUG: Response type 25 Wed Jun 4 21:51:08 2008:
>>> DEBUG: EAP
>>> PEAP inner authentication request for anonymous Wed Jun 4 21:51:08
>>> 2008:
>>> DEBUG: PEAP Tunnelled request Packet dump:
>>>
>>> ------------- Tunneled GTC Response sent internally by Radiator to
>>> GTC -----
>>>
>>> Code: Access-Request
>>> Identifier: UNDEF
>>> Authentic: ]<137>"<0><254>8<181>r<214>}_<178><246>I<16>|
>>> Attributes:
>>> EAP-Message = <2><1><0><14><6>zolavin38
>>> Message-Authenticator =
>>> <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
>>> User-Name = "anonymous"
>>> NAS-IP-Address = 192.168.2.2
>>> NAS-Identifier = "rixomap1100"
>>> NAS-Port = 348
>>> Calling-Station-Id = "001a.7391.7610"
>>>
>>> Wed Jun 4 21:51:08 2008: DEBUG: Handling request with Handler
>>> 'TunnelledByPEAP=1'
>>> Wed Jun 4 21:51:08 2008: DEBUG: Deleting session for anonymous,
>>> 192.168.2.2, 348 Wed Jun 4 21:51:08 2008: DEBUG: Handling with
>>> Radius::AuthOTP:
>>> Wed Jun 4 21:51:08 2008: DEBUG: Handling with EAP: code 2, 1, 14
>>> Wed Jun 4
>>> 21:51:08 2008: DEBUG: Response type 6 Wed Jun 4 21:51:08 2008:
>>> DEBUG: EAP
>>> result: 0, Wed Jun 4 21:51:08 2008: DEBUG: AuthBy OTP result:
>>> ACCEPT, Wed
>>> Jun 4 21:51:08 2008: DEBUG: Access accepted for anonymous Wed
>>> Jun 4
>>> 21:51:08 2008: DEBUG: Returned PEAP tunnelled packet dump:
>>>
>>> ------------------ GTC ACCESS-ACCEPT ----------
>>>
>>> Code: Access-Accept
>>> Identifier: UNDEF
>>> Authentic: ]<137>"<0><254>8<181>r<214>}_<178><246>I<16>|
>>> Attributes:
>>> EAP-Message = <3><1><0><4>
>>> Message-Authenticator =
>>> <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
>>>
>>> Wed Jun 4 21:51:08 2008: DEBUG: EAP result: 3, EAP PEAP inner
>>> authentication redespatched to a Handler Wed Jun 4 21:51:08 2008:
>>> DEBUG:
>>> AuthBy FILE result: CHALLENGE, EAP PEAP inner authentication
>>> redespatched to
>>> a Handler Wed Jun 4 21:51:08 2008: DEBUG: Access challenged for
>>> tom: EAP
>>> PEAP inner authentication redespatched to a Handler Wed Jun 4
>>> 21:51:08
>>> 2008: DEBUG: Packet dump:
>>> *** Sending to 82.75.154.105 port 27803 ....
>>>
>>> Packet length = 112
>>> 0b e7 00 70 89 b4 5b 6d f7 16 a3 4b 29 09 cc 66 ba 35 cd e1 4f 4a
>>> 01 09 00
>>> 48 19 01 17 03 01 00
>>> 18 7a 9a ba 58 45 b0 99 16 48 47 eb 6d 9d 32 f5
>>> 39 cd da 7c 8c 40 2f e0 bc 17 03 01 00 20 75 2e
>>> 41 15 7b 26 82 ef 13 43 a7 3c b8 a5 22 69 f0 2a 20 f3 53 f3 8a 67
>>> 7d 52 24
>>> b5 eb 23 e0 01 50 12
>>> 56 0c 63 9d 7e 82 83 a3 d5 5e 8a 32 3d 82 21 89
>>> Code: Access-Challenge
>>> Identifier: 231
>>> Authentic: <176><204><3><223>><248>r<224>8)<216><248>l<208>[e
>>> Attributes:
>>> EAP-Message =
>>> <1><9><0>H<25><1><23><3><1><0><24>z<154><186>XE<176><153><22>HG<235>
>>> m<
>>> 157>2<
>>> 245>9<205><218>|<140>@/<224><188><23><3><1><0>
>>> u.A<21>{&<130><239><19>C<167><<184><165>"i<240>*
>>> <243>S<243><138>g}R$<181><235>#<224><1>
>>> Message-Authenticator =
>>> <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
>>>
>>> When decrypted in SecureW2 there are two application_data messages,
>>> one 24
>>> bytes long and the other 32 bytes (the message authenticator) but
>>> both
>>> containing nothing that looks like a access-accept :(
>>>
>>> The packet that should contain an access accept is:
>>>
>>> [4348] 23:20:08:326: TLSParseServerPacket::application data (11)
>>> [4348] 23:20:08:326: 0B000901 00038021 00010002 00000000
>>> |.......!........|
>>>
>>> Which in hex is:
>>>
>>> 1,9,0,b,21,80,3,0,2,0
>>>
>>> The last 4 are the access accept, but the EAP header is all wrong.
>>>
>>> Is there maybe a way to enable more SSL logging?
>>>
>>> Tom
>>>
>>> --
>>> 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.
>>
>>
>>
>> NB:
>>
>> Have you read the reference manual ("doc/ref.html")?
>> Have you searched the mailing list archive (www.open.com.au/archives/
>> radiator)?
>> Have you had a quick look on Google (www.google.com)?
>> Have you included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>> Have you checked the RadiusExpert wiki:
>> http://www.open.com.au/wiki/index.php/Main_Page
>>
>> --
>> Radiator: the most portable, flexible and configurable RADIUS server
>> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
>> Includes support for reliable RADIUS transport (RadSec),
>> and DIAMETER translation agent.
>> -
>> Nets: internetwork inventory and management - graphical, extensible,
>> flexible with hardware, software, platform and database independence.
>> -
>> CATool: Private Certificate Authority for Unix and Unix-like systems.
>>
>
NB:
Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.
--
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