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

Re: ISAKMP DELETE payload





> >>   Also, I would suggest that ISAKMP doc should state explicitly that a
> >> DELETE payload should be sent together with a HASH paylaod, assuming that
> >> is the intention of ISAKMP.
> >
> >Does this belong in the ISAKMP doc or in the ISAKMP/Oakley doc? The
> >ISAKMP/Oakley doc outlines which of the ISAKMP exchanges it uses and
> >then adds the additional ones. Should they also specify how to use
> >Informational Exchanges within the context of an IPSEC DOI using Oakley
> >or should this be done in the ISAKMP doc? If I specify it in the ISAKMP
> >doc then any DOI/Key Exchange would have to use it in the way
> >specified. The splitting of the details from the ISAKMP doc to the
> >other docs was to eliminate this. Would appreciate any other opinions
> >on this issue?
> 
> Given that:
> - DELETE payloads only have meaning when under the protection of an
> ISAKMP SA,
> - Oakley is a specific transform used for establishing ISAKMP SAs under
> the IPSEC DOI (and in fact is the only transform fully defined so far for
> this DOI),
> - it is the transform which defines the encryption and hash algorithms in
> use, and how to derive keys for those algorithms,
> 
> then the definition of how to protect a DELETE payload in the Informational
> exchange must be part of the transform document, which in this case is the
> ISAKMP/Oakley draft.


  I think this is an ISAKMP job. IMHO, Oakley is a Key Exchange Protocol
  but deleting an SA is part of SA management, not key exchange. From an
  operational point of view, the SPI's in the msg header will identify the
  ISAKMP SA, which leads to the right hash algorithm and key. So no
  KEP-specific details are needed here. After all, the DELETE and HASH
  payloads are defined by ISAKMP, not OAKLEY.
  
  
  Pau-Chen
  
> 
> I was working under the (possibly incorrect) assumption that the way
> to protect the Informational exchange under ISAKMP/Oakley would be the
> same as the way the Oakley Quick Mode and New Group Mode exchanges are
> protected - namely, by encryption with the key derived from SKEYID_e.
> 
> -Shawn Mamros
> E-mail to: mamros@ftp.com
> 
>