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

Re: ISAKMP DELETE payload


Well, it seems that we are in basic agreement on :

     1. The DELETE payload has to be authenticated.
     2. The exact way of authentication (input/format to the hash,
        the key, ...) should be defined.
        
The only disagreement is where it should be defined. I still prefer ISAKMP.
But I think this topic is minor relative to many other issues of ISAKMP and
OAKLEY. So either

   1. ISAKMP/OAKLEY start defining it, Or
   2. we can say in ISAKMP "The entire DELETE payload minus
      the generic payload header must be authenticated"
and leave the exact crypto algorithm and key to the KEP.

Either way, we can always move the definition later if needed.
> 
>   Shawn,
> 
> (responding to Pau-Chen)
> > >  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. Fom 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.
> > 
> > On the one hand, I understand your viewpoint.  On the other, though,
> > one cannot establish an ISAKMP SA from the details of the ISAKMP draft
> > alone.  One needs a DOI definition, and specific transforms need to
> > be proposed by the initiator for the ISAKMP SA; those transforms are in
> > turn defined by the DOI.
> 
> And ISAKMP does not specify the key exchange. There must be something
> used to protect this message; ISAKMP does not specify how to generate
> this thing but ISAKMP/Oakley does. The technique used to protect Quick
> Mode can easily be used to protect Informational exchanges.
> 
> > It also isn't clear that one would always want to use a HASH payload
> > to protect the DELETE.  A DOI definition could just as well mandate
> > that the Informational exchange must be encrypted, rather than hashed.
> 
> It *is* encrypted. Informational exchanges must be sent under the protection 
> of an existing ISAKMP SA. The issue is authenticating the message as well.
> Steve Bellovin (in a paper whose title I cannot remember and I don't have 
> on hand right now since I'm at home) noted some attacks that can be made
> on messages that are encrypted but not authenticated. We must protect 
> ourselves against this sort of attack.
> 
> > Also, keep in mind that one may be using the Informational exchange to
> > delete not the ISAKMP SA, but rather some underlying protocol SA, such
> > as an IPSEC SA.  By definition, the details of those protocol SAs are
> > defined by the DOI, and not in the base ISAKMP document.
> 
> A good point.
> 
>   regards,
> 
>   Dan.
>