RE: data origin authentication

[Christina Helbig <cbh@zyfer.com>]

Hello, Joern
if you are a bad guy and you own a in-bound SA you can produced a faked ESP
packet that looks like its come from the other party of your in-bound SA.
Then you can claim that you got this packet from the other party. So the
data origin authentication of ESP (two parties know the same authentication
key) don't deliver non-repudiation of data origin.  But a receiver can be
sure that the sender of an incoming ESP packet is only the other party of
the related in-bound SA or the receiver itself. For this proof, I guess, the
receiver needs only <dst IP address, protocol (ESP), SPI> to find the
related SA and the related authentication key. The receiver proofs the
authentication value and this proof delivers the answer, if the sender has
the identity the sender claimed. The check against the ip address of the
sender saves time (if you do it before) and is a MUST but for the data
authentication not really necessary. But I'm also a newcomer in IPSec and
may be I'm wrong.
Christina

> -----Original Message-----
> From: Joern Sierwald [mailto:joern@f-secure.com]
> Sent: Tuesday, May 07, 2002 8:21 AM
> To: ipsec@lists.tislabs.com
> Subject: Re: data origin authentication
> 
> 
> At 16:29 07.05.2002 +0200, you wrote:
>  >Hello All,
>  >
>  >In rfc 2406 "IP Encapsulating Security Payload", and also in
>  >draft-ietf-ipsec-esp-v3-02.txt,
>  >I read: "EPS is used to provide confidentiality, data 
> origin authentication,
>  >connectionless integrity,
>  >an anti-replay service (a form of partial sequence 
> integrity), and limited
>  >traffic flow confidentiality.
>  >The set of services provided depends on options selected at 
> the time of
>  >Security Association (SA)
>  >establishment and on the location of the implementation in a network
>  >topology."
>  >
>  >I have been reading more carefully through the rfc (not 
> through the draft
>  >yet). I is correct to say
>  >that if ESP is used in transport mode, there is no data origin
>  >authentication? I would say this because
>  >the IP header, containing the source IP address is not 
> authenticated.
>  >Or am I missing something here?
>  >
>  >
>  >Greetings,
>  >
>  >Stefan.
> 
> I guess you are missing something. You receive an ESP packet. 
> By looking up
> <dst IP address, protocol (ESP), SPI> you find the IPsec SA.
> 
> Now, since you negotiated the SA for transport mode, the SA data will 
> contain the
> remote IP address. The SA entry states "<dst addr 1.2.3.4 
> (that's us), ESP, 
> SPI 0x61782395>, that
> should come from 5.6.7.8". And if it doesn't, you can discard 
> the packet.
> 
> Or, to explain it in another way:
> 
> Transport mode: src IP address is the same for all packets. 
> Easy to check.
> Tunnel mode: src IP addresses (inner header) can vary. 
> Therefore is must be 
> authenticated.
> 
> Jörn
> 
> 
>