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

RE: Comments on ISAKMP and Oakley resolution document.



Dan, thanks for the clarifications.

Baiju

-----Original Message-----
From:	Daniel Harkins [SMTP:dharkins@cisco.com]
Sent:	Friday, October 03, 1997 10:04 AM
To:	baiju@mailbox.jf.intel.com
Cc:	'ipsec'
Subject:	Re: Comments on ISAKMP and Oakley resolution document. 

  Baiju,

> 1. Is the value SAp in HASH_I the SA payload as sent by the initiator and 
> SAp in HASH_R the SA payload sent by the responder? It seems like many 
> people have implemented there ISAKMP/Oakley with above interpretation. 
> However, SAp defined in section 3.2 clearly states that it is SA payload
> sent by the initiator.
> 
> Could someone please clarify this?

The whole point of including SAp in the hash is to prevent a man-in-the-middle
attack against the initial offer (which would otherwise be unauthenticated).
If the responder only included his response it would not preclude such an
attack (and would, in fact, be pointless). So, as defined in the draft, SAp
is the entier body of the SA payload sent by the initiator. If anyone
implemented otherwise they wouldn't interoperate and judging by the very 
high degree of ISAKMP interoperability at the last IPSec bakeoff I think
everybody is doing it this way.

> 2. Examples of phase 1 (e.g., section 5.8.1) shows SPI to be 8 bytes. Since 
> SPI has no interpretation (that I know of) in phase 1, SPI size should be 
> set to 0 and SPI field should not exist. Many implementations ignore non-zero 
> SPI's. However, there is no reason to show something in the example that is 
> not required.

I've removed that but I know of implementations which send 8 bytes of zero.
You can say that that is pointless (and I wouldn't argue with you) but some
do and you shouldn't barf if they send it to you.

> 3. In section 5.4
>    HASH(1) is the prf over the message id (M-ID) from the ISAKMP
>    header concatenated with the entire message that follows the hash
>    including all payload headers, but excluding any padding added for
>    encryption.
> 
> Gives an impression that somehow header (not just MID should be included in 
> the HASH(1).  Also, it gives an impression that if you took MID, and rest 
> of the payload (excluding padding) and computed hash you will be all set. 
> After reading this, any optional payloads were transmitted with the message, 
> they will also be included in the hash computation.
> 
>  At the same time, HASH(1) is defined as
> 
> HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDui | IDur ])
>       
> Which clearly says that different payloads of ISAKMP/Oakley must be hashed 
> in a particular order (not necessarily the order of transmission of these 
> payloads). One of the two definitions need to be changes. This definition 
> excludes anything except what is specified.  One of the two need to be 
> fixed. Same comments hold for HASH(2) description. 

The "entire message following the hash" cannot include the header because
the header precedes the hash. If you can think of a better way to describe 
this please let me know. 

The contents of HASH(1) (and HASH(2) too) are defined in text. The illustration
is "for the above exchange". The draft only states that the HASH payload must
be first and IDui must precede IDur, not that any of the other payloads have 
any specific order. The illustration is just that. If you send the KE before
the nonce then you should hash the "entire message following the hash"
into HASH(1) and that message would have the KE before Ni.

Your impression is correct. If you took the M-ID and the rest of the payload
(excluding the padding) and computed the hash you would be all set.

I'll add "nothing in this illustration should be construed as mandating a
particular order to payloads outside that already specified in this draft"
if it will dispell this belief.

  Dan.