RE: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-related Security issues) (Templin, Fred L)

["Templin, Fred L" <[e-mail]>]

Hi Sreenatha,

You are right that the draft needs to be clarified on this point. The
answer is that whether or not there is a shared secret key the
destination node can validate or not validate the signature as it
deems fit. If the destination willl not validate the signature, then it
simply ignores the SEAL option and processes the next option.

If the destination sees the SEAL option as an unknown option
type, then it should ignore the option and process the next
option. This would seem to indicate that the SEAL digital signature
should appear as a Destination Option and not as its own header
extension, because the destination would discard any packet with
an extension header having an unknown "Next Header" value. I
will update the draft with these changes.

Thanks - Fred

________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Sreenatha setty
Sent: Thursday, January 12, 2012 8:45 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-related Security issues) (Templin, Fred L)


Hi Fred,

      In the draft, the behavior of destination node in processing the SEAL header is need to be cleared.  If nodes are not exchanging symmetric key and it received SEAL extension header packet and the packet is not ICMPv6 error packet, how destination node should process the SEAL header? It should simply ignore the SEAL header and go to next header processing or it should try to validate the signature in SEAL header?



Thanks - Sreenatha



-----------------------------------------------------

From: "Templin, Fred L" <[e-mail]>

To: Sreenatha setty <[e-mail]>, "[e-mail]"

      <[e-mail]>

Cc: "[e-mail]" <[e-mail]>

Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header

      (was:Fragmentation-related Security issues)

Message-ID:

      <[e-mail]>



Content-Type: text/plain; charset="us-ascii"



Hi Sreenatha,



Since posting my message, I have submitted an actual draft that deprecates

the list-posted pre-draft:



https://datatracker.ietf.org/doc/draft-templin-sealopt/



The posted version makes the observation that the source can use the SEAL

option either in coordination with the destination (in which case the source

includes a digital signature that the destination can verify) or independently

from the destination (in which case the source can include any type of

signature it likes). Your question seems to stem from the former case:



> 1. SEAL IPv6 extension header functionality is similar to AH header functionality

> which is already standardized in RFC 2402(IP Authentication Header). AH header

> also calculates the ICV of the packet [Section 3.3.3.1.2 ICV Computation for IPv6

> in RFC 2402] which is used to check the integrity of the packet. So what is the

> advantage of using SEAL header over AH header?



When the source and destination share a secret key used for digital signature

calculation and verification, it is true that SEAL somewhat resembles AH.

However, the SEAL source only calculates the digital signature over the leading

128 bytes of the packet beginning with the SEAL header itself. So, unlike AH,

the digital signature does not cover the entire packet and does not cover a

pseudo-header of the IPv6 header.



This has two important implications. First, when a router on the path needs to

drop an IPv6 packet with a SEAL option and return an ICMP error message, the

packet-in-error within the ICMP will include enough of the leading portion  of the

SEAL packet so that the source can verify that the ICMP was generated by an

on-path router. The same is not true for AH, since the AH ICV covers the entire

packet, and the packet-in-error field within the ICMP message may not include

the entire packet. Second, the digital signature will remain valid even if the IPv6

header is subject to network address translation.



------------------------------



Message: 3

Message-ID: <[e-mail]>



ight

weight data origin authentication and integrity checking capability for the

leading 128 bytes of the packet. The Identification field additionally prov=

ides

the destination with a means to detect replayed packets. Note that this

provides less authentication assurance than AH, since a middlebox on the

path could alter the "tail" of the packet beyond the leading 128 bytes. But=

,

it defeats off-path spoofing attacks.



Note again that, when the source and destination are not engaged in a

digital signing and verification relationship, the source could sign the

message any way it wants, e.g., by writing a constant or time-varying

nonce. In that case, the destination would be vulnerable to an off-path

attacker guessing the nonce and hence should not use the nonce as

a data origin authentication signature.



Thanks - Fred



PS The number 128 was chosen so that enough of the packet would be

included to provide sufficient inter-packet diversity in calculating the di=

gital

signature. However, I could also see an arguement for a smaller number,

e.g., 64, 80, 96, etc.