Subject: [IPsec] Question about AUTH payload

From: Joy Latten <[email-masked]>
Date: Thu, 01 Jul 2010 13:02:20 -0500

I have a question about RESERVED field and its influence on 
AUTH payload.

Suppose responder sends and IKE_AUTH message whose IDr payload has 1's in
the RESERVED field instead of 0's. 
(I know rfc says no to this, but this is in regards to
an IKEv2 TAHI testcase that tests implementation's response to 
receiving 1's in RESERVED fields of IKE_AUTH message.)

I understand that in section 2.5 it states,
  "Also for forward compatibility, all fields marked RESERVED MUST be
   set to zero by an implementation running version 2.0, and their
   content MUST be ignored by an implementation running version 2.0 ("Be
   conservative in what you send and liberal in what you receive")."

However, when computing the AUTH payload in the IKE_AUTH message, the
value prf(SK_pr, IDr) will be appended.
ikev2bis breaks this down in section 2.15, 

   ResponderIDPayload = PayloadHeader | RestOfRespIDPayload
   RestOfRespIDPayload = IDType | RESERVED | RespIDData
   MACedIDForR = prf(SK_pr, RestOfRespIDPayload)

I am thinking it can be concluded that responder computed MACedIDForR with
1's in the RESERVED field.

My confusion is how should initiator handle this?
When section 2.5 says "content MUST be ignored", I am not sure how
to interpret because the RESERVED field is now part of the MAC.

Initiator needs to compute MACedIDForR to verify the MACedIDForR 
he received from responder. Should he use the IDr payload responder sent
with 1's in RESERVED field?
Or does "ignoring content" of RESERVED field mean initiator
can safely assume/build the IDr payload using 0's for RESERVED field
when he computes MACedIDForR? Of course in this case the authentication
will fail... would that be expected behaviour?

Thanks for any clarification. 

regards,
Joy Latten

---

From: Dan McDonald <[email-masked]>
Date: Thu, 1 Jul 2010 14:35:10 -0400

On Thu, Jul 01, 2010 at 01:02:20PM -0500, Joy Latten wrote:
<SNIP!>
> 1's in the RESERVED field.

That seems valid (though clearly the implementation who sends 1s is violating
Postel's Law, but you did say it's a TAHI test...).

> with 1's in RESERVED field?

Yes, that's how I interpreted it.  You can't rewrite bits that are fed into
an off-the-wire authentication calculation.

> will fail... would that be expected behaviour?

Postel's Law ("Be conservative in what you send, be liberal in what you
receive.") would suggest you compute the authentication with the EXACT
contents of what was on the wire.

Dan

---

From: Joy Latten <[email-masked]>
Date: Fri, 02 Jul 2010 09:59:20 -0500

> contents of what was on the wire.
Ahh, ok. Good explanation! :-) Thanks!
Guess I need to fix some code. :-)

regards,
Joy