(RADIATOR) tunnel-password questions

Tue Oct 4 05:46:36 CDT 2005

> -----Message d'origine-----
> De : Mike McCauley [mailto:mikem at open.com.au]
> Envoyé : mardi 4 octobre 2005 00:01
> À : PREVOSTO, Laurent
> Cc : radiator at open.com.au
> Objet : Re: (RADIATOR) tunnel-password questions
> 
> Hello Laurent,
> 
> On Tuesday 04 October 2005 03:46, PREVOSTO, Laurent wrote:
> > > De : Mike McCauley [mailto:mikem at open.com.au]
> > > Envoyé : lundi 3 octobre 2005 02:02
> > > À : PREVOSTO, Laurent
> > > Cc : radiator at open.com.au
> > > Objet : Re: (RADIATOR) tunnel-password questions
> > >
> > > Hello Laurent,
> > >
> > > On Thursday 29 September 2005 20:16, PREVOSTO, Laurent wrote:
> > > > Hi,
> > > >
> > > > I am not sure everything works perfectly, i have made a few tests
> with
> > > > radiator 3.13 + patches
> > > >
> > > > The conf is the following :
> > > >
> > > > <Client DEFAULT>
> > > > 	Secret secret
> > > > </Client>
> > > >
> > > > <AuthBy INTERNAL>
> > > > 	Identifier Always-Accept
> > > > 	AuthResult ACCEPT
> > > > </AuthBy>
> > > >
> > > > <Handler Realm="test">
> > > > 	AuthBy Always-Accept
> > > > 	AddToReply Tunnel-Password="1:password"
> > > > </Handler>
> > > >
> > > > I plan to test what is the value of the returned Tunnel-Password if
> I
> > >
> > > put
> > >
> > > > string or tagged-string for the Tunnel-Password attribute in the
> > >
> > > dictionary
> > >
> > > > file and if is add or not ClearTextTunnelPassword in the Client
> clause.
> > > >
> > > > I do a radpwtest -trace 4 -s localhost -noacct -dictionary
> > > > dictionary.with.no.tag -user lp at test -password test
> > > >
> > > > (I use a dictionary with no tag for radpwtst so I can see the very
> > > > value
> > >
> > > of
> > >
> > > > the attribute).
> > >
> > > The key to understanding the opertion is that Radiator keeps Tunnel-
> > > Password
> > > in plaintext format internally and encrypts/decrypts it at the 'edges'
> > > when
> > > receiving replies  from a remote server and sending replies back to
> the
> > > client.
> > >
> > > Therefore, Tunnel-Password in a user file or user database _must_ be
> in
> > > plaintext format. Indeed, it does not make sense to have Tunnel-
> Password
> > > in a
> > > user file alrteady encrypted, since the encryption depends on the
> RADIUS
> > > shared secret.
> > >
> > > > There are 4 cases :
> > > >
> > > > 1. Tunnel-Password is string and tunnel password is NOT clear text
> > > > 	Tunnel-Password =
> > > >
> "<1><224><21><153><141><226>0<134>it<197>b<0<232><13><202><227><237>" I
> > > > assume this is ok : there is a <1> byte tag and it is encrypted
> > >
> > > OK.
> > >
> > > > 2. Tunnel-Password is string and I put ClearTextTunnelPassword in
> the
> > > > Client clause : Tunnel-Password = "1:password"
> > > > I assume this is wrong : I was expecting something like <1>password
> > >
> > > Expected.
> > > If ClearTextTunnelPassword  is set then there is no
> > > encryption/tagging/special
> > > processing: the Tunnel-Password in the user database wil lbe sent
> > > literally
> > > and unchanged to the client.
> > >
> > > > 3. Tunnel-Password is tagged-string and tunnel password is NOT clear
> > >
> > > text
> > >
> > > > 	Tunnel-Password =
> > > > "<0><1><161><139><0>Y<230><173><12><1>b_J><232><127>s<191><223>g" I
> > >
> > > assume
> > >
> > > > this is wrong : the password is encrypted but I have the wrong tag
> > >
> > > No, it will get encrypted again when sent to the client. Thats why you
> > > are seeing the wrong tag.
> >
> > I don't get it : in my config file i have AddToReply
> > Tunnel-Password=1:password : the value is not in encrypted form. So
> there
> > is no way it should be encrypted "again". When I say "tunnel password is
> > not clear text", I mean : i did not put ClearTextTunnelPassword in the
> > config file...
> 
> Sorry, I made the wrong explanation.
> Curious.
> Tests here show that if you have
> AddToReply Tunnel-Password=1:password
> in the AuthBy and
> ClearTextTunnelPassword
> in the Client, you get:
> 
> *** Received from 127.0.0.1 port 1645 ....
> Code:       Access-Accept
> Identifier: 90
> Authentic:
> <251><212><158>R<149><172>e<142>x<240><163><133><226>><152><155>
> Attributes:
>         Tunnel-Password = "1:password"
> 
> and if you have:
> AddToReply Tunnel-Password=\001password
> you get
> 
> *** Received from 127.0.0.1 port 1645 ....
> Code:       Access-Accept
> Identifier: 226
> Authentic:  7<162><130><132>n<215>><173><147>>z<185>l<6>u<224>
> Attributes:
>         Tunnel-Password = "<1>password"
> 
> showing that when ClearTextTunnelPassword is set, the Tunnel-Password
> contains
> the literal string. Caution, AddToReply  will not recognise <n> as an
> escape
> code for character n.

I notice that if ClearTextTunnelPassword is not set, i have the following in the log file :

*** Sending to 127.0.0.1 port 32806 ....
Code:       Access-Accept
Identifier: 38
Authentic:  1234567890123456
Attributes:
        Tunnel-Password = <1><238><6><16>W^P<178>[<205><128>^<3><129>)K<148><3>0

But I get the following on the radpwtst side :

*** Received from 127.0.0.1 port 1812 ....
Code:       Access-Accept
Identifier: 38
Authentic:  te<181><211><204><25>B8Xye<12><140><250><253>|
Attributes:
        Tunnel-Password = "<0><1><238><6><16>W^P<178>[<205><128>^<3><129>)K<148><3>0"

Which means that if I put Tunnel-Password as tagged-string in the dictionary, it has a nasty side effect since it adds a <0> at the begining of the string.

Conclusion : I still can't find a common setup to be able to handle both encrypted and non encrypted tagged Tunnel-Password : for instance, considering Tunnel-Password is declared "string" in the dictionary :
If I have ClearTextTunnelPassword set, I must return \001password but if it is not set, I must reply 1:password which is quite confusing for the operating guys...

Regards

Laurent

(...)

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