(RADIATOR) PEAPV1-GTC implementation

SecureW2 (List) list at securew2.com
Thu Jun 5 03:18:07 CDT 2008


Hugh,

-------------------------- snippet EAP_25.pm -----------------------
...
sub handle_tls_data
{
    my ($self, $context, $p, $data) = @_;

    # For tunnelled EAP requests, the
    # first byte is the EAP type (identity etc). No request/response code,
    # ID or length
    # For EAP Extensions reponses, it _does_ include the EAP code, id
    # and length. Sigh
    my ($code, $id, $len, $type) = unpack('C C n C ', $data);

    # Maybe an EAP extensions response, acknowledging
    # a previous success or failure
    return &handle_eap_extension($self, $context, $p, $data)
        if ($code == $Radius::EAP::EAP_CODE_RESPONSE
            && $type == $Radius::EAP::EAP_TYPE_EXTENSIONS);
...
---------------------------------------------------------------------

The function handle_eap_extension SHOULD check for PEAPv0 or PEAPv1, and in
the case of PEAPv0 send the extension and for PEAPv1 a normal success
packet.

I am using the following drafts: 

http://tools.ietf.org/html/draft-josefsson-pppext-eap-tls-eap-05 (PEAPv1) 

which shows the following in the flow diagrams:

  <- EAP-Success

and

http://tools.ietf.org/html/draft-kamath-pppext-peapv0-00 (PEAPv0)

which shows the following in the flow diagrams:

                        <- EAP-Request/
                           EAP-Type=Extensions
                           Result=Success

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.
> 


--
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