(RADIATOR) PEAPV1-GTC implementation
SecureW2 (List)
list at securew2.com
Thu Jun 5 03:44:37 CDT 2008
Hugh,
Thanks, but there is nothing wrong with the actual TLS encryption (for which
the labels are used), however I am seeing part of the PEAPV0 protocol in the
PEAPV1 implementation of Radiator.
This is the code:
--------------------- EAP_25.pm --------------------------------------
elsif ($reply_code eq 'Access-Accept'
&& $code == $Radius::EAP::EAP_CODE_SUCCESS)
{
# The inner authentication succeeded
# Create an EAP extension request, acknowledged success, and tunnel
it back
# Client will ack later with an EAP extension reply, acknowledged
success
&eap_extension($self, $context, $op,
$Radius::EAP_25::EAPEXTENSIONS_RESULT_SUCCESS);
....
------------------------------------------------------------------------
It basically creates an eap_extension no matter what PEAP version is used :(
But my understanding is that PEAPV1 does not use eap extensions. Or am I
incorrect?
Regards,
Tom
> -----Oorspronkelijk bericht-----
> Van: Hugh Irvine [mailto:hugh at open.com.au]
> Verzonden: donderdag 5 juni 2008 10:28
> Aan: SecureW2 ((List))
> CC: radiator at open.com.au list
> Onderwerp: Re: (RADIATOR) PEAPV1-GTC implementation
>
>
> Hello Tom -
>
> Further to this, please see sections 5.18.41 and 5.18.42 in the
> Radiator 4.2 reference manual ("doc/ref.pdf").
>
> regards
>
> Hugh
>
>
> On 5 Jun 2008, at 18:24, Hugh Irvine wrote:
>
> >
> > 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.
>
>
>
> 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