Subject: Comments on 2831 Confidentiality Protection

From: [email-masked]
Date: Thu, 10 Apr 2003 11:23:15 -0700

I noticed that the confidentiality clause (2.4) utilizes a SEAL that computes the cipher of the message as well as a catenated HMAC.   This requires decryption of the entire message before authentication can be done.
 
RFC2406 (Encapsulating Security Payload for IPSEC) defines a nearly identical encoding.  One notable difference is that ESP defines the HMAC to be done on the encrypted contents so that the message can be authenticated without the potentially costly cipher being done  (another form of denial of protection against denial of service,  replay or man in the middle attacks). Since the form of the message is so close to ESP, I would suggest utilizing the exact packet format as defined in RFC2406.  This RFC includes the sequence number, padding, authentication and encryption techniques to assemble a packet with only slight differences to what 2831 specifies.  See section 2 of the rfc2406.
 
I would suggest specifying that the Confidentiality Protection for rfc2831 payload be constructed as described in RFC2406.  For purposes of rfc2831, the SPI and next header fields could be defined as zeros.  
 
As an enhancement consider the following - sInce rfc2831 is connection oriented the SPI used in ESP/IPSEC is 'implied' by the connection.  If UDP was instead used as the communication medium then the rfc2831 dialog could still be done pretty much as defined with the addition of an SPI argument returned to the client.

--
Glenn

[email-masked] / Agilent Laboratories / NN7N / 425-335-2066

---

From: Chris Newman <[email-masked]>
Date: Thu, 10 Apr 2003 12:13:59 -0700

The correct time to make this comment was prior to the publication of RFC 2831 
-- that's the purpose of the last call period.

While consistency across the Internet suite is aesthetically attractive and I 
would have supported this proposal prior to the publication and deployment of 
RFC 2831, I must oppose this proposal now.  There are a number of deployed 
implementations of RFC 2831, so backwards compatibility and interoperability 
with the running code would trump the majority of aesthetic and minor technical 
points.

Now if it were determined that the way RC4 is specified in RFC 2831 has a fatal 
security flaw and can not be fixed without breaking interoperability, then your 
proposal would merit consideration.  But I have yet to hear such a 
determination.

                - Chris

begin  quotation by [email-masked] on 2003/4/10 11:23 -0700:

>
> I noticed that the confidentiality clause (2.4) utilizes a SEAL that computes
> the cipher of the message as well as a catenated HMAC.   This requires
> decryption of the entire message before authentication can be done.
> RFC2406 (Encapsulating Security Payload for IPSEC) defines a nearly identical
> encoding.  One notable difference is that ESP defines the HMAC to be done on
> the encrypted contents so that the message can be authenticated without the
> potentially costly cipher being done  (another form of denial of protection
> against denial of service,  replay or man in the middle attacks). Since the
> form of the message is so close to ESP, I would suggest utilizing the exact
> packet format as defined in RFC2406.  This RFC includes the sequence number,
> padding, authentication and encryption techniques to assemble a packet with
> only slight differences to what 2831 specifies.  See section 2 of the
> rfc2406.
> I would suggest specifying that the Confidentiality Protection for rfc2831
> payload be constructed as described in RFC2406.  For purposes of rfc2831, the
> SPI and next header fields could be defined as zeros.
> As an enhancement consider the following - sInce rfc2831 is connection
> oriented the SPI used in ESP/IPSEC is 'implied' by the connection.  If UDP
> was instead used as the communication medium then the rfc2831 dialog could
> still be done pretty much as defined with the addition of an SPI argument
> returned to the client.
>
> --
> Glenn
>

---

From: Chris Newman <[email-masked]>
Date: Thu, 10 Apr 2003 12:13:59 -0700

- Chris