[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard
We could be confusing functionality with mechanism.
I am in full support of providing authentication functionality for IP
packets. In my initial note (that was probably written in too great of
haste) I hypothesize that AH is not a great way to implement this
functionality (misplacement of the ICV is at the top of my hit list) and
given that we have ESP we can get authentication functionality through an
appropriate ESP.
To cover the export issue we can have transforms that do NULL encryption
(here he goes again lighting another fuse ...) and simply provide
authenticity/identity, integrity and anti-replay in an ESP. If we need to
cover headers we can discuss if this is done by changing the way ESP is
defined (e.g. an ESP that covers headers) or via encapsulation and
subsequent ESP.
My sense of history is that the old AH vs ESP design came from the desire to
cut and paste security functionality as in getting the full power set of
authentication and encryption. Mr. Bellovin did an admirable job of
documenting that cut and paste in design can result in cut and paste in
attack. We have fixed some of this in ESP; why not go the entire length?
(I will admit now that I get on/off the IPSEC mailing list based on its
monsoonal behaviours and have not read EVERY posting on the IPSEC list).
We certainly do not want a coupling of the form "policy to mechanism" as in
AH is good for export, ESP is bad for export, especially from an export or
use/filtering perspective.
with regards,
peter
> -----Original Message-----
> From: Alex Alten [SMTP:Andrade@ix.netcom.com]
> Sent: Saturday, March 28, 1998 11:28 PM
> To: Robert Moskowitz; Peter Ford; 'iesg@ns.ietf.org'
> Cc: ipsec@tis.com
> Subject: RE: Last Call: Security Architecture for the Internet
> Protocol to Proposed Standard
>
> At 09:06 AM 3/27/98 -0800, Robert Moskowitz wrote:
> >At 09:04 PM 3/26/98 -0800, Peter Ford wrote:
> >
> >
> >Another strong argument for AH was export. The assumption is that AH
> will
> >always be exportable. Getting an export license for an ESP
> implementation
> >that only does NULL-ESP might be a little hard.
> >
>
> Yes, I imagine it will be quite hard without some sort of key escrow.
> This in my opinion will seriously hobble IPSEC's deployment. I'm not
> kidding about this. The US Commerce department will not back down on
> this.
> The reason is because they have already approved some unrestricted key
> length export licenses for world wide shipment (except the forbidden 5).
> Some, like TIS's RecoverKey(tm), use 3rd party key escrow. This puts them
>
> in a very strong position for the foreseeable future.
>
> - Alex
>
> --
> Alex Alten
> Andrade@Netcom.Com
> P.O. Box 11406
> Pleasanton, CA 94588 USA
> (510) 417-0159