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

No Subject

Fri, 27 Feb 1998 14:48:19 -0500 (EST)
Message-ID: <A1B6CB375930D11188D100A0C95A36BD011477A2@FMSMSX31>
From: "Patel, Baiju V" <baiju.v.patel@intel.com>
To: "'Stephen Kent'" <kent@bbn.com>,
        "Patel, Baiju V"
	 <baiju.v.patel@intel.com>
Cc: "'ipsec'" <ipsec@tis.com>
Subject: RE: IPSEC WORKING GROUP LAST CALL
Date: Fri, 27 Feb 1998 11:12:12 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk

Steve Kent writes:
	If you choose to employ BOTH AH and ESP, AND if you elect to use
	authentication with ESP (which is an option, not a requirement),
then you
	will need to perform two HMAC computations, since the two ICVs
cover
	different portions of the packet.  However, a primary reason for
not
	requiring authentication with ESP in all cases is precisely this
example.
	Yes, you should be able to negotiate a null authentication
algorithm for
	use with ESP.

Steven M. Bellovin [smb@research.att.com] writes:

No.  You could just do ESP in tunnel mode, in which case the inner IP
header
would be protected.  The reason you need to have an authentication field
in
ESP is that authentication is mandatory under many circumstances, just
to
protect confidentiality.


My comments: 

If I read above statements carefully, it seems that Steve Bellovin is
saying that authentication is
mandatory for ESP which is different from what Steve Kent says.

I have been reading documents to figure out how you
can specify not to use authentication with ESP
Here are the values allowed for AH transforms in DOI spec (by the way
in this paragraph, there are two mandatory transforms and not one).
4.4.3 IPSEC AH Transform Identifiers 
The Authentication Header Protocol (AH) defines one mandatory 
and several optional transforms used to provide authentication, 
integrity, and replay detection. 
The following table lists the defined AH Transform Identifiers 
for the ISAKMP Proposal Payload for the IPSEC DOI. 
Transform ID Value 
------------ ----- 
RESERVED 0-1 
AH_MD5 2 
AH_SHA 3 
AH_DES 4.

I do not see an AH NULL here.

ESP specs to not have authentication data optional. therefore, we do 
need this field. If we indeed managed to specify null authentication 
what will be the length of this field and what would we put there.

there is also a broader question here. If you do not need
AH+ESP in tunnel mode, what is the drawback of using 
ESP with tunnel mode to achieve equivalent functionality
of AH+ESP in transport mode (the packet sizes are same
anyway, and both protect IP headers). Unless there is
a convincing argument to use AH+ESP in transport mode
over ESP in tunnel mode, why don't we scrap AH+ESP from
the requirements.

Baiju




4.4.3 IPSEC AH Transform Identifiers 
The Authentication Header Protocol (AH) defines one mandatory
and several optional transforms used to provide authentication,
integrity, and replay detection. 


> -----Original Message-----
> From:	Stephen Kent [SMTP:kent@bbn.com]
> Sent:	Wednesday, February 25, 1998 10:35 PM
> To:	Patel, Baiju V
> Cc:	'ipsec'
> Subject:	RE: IPSEC WORKING GROUP LAST CALL
> 
> Baiju,
> 
> >I have a concern with AH+ESP in transport mode.
> >Based on the requirements of ESP, ESP must negotiate
> >an integrity check mechanism. The MD5-HMAC or SHA-1 HMAC
> >MUST be supported for ESP. Similarly, the same integrity
> >algorithms are used by AH.
> >
> >Therefore, it looks like I have to compute authentication data
> >twice using possibly same algorithm over mostly same data.
> >Something tells me that in this combination, I should be able
> >to negotiate NULL authentication algorithm for ESP.
> 
> If you choose to employ BOTH AH and ESP, AND if you elect to use
> authentication with ESP (which is an option, not a requirement), then
> you
> will need to perform two HMAC computations, since the two ICVs cover
> different portions of the packet.  However, a primary reason for not
> requiring authentication with ESP in all cases is precisely this
> example.
> Yes, you should be able to negotiate a null authentication algorithm
> for
> use with ESP.
> 
> >I do understand that DES-CBC values can be used for authentication
> >data in ESP but then what happens when we are not using DES.
> 
> Use of DEC-CBC is for encryption, and any authentication benefits are
> secondary, as far as ESP is concerned.  However, if you employ a
> suitable
> block cipher base, other algorithms used in CBC mode offer analogous
> functionality re authentication.
> 
> Steve
>