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: [email-masked]
Date: Fri, 11 Apr 2003 09:42:51 -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.

I just stumbled across the rfc Wednesday.  When was the last call ?  It "would have been" nice to utilize ESP encoding as it addresses other encryption/auth algorithms and would provide a framework for re-using existing IPSEC code in conjunction with SASL.  A new draft of ESP includes policy on how to deal with high speed connections where the sequence number can roll over as well as providing protection from traffic flow analysis. 

By combining the simplicity of Digest Authentication in 2831 and it's nice way of defining keys with ESP a really nice combination would result.

--
Glenn

---

From: [email-masked]
Date: Fri, 11 Apr 2003 15:07:05 -0700

>From the information on the SASL website it appears to me that 2831 is currently 'under revision', hence my suggestion to allow use of ESP as an option for encoding the integrity and confidentiality protection.  This could easily be done by simply specifying an 'encoding' field in much the same way the ciper is specified.  If the intent is to only 'tweak' technical errors then this suggestion is clearly too late. 

--
Glenn

> >
> >I just stumbled across the rfc Wednesday.  When was the last call ?
> 
> December 1998.
> 
> >It "would have been" nice
> 
> Lot's of things "would have been" nice.
> 
> We need to focus on resolving clear technical errors and omissions.
> 
> Kurt 
>