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

Re: ESP revisions straw poll

Below...
 ----------
>From: Bill Trost
>Subject: Re: ESP revisions straw poll
>
<cut>
>
>After all this wrangling, I'd like to submit a straw of "whatever, let's
>get this over with".  I think encryptionless ESP is a fine idea, but I see
>no compelling need to mention it in the ESP draft.
>

I'd like to latch on an idea here... "I see no compelling need to mention it 
in the ESP draft".

Currently:

We have an *algorithm independent* encryption protocol (ESP) which has a 
conformance section that specifies which algorithms you must implement.

We have an *algorithm independent* key management protocol (ISAKMP) which 
uses a separate document (a DOI) to describe the negotiation of available 
algorithms (among other things).

We have an IPSec DOI that makes statements like "All implementations within 
the IPSEC DOI MUST support ESP_DES...".

Therefore:

 I see no compelling need to mention ANY ALGORITHM IMPLEMENTATION 
REQUIREMENTS in the ESP draft.

This means that the IPSec DOI document is more than a supplement to ISAKMP, 
 it is essentially a high level policy for implementing IPSec.  (I claim 
that, as the DOI is written, this is already true.)

Now, back to the question at hand:  Should encryptionless ESP be qualified 
as MUST, SHOULD, MAY, MAY NOT, SHOULD NOT, BETTER NOT, or ignored?  From the 
DOI (draft-ietf-ipsec-ipsec-doi-02.txt) Section 4.4.4:
_____________

4.4.4,  IPSEC ESP Transform Identifiers

   The Encapsulating Security Protocol (ESP) defines one mandatory and 
several optional transforms used to provide data confidentiality. The 
following table lists the defined ESP Transform Identifiers for the ISAKMP 
Proposal Payload for the IPSEC DOI.

       Transform ID                        Value
       ------------                        -----
       RESERVED                            0
       ESP_DES_CBC                         1
       ESP_DES                             2
       ESP_3DES                            3
       ESP_RC5                             4

4.4.4.1 ESP_DES_CBC -- MAY be used for compatibility
4.4.4.2 ESP_DES -- MUST support ESP_DES along with the HMAC and REPLAY 
attributes.
4.4.4.3 ESP_3DES -- strongly encouraged to support ESP_3DES along with the 
HMAC and REPLAY attributes
4.4.4.4 ESP_RC5 -- (no requirement to implement stated)
_____________

I claim that we could add:

      ESP_NADA      5    (or ESP_IDENTITY, or ...   :-)

and a section 4.4.4.5 that makes no statement concerning mandatory-ness 
(just as was done in the case of RC5).  Note that this section could include 
any information needed in the "encryptionless transform" document some are 
asking for.

Dale Hapeman
hapemand@bah.com
Follow-Ups: