Subject: Re: [IPsec] IPSec, ESP and AH authentication

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 10 Oct 2007 08:39:01 -0700 (GMT-07:00)

As Srinivasa points out, changes to the source IP really are irrelevant. Data origin authentication has nothing to do with IP addresses - it has to do with _endpoints_, which may be applications, people, etc. 

IP addresses can change, but presumably, only the authorized, authenticated endpoint has the appropriate keys with which to assert the originating identity.

-----Original Message-----
>From: ns srinivasa murthy <[email-masked]>
>Sent: Oct 10, 2007 12:47 AM
>To: "Steven M. Bellovin" <[email-masked]>, Tjeu <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [IPsec] IPSec, ESP and AH authentication
>
>
>In tunnel mode ESP ,the inner IP header is protected and as such no 
>one can change the source IP in between.This inner IP packet is the 
>actual data packet and its source IP can not be changed.So Data 
>origin Authentication is supported in tunnel mode ESP.
>
>Even if the outer Source IP is changed in between,the attacker can 
>not do any harm.The implementation has to take care that the out 
>going ESP traffic is sent only to the tunnel end point detected as 
>part of IKE negotiation.
>
>-nsmurthy
>
>At 05:13 AM 10/10/2007, Steven M. Bellovin wrote:
>>On Tue, 9 Oct 2007 06:26:57 -0700 (PDT)
>>Tjeu <[email-masked]> wrote:
>>
>> >
>> > Dear All,
>> >
>> > As you might know, IPSec ESP authentication does not authenticate the
>> > destination and source
>> > addresses of the IP header, whereas the IPSec AH authentication
>> > does(i.e. calculatec MAC over them). However, both claim that they
>> > offer data origin authentication. It is not clear for me how the ESP
>> > authentication offers data origin authentication, as the MAC is not
>> > computed on the source and dest addresses. Therefore the attacker
>> > could easily modify them. Am I missing something ? I would be
>> > thankful if anyone could provide links where I could read regarding
>> > this subject, in more details. I looked through some RFC's but they
>> > dont seem to help.
>> >
>>Put the IP addresses in the SPD, and derive that in turn from the
>>authenticated identity.  If the attacker modifies them, the packet will
>>be dropped because it won't match the SPD.
>>
>>
>>                 --Steve Bellovin, http://www.cs.columbia.edu/~smb
>>
>>
>>_______________________________________________
>>IPsec mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/ipsec
>
>
>********************************************************************************
>This email message (including any attachments) is for the sole use of the intended recipient(s) 
>and may contain confidential, proprietary and privileged information. Any unauthorized review, 
>use, disclosure or distribution is prohibited. If you are not the intended recipient, 
>please immediately notify the sender by reply email and destroy all copies of the original message. 
>Thank you.
> 
>Intoto Inc. 
>

_______________________________________________
IPsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Dunn, Jeffrey, CTR, OASD(HA)/TMA" <[email-masked]>
Date: Wed, 10 Oct 2007 12:56:17 -0400

Scott,

While data origin is IP (v4 or v6) address agnostic from the point of
view of user data, e.g., e-mail, it can be important to routing
protocols.  This is especially true for IPv6, where the OSPFv3 router ID
is no longer an IP (v4) address, it is just a 32 bit unsigned integer.
As a result, ESP-Null authenticated packets can be re-played with a
different source IPv6 address.  This will cause some obvious and nasty
problems.  Putting IPv6 addresses in the SPD will, of course, mitigate
this problem, but with a 16 octet IPv6 address, this is cumbersome and
error prone.  As a result, it is more expedient to use AH.

Best Regards,

Jeffrey Dunn

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Wednesday, October 10, 2007 11:39 AM
To: Tjeu
Cc: [email-masked]
Subject: Re: [IPsec] IPSec, ESP and AH authentication

As Srinivasa points out, changes to the source IP really are irrelevant.
Data origin authentication has nothing to do with IP addresses - it has
to do with _endpoints_, which may be applications, people, etc. 

IP addresses can change, but presumably, only the authorized,
authenticated endpoint has the appropriate keys with which to assert the
originating identity.

-----Original Message-----
>In tunnel mode ESP ,the inner IP header is protected and as such no one

>can change the source IP in between.This inner IP packet is the actual 
>data packet and its source IP can not be changed.So Data origin 
>Authentication is supported in tunnel mode ESP.
>
>Even if the outer Source IP is changed in between,the attacker can not 
>do any harm.The implementation has to take care that the out going ESP 
>traffic is sent only to the tunnel end point detected as part of IKE 
>negotiation.
>
>-nsmurthy
>
>>On Tue, 9 Oct 2007 06:26:57 -0700 (PDT) Tjeu 
>><[email-masked]> wrote:
>>
>> >
>> > Dear All,
>> >
>> > As you might know, IPSec ESP authentication does not authenticate 
>> > the destination and source addresses of the IP header, whereas the 
>> > IPSec AH authentication does(i.e. calculatec MAC over them). 
>> > However, both claim that they offer data origin authentication. It 
>> > is not clear for me how the ESP authentication offers data origin 
>> > authentication, as the MAC is not computed on the source and dest 
>> > addresses. Therefore the attacker could easily modify them. Am I 
>> > missing something ? I would be thankful if anyone could provide 
>> > links where I could read regarding this subject, in more details. I

>> > looked through some RFC's but they dont seem to help.
>> >
>>authenticated identity.  If the attacker modifies them, the packet 
>>will be dropped because it won't match the SPD.
>>
>>
>***********************************************************************
>********* This email message (including any attachments) is for the 
>sole use of the intended recipient(s) and may contain confidential, 
>proprietary and privileged information. Any unauthorized review, use, 
>disclosure or distribution is prohibited. If you are not the intended 
>recipient, please immediately notify the sender by reply email and
destroy all copies of the original message.