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

ESP - authenticationless OR encryptionless?

smb@research.att.com wrote:

 > Let me be very precise here.  In most cases, you will want to use
 > authentication with ESP -- so many that the authentication *field* is a
 > standard part of the ESP packet format.  Use is optional; you could
 > negotiate not using it.  The same applies to the anti-replay counter.
 > But both fields are always present.  The paper of mine that I cited
       ????

The authentication data field is an optional field for ESP, the counter is
mandatory.  The text below is from the latest ESP concerning the
authentication data field:

  2.7  Authentication Data

     The Authentication Data is a variable-length field containing an
     Integrity Check Value (ICV) computed over the ESP packet minus the
     Authentication Data.  The length of the field is specified by the
     authentication function selected.  The Authentication Data field is
     optional, and is included only if the authentication service has been
     selected for the SA in question.  The authentication algorithm
     specification MUST specify the length of the ICV and the comparison
     rules and processing steps for validation.


Now that we've reestablished once again that authentication is optional
for ESP whats the story with encryption?  My reading of the latest ESP
and architecture specifications was that an encryption algorithm was
mandatory.  But just noticed that in the latest DOI-07 (and earlier as
well) the following:

  4.4.4.1 ESP_NULL
  
     The ESP_NULL type specifies no confidentiality is to be provided by
     ESP.  ESP_NULL is used when ESP is being used to tunnel packets which
     require only authentication and integrity protection.  See the Auth
     Algorithm attribute description in Section 4.5 for additional
     requirements relating to the use of ESP_NULL.

(And below in 4.5 the ESP_NULL reference has the following.)

           When negotiating ESP without authentication, the Auth
           Algorithm attribute MUST NOT be included in the proposal.

           When negotiating ESP without confidentiality, the Auth
           Algorithm attribute MUST be included in the proposal and
           the ESP transform ID must be ESP_NULL.


So, are both the ESP and DOI documents correct?  Is the DOI document
merely anticipating the (future?) submission of a standard ESP NULL
"encryption" transform?  Has anyone submitted a draft for that yet?  I
assume no padding or IV is needed, the (unmodified) payload would be
moved in following the ESP header, and the ESP header and trailer
fields are otherwise present/used, as normal.  It would be a pretty
simple spec. though it may "break" statements we have in some docs
such as "ESP always provides confidentiality for traffic".

I also ask because apparently ESP_NULL has been mentioned for the IPSEC
interop next week and I don't have any pointer to ESP_NULL, except the
description above.  Can someone confirm that what I wrote is what some
folks plan on testing next week for ESP_NULL?


Thanks...
                 
                         
   -- Marc --