[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

This thread should be moved to tcpdump-workers  since it is much more
important that they and winpcap agree on a common format and common
method to allow remote capturing and authentication  than ethereal
developers.

First one would have to decide, it is sufficient to just do
authentication  or is
integrity and / or privacy also required?

Second   do we need to support several types of authentication methods or is one
enough?  Since it is probably only a handful of apps that will ever
use this i think it would be sufficient to just use one single
authentication algorithm,    why not pick md5-hmac?

(hmac described in ftp://ftp.rfc-editor.org/in-notes/rfc2104.txt )


Then let us define a simple rpcap url :
rpcap://<ip-address>[:tcp-port][@username$password:<method>/<interface>[:filter]

let method be "md5-hmac" to start with. md5-hmac is initially the only
supported authentication method.

when the client connects to the server it passes the rpcap url over to
the server, everything
EXCEPT  the $password part of the string in the very first pdu.

If the client does NOT specify a @username:<method> and the server is
configured to require authentication, then the server will immediately
RST the connection  and fill in some ascii text in the payload of the
RST segment   something like "Authentication not offered by client but
required by server policy".

If the client does specify a @username:<method> but method is NOT the
string  md5-hmac, then the server will respond with RST the session
and adding a payload to the RST segment "Client authentication
mechanism <method> not supported by server"


Othervise the server generates a 512 byte block of random data and
sends back to the client.

Client then takes this random block of data, and the password  and
calculates the md5-hmac of it and passes it back to the server.

Server goes to some config file and reads the password for  username 
and repeats the same calculation of the block of random data and the
password.   If the hmac it gets back
from the client does not match the hmac it calculated itself it will
RST the connection
with the reason "authentication failed".

Othervise, everything is a-ok and we now proceed with the normal
exchange of rpcap packets.


The above would have to be wrapped into some sort of new command PDUs
for rpcap though,   and it would also have to be discussed with
libpcap people so they accept the solution as well.


Any specific authorization based on username is up to the server
application itself to decide on and should not be specified (user foo
can only capture from interface 5 on fridays between 7 and 9)



one could use something as simple as that.

when defining the pdu's please leave space/placeholders to also
negotiate integrity hash and privay if someone wants to add it in some
future.
i think just plain authentication is sufficient to start with.


see what tehy say    both md5 and hmac are very easy to implement.



On Wed, 16 Feb 2005 20:40:45 +0100, Fulvio Risso <fulvio.risso@xxxxxxxxx> wrote:
> 
> 
> > -----Original Message-----
> > From: ethereal-dev-bounces@xxxxxxxxxxxx
> > [mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of Lars Roland
> > Sent: mercoledì 16 febbraio 2005 11.01
> > To: Ethereal development
> > Subject: Re: [Ethereal-dev] ERTSP: Ethereal's RemoTe Sniffing Protocol
> >
> >
> > I've had recently a look at the rpcap documentation. It looks like it
> > can authenticate requests using a login and a password. However,
> > ethereal doesn't support this authentication scheme. We would have to
> > rewrite the windows version of ethereal's capture dialog, using
> > winpcap's new api. It would be good, if the libpcap and winpcap
> > developers could agree on a common api for this.
> 
> I'm completely open to suggestions for this.
> 
>         fulvio
> 
> 
> > Regarding Luis' idea of using display filters on the remote site,
> > perhaps tethereal can be used for that. Can tethereal write the captured
> > file to a pipe? Then a perl script running on the remote host (the ERTSP
> > server) could take the capture file from tethereal and send it to the
> > local client.
> >
> > ronnie sahlberg schrieb:
> > > i belive  rpcap takes a pcap style capture filter which it applies
> > > locally before transmitting all packets that passes across to the
> > > capture client.
> > >
> > > problem is that rpcap is totally insecure and can not be used in any
> > > production environments for that reason.
> > > adding an authentication phase with some simple mechanism such as chap
> > > should not be too difficult.
> > >
> > >
> > >
> > > On Mon, 14 Feb 2005 18:27:51 +0100, LEGO <luis.ontanon@xxxxxxxxx> wrote:
> > >
> > >>Again, my intention is not just to remotize the capture process, it is
> > >>to create intelligent probes.
> > >>Probes that might be able even to filter transactions (for
> > example using MATE).
> > >>
> > >>I think in telephony (my field) where I could put few different probes
> > >>arround the network and  be able to trace a sigle call's signalling
> > >>without transporting more frames than necessary.
> > >>
> > >>
> > >>On Mon, 14 Feb 2005 17:46:16 +0100, Gianluca Varenni
> > <varenni@xxxxxxxxx> wrote:
> > >>
> > >>>Hi.
> > >>>
> > >>>What about the remote capture features of WinPcap? WinPcap is able to
> > >>>capture from remote machines, and the code for the remote
> > capture runs on
> > >>>windows and Linux (I'm not sure about BSD).
> > >>>
> > >>>More details can be found here
> > >>>
> > >>>http://winpcap.polito.it/docs/man/html/group__remote__help.html
> > >>>
> > >>>Have a nice day
> > >>>GV
> > >>>
> > >>>
> > >>>----- Original Message -----
> > >>>From: "John McDermott" <jjm@xxxxxxxxxx>
> > >>>To: "LEGO" <luis.ontanon@xxxxxxxxx>
> > >>>Cc: <jjm@xxxxxxxxxx>; "Ethereal development"
> > <ethereal-dev@xxxxxxxxxxxx>
> > >>>Sent: Monday, February 14, 2005 5:25 PM
> > >>>Subject: Re: [Ethereal-dev] ERTSP: Ethereal's RemoTe Sniffing Protocol
> > >>>
> > >>>
> > >>>>>>>The Idea is a protocol to have sniffing clients and a
> > sniffing servers
> > >>>>>>>communicate. Part like RTSP, and part like RTP+RTCP with
> > >>>>>>>retransmissions.
> > >>>>>>
> > >>>>>>This sounds really cool and well thought out.  Maybe I'm missing
> > >>>>>>something, though.  What about RMON? Yes, it has another filtering
> > >>>>>>language and yes, it is not "real time" in the sense that
> > Ethereal is,
> > >>>>>>but
> > >>>>>>mightn't it be an appropriate solution?  Then, Ethereal could
> > >>>>>>inter-operate with existing probes and so forth.
> > >>>>>
> > >>>>>The point is to be able to use display filters on the remote probe
> > >>>>>before packets are transmitted.
> > >>>>
> > >>>>Well, RMON does that, but it uses its own filtering language,
> > and if we
> > >>>>want true Ethereal display filters, then, of course RMON is
> > out (unless we
> > >>>>were to create a private filter MIB, I suppose...).  I just thought
> > >>>>interoperability might be useful.  I'm not convinced RMON is
> > better than
> > >>>>your proposal, BTW, I just wanted to offer the thought.
> > >>>>
> > >>>>We discussed this in 1999/2000 so you might want to check the
> > archives for
> > >>>>that discussion, too.
> > >>>>
> > >>>>--john
> > >>>>
> > >>>>_______________________________________________
> > >>>>Ethereal-dev mailing list
> > >>>>Ethereal-dev@xxxxxxxxxxxx
> > >>>>http://www.ethereal.com/mailman/listinfo/ethereal-dev
> > >>>>
> > >>>
> > >>>_______________________________________________
> > >>>Ethereal-dev mailing list
> > >>>Ethereal-dev@xxxxxxxxxxxx
> > >>>http://www.ethereal.com/mailman/listinfo/ethereal-dev
> > >>>
> > >>
> > >>_______________________________________________
> > >>Ethereal-dev mailing list
> > >>Ethereal-dev@xxxxxxxxxxxx
> > >>http://www.ethereal.com/mailman/listinfo/ethereal-dev
> > >>
> > >
> > >
> > > _______________________________________________
> > > Ethereal-dev mailing list
> > > Ethereal-dev@xxxxxxxxxxxx
> > > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> > >
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> 
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>