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

Re: Comments on AH and ESP drafts

Cheryl,

	Thanks for the detailed feedback on the AH and ESP specs.  Below
are responses to your comments:



>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.]

Yes, that will be done.

>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.

The ultimate responsibility for preventing replay lies with the receiver,
so even if the NOTIFY is lost (in the current design), the receiver will
not accept messages that appear to be replayed, even if they are just the
result of counter overflow at the sender.  Note that the AH and ESP specs
don't call for counter overflow to trigger creation of a new SA; the
counter overflow check is primarily an input to the audit mechanism and a
backup to reduce the likelihood that packets will be sent that will be
rejected.  (Can't one cause the sender to create a new SA  based on an
algorithm-specific packet count trigger that is independent of sender
checking of the AR counter?)

Consider both choices of defaults for the sender:  if the default is AR OFF
(no counter checking), then the sender may continue to send packets while
the receiver rejects them, and some trigger must be invoked to create a new
SA to fix the problem; if the default is AR ON, then the sender may stop
sending packets prematurely (given that the receiver was not checking) and
some trigger must be invoked to create a new SA, as above.  (But, to make
this second default work one would have to special-case manual keying,
which makes it not so clean ...) So the current text adopts the first
default and uses NOTIFY to increase the likelihood that the sender and
receiver have the same AR status notion, but it's imperfect because the
NOTIFY is unreliable (and because sending the NOTIFY is a SHOULD, not a
MUST).

Without a reliable assertion of the receiver's AR status to the sender, we
can only err in one direction or the other.  If, on the other hand, we
could have AR OFF as the default (to satisfy the manual keying case), the
sender could negotiate AR ON, and the receiver could accept or reject the
proposa.  Then we would have a reliable, deterministic way for both ends to
know the AR status and avoid these problems. We can live with the
uncertainty implied by either of the non-negotiated choices, on the
assumption that sender overflow is rare, i.e., lots of packets have to be
sent before the problem arises.  This is consistent with other design
decisions we're making in IPsec, e.g., the race conditions in ISAKMP that
have been discussed recently.  Absent a compelling reason to choose one
default vs. the other, let's stick with what we have now.

>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 ;-).]

Yes, this has been pointed out and has been changed.  The 96-bit size is
applicable to the default authentication algorithms, but other algorithms
may define other auth data lengths.

>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."
>
Good point.  For a public key auth algorithm, the comparison procedure
would be different.

>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."

The "per-receiver" clarification is appropriate and we'll make the change.

>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.

Yes, there has been a lot of traffic on this topic, but I'd still rather
spend the time to get it right, so your comments are still important.

>(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.

Then maybe this is a limitation of ISAKMP that needs to be addressed.  Just
as you have found it hard to find the time to review the AH and ESP specs,
as the folks who have rewritten them (and the arch doc) from scratch, we've
found it hard to make the time to review the ISAKMP, Oakley interpretation,
and the IPsec DOI documents. There is a difference between the security
functions afforded by different orderings of AH and ESP, so I think we need
to be able to express the ordering requirements of the entity that will be
sending traffic over the SA being established.

>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.

Agreed.

>(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.

We'll review the wording.  Arbitrary nesting is an issue for both tunnel
and transport modes, but transport mode is more complicated when the same
IP header is covered by multiple layers of AH.

>(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.]

Charlie Lynn expressed the same notion in one of his messages, in response
to a question from a WG member about how to do the processing.  We'll make
sure the final text expresses this notion of intertive processing and
"discarding" of "consumed" headers at the receiver, if we retain the
arbitrary nesting facility.

>(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.

I have mixed feelings about this myself.  I'm not in favor or arbitrary
nesting, because of the potential complexity, but Charlie and a few other
folks have argued in favor of allowing it, e.g., to accommodate the use of
an outboard BITW implementation in conjunction with an integrated IPsec
implementation, when each was ignorant of the presence of the other.  I'd
prefer to establish a limited set of ordered combinations of AH and ESP, in
tunnel and transport modes, tailored to demonstrable, agreed upon host and
gateway requirements.  But, the WG has to decide on this and the traffic
favored the sort of unconstrained nesting that Charlie proposed, so ...

>>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.

The major motivation cited is a clause in the IPv6 spec about repeated
extension  headers, and the generic "be conservative in what you send but
liberal in what you accept" admonition (attributed to Jon Postel).

>(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.

See the example cited above as a motivation for this text.

>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.
>
Interesting point.  Whether the other end can build the correct sequence of
headers for the return path would be a function of how the packets were
mapped onto the SAs that all terminate at the same endpoint.  I gather the
argument is that unless multiple SAs are negotiated at the same time in
ISAKMP, there is no way for IPsec to link together the SAs, even if they
specify all the same selectors for outbound traffic.  We need to resolve
this, and that may provide a rationale for being more restrictive in
allowable IPsec header nesting.

>
>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".

Good point.  We'll reword to emphasize that the padding (for encryption
algorithm purposes) computation applies to the plaintext portion of the
payload, exclusive of the IV (if present).

>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.

Yes, the rationale is for alignment of the authentication data field.  We
can add that rationale.

>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).

For some IV-based modes of operation, the receiver treats the IV as the
start of the ciphertext, feeding it into the algorithm directly.  In these
modes, alignment of the start of the (real) ciphertext is not an issue at
the receiver.  This is an issue that needs to be addressed on a
per-algorithm basis, and might even be per-implementation in reality, so
other than a note about the possible pitfalls here, I'm not sure what to do.

>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"

OK, we will clarify the position of the implicit padding.

>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.

I think the agreement has been that checking for WK padding was optional at
the receiver.  We didn't require checking as that really is not a
decryption failure but rather a (generally weak) form of integrity
checking.  Since we have an explicit integrity/authentication facility, the
WG wanted to downplay the use of this field for that purpose.  We can
revise the text in this bullet to state that inbound processing of the
padding is specific to the encryption algorithm spec, instead of just
calling for the padding to be removed.

>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".

Good point.  We want to allow parallel decryption and authentication and a
note to that effect will be included.

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

See my comments above about decryption failures vs. integrity check failures.

Steve
Follow-Ups: References: