From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Fri Apr 11 19:29:10 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04986 for ; Fri, 11 Apr 2003 19:29:08 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3BNUjM29267 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Fri, 11 Apr 2003 19:30:47 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h3BNV0U13758 for ipseckey-outgoing; Fri, 11 Apr 2003 19:31:00 -0400 (EDT) Received: from fledge.watson.org (ak82hjs7hex92j@fledge.watson.org [204.156.12.50]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3BNUt613741 for ; Fri, 11 Apr 2003 19:30:56 -0400 (EDT) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h3BNUKYX073679 for ; Fri, 11 Apr 2003 19:30:20 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.12.9/8.12.9/Submit) with SMTP id h3BNUGCm073673 for ; Fri, 11 Apr 2003 19:30:20 -0400 (EDT) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 11 Apr 2003 19:30:15 -0400 (EDT) From: Sam Weiler Reply-To: Sam Weiler To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] new draft revision (00b) In-Reply-To: <200304080004.h3804pIC046668@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Tue, 8 Apr 2003 Mark.Andrews@isc.org wrote: > > 2) byte to distinguish type. > > FQDN) wire-encode item > > IPv4) 4 bytes > > IPv6) 16 bytes > > Go with 2. This is a bicycle shed. It sounds like we have rough consensus on the gateway format. If I've missed something vital, please speak up. Otherwise, I suggest that Micheal incorporate the second option into the draft. As always, read the draft, send comments to the list or the editor. -- Sam - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From mcr@lox.sandelman.ottawa.on.ca Tue Apr 15 11:46:02 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01987 for ; Tue, 15 Apr 2003 11:45:58 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3FFmQ607473 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 15 Apr 2003 11:48:35 -0400 (EDT) Received: (from mcr@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h3FFlnZ05484; Tue, 15 Apr 2003 11:47:49 -0400 (EDT) Date: Tue, 15 Apr 2003 11:47:49 -0400 (EDT) Message-Id: <200304151547.h3FFlnZ05484@lox.sandelman.ottawa.on.ca> From: mcr@sandelman.ottawa.on.ca Subject: [ipseckey] Monthly information file for ipseckey@sandelman.ottawa.on.ca To: ipseckey-archive@ietf.org BOF description IPSEC KEYing information resource record WG (ipseckey) Please see http://www.ietf.org/html.charters/ipseckey-charter.html for the official page. To unsubscribe, email to majordomo@sandelman.ca, body is: "unsubscribe ipseckey" You can always ask majordomo@sandelman.ottawa.on.ca to remove you from any list hosted by Sandelman Software This message sent to ipseckey-archive@lists.ietf.org From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon Apr 28 19:39:06 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19088 for ; Mon, 28 Apr 2003 19:39:05 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3SNexC15642 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 28 Apr 2003 19:41:02 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h3SNfb908817 for ipseckey-outgoing; Mon, 28 Apr 2003 19:41:37 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3SNfau08800 for ; Mon, 28 Apr 2003 19:41:36 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3SNeeC15639 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 28 Apr 2003 19:40:41 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h3SNed64014943 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 28 Apr 2003 19:40:40 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h3SNedPJ014939 for ; Mon, 28 Apr 2003 19:40:39 -0400 Message-Id: <200304282340.h3SNedPJ014939@marajade.sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: [IPSECKEY] "example" IPv6 blocks Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 28 Apr 2003 19:40:38 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca IANA/IETF has reserved 192.2.0.0 for examples. Is there an equivalent IPv6 block? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon Apr 28 20:46:26 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20398 for ; Mon, 28 Apr 2003 20:46:25 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3T0mqC15989 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 28 Apr 2003 20:48:55 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h3T0nc112737 for ipseckey-outgoing; Mon, 28 Apr 2003 20:49:38 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3T0nZu12732 for ; Mon, 28 Apr 2003 20:49:35 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3T0mdC15986 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 28 Apr 2003 20:48:40 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h3T0mb64016942 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 28 Apr 2003 20:48:39 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h3T0mbds016938 for ; Mon, 28 Apr 2003 20:48:37 -0400 Message-Id: <200304290048.h3T0mbds016938@marajade.sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: [IPSECKEY] draft -01 changes Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 28 Apr 2003 20:48:36 -0400 From: Michael Richardson Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lox.sandelman.ottawa.on.ca id h3T0nbu12733 Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- The CVS diff -u of the XML is attached below. I have asked the ID editor to publish the version that has change bars as -01. http://www.sandelman.ca/SSW/ietf/ipsec/key/ if you can't wait. Summary of changes: 1) added gateway-type field again. 2) changed gateway field to have 3 formats: 4-byte IPv4, 16-byte IPv6, and wire-encode format. 3) fixed examples 4) added IPv6 example. The IPv6 example had me stumped for awhile on formatting.... the ip6.arpa. string is 73 characters long. How can I make this look nice. I hope that my method of using $ORIGIN is meets with people's approval. I used the 3ffe: address for www.kame.net until I can figure out if there is an "example" space that I should really use. === cd /corp/projects/freeswan/sandbox-main/doc/src/ === /usr/bin/cvs diff -u draft-richardson-ipsec-rr.xml Index: draft-richardson-ipsec-rr.xml =================================================================== RCS file: /freeswan/MASTER/freeswan/doc/src/draft-richardson-ipsec-rr.xml,v retrieving revision 1.7 diff -u -r1.7 draft-richardson-ipsec-rr.xml - --- draft-richardson-ipsec-rr.xml 30 Mar 2003 17:00:29 -0000 1.7 +++ draft-richardson-ipsec-rr.xml 29 Apr 2003 00:40:49 -0000 @@ -2,7 +2,7 @@ - - + Security @@ -26,7 +26,7 @@ - - + @@ -36,7 +36,7 @@ This record replaces the functionality of the sub-type #1 of the KEY Resource - -Record, which has been proposed to be obsoleted by +Record, which has been proposed to be obsoleted by RFC3445 . @@ -59,7 +59,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in - - . + RFC2119 . @@ -96,8 +96,8 @@ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - | precedence | algorithm | gateway | - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | precedence | gateway type | algorithm | gateway | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + ~ gateway ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / @@ -111,16 +111,16 @@ This is an 8-bit precedence for this record. This is interpreted in the same way as the PREFERENCE field described in section - -3.3.9 of . +3.3.9 of RFC1035 .
- -aThe algorithm type field indicates the type of key that is +The algorithm field indicates the type of key that is present in the public key field. A positive number, larger than 0 identifies an algorithm type. The following values, which have been previously - -defined by IANA are useful (). +defined by IANA are useful (see RFC2535 ). A value of 0 indicates that no key is present. @@ -129,8 +129,27 @@ The following values defined by IANA are useful: - - A DSA key is present, in the format defined in - - A RSA key is present, in the format defined in + A DSA key is present, in the format defined in RFC2536 + A RSA key is present, in the format defined in RFC3110 + + + +
+ +
+ +The gateway type field indicates the format of the gateway that +is stored in the gateway field. + + + +The following values are defined: + + No gateway is present + A 4-byte IPv4 address is present + A 16-byte IPv6 address is present + A wire-encoded domain-name is present. The wire-encoded +format is self-describing, so the length is implicit. @@ -140,22 +159,24 @@ The gateway field indicates a gateway to which an IPsec tunnel may be created in order to reach the entity holding this resource record. - -The gateway field is a normal wire-encoded domain name (section 3.3 of - -). - -If no gateway is to be represented, then a null domain name MUST be present. +There are three formats: - -It is a simple fully qualified domain name (FQDN). - -IP version 4 and IP version 6 addresses may be represented using the reverse - -name format, from in-addr.arpa. and ip6.arpa. +A 32-bit IPv4 address is present in the gateway field, as defined in section 3.4.1 of +RFC1035. This is a 32-bit number in network byte order. + + +A 128-bit IPv6 address is present in the gateway field. +The data portion is an IPv6 address as described in section 3.2 of +RFC1886. This is a 128-bit number in network byte order. - -For instance, the IP version 4 address 192.0.1.2 is represented as the - -domain name 2.1.0.192.in-addr.arpa. +The gateway field is a normal wire-encoded domain name (section 3.3 of +RFC1035 ).
@@ -164,7 +185,7 @@ If the algorithm type has the value 5 then public key portion contains an RSA public key, encoded as described in secion 2 of - -. +RFC3110 . @@ -190,7 +211,7 @@
If the algorithm type has the value 3, then public key portion contains an - -DSA public key, encoded as described in . +DSA public key, encoded as described in RFC2536 .
@@ -204,12 +225,16 @@
IPSECKEY RRs may appear as lines in a zone data master file. - - The precedence, algorithm and gateway fields are REQUIRED. There - - base64 encoded public key block is OPTIONAL. + The precedence, gateway type and algorithm and gateway fields are REQUIRED. + There base64 encoded public key block is OPTIONAL. If no gateway is to be indicated, then the root (".") SHOULD be used. +
@@ -217,8 +242,8 @@ An example of a node 192.2.0.38 that will accept IPsec tunnels on its own behalf. An example of a node, 192.2.0.38 that has published its key only. + +An example of a node, 3ffe:501:4819:2000:210:f3ff:fe03:4d0 that has +delegated authority to the node + + +
+ This entire memo pertains to the provision of public keying material + for use by key management protocols such as ISAKMP/IKE (RFC2407) + . + + + + Implementations of DNS servers and resolvers SHOULD take care to make + sure that the keying material is delivered intact to the end application. + The use of DNSSEC to provide end-to-end integrity protection is strongly + encouraged. + + + + The semantics of this record is outside of the scope of this document, + so no advice for users of this information is provided. Any user of this + resource record MUST carefully document their trust model, and why the + trust model of DNSSEC is appropriate.
@@ -298,9 +357,9 @@
- - +My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, +and Ólafur Guðmundsson who reviewed this document carefully. +Additional thanks to Ólafur Guðmundsson for a reference implementation.
@@ -316,7 +375,9 @@ + + === Exit status: 1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPq3L4YqHRg3pndX9AQGbtwP+NS/Htuzb56O+jtmgNSda/LvMjQwVQPzi KLSlau/9Rdy6jKxhCZiHNsLPTkajoOpvF45TI6n8TqPuE0oqYtEDpKbmpPPpTYvR CD2sfw+tuqMqOe9WjOO/p/ONALGSijNDAiUiH9shDP16kgs55cPS68P2XE6mILve Lx9CSTVhCIM= =34C9 -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon Apr 28 22:04:43 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22091 for ; Mon, 28 Apr 2003 22:04:41 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3T26wC16225 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 28 Apr 2003 22:07:00 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h3T27h117259 for ipseckey-outgoing; Mon, 28 Apr 2003 22:07:43 -0400 (EDT) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3T27fu17254 for ; Mon, 28 Apr 2003 22:07:41 -0400 (EDT) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3T26dbU007966 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 29 Apr 2003 04:06:40 +0200 To: ipseckey@sandelman.ca Subject: [IPSECKEY] Comments on draft-ietf-ipseckey-rr-01.txt From: Simon Josefsson X-Payment: hashcash 1.2 0:030429:ipseckey@sandelman.ca:277aac03260ccd04 X-Hashcash: 0:030429:ipseckey@sandelman.ca:277aac03260ccd04 Date: Tue, 29 Apr 2003 04:06:39 +0200 Message-ID: User-Agent: Gnus/5.09002 (Oort Gnus v0.20) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-6.3 required=5.0 tests=USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca ,---- | An IPSECKEY resource record SHOULD be authenticated DNSSEC resource | record. `---- Light-weight resolvers may prefer TSIG instead of DNSSEC. Should this scenario be mentioned? E.g., add "or protected by TSIG". ,---- | The algorithm field does not require any IANA action, as it is | inherited from DNS KEY algorithm values. `---- The SIG RR also uses the same algorithm IANA registry. It requires a standards action to add a new algorithm. An alternative would be to fork the registry. What about wildcard examples? E.g.: An example of a network that has delegated authority to the node with the identity "corpgw.example.org". *.0.2.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 5 1 corpgw.example.org. AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8 cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3 fejrfi1H ) - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon Apr 28 22:16:46 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22330 for ; Mon, 28 Apr 2003 22:16:46 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3T2JOC16264 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 28 Apr 2003 22:19:26 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h3T2KG517941 for ipseckey-outgoing; Mon, 28 Apr 2003 22:20:16 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3T2KEu17927 for ; Mon, 28 Apr 2003 22:20:15 -0400 (EDT) Received: from sentry.rv.nailabs.com (firewall-user@sentry.rv.nailabs.com [204.254.155.100]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3T2JHC16261 for ; Mon, 28 Apr 2003 22:19:18 -0400 (EDT) Received: by sentry.rv.nailabs.com; id WAA03381; Mon, 28 Apr 2003 22:20:22 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma003362; Mon, 28 Apr 03 22:19:39 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6/8.11.6) with ESMTP id h3T2IV911166 for ; Mon, 28 Apr 2003 22:18:31 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Mon, 28 Apr 2003 22:18:31 -0400 (EDT) From: Sam Weiler X-X-Sender: To: Subject: [IPSECKEY] minutes from SFO Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca I just realized that I never sent the minutes to the list. The minutes were submitted for publication. -- Sam IPSECKEY IETF56, San Francisco 18 March 2003 Minutes reported by Charlie Kaufman Meeting convened at 5:01pm Michael Richardson presented draft-richardson-ipsec-rr-02.txt Suggestion was made and accepted to swap the order of the precedence and algorithm fields and make the presentation format match the wire format. Olafur Gudmundsson suggested that the working group accept the draft as a working group document, make a nits pass, and go to working group last call. The proposal was accepted by the room without dissent. Meeting adjourned at 5:08 pm. Steve Bellovin explained likely timeframes for advancement to RFC. Meeting adjourned again at 5:12 pm with goal of revising the document before the scheduled end time of 6 pm. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue Apr 29 16:41:56 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09771 for ; Tue, 29 Apr 2003 16:41:53 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3TKiBC19700 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 29 Apr 2003 16:44:13 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h3TKilP22589 for ipseckey-outgoing; Tue, 29 Apr 2003 16:44:47 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3TKikU22584 for ; Tue, 29 Apr 2003 16:44:46 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3TKhnC19697 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 29 Apr 2003 16:43:50 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h3TKhm64011417 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 29 Apr 2003 16:43:49 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h3TKhmd4011405 for ; Tue, 29 Apr 2003 16:43:48 -0400 Message-Id: <200304292043.h3TKhmd4011405@marajade.sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Comments on draft-ietf-ipseckey-rr-01.txt In-reply-to: Your message of "Tue, 29 Apr 2003 04:06:39 +0200." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Apr 2003 16:43:47 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Simon" == Simon Josefsson writes: Simon> ,---- Simon> | An IPSECKEY resource record SHOULD be authenticated DNSSEC resource Simon> | record. Simon> `---- Simon> Light-weight resolvers may prefer TSIG instead of DNSSEC. Should this Simon> scenario be mentioned? E.g., add "or protected by TSIG". First, assuming that "DNSSEC = SIG only", Unless you are restricting this use scenario to within an enterprise (and even there, the scaling of TSIG is pretty dubious), I would expect that a light-weight resolver will talk to a full resolver that does DNSSEC. As such, it seems to me that you are just using TSIG to get a trusted path to a full resolver, and therefore this is a local issue. The records will still traverse the wire with DNSSEC. Second, last I checked DNSSEC means SIG as well as TSIG. Simon> ,---- Simon> | The algorithm field does not require any IANA action, as it is Simon> | inherited from DNS KEY algorithm values. Simon> `---- Simon> The SIG RR also uses the same algorithm IANA registry. It requires a Simon> standards action to add a new algorithm. An alternative would be to Simon> fork the registry. Simon> What about wildcard examples? E.g.: Simon> An example of a network that has delegated authority to the node with Simon> the identity "corpgw.example.org". Simon> *.0.2.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 5 1 Simon> corpgw.example.org. Simon> AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ Simon> Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La Simon> 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1 Simon> 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC Simon> MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8 Simon> cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3 Simon> fejrfi1H ) I can include this is there is some value in it. It has been suggested in private email that the gateway type field be taken from the RR-type field, i.e: In section 2.4 you have created a new number space (gateway type) but have not mentioned this in the IANA considerations section. Could you reuse the RR type number space for this? (eg. A(1) for IPv4 address, AAAA(28) for IPv6 address, PTR(12) for gateway name). If this is a bad idea then you need to mention that you are creating a new number space. I rather like this idea. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPq7kAYqHRg3pndX9AQEBGQQA65k88E4QGHJi/8zAkjUpV7NSoY1ROEXD kTM0Ilx8JJNpNbtwb6MzC8s4lvBwYtvg5+ttXsWEXsz7c04wFkMNambVzkA1REB7 yQ3nYQ/qSg4065owgB/BL4xnZZu21Zgz6NN4amUIizAu/pl6TxNmu+1UCvVpME1a ynPlaXv1ZTQ= =+TOT -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue Apr 29 17:45:15 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12180 for ; Tue, 29 Apr 2003 17:45:14 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3TLlEC19873 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 29 Apr 2003 17:47:16 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h3TLm0W26243 for ipseckey-outgoing; Tue, 29 Apr 2003 17:48:00 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3TLlwU26236 for ; Tue, 29 Apr 2003 17:47:59 -0400 (EDT) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3TLkxC19870 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Tue, 29 Apr 2003 17:47:02 -0400 (EDT) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3TLkdbU029598 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 29 Apr 2003 23:46:40 +0200 To: Michael Richardson Cc: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Comments on draft-ietf-ipseckey-rr-01.txt References: <200304292043.h3TKhmd4011405@marajade.sandelman.ottawa.on.ca> From: Simon Josefsson X-Payment: hashcash 1.2 0:030429:mcr@sandelman.ottawa.on.ca:95491fdcab9e7968 X-Hashcash: 0:030429:mcr@sandelman.ottawa.on.ca:95491fdcab9e7968 X-Payment: hashcash 1.2 0:030429:ipseckey@sandelman.ca:398d6d5e9a7bc34c X-Hashcash: 0:030429:ipseckey@sandelman.ca:398d6d5e9a7bc34c Date: Tue, 29 Apr 2003 23:46:39 +0200 In-Reply-To: <200304292043.h3TKhmd4011405@marajade.sandelman.ottawa.on.ca> (Michael Richardson's message of "Tue, 29 Apr 2003 16:43:47 -0400") Message-ID: User-Agent: Gnus/5.09002 (Oort Gnus v0.20) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Michael Richardson writes: >>>>>> "Simon" == Simon Josefsson writes: > Simon> ,---- > Simon> | An IPSECKEY resource record SHOULD be authenticated DNSSEC resource > Simon> | record. > Simon> `---- > > Simon> Light-weight resolvers may prefer TSIG instead of DNSSEC. Should this > Simon> scenario be mentioned? E.g., add "or protected by TSIG". > > First, assuming that "DNSSEC = SIG only", That is my assumption. > Unless you are restricting this use scenario to within an > enterprise (and even there, the scaling of TSIG is pretty dubious), > I would expect that a light-weight resolver will talk to a full > resolver that does DNSSEC. Yes. > As such, it seems to me that you are just using TSIG to get a trusted path > to a full resolver, and therefore this is a local issue. The records will > still traverse the wire with DNSSEC. Yes. But from the point of view of the light-weight resolver, the IPSECKEY is authenticated using TSIG and not DNSSEC. I now understand that you and the document may be talking about it from the point of the server, but this is not clear IMHO. > Second, last I checked DNSSEC means SIG as well as TSIG. RFC 2535 (DNSSEC) do not mention TSIG. RFC 2845 (TSIG) do not update RFC 2535. The RFC 2535bis documents do not talk about DNSSEC as including anything beyond what RFC 2535bis defines. The introduction document of RFC 2535bis further says (see below) that DNSSEC by itself is not enough, and that TSIG and other channel security approaches are often needed. To me this implies that TSIG is not considered part of DNSSEC. If my assumption is wrong, I believe the DNSSEC specification rewrite should adopt the new definition. DNSSEC, by itself, is not enough to protect the integrity of an entire zone during zone transfer operations, since even a signed zone contains some unsigned data, so zone maintenance operations will require some additional mechanisms (most likely some form of channel security, such as TSIG, SIG(0), or IPsec). > Simon> An example of a network that has delegated authority to the node with > Simon> the identity "corpgw.example.org". > > Simon> *.0.2.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 5 1 > Simon> corpgw.example.org. > Simon> AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ > Simon> Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La > Simon> 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1 > Simon> 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC > Simon> MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8 > Simon> cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3 > Simon> fejrfi1H ) > > I can include this is there is some value in it. The value I see is that it makes it clear that the wildcard usage model was considered, and isn't an abuse of the standard, or deprecated in any way. An example isn't required, but I think at least mentioning wildcard adresses would be useful. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed Apr 30 06:30:37 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27688 for ; Wed, 30 Apr 2003 06:30:36 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3UAWLC22384 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 30 Apr 2003 06:32:23 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h3UAWv111456 for ipseckey-outgoing; Wed, 30 Apr 2003 06:32:57 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3UAWuc11451 for ; Wed, 30 Apr 2003 06:32:56 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3UAVxC22377 for ; Wed, 30 Apr 2003 06:32:00 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27539; Wed, 30 Apr 2003 06:29:06 -0400 (EDT) Message-Id: <200304301029.GAA27539@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipseckey@sandelman.ca From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [IPSECKEY] I-D ACTION:draft-ietf-ipseckey-rr-01.txt Date: Wed, 30 Apr 2003 06:29:06 -0400 Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPSEC KEYing information resource record Working Group of the IETF. Title : A method for storing IPsec keying material in DNS Author(s) : M. Richardson Filename : draft-ietf-ipseckey-rr-01.txt Pages : 14 Date : 2003-4-29 This document describes a new resource record for DNS. This record may be used to store public keys for use in IPsec systems. This record replaces the functionality of the sub-type #1 of the KEY Resource Record, which has been proposed to be obsoleted by RFC3445 [9]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipseckey-rr-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipseckey-rr-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipseckey-rr-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-29164415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipseckey-rr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipseckey-rr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-29164415.I-D@ietf.org> --OtherAccess-- --NextPart-- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed.