Re: Removing T/TCP and replacing it with something simpler
From: Andre Oppermann (andre_at_freebsd.org)
Date: 10/21/04
- Previous message: Mike Silbersack: "Re: Removing T/TCP and replacing it with something simpler"
- In reply to: Mike Silbersack: "Re: Removing T/TCP and replacing it with something simpler"
- Next in thread: Garrett Wollman: "Re: Removing T/TCP and replacing it with something simpler"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 21 Oct 2004 17:35:26 +0200 To: Mike Silbersack <silby@silby.com>
Mike Silbersack wrote:
>
> On Thu, 21 Oct 2004, Andre Oppermann wrote:
> > o The client has to enable the option in the TCP SYN request to the server.
> > If the server accepts it, then it returns a unique cookie generated from
> > the IP address of the client and some random seed. On subsequent
> > connections
> > the client will include the cookie in the TCP SYN request and it will
> > send the first chunk of payload in the SYN packet. If the cookie matches
>
> I think that it would have to be slightly more complex than that for it to
> be secure. Instead of using syncookie/RFC1948-like generation, just
> randomly generate the cookie and store it in the tcp host cache. Then
> steal the concept of NQNFS leases, giving the cookie a limited lifetime,
> after which it must be reissued. I think you'll need to track two cookies
> on the server side, to gracefully handle the cookie transition period...
It wasn't meant to use the exact syncookies code, but the general mechanism
like your description of it. We can't use syncookies and that code as is
anyway because it puts far more information into the cookie.
> Well, I'm sure there are many ways to do it, but I agree that it's
> certainly doable; we have plenty of time to talk about the exact
> implementation. My reason for avoiding the use of syncookies/RFC1948 in
> the implementation is that relying on those pieces of code makes a FreeBSD
> implementation easy, but would make an implementation in other OSes
> potentially difficult.
-- Andre _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Mike Silbersack: "Re: Removing T/TCP and replacing it with something simpler"
- In reply to: Mike Silbersack: "Re: Removing T/TCP and replacing it with something simpler"
- Next in thread: Garrett Wollman: "Re: Removing T/TCP and replacing it with something simpler"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: Chicken and egg issue with Cookie based login?
... >> Cookies are created by the server, not by the client. ... a
client can create a cookie as well. ... The credentials are created when the user
logs into the server. ... (comp.security.misc) - Re: If not readdir() then what?
... Please go read the NFS spec. ... The only thing an NFS client has in
order ... filehandle and a cookie as its arguments. ... The server is expected
to return cookies for _each_ ... (Linux-Kernel) - Re: Removing T/TCP and replacing it with something simpler
... >> o The client has to enable the option in the TCP SYN request to the
server. ... >> If the server accepts it, then it returns a unique cookie generated
from ... (freebsd-net) - Re: Getting 12209 error on isa when server tries to connect to cookie enabled site. Xp workstation w
... and closed all handles to the original winhttp.dll on the win2003 server. ...
This cookie is after an internal 302 redirect transmitted to the server ... First the client
situation ... 2.The conclusion is that when Cookie header is sent from the server to
... (microsoft.public.isa) - Re: Chicken and egg issue with Cookie based login?
... a client can create a cookie as well. ... So in reference to the W3C
document, this MAC is created by the server? ... a new client created hashed cookie to
pass the credentials to the server. ... (comp.security.misc)