Re: [OSPF] [karp] Last Call: <draft-ietf-ospf-auth-trailer-ospfv3-05.txt> (Supporting Authentication Trailer for OSPFv3) to Proposed Standard
Acee Lindem <acee.lindem@ericsson.com> Wed, 24 August 2011 14:45 UTC
Return-Path: <acee.lindem@ericsson.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B382621F8B6B; Wed, 24 Aug 2011 07:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.493
X-Spam-Level:
X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1ctv8hj1CfB; Wed, 24 Aug 2011 07:45:27 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 117F421F8AD9; Wed, 24 Aug 2011 07:45:27 -0700 (PDT)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7OEkFKK018477; Wed, 24 Aug 2011 09:46:33 -0500
Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 24 Aug 2011 10:46:31 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: Acee Lindem <acee.lindem@ericsson.com>
Date: Wed, 24 Aug 2011 10:46:31 -0400
Thread-Topic: [OSPF] [karp] Last Call: <draft-ietf-ospf-auth-trailer-ospfv3-05.txt> (Supporting Authentication Trailer for OSPFv3) to Proposed Standard
Thread-Index: AcxibJ0W8exhPoa4TDCkVUgqhZqnuA==
Message-ID: <1D4A7913-4FE3-4B9F-9D0D-9FBC5E12F56E@ericsson.com>
References: <20110719145739.5942.53564.idtracker@ietfa.amsl.com> <tsl7h6ed1sp.fsf@mit.edu> <7C362EEF9C7896468B36C9B79200D8350CFF9A5F02@INBANSXCHMBSA1.in.alcatel-lucent.com> <8D54DD3C-45C6-4C34-9CD3-DF6B6C758B4E@ericsson.com>
In-Reply-To: <8D54DD3C-45C6-4C34-9CD3-DF6B6C758B4E@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-121-882542660"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Cc: Sam Hartman <hartmans-ietf@mit.edu>, "ospf@ietf.org" <ospf@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "karp@ietf.org" <karp@ietf.org>
Subject: Re: [OSPF] [karp] Last Call: <draft-ietf-ospf-auth-trailer-ospfv3-05.txt> (Supporting Authentication Trailer for OSPFv3) to Proposed Standard
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2011 14:45:27 -0000
On Aug 24, 2011, at 10:44 AM, Acee Lindem wrote: > > > Hi Manav, > > On Aug 24, 2011, at 10:39 AM, Bhatia, Manav (Manav) wrote: > >> Hi, >> >> [clipped] >> >>> >>> Based on this review I have a few recommendations for the >>> OSPF v3 authentication trailers document. >>> >>> 1) The v3 authentication trailer takes a step back in the >>> ability to rekey security associations both from OSPF v2, >>> from IPsec for OSPF v3 and from >> >> [ ..] >> >>> >>> I believe that draft-ietf-ospf-auth-trailer-ospfv3-05 needs >>> to be revised to require implementation behavior at least as >>> flexible as draft-ietf-karp-crypto-tables. That is, >>> associated with each security association is a time for when >>> sending packets can start with a given SA and for when it >>> must stop. Infinity and 0 should of course be supported for >>> the appropriate times. >>> >>> 2) I notice terminology inconsistency between key identifier >>> and security association identifier. This should probably be >>> cleaned up, although it's not that big of a deal. >> >> http://tools.ietf.org/id/draft-ietf-ospf-auth-trailer-ospfv3-06.txt addresses the first two comments. >> >>> >>> >>> 3) draft-ietf-ospf-analysis says that we are going to solve >>> related protocol attacks. That is, we recognize that it's >>> quite likely that some people will use the same preshared key >>> both for OSPF authentication and for something else. We need >>> to mix something into the key or hash or something that is >>> unlikely to appear in any other use in order to make it >>> cryptographically unlikely for the resulting OSPF >>> authentication hash to be a hash useful in some other >>> protocol or for the hash from some other protocol to be >>> useful in OSPF. This draft does not do that. One possible >>> way to solve this would be to prepend a constant in front of >>> the key in the key preparation step or a constant in front of >>> every packet that gets hashed. The constant should be the >>> same for OSPFv3 and not used for any other purpose. >> >> We had an offline discussion with Sam and others and we seem to have converged at this text: >> >> We change the hex that's repeated in the Apad from 0x878FE1F3 to 0x878FE1F4. This value will be unique for OSPFv3. Other protocols that use this mechanism must use a different value of Apad - you could think of this as "salting" the Apad. > > Could we simply use the OSPFv3 protocol number, 89, in the Apad, e.g., 0x898FE1F4, (or at least the first instance of Apad). Otherwise, we probably need a registry for IANA Apads. I meant 0x898FE1F3 as to not change the last 3 octets of the existing HMAC-SHAx Apad. Thanks, Acee > > Thanks, > Acee > > >> >> OLD TEXT in Sec 4.4: >> >> Apad is a value which is the same length as the hash output or message digest. The first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. >> This implies that hash output is always a length of at least 16 octets. >> >> NEW TEXT: >> >> Apad is a value which is the same length as the hash output or message digest. The first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F4 repeated (L-16)/4 times. >> This implies that hash output is always a length of at least 16 octets. >> >> Cheers, Manav >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >
- [OSPF] Last Call: <draft-ietf-ospf-auth-trailer-o… The IESG
- Re: [OSPF] [karp] Last Call: <draft-ietf-ospf-aut… Bhatia, Manav (Manav)
- Re: [OSPF] [karp] Last Call: <draft-ietf-ospf-aut… Acee Lindem
- Re: [OSPF] [karp] Last Call: <draft-ietf-ospf-aut… Acee Lindem
- Re: [OSPF] [karp] Last Call: <draft-ietf-ospf-aut… Bhatia, Manav (Manav)
- Re: [OSPF] [karp] Last Call: <draft-ietf-ospf-aut… Acee Lindem
- Re: [OSPF] [karp] Last Call: <draft-ietf-ospf-aut… Acee Lindem