[e2e] where to put endpoint authentication?

[RJ Atkinson]

On May 07, 2004, at 14:24, Joe Touch wrote:
> 	2) do transport protocols need authentication?
>
> 		current transport authentication - cookies, MD5
> 		signatures, etc., protect against off-path spoofing

TCP MD5 provides pretty reasonable protection on the wire,
but lacks dynamic key management (lacks it for now; this is fixable).
TCP MD5 protects against both on-path and off-path forgery --
if anyone thinks it doesn't protect both, please explain why not
on the list.

UDP lacks anything equivalent to TCP MD5.  I'm not sure about SCTP,
though its threats are probably greater than for TCP.

ASIDE:  IETF's so-called "Transport Layer Security" is actually at
the application-layer, not at the transport-layer, and hence
does nothing for the transport-layer security issues.

Transport-mode IPsec (where IPsec == {AH, ESP}) provides
transport-layer security.  Tunnel-mode IPsec provides network-layer
security.  IPsec is supported by key management from IKE.
(NB: In my terminology, IKE is not "IPsec" but is instead a
separate key management protocol that could be used for protocols
unrelated to IPsec.  Terminology varies widely for "IPsec".).

As far back as August 1995, BSD Sockets API code existed at NRL
(probably still available via MIT :-) that let an application:
	- specify (setsockopt()) what security properties the application
		desired from the operating system (and networking stack)
	- learn from the kernel (getsockopt()) what security properties
		were actually being provided
That API, unfortunately, is not widely implemented even today
as far as I know.  If it were widely implemented, then application
authors could use IPsec at either transport-layer or the network-layer
for protection against forgeries at either layer respectively.

Some such IPsec API needs to be openly specified and widely implemented
before that API becomes widely useful.  (I'm being very careful here
to NOT use the word "standard" anyplace, because it really does not
matter if it is officially sanctioned so long as its widely available.)

> 		such spoofing relies on forgery of several values:
> 			- IP source/dest addresses
> 			- TCP ports/sequence numbers
>
> 		such attacks can be considered either:
> 			- primarily network forgery
> 			- forgery at both network and transport layers

If something is forging TCP header or TCP data information,
		then it is a kind of transport-layer attack.
If something is forging IP header information,
		then it is a kind of network-layer attack.
If it is doing both, then it is forgery at both layers.

> 		where is protection more appropriate/useful?
> 			- network (IMO)
> 			- transport
> 			- both are needed

There are a number of papers on placement (layering) of security
services.  These are sometimes referred to in the security community
as "layer wars papers".

I believe the only rational answer is that a networking protocol suite
needs to provide mechanisms at several layers and let operating system/
application designers and implementers select the level of protection
that is appropriate for the information being conveyed over the network.

> 	3) are cookies reasonable authentication for transport layers?

I would not call cookies "authentication", but maybe that is just me.

The big threat is often the insider threat.  Insiders often can easily
wiretap along-the-path.  Any party that can wiretap along-the-path
will find cookies annoying but will still be able to forge packets.
So the probability is that the major threats won't be deterred with
cookies.

Ran
rja at extremenetworks.com