[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments on AH and ESP drafts


It's possible that I may have more comments after I finish 
reading the other drafts and correlating them back to these
drafts. 

I haven't had the cycles to read all of the recent email discussing 
the drafts, so if there is duplication here, sorry about that.

I understand that some of the things that I'm commenting on have
probably existed in the drafts for some time; unfortunately I don't
always catch these, even with doing detailed reads ;-(. 

- C



Many of these comments apply to both drafts, so I'll list those
first.


1. Put in the boilerplate paragraph from RFC2119 (the one stating
that readers should refer to 2119 for the definitions for MUST, etc.).
[All of us should simply stick that paragraph into our respective
documents and be done with it.]

2. Replay: in general, I had thought that the compromise proposal
(receiver notifying sender of replay support) seemed reasonable.
However, now as I read the specifics that have been put into these
drafts, I want to revisit the topic.

As a NOTIFY message is not a "guaranteed delivery" message, 
having the sender simply not do a sequence number rollover check
because it didn't receive said message is a bad idea. The responder
may have been a good citizen and sent the notify, but something
may have prevented its delivery.

I personally think it would be much cleaner for the sender to 
assume that the receiver will enforce replay, and assume that
when the sender cycles through the sequence number space, if 
the sender does not force the creation of a new SA, that the receiver
will drop packets (and audit) when it detects said cycling. 

The only place where the sender should not perform such a rollover
check is for manually-keyed/installed/whatever SAs. 

If the receiver so chooses, it can still notify the sender of 
support (or better yet, lack thereof) for replay. 

3. Size of authentication data: scattered throughout these drafts
is the mention of "if algorithm yields more than 96 bits, the output
is truncated".

While it's been agreed to be approrpriate (and a good idea 
cryptographically) in the context of the HMAC auth algorithms, 
this may be completely off-base for any other type of auth algorithm.
Yes, there has been a desire to limit the number of combinations
of variables; I think we've been addressing that with the algorithm
drafts. But I don't think we've intended it to be a universal 
rule.

I think it's OK to state that the *default* auth data size is 96
bits, but remove the text that seems to indicate that 96 bits is the
*only* size. [The main transform layout text is reasonably general
in this regard -- we could talk about the default size there if so
desired. Or if we don't talk about a default size, maybe we should 
remove the reference to "96 bits is the default auth data size as
is stated in the base drafts" from the auth algorith drafts ;-).]

4. In the section on ICV verification, instead of the specific 
reference to 96 bits: replace with text saying "compare the result
with the saved value, using the comparison rules defined by the
authentication algorithm specification."


5. In the section on sequence number verification, the first 
sentence should state: "though its use may be enabled or disabled
by the receiver on a per-SA basis."

6. Nesting of transforms. I know this was a topic on the list a
while back, but I didn't have the cycles to think much about it,
beyond having some nagging feeling about it that I couldn't put
into words. 

(a) There are words to the effect of "the security policy MUST
define the order of transforms". That's fine, but there's a good
chance that I can't *negotiate* this with my peer. 

Why? From what I can tell, there is not a universal assumption of
order in specifying the transforms in the proposal. In other 
words, "AH + ESP" is considered to be the same as "ESP + AH" for
most implementors, meaning that the packets will be encapsulated
as IP + AH + ESP.  

How will I be able to specify to my peer my desired order of 
 IP + AH + ESP + ESP + AH, for example? 

Removing the ordering requirement would be a bad idea, I think.
As a receiver, who only knows that I need to do (2 AHs and 2 ESPs),
I may have to do a significant amount of unnecessary processing
before determining that this was a malformed packet. As a receiver,
it would be in my best interest to enforce a ordering, so if that 
first ESP was followed by an AH in the above example, I could declare
the packet to be in error and not work on it anymore. 

(b) This nesting seems to only be specified for transport mode. Why is
that? I can't convince myself of the usefulness of the general case, 
so I can't see where it's useful for one mode but not the other. 

(c) If there *is* going to be nesting such as above, the AH draft
should be more careful about specifying the scope of the authentication
calculation. Actually, it may be cleaner to remove the discussion
of "ignoring the outer IPSEC headers in the AH calculation", and 
simply treat this as an interative process, where the AH is 
calculated on the "full" packet at the point of header insertion. Right
now the supporting text on AH calculation is "partially" sensitive
to nesting, but the concept is not consistently applied (some of 
the text refers to "partial" while other text refers to the full
packet). 

[If a simple iterative approach is taken, it needs to be noted that as
AH headers are "consumed" by the receiver, the ip->tl of the outer
header *must* be adjusted so that the inner AH calculations are 
successful.]

(d) I haven't understood the reasons *why* for such a nesting 
between the same source and destination IPSEC system. I can 
understand nesting of the type where one of the endpoints varies
between the "inner" and "outer" nesting (for example, where a system
that is an endpoint for both an IPSEC transport mode connection as
well as an endpoint for an intervening tunnel: it builds a transport 
mode IPSEC packet to send to its final destination, but then has to 
reencapsulate it in tunnel mode to get it through the tunnel). But
this particular style of nesting hasn't made sense to me.

>From what I recall of the previous discussion, there wasn't much
justification as to why this was desirable/needed, it seemed to
be more along the line of "this could be an OK thing to do". The
complexity of this worries me, and if we do support it, it needs
to be better fleshed out, IMO.

(e) In the AH draft, in the section on outbound packet processing,
the last paragraph worries me. Especially the last sentence: "(While
a native IP or bump-in-the stack implementation could predict the
contents of later IPSEC headers that it applies itself, it won't
be possible for it to predict any IPSEC headers added by a 
bump-in-the-wire implementation between the host and the network.)"

I interpret this as a single IPSEC endpoint (single IP address) has
multiple entities adding IPSEC headers to a single packet that is
going to the same destination. These headers may or may not be 
separated by intervening IP headers.

My issues: (1) given the above, how does this all get coordinated 
via ISAKMP? Separate negotiations won't work, as the receiver won't 
know that these are linked together, and won't build the correct 
sequence of headers for the return trip. (2) If I was worried 
about the general complexity of nesting before, I'm much more
worried after reading this.



Now for comments specific to the ESP draft:

1. Section 2, footnote to packet layout: here we state that the
cryptographic synchronization data is a part of the Payload Data
(fine), but elsewhere we state that the padding is done taking the
size of the payload data field into account. 

That's OK if the (explicit) IV size is the same as the block size, but 
if it isn't, that could result in incorrect padding processing. 

The text that talks about padding processing should be more explicit
in saying that the size of the Payload Data for padding purposes
includes only the "to be encrypted data" portion of the Payload Data, 
or "everything except the IV".

2. Section 2.4 states that the Pad Length and Next Header fields
should be right-aligned within a 4-byte word. Why? They will be
stripped off of the end of the decapsulated packet. The reason 
given is that the ciphertext should terminate on a 4-byte boundary.
To me, the only reason that I could come up with is to force 
alignment of the following authentication data field. Whether or
not this is the case, some rationale for this padding requirement
should be given.

3. While on the subject of alignment: I don't see a discussion of
wanting to ensure that the *start* of the ciphertext should be 
aligned on a 64-bit boundary for IPv6 packets. In other words,
32-bit inline IVs may not be a good thing. If the IPv6-knowledgeable
folks can give an opinion on this, and if they do strongly encourage
alignment, something should be stated to make this a requirement
for cipher algorithm writers (either in the ESP draft itself or
the framework document).

4. Section 3.3.4. Insert the following (text in parenthesis):

"implicit padding MUST be appended to the end of the ESP packet
(logically after the Next Header field), prior to ICV"

5. Section 3.4.5, bullet item 2: if the receiver knows what the
padding values will be (e.g. the WK padding is used), the receiver
may check the padding values instead of simply ignoring them. 
Someone argued that using a WK padding scheme would help to
check for decryption failures.

6. Section 3.4.5, paragraph starting "If authentication has been
selected, ICV verification SHOULD be performed before decryption."

This statement could be misconstrued. I think the intention is
that the ICV verfication MUST be completed before the decryption
completes, in the case where the steps are run in "parallel".

7. Same section: dicussion of detection of decryption failures
could mention the use of the padding check.
Follow-Ups: