From owner-ipsec Tue Dec 1 11:55:58 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA12658 for ipsec-outgoing; Tue, 1 Dec 1998 11:48:46 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF5F5F6A@exchange> From: Tim Jenkins To: "'ipsec@tis.com'" Subject: Monitoring MIB: draft-ietf-ipsec-mib-03.txt Date: Tue, 1 Dec 1998 12:08:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk In time for perusal before IETF: is available. It intends to address many, but not all, of the concerns raised by the previous version. There are significant changes to this one. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 From owner-ipsec Tue Dec 1 12:17:12 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA12800 for ipsec-outgoing; Tue, 1 Dec 1998 12:16:50 -0500 (EST) Message-ID: <36642959.3F84AF3F@redcreek.com> Date: Tue, 01 Dec 1998 09:37:29 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: perry@piermont.com CC: Henry Spencer , Markku Savela , ipsec@tis.com Subject: Re: Use IPSEC as SSH replacement References: <199812010231.VAA15466@jekyll.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk "Perry E. Metzger" wrote: > > I had originally hoped, in fact, that IPSec would make tools like SSH > unnecessary by providing upper layer tools sufficient information that > they could simply ask the identity of the other side of any TCP > session from the security layer and not need to manage any > cryptography on their own at all. Sadly, things have not thus far > worked out this way, but it is not an unreasonable goal for people to > be striving for. It seems that one of the greatest impediments to this is the perceived vulnerability of the channel between the application and the ipsec layer. I've been giving this a lot of thought lately due to the implications this vulnerability has for using ipsec to secure the (remote) configuration of ipsec-enabled devices. The argument I've heard most often is that in this and many other cases, there is a requirement for securing the data all the way to the (configuring) application, and that our current implementations don't fulfill this requirement. The diagram below illustrates: +-------------------------------------------------+ | User Space | | +-------------+ +--------------+ | | | configuring | | rogue | | | | (or other) | | | | | application | | application,| | | +-----------|-+ | | | +--------------------|-------| code, +-----+ | Kernel Space +--|-------+ | | | | ~ driver, etc. | | | +--|-------+--------------+ | | +--|-------------------------+ | | | V IPSEC Layer | | | +----------------------------+ | +-------------------------------------------------+ In general, the user application seems to be vulnerable to the rogue application in several ways: (1) unencrypted data may be inspected prior to arriving in and after leaving the application, (2) unencrypted data may be inspected within the user app's runtime memory, (3) any additional (second factor) software authentication mechanism utilized by the user application is subject to compromise via the same avenues. I'm inclined to think that (3) renders the TLS case equivalent unless a hardware device (such as a smart card) is added to the picture, and that this really amounts to a problem of physical security. However, while this may represent a tidy characterization of the ipsec-device-config problem, it does not address the general case you refer to above, i.e. securing user sessions on systems in arbitrary environments. This is an interesting problem which may not have a solution outside of the smartcard class. Scott From owner-ipsec Tue Dec 1 12:38:01 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA12870 for ipsec-outgoing; Tue, 1 Dec 1998 12:37:49 -0500 (EST) Message-Id: <199812011757.MAA24670@jekyll.piermont.com> To: "Scott G. Kelly" cc: ipsec@tis.com Subject: Re: Use IPSEC as SSH replacement In-reply-to: Your message of "Tue, 01 Dec 1998 09:37:29 PST." <36642959.3F84AF3F@redcreek.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 01 Dec 1998 12:57:07 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk "Scott G. Kelly" writes: > "Perry E. Metzger" wrote: > > I had originally hoped, in fact, that IPSec would make tools like SSH > > unnecessary by providing upper layer tools sufficient information that > > they could simply ask the identity of the other side of any TCP > > session from the security layer and not need to manage any > > cryptography on their own at all. Sadly, things have not thus far > > worked out this way, but it is not an unreasonable goal for people to > > be striving for. > > It seems that one of the greatest impediments to this is the perceived > vulnerability of the channel between the application and the ipsec > layer. You presumably get information into and out of the IPSec layer via system calls. If you can't trust your kernel, you can't trust your own code because the kernel can do arbitrary things to the running application, including replacing its code on the fly. Therefore, I don't think this is a giant issue. Perry From owner-ipsec Tue Dec 1 13:15:28 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA13101 for ipsec-outgoing; Tue, 1 Dec 1998 13:14:48 -0500 (EST) From: Dan McDonald Message-Id: <199812011832.KAA10161@kebe.eng.sun.com> Subject: Re: Use IPSEC as SSH replacement To: skelly@redcreek.com (Scott G. Kelly) Date: Tue, 1 Dec 1998 10:32:14 -0800 (PST) Cc: perry@piermont.com, henry@spsystems.net, msa@hemuli.tte.vtt.fi, ipsec@tis.com In-Reply-To: <36642959.3F84AF3F@redcreek.com> from "Scott G. Kelly" at Dec 1, 98 09:37:29 am X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk First, to Perry... > > I had originally hoped, in fact, that IPSec would make tools like SSH > > unnecessary by providing upper layer tools sufficient information that > > they could simply ask the identity of the other side of any TCP > > session from the security layer and not need to manage any > > cryptography on their own at all. Sadly, things have not thus far > > worked out this way, but it is not an unreasonable goal for people to > > be striving for. It is not an unreasonable goal. And BTW, these are the sort of requirements IPsec extensions to a socket API require. The various sputterings (many of them mine) about such APIs have tried to make sure that gets taken into account. Now on to Scott... > It seems that one of the greatest impediments to this is the perceived > vulnerability of the channel between the application and the ipsec > layer. Whose perceptions are these? > I've been giving this a lot of thought lately due to the > implications this vulnerability has for using ipsec to secure the > (remote) configuration of ipsec-enabled devices. The argument I've heard > most often is that in this and many other cases, there is a requirement > for securing the data all the way to the (configuring) application, and > that our current implementations don't fulfill this requirement. The > diagram below illustrates: > > +-------------------------------------------------+ > | User Space | > | +-------------+ +--------------+ | > | | configuring | | rogue | | > | | (or other) | | | > | | application | | application,| | > | +-----------|-+ | | | > +--------------------|-------| code, +-----+ > | Kernel Space +--|-------+ | | > | | ~ driver, etc. | | > | +--|-------+--------------+ | > | +--|-------------------------+ | > | | V IPSEC Layer | | > | +----------------------------+ | > +-------------------------------------------------+ > > In general, the user application seems to be vulnerable to the rogue > application in several ways: (1) unencrypted data may be inspected prior > to arriving in and after leaving the application, (2) unencrypted data > may be inspected within the user app's runtime memory, (3) any > additional (second factor) software authentication mechanism utilized by > the user application is subject to compromise via the same avenues. (1) can be implemented by a rogue run-time library. Especially on dynamic loading/linking systems (including the product I work on), this may be a problem. Keep in mind, however, that such dynamic libraries are part of your trusted computing base. Writing to these libraries requires "root" privilege, or some finer grained "system admin" privilege on a MLS system. (2) Is only a problem if the adversary has access to the application's address space. Proper enforcement of process address space privilege (in my world, this is enforced by procfs, i.e. /proc) should prevent this. (3) See (1) and (2). > problem, it does not address the general case you refer to above, i.e. > securing user sessions on systems in arbitrary environments. This is an > interesting problem which may not have a solution outside of the > smartcard class. As Perry as pointed out already, if your kernel has been compromised, you're in a world of hurt. Or as we say here while explaining such vulnerabilities, "If root is compromised, all bets are off!" You make an eloquent case, Scott, for why OSes eventually need to migrate toward an MLS model with mandatory access control. Assuming you can trust your TCB, however, the "IPsec layer" can provide valuable information to an application with decent socket API extensions. Dan From owner-ipsec Tue Dec 1 13:20:01 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA13147 for ipsec-outgoing; Tue, 1 Dec 1998 13:19:49 -0500 (EST) Date: Tue, 1 Dec 1998 13:39:06 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Use IPSEC as SSH replacement In-Reply-To: <36642959.3F84AF3F@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 1 Dec 1998, Scott G. Kelly wrote: > It seems that one of the greatest impediments to this is the perceived > vulnerability of the channel between the application and the ipsec > layer... Unfortunately, in the most severely general case, this problem is beyond solution... because in a system with the classical user/kernel split, any hostile software which can intervene at the kernel level can also inspect and change the code and data of the application itself, defeating *any* application-level safeguards. It seems to me that there is little hope of defending the application against a sophisticated attack mounted from within the kernel it is running on. Effective defences have to be placed further out, defending the kernel against intrusion. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Tue Dec 1 13:22:56 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA13182 for ipsec-outgoing; Tue, 1 Dec 1998 13:22:48 -0500 (EST) Message-ID: From: "Freedman, Jerome" To: "'Scott G. Kelly'" Cc: "'ipsec@tis.com'" Subject: RE: Use IPSEC as SSH replacement Date: Tue, 1 Dec 1998 13:44:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk >The argument I've heard >most often is that in this and many other cases, there is a requirement >for securing the data all the way to the (configuring) application, and >that our current implementations don't fulfill this requirement. The I have been working on this stuff for the gov't for a while and securing the data while its in the box is almost more important than having the box communicate. While I do think that this point of view is extreme, there is something to be said for it. I think ( although this is definitely off topic I think it needs to be said) that it is not enough to tell a customer that your box will encrypt/authenticate his packets and route them through the appropriate VPN, there should be some assurance that a rogue application/miscoded interrupt/malicious developer will not cause your box to start spewing keys over the net From owner-ipsec Tue Dec 1 13:33:09 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA13249 for ipsec-outgoing; Tue, 1 Dec 1998 13:32:49 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF5F6002@exchange> From: Tim Jenkins To: "'ipsec@tis.com'" Subject: RE: Monitoring MIB: draft-ietf-ipsec-mib-03.txt Date: Tue, 1 Dec 1998 13:52:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE1D5B.CB58FD20" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE1D5B.CB58FD20 Content-Type: text/plain; charset="iso-8859-1" Please wait a bit; the version there is truncated. I'll fix ASAP. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Tim Jenkins [mailto:tjenkins@TimeStep.com] > Sent: Tuesday, December 01, 1998 12:09 PM > To: 'ipsec@tis.com' > Subject: Monitoring MIB: draft-ietf-ipsec-mib-03.txt > > > In time for perusal before IETF: > > is > available. It intends > to address > many, but not all, of the concerns raised by the previous version. > > There are significant changes to this one. > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 > ------_=_NextPart_001_01BE1D5B.CB58FD20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Monitoring MIB: draft-ietf-ipsec-mib-03.txt

Please wait a bit; the version there is truncated. = I'll fix ASAP.

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


> -----Original Message-----
> From: Tim Jenkins [mailto:tjenkins@TimeStep.com]<= /FONT>
> Sent: Tuesday, December 01, 1998 12:09 = PM
> To: 'ipsec@tis.com'
> Subject: Monitoring MIB: = draft-ietf-ipsec-mib-03.txt
>
>
> In time for perusal before IETF:
>
> <ftp://206.191.59.148/draft-ietf-ipsec-mib-03.txt&g= t; is
> available. It intends
> to address
> many, but not all, of the concerns raised by = the previous version.
>
> There are significant changes to this = one.
>
> ---
> Tim = Jenkins           = ;            = TimeStep Corporation
> = tjenkins@timestep.com        &nb= sp; http://www.timestep.com
> (613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617
>

------_=_NextPart_001_01BE1D5B.CB58FD20-- From owner-ipsec Tue Dec 1 13:39:56 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA13295 for ipsec-outgoing; Tue, 1 Dec 1998 13:39:48 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF5F6010@exchange> From: Tim Jenkins To: "'ipsec@tis.com'" Subject: RE: Monitoring MIB: draft-ietf-ipsec-mib-03.txt Date: Tue, 1 Dec 1998 14:00:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE1D5C.D956EE20" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE1D5C.D956EE20 Content-Type: text/plain; charset="iso-8859-1" Fixed. It has 65 pages, not 47. My apologies for the confusion. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Tim Jenkins > Sent: Tuesday, December 01, 1998 1:53 PM > To: 'ipsec@tis.com' > Subject: RE: Monitoring MIB: draft-ietf-ipsec-mib-03.txt > > > Please wait a bit; the version there is truncated. I'll fix ASAP. > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 > > > > -----Original Message----- > > From: Tim Jenkins [mailto:tjenkins@TimeStep.com] > > Sent: Tuesday, December 01, 1998 12:09 PM > > To: 'ipsec@tis.com' > > Subject: Monitoring MIB: draft-ietf-ipsec-mib-03.txt > > > > > > In time for perusal before IETF: > > > > is > > available. It intends > > to address > > many, but not all, of the concerns raised by the previous version. > > > > There are significant changes to this one. > > > > --- > > Tim Jenkins TimeStep Corporation > > tjenkins@timestep.com http://www.timestep.com > > (613) 599-3610 x4304 Fax: (613) 599-3617 > > > ------_=_NextPart_001_01BE1D5C.D956EE20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Monitoring MIB: draft-ietf-ipsec-mib-03.txt

Fixed. It has 65 pages, not 47.

My apologies for the confusion.

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


> -----Original Message-----
> From: Tim Jenkins
> Sent: Tuesday, December 01, 1998 1:53 PM
> To: 'ipsec@tis.com'
> Subject: RE: Monitoring MIB: = draft-ietf-ipsec-mib-03.txt
>
>
> Please wait a bit; the version there is = truncated. I'll fix ASAP.
>
> ---
> Tim = Jenkins           = ;            = TimeStep Corporation
> = tjenkins@timestep.com        &nb= sp; http://www.timestep.com
> (613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617
>
>
> > -----Original Message-----
> > From: Tim Jenkins [mailto:tjenkins@TimeStep.com]<= /FONT>
> > Sent: Tuesday, December 01, 1998 12:09 = PM
> > To: 'ipsec@tis.com'
> > Subject: Monitoring MIB: = draft-ietf-ipsec-mib-03.txt
> >
> >
> > In time for perusal before IETF:
> >
> > <ftp://206.191.59.148/draft-ietf-ipsec-mib-03.txt&g= t; is
> > available. It intends
> > to address
> > many, but not all, of the concerns raised = by the previous version.
> >
> > There are significant changes to this = one.
> >
> > ---
> > Tim = Jenkins           = ;            = TimeStep Corporation
> > = tjenkins@timestep.com        &nb= sp; http://www.timestep.com
> > (613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617
> >
>

------_=_NextPart_001_01BE1D5C.D956EE20-- From owner-ipsec Tue Dec 1 15:11:05 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA13726 for ipsec-outgoing; Tue, 1 Dec 1998 15:09:49 -0500 (EST) From: kunzinge@us.ibm.com X-Lotus-FromDomain: IBMUS To: ipsec@tis.com Message-ID: <852566CD.006C32F9.00@us.ibm.com> Date: Tue, 1 Dec 1998 14:45:15 -0500 Subject: Some possible discussion items on "PKI Requirements" Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk In reviewing the draft "PKI Requirements for IP Security" and trying to relate its contents to the associatedated IKE and PKI specs, I discovered several areas that seem unclear and/or inconsistent with other related IETF documents. Since a discussion of digital certificates is on the agenda for next week, I'm listing our concerns as "food for thought"--I'm not sure myself what the best answers are to some of these concerns. 1. The "IPSec DOI" (RFC 2407) allows several formats for the "ID Payload" carried in IKE messages. However, "PKI Requirements for IP Security" permits only three of the formats (ipAddress, dNSName, and rFC822Name) to be carried in the subjectAltName of the corresponding digital certificate. It further restricts the "ipAddress" to handle carry only single IPv4 addresses, excluding for example subnet addresses and IPv6 addresses. On the other hand, the underlying PKI spec ("PKIX-1" will denote draft-ietf-pkix-ipki-part1-09.txt, section 4.2.1.7) allows the use of IPv6 addresses in the subjectAltName field. This raises two questions: a) Why is the use of IPv6 addresses outlawed by the "PKI Requirements for IPSec" document, and b) should our drafts state explicitly that the "unmentioned" formats allowed by "DOI" for ID Payloads can not be used in digital certificates (these formats, from the "DOI", are ID_IPV4_ADDR_SUBNET, ID_IPv6_ADDR, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE, ID_KEY_ID, ID_DER_ASN1_GN, and ID_DER_ASN1_DN). 2. I'd expect ID_DER_ASN1_DN formatted names to appear in the subject field of the digital certificate. Yet, "PKI Requirements for IP Security" states in section 4.1.2 that "For IPSec devices, the actual name of the subject is stored in the subjectAltName field"--but the format ID_DER_ASN1_DN is not allowed by "PKI Requirements for IP Security" to be used in the subjectAltName field. Should there be additional text stating that when distinguished names are used to identify the subject, they can appear in the "subject" field of the digital certificate? Should we also add text to state that the subject of the certificate can appear in either the subject field and/or the subjectAltName field, in order to be consistent with "PKIX-1" wording in its section 4.1.2.6? 3. "PKIX-1" states in its section 4.1.2.6 that "If subject naming information is present only in the subjectAltName extension...then the subject name shall be an empty sequence and the subjectAltName extension shall be critical". "PKI Requirements for IP Security" states in its section 3.4.3 that "subjectName SHOULD be non-empty" and also that "subjectAltName MAY contain a relevant and valid name". Yet in section 3.1.1, "PKI Requirements..." says that in the certifcate request message subjectALtName MUST be set to an appropriate value: and that "the certificate generated by the PKI service provider MUST contain the subjectAltName specified and MAY NOT be changed". This set of statements raises several questions: a) given that "PKIX-1" explicitly allows an empty subject field, what is the rationale for IPSec certificates to require a non-empty one? and b) is there a recommendation as to what should be placed in the "non-empty" subject field (since whatever it is will be associated with the public key carried in the certificate)? and c) is the use of subjectAltName field a "MUST", "SHOULD", or "MAY" in the context of "PKI Requirements..."? 4. "DOI" (RFC 2407) states in its section 4.6.2.1 that "When an IKE exchange is authenticated using certificates (of any format), any ID's used for input to local policy decisions SHOULD be contained in the certificate used in the authentication of the exchange". This wording says to me that a IKE negotiator SHOULD check that at least one entry in the certificate's "subject" or "subjectAltName" fields matches the contents carried in the ID Payload of the IKE message. Yet, "PKI Requirements..." seems to be much more lenient, saying in its section 3.3 that "The subjectAltName MAY be checked for consistency". However, it never explicitly states the thing against which consistency should be checked. Since the ID Payload is mandatory in the Phase 1 IKE exchanges, should we be more explicit and state that the contents of the ID Payload and at least one of the names in the "subject" or "subjectAltName" field must match. 5. "PKIX-1" in section 4.2.1.7 seems to imply that multiple identities can be carried in the subjectAltName extension. At the recent Interoperability WOrkshop, we spoke briefly about the possibility of IKE allowing multiple identities to be carried in this field. Do we intend to update "PKI Requirements" to allow mulitple identities to be carried within a single digital certificate? ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) TCP/IP Technology Management, JDGA/501, RTP Phone: Tie 8-444-4142 , External 1-919-254-4142 Fax: Tie 8-444-6243, External 1-919-254-6243 VM: IBMUSM27(KUNZINGE) From owner-ipsec Tue Dec 1 15:20:11 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA13769 for ipsec-outgoing; Tue, 1 Dec 1998 15:19:50 -0500 (EST) Message-ID: <366453CE.618D3A98@lmf.ericsson.se> Date: Tue, 01 Dec 1998 22:38:38 +0200 From: Ari Huttunen Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tis.com Subject: SA bundles, multiple tunnels? Content-Type: multipart/mixed; boundary="------------6716D12A077DE746A3CC8B37" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------6716D12A077DE746A3CC8B37 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi folks, I'm currently involved in IPSec implementation, and I have a couple of specific questions. I've read the architecture draft several times by now, but it didn't seem to give me definitive answers. Question 1: Can one SA be a part of more than one SA bundle? Question 2: <-------SA1----------------> <-------SA2------> [IP1][AH][IP2][AH][IP3][TCP] Assume that I have two tunnel mode AH SAs. Both of these SAs terminate at the current router. I further define for both SAs a selector for "Transport Layer Protocol". What should they match? Will the selector for SA1 match "IP" or will it go further down the headers all the way to "TCP"? Question 3: <-------SA---------> [IP1][ESP][IP2][TCP] This is a sort of stupid question. Assume that I have one ESP SA terminating at the current router. Here a selector for transport layer protocol is also defined for this SA. Should the behaviour be to a) First match the selector, producing OPAQUE, since the inner packet is still encrypted. Or b) First decrypt the packet, and only then match the selector, which now succeeds fine. Only b) seems sane, but the architecture RFC section 5.2.1 only says "Use the SA found in (1) to do the IPsec processing, e.g., authenticate and decrypt. This step includes matching the packet's (Inner Header if tunneled) selectors to the selectors in the SA." This could mean either behaviour. Question 4: What sort of policy filtering does IPSec intend to define for throughgoing IPSec traffic? This is related to the previous question, since if a) is the intended behaviour, the following sentence at section 4.4.2 makes a whole lot more sense. "NOTE: To locate the transport protocol, a system has to chain through the packet headers checking the "Protocol" or "Next Header" field until it encounters either one it recognizes as a transport protocol, or until it reaches one that isn't on its list of extension headers, or until it encounters an ESP header that renders the transport protocol opaque." Thus for throughgoing traffic, which can't be authenticated or decrypted, the selector in the policy database would go inside the protected packet. Thanks, Ari Huttunen --------------6716D12A077DE746A3CC8B37 Content-Type: text/x-vcard; charset=us-ascii; name="Ari.Huttunen.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ari Huttunen Content-Disposition: attachment; filename="Ari.Huttunen.vcf" begin:vcard n:Huttunen;Ari tel;fax:+358-9-2992634 tel;work:+358-9-2992472 x-mozilla-html:FALSE org:L M Ericsson;LMF/T/TK version:2.1 email;internet:Ari.Huttunen@lmf.ericsson.se title:Software Designer adr;quoted-printable:;;Oy L M Ericsson Ab=0D=0ATelecom R&D;;;02420 Jorvas;Finland x-mozilla-cpt:;-30024 fn:Ari Huttunen end:vcard --------------6716D12A077DE746A3CC8B37-- From owner-ipsec Tue Dec 1 18:55:45 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA14502 for ipsec-outgoing; Tue, 1 Dec 1998 18:53:52 -0500 (EST) Message-Id: <199812020013.QAA28477@chip.cisco.com> To: Robert Moskowitz cc: ipsec@tis.com Subject: Re: Agenda stuff In-reply-to: Your message of "Fri, 27 Nov 1998 15:23:15 EST." <4.1.19981127123012.00b9eef0@homebase.htt-consult.com> <4.1.19981127123012.00b9eef0@homebase.htt-consult.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28475.912557582.1@cisco.com> Date: Tue, 01 Dec 1998 16:13:03 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 27 Nov 1998 15:23:15 EST Robert Moskowitz wrote > > (I know there is more here than we can cover in 2 hours. If some of this > is straightforward we can handle it on the list. I would like to see if we > have a pending set of documents ready for last call and to define what is > important to everyone for 'IPsec ond'). > > Outstanding Items: > > Revs for IKE D. Harkins Perhaps the "Revs for IKE" is straightforward enough that we can handle it on the list. Let's try. The IKE/DOI errata are at http://www.lounge.org/ike_doi_errata.html. Most of these issues have obvious solutions which are mentioned along with the issue (like "add group 5"). Some don't. Here's suggestions for those that don't. These are not intended on being THE WAY but only to encourage discussion on these matters since no one seems to be discussion them on this list. 1. What type of cert encoding is used in a cert request payload if you wish to obtain the peer's encryption certificate (assuming the peer has one signature only and one for encipherment only)? ISAKMP mentions "X.509 Certificate - Signature" and "X.509 Certificate - Key Exchange". Signature should be out of the question because if you have a cert restricted to signatures only that's not the one to request to do encryption with. So is it "Key Exchange"? Is this merely a semantic problem in that that doesn't sound too informative? 2. Addition of new elliptic curve groups. Possibly add groups over F2^p, where p is prime. Open item is whether this goes in IKE or becomes a standalone BCP-type RFC. Perhaps those who want new groups can suggest a resolution to this. 3. There are issues surrounding the rekeying of both phase1 (IKE) and phase2 (IPSec) SAs. "IPSec Re-keying Issues" [Tim Jenkin's document] discusses these. Since Tim is presenting his document next week we can punt this one. 4. Clarification on what SPI to use during transactional exchanges like new group mode or configuration mode. How about none? 5. Some verbage needed to specify when to start using the IKE SA to protect notification exchanges. As soon as "crypto active" which could screw up the running IV or after the phase 1 exchange which could leave some notifies unprotected? This is an issue if you want to send a notify after the Diffie-Hellman exchange has completed but before the SA has been authenticated. IKE says "If the ISAKMP security association has not yet been established at the time of the Informational Exchange, the exchange is done in the clear without an accompanying HASH payload." So I guess that means it goes in the clear but then that can open us up to attack. So should we say that the IV used to encrypt the message (in the unauthenticated key by the way) is generated the same way in this case as it is for the post-established SA case? In other words, a hash of the last phase 1 CBC output block and the message ID of the notify. And since the last phase 1 CBC output block has not be determined yet the IV would be a hash of the message ID. 6. A rewrite of the wording in section 3.5 in the ISAKMP document that seems to mandate a covert channel. Kivinen has suggested the following text: "During phase 1 negotiations, the initiator and responder cookies determine the ISAKMP SA. Therefore, the SPI field in the Proposal payload is redundant and its size MUST be set to 0." as a replacement for: "In the case of ISAKMP, the Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). If the SPI Size is non-zero, the content of the SPI field MUST be ignored." which just seems broken. That sounds good. Doug (Maughan) do you have any input here? There are 3 issues that effect interoperability that need to be addressed in son-of-IPSec so we can leave those for later. But it would be nice if we could come to some resolution on these other issues. Also, check out the web page. If any of those issues I didn't mention don't seem to have a straightforward solution please point that out and suggest one. Dan. From owner-ipsec Tue Dec 1 21:53:12 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA14963 for ipsec-outgoing; Tue, 1 Dec 1998 21:48:56 -0500 (EST) Message-Id: <199812012105.QAA04376@smb.research.att.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Henry Spencer Subject: Re: Use IPSEC as SSH replacement cc: IP Security List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Dec 1998 16:02:55 -0500 From: "Steven M. Bellovin" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Henry Spen cer writes: >On Tue, 1 Dec 1998, Scott G. Kelly wrote: >> It seems that one of the greatest impediments to this is the perceived >> vulnerability of the channel between the application and the ipsec >> layer... > >Unfortunately, in the most severely general case, this problem is beyond >solution... because in a system with the classical user/kernel split, any >hostile software which can intervene at the kernel level can also inspect >and change the code and data of the application itself, defeating *any* >application-level safeguards. It seems to me that there is little hope of >defending the application against a sophisticated attack mounted from >within the kernel it is running on. Effective defences have to be placed >further out, defending the kernel against intrusion. Agreed. The issue with IPSEC is the granualarity of protection. In particular, if host-level or gateway-level protection is used, how can an application request some minimum level of protection, find out what is in fact being used, and look at the certificate presented. For many purposes, a replacement for ssh would need these abilities. From owner-ipsec Tue Dec 1 23:33:47 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA15294 for ipsec-outgoing; Tue, 1 Dec 1998 23:27:58 -0500 (EST) Message-Id: <3.0.1.32.19981202101651.00946840@172.16.1.10> X-Sender: rohit@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 02 Dec 1998 10:16:51 +0500 To: Ari Huttunen From: rohit Subject: Re: SA bundles, multiple tunnels? Cc: ipsec@tis.com In-Reply-To: <366453CE.618D3A98@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:38 PM 12/1/98 +0200, you wrote: >Hi folks, > >I'm currently involved in IPSec implementation, and >I have a couple of specific questions. I've read the >architecture draft several times by now, but it didn't >seem to give me definitive answers. > >Question 1: > >Can one SA be a part of more than one SA bundle? > Yes, SA can be part of more than one SA bundle, if you allow sharing of SAs. >Question 2: > ><-------SA1----------------> > <-------SA2------> >[IP1][AH][IP2][AH][IP3][TCP] > >Assume that I have two tunnel mode AH SAs. Both >of these SAs terminate at the current router. I further >define for both SAs a selector for "Transport Layer >Protocol". What should they match? Will the selector >for SA1 match "IP" or will it go further down the >headers all the way to "TCP"? In the inbound IPSec Processing, all the SAs applied will be collected in a SA Bundle, the selectors of the last SA applied will be compared with the pkt selectors. Since the selectors wont change from one SA to the other SA for one SABundle. Thus the transport protocol will be TCP while matching the selectors. > >Question 3: > ><-------SA---------> >[IP1][ESP][IP2][TCP] > >This is a sort of stupid question. Assume that I have >one ESP SA terminating at the current router. Here a >selector for transport layer protocol is also defined >for this SA. Should the behaviour be to > >a) First match the selector, producing OPAQUE, since > the inner packet is still encrypted. Or > >b) First decrypt the packet, and only then match > the selector, which now succeeds fine. > >Only b) seems sane, but the architecture RFC section >5.2.1 only says > "Use the SA found in (1) to do the IPsec processing, e.g., > authenticate and decrypt. This step includes matching the > packet's (Inner Header if tunneled) selectors to the > selectors in the SA." >This could mean either behaviour. b) is the correct processing, selector comparison is done as said above. > >Question 4: > >What sort of policy filtering does IPSec intend to define >for throughgoing IPSec traffic? > >This is related to the previous question, since if a) >is the intended behaviour, the following sentence at >section 4.4.2 makes a whole lot more sense. >"NOTE: To locate the transport protocol, a system has to chain > through the packet headers checking the "Protocol" or "Next > Header" field until it encounters either one it recognizes as a > transport protocol, or until it reaches one that isn't on its > list of extension headers, or until it encounters an ESP header > that renders the transport protocol opaque." >Thus for throughgoing traffic, which can't be authenticated >or decrypted, the selector in the policy database would >go inside the protected packet. > During inboundprocessing, if the secprotocol extracted from the packet is neither AH nor ESP then the inbound policies shold be searched for a matching policy, which will lead to a bypass policy (if one present!). Hope this will help . -Rohit From owner-ipsec Wed Dec 2 04:32:41 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id EAA16192 for ipsec-outgoing; Wed, 2 Dec 1998 04:28:55 -0500 (EST) Date: Wed, 2 Dec 1998 11:48:26 +0200 (EET) From: Markku Savela Message-Id: <199812020948.LAA31194@anise.tte.vtt.fi> To: ipsec@tis.com In-reply-to: <199812010231.VAA15466@jekyll.piermont.com> (perry@piermont.com) Subject: Re: Use IPSEC as SSH replacement Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk My query about using some solution based on IPSEC to replace SSH, originates from a desire to demonstrate and do something *useful* with IPSEC as fast as possible, preferrably *NOW*. I was hoping some minimal effort IKE (or something) specification that would give at least the same as SSH, but using IPSEC architecture. A solution that would be forward compatible with future "real" solutions that were mentioned, secure DNS etc., when they become available. It also should be as simple to use as ssh, and free to use (don't require CAs that cost money to get). Just doing PING tests is boring. Is there a test setup with IPSEC on a host that would allow me to telnet in, either to IPSEC host itself or to a some test host behind the IPSEC gateway, or even more ambitious, have AH+ESP (tunnel) to SG, and another AH+ESP layer to the test host behind it [however, I only do with manual keys...]. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Wed Dec 2 05:20:45 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA16311 for ipsec-outgoing; Wed, 2 Dec 1998 05:17:56 -0500 (EST) To: msa@hemuli.tte.vtt.fi (Markku Savela) cc: ipsec@tis.com In-reply-to: msa's message of Wed, 02 Dec 1998 11:48:26 +0200. <199812020948.LAA31194@anise.tte.vtt.fi> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Use IPSEC as SSH replacement Date: Wed, 02 Dec 1998 19:36:38 +0900 Message-ID: <11658.912594998@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipsec@ex.tis.com Precedence: bulk >My query about using some solution based on IPSEC to replace SSH, >originates from a desire to demonstrate and do something *useful* with >IPSEC as fast as possible, preferrably *NOW*. I was hoping some >minimal effort IKE (or something) specification that would give >at least the same as SSH, but using IPSEC architecture. I was thinking about using SSH's host key pair for IKE daemon, for some months. Thinking about granurality of protection, I think it is not very good way. 1. user A performs ssh session from host X to host Y. This installs Y's public key into ~A/.ssh/known_hosts. 2. user A performs ssh session from host Y to host X. Now, X has Y's public key, Y has X's public key. 3. kick IKE daemon for negotiating IPsec SA, by using /etc/ssh_host_key and ~A/.ssh/known_hosts. In (1) and (2) ssh works as "public key distribution mechanism". Notice that there's almost no authentication other than "do you really want to perform ssh session to A (yes/no)" in (1) and (2). Any experiences are welcomed... itojun From owner-ipsec Wed Dec 2 08:06:57 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA16746 for ipsec-outgoing; Wed, 2 Dec 1998 08:02:55 -0500 (EST) Message-ID: <36653EFB.7ECC32A0@cyphers.net> Date: Wed, 02 Dec 1998 05:22:07 -0800 From: Will Price X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: Use IPSEC as SSH replacement References: <199812020948.LAA31194@anise.tte.vtt.fi> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Well, that pretty much rules out X.509 certs. I don't think what you want exists today, but the specs for IPSEC certainly support it. The following would solve the issue were the following to exist: 1] Use IKE with OpenPGP certs. They don't constantly expire, don't cost money, and you can use whatever trust model you want with them (hierarchy, WOT, etc...) The ISAKMP RFC already has an ID for OpenPGP certs, so no changes required. (see RFC 2044 for OpenPGP) 2] To be just like SSH in terms of ease of use, your IKE implementation must be able to be configured such that the certificate received when the first Phase 1 SA is established with any other host on the internet is implictly accepted. That certificate from then on is required for authentication whenever communicating with the same remote host. While this introduces a minor security issue for first connections, this is something most people have been willing to live with for years with SSH. To eliminate this security issue, just use the web of trust to validate the certs. If that doesn't scale to your organization, use OpenPGP meta-introducers to establish a hierarchy. One day if these worldwide CA-based pay-for-each-cert IPSEC X.509 PKI ramblings become accepted and popular, your IKE implementation could also support X.509 and be compatible with that too. In the meantime, I agree that it would be nice to get IKE widely usable without the hurdles that seem to have been erected for it. -Will Markku Savela wrote: > My query about using some solution based on IPSEC to replace SSH, > originates from a desire to demonstrate and do something *useful* with > IPSEC as fast as possible, preferrably *NOW*. I was hoping some > minimal effort IKE (or something) specification that would give > at least the same as SSH, but using IPSEC architecture. > > A solution that would be forward compatible with future "real" > solutions that were mentioned, secure DNS etc., when they become > available. It also should be as simple to use as ssh, and free to use > (don't require CAs that cost money to get). > > Just doing PING tests is boring. Is there a test setup with IPSEC on a > host that would allow me to telnet in, either to IPSEC host itself or > to a some test host behind the IPSEC gateway, or even more ambitious, > have AH+ESP (tunnel) to SG, and another AH+ESP layer to the test host > behind it [however, I only do with manual keys...]. > > -- > Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland > Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ -- Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. Direct (408)346-5906 Cell/VM (650)533-0399 PGPkey: From owner-ipsec Wed Dec 2 09:20:24 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA17168 for ipsec-outgoing; Wed, 2 Dec 1998 09:18:57 -0500 (EST) Message-Id: <9812021443.AA21210@anuxc.mv.lucent.com> X-Sender: dac@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 02 Dec 1998 09:40:13 -0500 To: ipsec@tis.com From: Dave Clark Subject: IKE signature payload Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello; The cryptographic library I'm using for IKE has an RSA_Sign routine which returns a 'sign length' indicating the number of significant bits in the created signature. This length may not be a multiple of 8. The corresponding RSA_Verify routine needs to know this length. I can't see how to encode the signature length in bits into the Signature payload ... should my RSA implementation be handling the padding of the signature to the byte boundary, for signature creation and verification? Thanks in advance. _________________________ Dave Clark Secure Technologies Lucent Technologies/Bell Labs dac@lucent.com From owner-ipsec Wed Dec 2 10:05:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA17430 for ipsec-outgoing; Wed, 2 Dec 1998 10:04:59 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <36653EFB.7ECC32A0@cyphers.net> References: <199812020948.LAA31194@anise.tte.vtt.fi> Date: Wed, 2 Dec 1998 10:23:30 -0500 To: Will Price From: Stephen Kent Subject: Re: Use IPSEC as SSH replacement Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Will, >Well, that pretty much rules out X.509 certs. What are you possibly referring to? >I don't think what you want exists today, but the specs for IPSEC certainly >support it. The following would solve the issue were the following to exist: > >1] Use IKE with OpenPGP certs. They don't constantly expire, don't cost >money, >and you can use whatever trust model you want with them (hierarchy, WOT, >etc...) X.509 certs have no intrinsic cost, expiration times are set by the CA, and the structure of the PKI in which they exist is determined by the community in which they are used. Your comments here suggest that you are equating a VeriSign model of a public PKI with what X.509 really allows and how it is often used. >One day if these worldwide CA-based pay-for-each-cert IPSEC X.509 PKI >ramblings >become accepted and popular, your IKE implementation could also support >X.509 and >be compatible with that too. In the meantime, I agree that it would be >nice to >get IKE widely usable without the hurdles that seem to have been erected >for it. Yes, this paragraph strongly suggests that your model of X.509 certs is unduly influenced by VeriSign and is not representative of the underlying technology. Steve From owner-ipsec Wed Dec 2 10:26:12 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA17640 for ipsec-outgoing; Wed, 2 Dec 1998 10:24:58 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199812012105.QAA04376@smb.research.att.com> Date: Wed, 2 Dec 1998 10:36:41 -0500 To: "Steven M. Bellovin" From: Stephen Kent Subject: Re: Use IPSEC as SSH replacement Cc: Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, >The issue with IPSEC is the granualarity of protection. In particular, >if host-level or gateway-level protection is used, how can an application >request some minimum level of protection, find out what is in fact being >used, and look at the certificate presented. For many purposes, a replacement >for ssh would need these abilities. In a native host implementation, an application can determine what IPsec services are applied to each data stream. The only real issue is the API for doing this, and I thought PFKey was a step in that direction. Certainly one cannot have the same sort of application control in a BITS or BITW or security gateway implementation, but that's not an IPsec limitation per se, but a result of all of the IPsec implementation options vs. the more limited options available for an application layer security protocol. Steve From owner-ipsec Wed Dec 2 11:13:34 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA17992 for ipsec-outgoing; Wed, 2 Dec 1998 11:12:59 -0500 (EST) From: Dan McDonald Message-Id: <199812021631.IAA11588@kebe.eng.sun.com> Subject: Re: Use IPSEC as SSH replacement To: kent@bbn.com (Stephen Kent) Date: Wed, 2 Dec 1998 08:31:34 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: from "Stephen Kent" at Dec 2, 98 10:36:41 am X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > In a native host implementation, an application can determine what IPsec > services are applied to each data stream. The only real issue is the API > for doing this, and I thought PFKey was a step in that direction. PF_KEY does not solve this problem. It solves the "user-level IKE daemon talking to the kernel SADB" problem. I had some "IPsec socket API extensions" drafts out a while back. Craig Metz has a "net-security-api" draft out. This is the sort of API that you're talking about, Steve. Dan From owner-ipsec Wed Dec 2 12:00:25 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA18197 for ipsec-outgoing; Wed, 2 Dec 1998 11:52:58 -0500 (EST) Message-ID: <36657396.CEBBE3B@checkpoint.com> Date: Wed, 02 Dec 1998 19:06:30 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tis.com Subject: Minor Security issues regarding Kb rekeying Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk There are two minor security issues regarding Kb rekeying. For IKE SAs: It is possible for an IKE SA to expire its KB lifetime without the peers that established this SA knowing it. For example, suppose that 2 peers established an IKE SA with a life duration of 10 Kb, Each peer encrypting 5 Kbytes using this SA but only 4 Kbytes reach their destination and 2 Kb get lost on the way. In this case each peer thinks only 9 Kb of material was encrypted whereas the IKE SA should have been expired. For IPSEC SAs: Suppose an IPSEC SA with a lifetime of 1000Kb was established between two peer. Alice encrypts 1000Kb of data using this SA but only 900Kb of encrypted data reach Bob. Eve has now 1000Kb of encrypted data and can after cracking the SAs keys, transmit data to Bob who thinks this SA is still valid. -- ======================================================================== Zegman Tamir Encryption group, R&D Tel: +972-3-7534606 Check Point Software Tech. Ltd. Fax: +972-3-5759256 3A Jabotinsky St., Diamond Tower Ramat-Gan 52520, ISRAEL e-mail: zegman@checkpoint.com http://www.checkpoint.com ======================================================================== From owner-ipsec Wed Dec 2 12:20:16 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA18304 for ipsec-outgoing; Wed, 2 Dec 1998 12:19:59 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF6172DF@exchange> From: Tim Jenkins To: Tamir Zegman , ipsec@tis.com Subject: RE: Minor Security issues regarding Kb rekeying Date: Wed, 2 Dec 1998 12:40:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Tamir Zegman [mailto:zegman@checkpoint.com] > Sent: Wednesday, December 02, 1998 12:07 PM > To: ipsec@tis.com > Subject: Minor Security issues regarding Kb rekeying > > > For IPSEC SAs: > Suppose an IPSEC SA with a lifetime of 1000Kb was established between > two peer. > Alice encrypts 1000Kb of data using this SA but only 900Kb of > encrypted > data reach Bob. > Eve has now 1000Kb of encrypted data and can after cracking the SAs > keys, transmit data to Bob who > thinks this SA is still valid. > Not if Alice sends a required and reliable delete indication to Bob. Oh, wait, we don't have one!! See my re-keying document for a proposal for a delete mode that can help reduce problems like this. From owner-ipsec Wed Dec 2 12:29:17 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA18318 for ipsec-outgoing; Wed, 2 Dec 1998 12:28:58 -0500 (EST) Message-ID: From: Greg Carter To: ipsec@tis.com, "'Dave Clark'" Subject: RE: IKE signature payload Date: Wed, 2 Dec 1998 12:39:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Yes, however IKE uses PKCS#1 style padding. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > ---------- > From: Dave Clark[SMTP:dac@lucent.com] > Sent: Wednesday, December 02, 1998 9:40 AM > To: ipsec@tis.com > Subject: IKE signature payload > > Hello; > > The cryptographic library I'm using for IKE has an RSA_Sign routine > which returns a 'sign length' indicating the number of significant > bits in the created signature. This length may not be a multiple of 8. > The corresponding RSA_Verify routine needs to know this length. I can't > see how to encode the signature length in bits into the Signature payload > ... should my RSA implementation be handling the padding of the signature > to the byte boundary, for signature creation and verification? Thanks in > advance. > > _________________________ > Dave Clark > Secure Technologies > Lucent Technologies/Bell Labs > dac@lucent.com > From owner-ipsec Wed Dec 2 13:31:05 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA18669 for ipsec-outgoing; Wed, 2 Dec 1998 13:30:03 -0500 (EST) Date: Wed, 2 Dec 1998 14:03:06 -0800 (PST) From: "Hilarie K. Orman" Message-Id: <199812022203.OAA05510@earth.hpc.org> To: tjenkins@TimeStep.com Cc: ipsec@tis.com, zegman@checkpoint.com In-reply-to: Yourmessage <319A1C5F94C8D11192DE00805FBBADDF6172DF@exchange> Subject: RE: Minor Security issues regarding Kb rekeying Sender: owner-ipsec@ex.tis.com Precedence: bulk It's Bob's problem if he wants to keep accepting data from an old SA (and if Eve has had time to break the key, the SA is surely old). I've become concerned about a slightly different matter with rekeying. Suppose Eve records and jams the Alice-Bob line for the duration of an SA use on a TCP connection ... she doesn't like the key. Bob and Alice change to a new SA, according to their preferred schedule. They retransmit all the previous information in a new key. Eve can keep doing this until Alice and Bob change to a key she prefers. This defeats some of the objectives of anti-replay and of using rekeying at all. It's a leap of faith to say that Eve could be in position to prefer some keys over others, so this is largely a gedanken concern, but still ... Hilarie From owner-ipsec Wed Dec 2 13:35:10 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA18710 for ipsec-outgoing; Wed, 2 Dec 1998 13:35:00 -0500 (EST) Message-Id: <199812021852.NAA07810@smb.research.att.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Stephen Kent Subject: Re: Use IPSEC as SSH replacement cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Dec 1998 13:52:30 -0500 From: "Steven M. Bellovin" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Stephen Kent writes: >Steve, > >>The issue with IPSEC is the granualarity of protection. In particular, >>if host-level or gateway-level protection is used, how can an application >>request some minimum level of protection, find out what is in fact being >>used, and look at the certificate presented. For many purposes, a replacemen >t >>for ssh would need these abilities. > >In a native host implementation, an application can determine what IPsec >services are applied to each data stream. The only real issue is the API >for doing this, and I thought PFKey was a step in that direction. >Certainly one cannot have the same sort of application control in a BITS or >BITW or security gateway implementation, but that's not an IPsec limitation >per se, but a result of all of the IPsec implementation options vs. the >more limited options available for an application layer security protocol. Precisely. As for PFkey -- Dan and I have talked at some length about the requirements for an advanced API. But there's still a lot more to be done. From owner-ipsec Wed Dec 2 14:30:14 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA19025 for ipsec-outgoing; Wed, 2 Dec 1998 14:30:01 -0500 (EST) Message-Id: <199812021948.TAA27813@orchard.arlington.ma.us> To: "Hilarie K. Orman" cc: tjenkins@TimeStep.com, ipsec@tis.com, zegman@checkpoint.com Subject: Re: Minor Security issues regarding Kb rekeying In-reply-to: Your message of "Wed, 2 Dec 1998 14:03:06 -0800 (PST) ." <199812022203.OAA05510@earth.hpc.org> Date: Wed, 02 Dec 1998 14:48:30 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > I've become concerned about a slightly different matter with rekeying. > Suppose Eve records and jams the Alice-Bob line for the duration of an > SA use on a TCP connection ... she doesn't like the key. Bob and > Alice change to a new SA, according to their preferred schedule. Given TCP's behavior (particularly in the presence of slow start), Eve would get at most a window's full of data, plus a bunch of retransmitted copies of one segment before Alice stopped transmitting.. (Hmm. the latter could be used as a potential aid to cryptanalysis in and of itself..).. > It's a leap of faith to say that Eve could be in position to prefer > some keys over others, so this is largely a gedanken concern, but > still ... I think algorithms known to have this property are not really suitable for use with IPSEC.. - Bill From owner-ipsec Wed Dec 2 14:43:28 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA19102 for ipsec-outgoing; Wed, 2 Dec 1998 14:43:02 -0500 (EST) Message-Id: <199812022001.UAA27866@orchard.arlington.ma.us> To: Tamir Zegman cc: ipsec@tis.com Subject: Re: Minor Security issues regarding Kb rekeying In-reply-to: Your message of "Wed, 02 Dec 1998 19:06:30 +0200 ." <36657396.CEBBE3B@checkpoint.com> Date: Wed, 02 Dec 1998 15:01:32 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > For IPSEC SAs: > Suppose an IPSEC SA with a lifetime of 1000Kb was established > between two peer. Alice encrypts 1000Kb of data using this SA but > only 900Kb of encrypted data reach Bob. Eve has now 1000Kb of > encrypted data and can after cracking the SAs keys, transmit data to > Bob who thinks this SA is still valid. The comments about explicit SA deletes being the answer here are part of the story. Howevver, I think is that this is one of the places where a margin of safety comes into play... if the algorithm is crackable in near-real-time with ~900kb of traffic, the per-key limit should be much smaller than ~1000kb.. Also, if you're trying to make a marginal/weak algorithm "safe" to use to secure real-time communications which don't have to be secret forever, you clearly want to use both Kb and time limits on the SA. - Bill From owner-ipsec Wed Dec 2 15:09:21 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA19347 for ipsec-outgoing; Wed, 2 Dec 1998 15:09:08 -0500 (EST) Message-ID: <3665A2E7.58CFF6A4@lmf.ericsson.se> Date: Wed, 02 Dec 1998 22:28:23 +0200 From: Ari Huttunen Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: rohit@trinc.com CC: Huttunen_Ari/OM/LMF@seeripo1.ericsson.se, ipsec@tis.com Subject: Re: SA bundles, multiple tunnels? References: <3.0.1.32.19981202101651.00946840@172.16.1.10> Content-Type: multipart/mixed; boundary="------------E11210529D397187BBE291A0" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------E11210529D397187BBE291A0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit rohit@trinc.com wrote: > >Question 1: > > > >Can one SA be a part of more than one SA bundle? > > > Yes, SA can be part of more than one SA bundle, if you allow sharing of SAs. OK. I hadn't looked at ISAKMP / IPSEC DOI stuff yet, but after I did that I can understand what you mean. I.e. you can negotiate the SA bundle == SA payload as follows. Since you can specify the SPI value in this negotiation, the answer was "yes". (Q.E.D. ;-) SA Payload Proposal payload / SPI Transform payload AND Proposal payload / SPI Transform payload OR Transform payload OR Proposal payload / SPI Transform payload OR Transform payload > >Question 2: > > > ><-------SA1----------------> > > <-------SA2------> > >[IP1][AH][IP2][AH][IP3][TCP] > > > >Assume that I have two tunnel mode AH SAs. Both > >of these SAs terminate at the current router. I further > >define for both SAs a selector for "Transport Layer > >Protocol". What should they match? Will the selector > >for SA1 match "IP" or will it go further down the > >headers all the way to "TCP"? > > In the inbound IPSec Processing, all the SAs applied will be collected in a > SA Bundle, the selectors of the last SA applied will be compared with the > pkt selectors. Since the selectors wont change from one SA to the other SA > for one SABundle. Thus the transport protocol will be TCP while matching > the selectors. It seems I read the architecture draft somewhat incorrectly. Would the following be correct? An SPD entry defines a set of selectors. When a corresponding SAD entry is created, the selectors are either given the value inside the packet or inside the SPD entry (instantiated). The instantiated selectors are associated with the SA bundle in the SAD. A shared SA, i.e. one that appears in several SA bundles, could be associated with several sets of instantiated selectors, with one set in each bundle. > > > >Question 3: > > > ><-------SA---------> > >[IP1][ESP][IP2][TCP] > > > >This is a sort of stupid question. Assume that I have > >one ESP SA terminating at the current router. Here a > >selector for transport layer protocol is also defined > >for this SA. Should the behaviour be to > > > >a) First match the selector, producing OPAQUE, since > > the inner packet is still encrypted. Or > > > >b) First decrypt the packet, and only then match > > the selector, which now succeeds fine. > > > >Only b) seems sane, but the architecture RFC section > >5.2.1 only says > > "Use the SA found in (1) to do the IPsec processing, e.g., > > authenticate and decrypt. This step includes matching the > > packet's (Inner Header if tunneled) selectors to the > > selectors in the SA." > >This could mean either behaviour. > > b) is the correct processing, selector comparison is done as said above. Let's rephrase the question. Suppose I wish to define either of the following security policies. (Of course the firewall couldn't actually check authentication.) [IP1][AH][IP2][TCP] "all throughgoing TCP traffic to port X must be authenticated in tunnel mode". [IP1][AH][TCP] "all throughgoing TCP traffic to port X must be authenticated in transport mode". Would I be able to use the transport layer protocol and destination port selectors in the SPD to give these sorts of traffic a bypass policy? Would I need additional implementation dependant selectors? > Hope this will help . > > -Rohit Sure. Thanks. ///Ari --------------E11210529D397187BBE291A0 Content-Type: text/x-vcard; charset=us-ascii; name="Ari.Huttunen.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ari Huttunen Content-Disposition: attachment; filename="Ari.Huttunen.vcf" begin:vcard n:Huttunen;Ari tel;fax:+358-9-2992634 tel;work:+358-9-2992472 x-mozilla-html:FALSE org:L M Ericsson;LMF/T/TK version:2.1 email;internet:Ari.Huttunen@lmf.ericsson.se title:Software Designer adr;quoted-printable:;;Oy L M Ericsson Ab=0D=0ATelecom R&D;;;02420 Jorvas;Finland x-mozilla-cpt:;-30024 fn:Ari Huttunen end:vcard --------------E11210529D397187BBE291A0-- From owner-ipsec Wed Dec 2 23:32:05 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA21389 for ipsec-outgoing; Wed, 2 Dec 1998 23:29:13 -0500 (EST) Message-Id: <199812030448.UAA27741@chip.cisco.com> To: ipsec@tis.com Subject: IKE stuff, was Re: Agenda stuff In-reply-to: Your message of "Tue, 01 Dec 1998 16:13:03 PST." <199812020013.QAA28477@chip.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27738.912660479.1@cisco.com> Date: Wed, 02 Dec 1998 20:47:59 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 01 Dec 1998 16:13:03 PST I wrote > > 1. What type of cert encoding is used in a cert request payload > if you wish to obtain the peer's encryption certificate (assuming > the peer has one signature only and one for encipherment only)? > > ISAKMP mentions "X.509 Certificate - Signature" and "X.509 Certificate - > Key Exchange". Signature should be out of the question because if you have > a cert restricted to signatures only that's not the one to request to > do encryption with. So is it "Key Exchange"? Is this merely a semantic > problem in that that doesn't sound too informative? This is a bit misleading, thanks to Steve Kent for pointing that out. There are actually two issues here and neither is really discribed by the above rambling. One issue is that ISAKMP should have "encoding types" to request X509 certificates for each type of certificate possible-- signature, keyEncipherment, dataEncipherment, did-I-miss-anything. The other is which one do you use when doing IKE's "RSA encrypted nonce" authentication? I guess the former is not really an issue that needs much discussion. It should be self-evident. The latter though can be contentious. In an effort to jump-start some contention I'll state that it should be "keyEncipherment" since the decrypted nonces are used to generate the SKEYID state. Dan. From owner-ipsec Thu Dec 3 03:07:37 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id DAA21996 for ipsec-outgoing; Thu, 3 Dec 1998 03:06:11 -0500 (EST) Message-ID: <36664ACC.B8FDE4FA@checkpoint.com> Date: Thu, 03 Dec 1998 10:24:44 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: ipsec@tis.com Subject: Re: Minor Security issues regarding Kb rekeying References: <319A1C5F94C8D11192DE00805FBBADDF6172DF@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim Jenkins wrote: > > Not if Alice sends a required and reliable delete indication to Bob. > Oh, wait, we don't have one!! > > See my re-keying document for a proposal for a delete mode that can > help reduce problems like this. Even if you had this proposed delete mode, you still cannot make sure this delete gets to Bob. Eve (or should I say Mallory) could still prevent this delete from reaching Bob. Anyway, I don't think this should be considered a major security issue. Maybe it's worth mentioning in one of the Security Considerations paragraphs. -- ======================================================================== Zegman Tamir Encryption group, R&D Tel: +972-3-7534606 Check Point Software Tech. Ltd. Fax: +972-3-5759256 3A Jabotinsky St., Diamond Tower Ramat-Gan 52520, ISRAEL e-mail: zegman@checkpoint.com http://www.checkpoint.com ======================================================================== From owner-ipsec Thu Dec 3 08:30:15 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA23049 for ipsec-outgoing; Thu, 3 Dec 1998 08:28:11 -0500 (EST) Date: Thu, 3 Dec 1998 15:46:55 +0200 (EET) Message-Id: <199812031346.PAA05582@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Will Price Cc: ipsec@tis.com Subject: Re: Use IPSEC as SSH replacement In-Reply-To: <36653EFB.7ECC32A0@cyphers.net> References: <199812020948.LAA31194@anise.tte.vtt.fi> <36653EFB.7ECC32A0@cyphers.net> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 14 min X-Total-Time: 13 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Will Price writes: > Well, that pretty much rules out X.509 certs. Not really. It rules out normal use of X.509 certificates and CA's. Also the normal X.509 trust model is not usefull in that case. But you can just create self signed certificates for each host, and when you see first occurance of that certificate you store it to some database and next time you take connection to that host you check that the public key is still same. This is what the SSH program does. When you first time connect to new host it prints out message saying that the host key is not found from the local database, and requests you to verify that you really want to continue this operation. If you answer yes to that then it just takes the public key and stores it to the local database. Next time it just verifies that the public key is still same and if it is it allows you to take connection. If the public key ever changes it prints out large banner warning you that something nasty is going on, and requests verification that user really want to continue operation. This makes man in the middle attacks possible, but only for the first connection attempt. After the first connection without man in the middle it is safe. So this is just compromise between security and usablity. > I don't think what you want exists today, but the specs for IPSEC certainly > support it. The following would solve the issue were the following to exist: > > 1] Use IKE with OpenPGP certs. They don't constantly expire, don't > cost money, and you can use whatever trust model you want with them > (hierarchy, WOT, etc...) The ISAKMP RFC already has an ID for > OpenPGP certs, so no changes required. (see RFC 2044 for OpenPGP) PGP certificate would of course be better than X.509 certificates because the trust model is already different, and you can propably use the normal PGP web of trust model without change. The problem is that I don't know any implementations that support PGP certificates in IKE. > 2] To be just like SSH in terms of ease of use, your IKE > implementation must be able to be configured such that the > certificate received when the first Phase 1 SA is established with > any other host on the internet is implictly accepted. That I think we must consult the user about this. Otherwise we are vulnerable to DNS attacks. The attacker just changes the www.foo.com IP address to something else and that happens to be new host, so the IKE will see new public key from the new host. If we put dialog to user, he can see that something funny is going on, this host should be already inside my database... > certificate from then on is required for authentication whenever > communicating with the same remote host. While this introduces a > minor security issue for first connections, this is something most > people have been willing to live with for years with SSH. To > eliminate this security issue, just use the web of trust to validate > the certs. If that doesn't scale to your organization, use OpenPGP > meta-introducers to establish a hierarchy. > > One day if these worldwide CA-based pay-for-each-cert IPSEC X.509 > PKI ramblings become accepted and popular, your IKE implementation > could also support X.509 and be compatible with that too. In the > meantime, I agree that it would be nice to get IKE widely usable > without the hurdles that seem to have been erected for it. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Thu Dec 3 08:45:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA23104 for ipsec-outgoing; Thu, 3 Dec 1998 08:44:11 -0500 (EST) Message-ID: From: Greg Carter To: ipsec@tis.com, "'Daniel Harkins'" Subject: RE: IKE stuff, was Re: Agenda stuff Date: Thu, 3 Dec 1998 08:56:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Agreed. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > I guess the former is not really an issue that needs much discussion. > It should be self-evident. The latter though can be contentious. In an > effort to jump-start some contention I'll state that it should be > "keyEncipherment" since the decrypted nonces are used to generate the > SKEYID state. > > Dan. > From owner-ipsec Thu Dec 3 12:40:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA23841 for ipsec-outgoing; Thu, 3 Dec 1998 12:34:14 -0500 (EST) Date: Thu, 3 Dec 1998 17:46:10 +0200 (EET) Message-Id: <199812031546.RAA06867@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Daniel Harkins Cc: Robert Moskowitz , ipsec@tis.com Subject: Re: Agenda stuff In-Reply-To: <199812020013.QAA28477@chip.cisco.com> References: <4.1.19981127123012.00b9eef0@homebase.htt-consult.com> <199812020013.QAA28477@chip.cisco.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 28 min X-Total-Time: 39 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > 1. What type of cert encoding is used in a cert request payload > if you wish to obtain the peer's encryption certificate (assuming > the peer has one signature only and one for encipherment only)? > ISAKMP mentions "X.509 Certificate - Signature" and "X.509 Certificate - > Key Exchange". Signature should be out of the question because if you have > a cert restricted to signatures only that's not the one to request to > do encryption with. So is it "Key Exchange"? Is this merely a semantic > problem in that that doesn't sound too informative? I think we should at least change the name from Key Exchange to something else (Key Encipherment?). The PKIX defines Diffie-Hellman Key Exchange Key (draft-ietf-pkix-ipki-part1-11.txt: 7.3.2), and I don't know whether the rfc 2408 (isakmp) "X.509 Certificate - Key exchange" means that or the encryption capable RSA key. > 4. Clarification on what SPI to use during transactional exchanges like > new group mode or configuration mode. > > How about none? There are two issues. 1) What spi use inside the SA payload in the negotiation. For transactional mode this is easy, because there is no SA payload, so it cannot have any SPIs. For new group mode there is no real meaningfull information to put in the SPI field, so it can be left empty (zero length). 2) What to put in to the error notification payloads SPI field, when you want to send back error message for new group mode or transactional mode. The notification payload has a SPI field that can be used to find out the correct exchange. Now if we have multiple new group mode exchanges going on, and the other end sends us a error notification we do not know which of the new group modes failed. I wrote earlier, that we should define generic method of putting the message id of the negotiation inside the notification payload. The message id is the only way to uniquely identify the new group mode or transactional exchange: ---------------------------------------------------------------------- Generic error/status notification to any phase II negotiation using message ID to identify the negotiation: o Payload Length - set to length of payload + size of data (var) o DOI - set to IPSEC DOI (1) o Protocol ID - set to PROTO_ISAKMP (1) o SPI Size - set to four (4) bytes (if it is sixteen (16), then SPI is two eight-octet ISAKMP cookies, and the error message is for the Phase I negotiation) o Notify Message Type - set to error code o SPI - set to the message ID (4 bytes) of the negotiation o Notification Data - fill in as normally. ---------------------------------------------------------------------- This method could be used to send notification to either to all phase II exchanges, or only to all other phase II exchanges except Quick Mode. In the quick mode we still have some problems, that the sender can select any of the protocols, and spis inside the SA proposal the other end offered, so we have to loop through all quick mode exchanges we have, and compare each protocol and spi inside each proposal to find the matching spi. I would rather use that above mentioned simplified method for them too, but we might just want to keep that old method for quick mode, so we do not change anything at this stage, we just allow new way of sending error codes for exchanges where it is not yet defined. > 5. Some verbage needed to specify when to start using the IKE SA to > protect notification exchanges. As soon as "crypto active" which could > screw up the running IV or after the phase 1 exchange which could > leave some notifies unprotected? > > This is an issue if you want to send a notify after the Diffie-Hellman > exchange has completed but before the SA has been authenticated. IKE says > "If the ISAKMP security association has not yet been established at the > time of the Informational Exchange, the exchange is done in the clear > without an accompanying HASH payload." So I guess that means it goes in > the clear but then that can open us up to attack. It doesn't really matter. If you accept any informational exchanges in clear, then it always opens denial of service attack. Attacker can always answer to your first SA proposal with a informational exchange saying proposal not chosen... > So should we say that the IV used to encrypt the message (in the > unauthenticated key by the way) is generated the same way in this > case as it is for the post-established SA case? I don't think so. I think we should say that all informational exchanges done before the Phase I is finishes, is done in clear unless we have previous Phase I exchange still available (rekeying case). > In other words, a hash of the last phase 1 CBC output block and the > message ID of the notify. And since the last phase 1 CBC output block has > not be determined yet the IV would be a hash of the message ID. I don't think that would gain as anything, because the keys are not yet authenticated. The Diffie-Hellman is only authenticated after the signature/hash payloads have been verified by the both ends, so we cannot really trust keys before that. Sending exchanges authenticated would just give out false sense of security. > 6. A rewrite of the wording in section 3.5 in the ISAKMP document that > seems to mandate a covert channel. > > Kivinen has suggested the following text: > > "During phase 1 negotiations, the initiator and responder cookies > determine the ISAKMP SA. Therefore, the SPI field in the Proposal > payload is redundant and its size MUST be set to 0." > > as a replacement for: > > "In the case of ISAKMP, the Initiator and Responder cookie pair > from the ISAKMP Header is the ISAKMP SPI, therefore, the SPI > Size is irrelevant and MAY be from zero (0) to sixteen (16). If > the SPI Size is non-zero, the content of the SPI field MUST be > ignored." > > which just seems broken. That sounds good. Doug (Maughan) do you have any > input here? Note, that there are two places that contains the same text, both must be fixed. The other place is: "During phase 1 negotiations, the initiator and responder cookies determine the ISAKMP SA. Therefore, the SPI field in the Proposal payload is redundant and MAY be set to 0 or it MAY contain the transmitting entity's cookie." -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Thu Dec 3 13:06:40 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA24087 for ipsec-outgoing; Thu, 3 Dec 1998 13:06:23 -0500 (EST) Message-ID: <3666D7A0.1E894C9A@shiva.com> Date: Thu, 03 Dec 1998 13:25:36 -0500 From: Jesse Walker Organization: Shiva Corporation X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Daniel Harkins CC: ipsec@tis.com Subject: Re: Agenda stuff References: <199812020013.QAA28477@chip.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan: > On Fri, 27 Nov 1998 15:23:15 EST Robert Moskowitz wrote > > > > (I know there is more here than we can cover in 2 hours. If some of this > > is straightforward we can handle it on the list. I would like to see if we > > have a pending set of documents ready for last call and to define what is > > important to everyone for 'IPsec ond'). > > > > Outstanding Items: > > > > Revs for IKE D. Harkins > > Perhaps the "Revs for IKE" is straightforward enough that we can handle it > on the list. Let's try. > > The IKE/DOI errata are at http://www.lounge.org/ike_doi_errata.html. > Most of these issues have obvious solutions which are mentioned along with > the issue (like "add group 5"). Some don't. Here's suggestions for those > that don't. These are not intended on being THE WAY but only to encourage > discussion on these matters since no one seems to be discussion them on > this list. > > 1. What type of cert encoding is used in a cert request payload > if you wish to obtain the peer's encryption certificate (assuming > the peer has one signature only and one for encipherment only)? > > ISAKMP mentions "X.509 Certificate - Signature" and "X.509 Certificate - > Key Exchange". Signature should be out of the question because if you have > a cert restricted to signatures only that's not the one to request to > do encryption with. So is it "Key Exchange"? Is this merely a semantic > problem in that that doesn't sound too informative? > > 2. Addition of new elliptic curve groups. Possibly add groups over F2^p, > where p is prime. Open item is whether this goes in IKE or becomes a > standalone BCP-type RFC. > > Perhaps those who want new groups can suggest a resolution to this. > > 3. There are issues surrounding the rekeying of both phase1 (IKE) and > phase2 (IPSec) SAs. "IPSec Re-keying Issues" [Tim Jenkin's document] > discusses these. > > Since Tim is presenting his document next week we can punt this one. > > 4. Clarification on what SPI to use during transactional exchanges like > new group mode or configuration mode. > > How about none? > > 5. Some verbage needed to specify when to start using the IKE SA to > protect notification exchanges. As soon as "crypto active" which could > screw up the running IV or after the phase 1 exchange which could > leave some notifies unprotected? > > This is an issue if you want to send a notify after the Diffie-Hellman > exchange has completed but before the SA has been authenticated. IKE says > "If the ISAKMP security association has not yet been established at the > time of the Informational Exchange, the exchange is done in the clear > without an accompanying HASH payload." So I guess that means it goes in > the clear but then that can open us up to attack. So should we say that > the IV used to encrypt the message (in the unauthenticated key by the way) > is generated the same way in this case as it is for the post-established SA > case? In other words, a hash of the last phase 1 CBC output block and the > message ID of the notify. And since the last phase 1 CBC output block has > not be determined yet the IV would be a hash of the message ID. > > 6. A rewrite of the wording in section 3.5 in the ISAKMP document that > seems to mandate a covert channel. > > Kivinen has suggested the following text: > > "During phase 1 negotiations, the initiator and responder cookies > determine the ISAKMP SA. Therefore, the SPI field in the Proposal > payload is redundant and its size MUST be set to 0." > > as a replacement for: > > "In the case of ISAKMP, the Initiator and Responder cookie pair > from the ISAKMP Header is the ISAKMP SPI, therefore, the SPI > Size is irrelevant and MAY be from zero (0) to sixteen (16). If > the SPI Size is non-zero, the content of the SPI field MUST be > ignored." > > which just seems broken. That sounds good. Doug (Maughan) do you have any > input here? > > There are 3 issues that effect interoperability that need to be addressed > in son-of-IPSec so we can leave those for later. But it would be nice if > we could come to some resolution on these other issues. Also, check out > the web page. If any of those issues I didn't mention don't seem to have > a straightforward solution please point that out and suggest one. > > Dan. An item that has arisen before but is covered neither by the errata nor the above discussion is whether the kilobytes lifetype may be used for phase 1. More generally, it would be useful to indicate definitively which SA proposal attributes MUST be negotiated in a phase 1 proposal, which in a phase 2 proposal, which are optional, and which, if any, are expressly forbidden in one of the two phases. -- Jesse Walker Consulting Engineer Shiva Corporation 28 Crosby Drive Bedford, MA 01730-1437 voice: 781-687-1719 fax: 781-687-1437 e-mail: jwalker@shiva.com From owner-ipsec Thu Dec 3 20:44:20 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA25564 for ipsec-outgoing; Thu, 3 Dec 1998 20:42:22 -0500 (EST) From: "Luis A. Sanchez" Message-Id: <199812040202.CAA03360@nutmeg.bbn.com> Subject: Security Association Map (SAM) To: ipsec@tis.com Date: Thu, 3 Dec 1998 21:02:35 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, While exploring approaches for caching security policies in the Security Policy System (SPS) we devised an algorithm that allows one to transform a set of overlapping security policies into a set of non-overlapping policies. RFC2401 discusses overlapping policies in more detail in section 4.4.1. This finding enabled caching in SPS. However, we soon realized that one could use this algorithm with any policy database. As we all know, the Security Policy Database (SPD) MAY contain policies with overlapping selectors therefore, in order to ensure consistent and predictable traffic processing the SPD entries MUST be ordered and SPDs MUST be searched always in the same order. This new algorithm guarantees that all policies found in an SPD will include at least one selector with non-overlapping values. One still needs to start with an ordered set of SPD entries especially if there are overlaps, as one would typically specify such rules. This algorithm allows us to reintroduce the notion of the Security Association Map (SAM) as the place to do a quick lookup for outbound traffic to see if any existent SAs or SA bundles are applicable, vs. needing to go back to the SPD to search it for a match. Bump-in-the-stack and Bump-in-the-wire implementations could now benefit from employing traffic oriented, performance dependent or other searching techniques in the SAM. This could be particularly beneficial for security gateways where processing loads are typically high. Since policies in the SPD are unique and non-overlapping, SAM entries, which include selectors and pointers to existing SAs or SA Bundles in the SAD, will also be non-overlapping allowing traffic processing to be deterministic and consistent. The details of the algorithm and some examples are provided in section 10 and appendix B of draft-ietf-ipsec-sps-00.txt, respectively. Thanks, Luis ps: We missed the draft submission deadline by minutes. You can obtain the draft from www.net-tech.bbn.com/pbsm/SPS-design From owner-ipsec Sun Dec 6 02:55:04 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id CAA03085 for ipsec-outgoing; Sun, 6 Dec 1998 02:41:22 -0500 (EST) Message-ID: <366A399B.CA656A5A@checkpoint.com> Date: Sun, 06 Dec 1998 10:00:28 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tis.com CC: Daniel Harkins Subject: Re: Agenda stuff References: <4.1.19981127123012.00b9eef0@homebase.htt-consult.com> <199812020013.QAA28477@chip.cisco.com> <199812031546.RAA06867@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Tero Kivinen wrote: > I wrote earlier, that we should define generic method of putting the > message id of the negotiation inside the notification payload. The > message id is the only way to uniquely identify the new group mode or > transactional exchange: > > ---------------------------------------------------------------------- > Generic error/status notification to any phase II negotiation using > message ID to identify the negotiation: > > o Payload Length - set to length of payload + size of data (var) > o DOI - set to IPSEC DOI (1) > o Protocol ID - set to PROTO_ISAKMP (1) > o SPI Size - set to four (4) bytes (if it is sixteen (16), > then SPI is two eight-octet ISAKMP cookies, and the error > message is for the Phase I negotiation) > o Notify Message Type - set to error code > o SPI - set to the message ID (4 bytes) of the negotiation > o Notification Data - fill in as normally. > ---------------------------------------------------------------------- There is also the issue of Notification data which is not defined anywhere. I think this field should be used in order to convey more detailed information on the reason of failure. If I recall we had this discussion in the Raleigh Bakeoff but it was not resolved. Some proposed to put in the proposal that failed the negotiation, we proposed to put in an ASCII string. I think the first option is not generic enough since it can be used only with regard to failing in selecting an appropriate proposal. Comments? -- ======================================================================== Zegman Tamir Encryption group, R&D Tel: +972-3-7534606 Check Point Software Tech. Ltd. Fax: +972-3-5759256 3A Jabotinsky St., Diamond Tower Ramat-Gan 52520, ISRAEL e-mail: zegman@checkpoint.com http://www.checkpoint.com ======================================================================== From owner-ipsec Mon Dec 7 16:11:50 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA08225 for ipsec-outgoing; Mon, 7 Dec 1998 15:59:30 -0500 (EST) Date: Mon, 7 Dec 1998 23:18:06 +0200 (EET) Message-Id: <199812072118.XAA00057@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Tamir Zegman Cc: ipsec@tis.com, Daniel Harkins Subject: Re: Agenda stuff In-Reply-To: <366A399B.CA656A5A@checkpoint.com> References: <4.1.19981127123012.00b9eef0@homebase.htt-consult.com> <199812020013.QAA28477@chip.cisco.com> <199812031546.RAA06867@torni.ssh.fi> <366A399B.CA656A5A@checkpoint.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 6 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Tamir Zegman writes: > There is also the issue of Notification data which is not defined > anywhere. I think this field should be used in order to convey more > detailed information on the reason of failure. If I recall we had > this discussion in the Raleigh Bakeoff but it was not resolved. I think that is also important issue. > Some proposed to put in the proposal that failed the negotiation, we > proposed to put in an ASCII string. I think the first option is not > generic enough since it can be used only with regard to failing in > selecting an appropriate proposal. Comments? I would like to see that the notification data is always list of attributes. This way we can easily add stuff later when we want to add more things. Currently the RESPONDER-LIFETIME already uses that. In that case we could have new attribute type numbers like: Failing SA proposal 256 Error message text (default: UTF-8, english) 257 ... And then I can include list of two attributes to the notification, one containing the failing SA proposal, and the second onme includes the error message text, saying something like "Phase I proposal rejected because of policy required 3DES encryption, and no proposal matching that was found". -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Mon Dec 7 20:58:17 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA09221 for ipsec-outgoing; Mon, 7 Dec 1998 20:55:28 -0500 (EST) Message-Id: <199812080132.UAA04648@morden.sandelman.ottawa.on.ca> To: nat@livingston.com, policy@raleigh.ibm.com, ietf-aaa@external.cisco.com CC: ipsec@tis.com Reply-To: policy@raleigh.ibm.com Subject: (NAT) Host NAT issues and Security Policy Servers In-reply-to: Your message of "Sun, 06 Dec 1998 20:39:38 CST." <862566D3.0008896F.00@mwgate02.mw.3com.com> Date: Mon, 07 Dec 1998 20:32:19 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- [I'm going to appologize in advance for cross posting so widely. I'm feeling a bit like every working group I attend is dealing with the same problems. I also, due to fog, missed both nat and aaa this morning. I heard the aaa BOF didn't arrive at any clear conclusions, and I'm glad there wasn't a fire drill during the NAT meeting or someone might have been trampled. ] Mike> Jeff, Mike> The framework that is used by DNAT, and now host-NAT, Mike> consists of several fundamental ideas: Mike> - Tunneling between a router or device with a public IP address Mike> and an end host. DNAT specifically supported IPsec tunnelling to the NAT device. This is important to a number of environments where they actually want authenticated outbound firewall traversal. Mike> - Using TCP/UDP ports or some other mechansim or combinations Mike> thereof to uniquely identify hosts from the private address Mike> space. Mike> - Assignment of global IP addresses to hosts for them to use when Mike> talking with the outside world. I want to note that this problem is essentially *IDENTICAL* to do the IPsec road warrior configuration problem. It is also a variation of the problem that Luis et al. designed their security policy system to solve. (draft-ietf-ipsec-sps-00.txt coming to a draft directory near you. I don't have the URL handy right now) Mike> The PDP was meant just to distribute port numbers. Nothing Mike> else. In our way of thinking, assignment of an IP address Mike> or other parameters to a host might as well occur using an Mike> existing extensible protocol, such as DHCP or as part of a Mike> tunnel establishment, rather than reproducing existing Mike> functionality. These parameters may require renegotiation. Mike> See the "Perspectives" section of the DNAT draft for a Mike> discussion of this. The PDP is not limited in any sense. The SPS policy server could well assign numbers. And yes, DHCP could do it. This was suggested for client configuration in the road warrior case. In addition, extensions to ISAKMP are being suggested to do client configuration. Mike> I recently started writing a draft about the general Mike> framework of end-to-end communication through a NAT, listing Mike> the issues that any solution must address. Here are some of Mike> the most relevant issues: I want to point out that IPsec security gateways are essentially stateful routers. Alas, we reinvent ATM! As such, the end-to-end issues with NAT and with IPsec are essentially the same. (ignoring the fact that NAT and IPsec often sit on the same box) As far as I'm concerned, the IP address in protocol problem typified by FTP, IRC (dcc), RealX, is less of a problem. These problems are simple and easily solved both at the NAT stage (after protocol design) and at the protocol design stage. But, getting rid of IP addresses in the TCP data flow doesn't solve anything: The question that should be asked by the IAB is does ICMP work through a NAT/IPsec box. The real issue is not, can NAT work in the presence of end-to-end IPSEC (DNAT and host-NAT are existence proofs that it is possible to do something), nor is the issue that IPsec makes traditional NAT hard to do, but that IPsec and NAT both introduce stateful routing. diffserv tries to not introduce more state. I think, the model that we have essentially converged upon in IPsec, NAT, diffserv, intserv, rap, aaa, qos... is of the end host going out to the network *policy* server and saying: "I'd like to do X" The policy server responds and says: "I'll let you do X, but to do so you will have to perform the following things: A, B, C." If I'm not mistaken (and I probably am, since the closest I ever got to an actual telephone switch, a DMS100, was when I once fixed the test guy's lab Xterminal many years ago), SS7 provides similar types of conversations. To recap, there are multiple protocols (or proposals) so far for carrying questions from the end systems to the intermediate systems: 1. RSVP 2. ISAKMP 3. host NAT, DNAT, DHCP 4. router/prefix discovery stuff in v6. 5. BBN's SPS protocol 6. SOCKS 7. ARP, ND [You may think that ARP doesn't belong, but I think that it does because it is something that one does prior to sending a packet to the node in question. There is no IS unless you consider a bridge to be a layer 2 IS] From intermediate systems to policy servers we have: 1. COPS 2. SPS 3. radius 4. AAA 5. did I miss something? A significant thing about the SPS work is that it operates both from ES to IS, and from IS to IS, and from IS to policy server. In addition, it permits *discovery* of IS systems and associated policy servers in the forwarding path, which isn't something that I see in the other protocols. I would like to see COPS and SPS merged somehow, and I wonder if this can provide the common AAA protocol, as well as the common DNAT/host-NAT, IPsec tunnel end point discovery, ... protocol. I don't know what this does to RSVP in the diffserv border router model. hmm. Pizza is here. ] At IETF43. Continental sucks |1 Fish/2 Fish[ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNmyBlx4XQavxnHg9AQH2AgH/f5ltwjZS94Tiw3z8fJReRyBJXCiypQbX si7pz5NxK+TnQxj5DwmeJydFAxd8hTaYhEzA7eSLyPa7zn0B34MZQg== =IusE -----END PGP SIGNATURE----- From owner-ipsec Mon Dec 7 23:27:57 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA09512 for ipsec-outgoing; Mon, 7 Dec 1998 23:25:27 -0500 (EST) Message-Id: <4.1.19981207231931.00b7f420@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 Dec 1998 23:44:43 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk OK. Here is **AN** Agenda. Sigh. I have done a lot of 15min slot allocations. I suspect that many of these will run shorter and we will have discussion time. Tuesday: Agenda Bashing Ts'o 5 RFC and blocked ID status Ts'o 5 Revs for IKE D. Harkins 10 Revs for DOI D. Piper 5 Rekeying T. Jenkins 15 Rechartering Schiller/ Moskowitz 10 MIBs T. Jenkins 15 Transport friendly ESP Bellovin 15 ICMP handling M. Richardson 15 X.509 req R. Thayer 15 Wednesday: MS Kerberos auth B. Swander 15 Xauth/CFG Pereira 15 Hybrid auth T. Zegman 15 Policy Schema Pereira 15 Policy engine L. Sanchez 15 Core Schema 15 VPN Policy M. Blaze 10 NAT Issues G. Montenegro 15 Mulitcast D. Harkins 5 Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue Dec 8 08:03:14 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA10704 for ipsec-outgoing; Tue, 8 Dec 1998 07:59:26 -0500 (EST) Message-ID: <366D262D.F425C164@checkpoint.com> Date: Tue, 08 Dec 1998 08:14:21 -0500 From: Tamir Zegman Organization: Check Point Software Technologies Ltd. X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tis.com CC: Tero Kivinen Subject: Re: Agenda stuff References: <4.1.19981127123012.00b9eef0@homebase.htt-consult.com> <199812020013.QAA28477@chip.cisco.com> <199812031546.RAA06867@torni.ssh.fi> <366A399B.CA656A5A@checkpoint.com> <199812072118.XAA00057@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Tero Kivinen wrote: > > Some proposed to put in the proposal that failed the negotiation, we > > proposed to put in an ASCII string. I think the first option is not > > generic enough since it can be used only with regard to failing in > > selecting an appropriate proposal. Comments? > > I would like to see that the notification data is always list of > attributes. This way we can easily add stuff later when we want to add > more things. Currently the RESPONDER-LIFETIME already uses that. In > that case we could have new attribute type numbers like: > > Failing SA proposal 256 > Error message text (default: UTF-8, english) 257 > ... > > And then I can include list of two attributes to the notification, > one containing the failing SA proposal, and the second onme includes > the error message text, saying something like "Phase I proposal > rejected because of policy required 3DES encryption, and no proposal > matching that was found". I agree. From owner-ipsec Tue Dec 8 09:44:21 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA11413 for ipsec-outgoing; Tue, 8 Dec 1998 09:42:27 -0500 (EST) Message-Id: <3.0.5.32.19981207185009.00a00910@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 07 Dec 1998 18:50:09 -0800 To: Michael Richardson From: Matt Holdrege Subject: Re: (NAT) Host NAT issues and Security Policy Servers Cc: nat@livingston.com, policy@raleigh.ibm.com, ietf-aaa@external.cisco.com, ipsec@tis.com In-Reply-To: <199812080132.UAA04648@morden.sandelman.ottawa.on.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:32 PM 12/7/98 -0500, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > > [I'm going to appologize in advance for cross posting so widely. >I'm feeling a bit like every working group I attend is dealing with >the same problems. > I also, due to fog, missed both nat and aaa this morning. I heard >the aaa BOF didn't arrive at any clear conclusions, and I'm glad there >wasn't a fire drill during the NAT meeting or someone might have been >trampled. ] Sorry to reply to such a cross-post, but I didn't want anyone to read this and think that we had a NAT meeting. NAT did not meet today and will meet as scheduled, Wednesday at 1pm. Matt Holdrege http://www.ascend.com matt@ascend.com From owner-ipsec Thu Dec 10 09:08:16 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA20026 for ipsec-outgoing; Thu, 10 Dec 1998 09:00:26 -0500 (EST) Message-Id: <199812100330.TAA01910@law-f54.hotmail.com> X-Originating-IP: [161.69.57.95] From: "Ashutosh Jha" To: ipsec@tis.com Subject: Authentication Header MIME-Version: 1.0 Content-Type: text/plain Date: Wed, 09 Dec 1998 19:30:43 PST Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, In authentication header what should be length of ICV? Just depending on algorithm selected or something more than that? In the "*auth-header-07.txt" it talks about "standard" case of 96 bit. Does this mean that in AH, I should put only 96 bit or consider only 96 bit for verification. In ESP header it doesn't talk anything like this. So looks like I will have to put complete ICV according to algorithm selected. Am I right? If not please clarify. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec Thu Dec 10 09:08:18 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA20044 for ipsec-outgoing; Thu, 10 Dec 1998 09:01:27 -0500 (EST) Message-ID: <6FB07D8C72BFD011BD1E00805FEA6698D3D9A7@azmelx4.mel.az.bp.com> From: "Johnston, Phil A (Telstra)" To: "'ipsec@tis.com'" Subject: IPSec details Date: Thu, 10 Dec 1998 16:12:23 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Could you please advise where I can obtain uptodate description and rfc if available for IPsec? Thanks in advance, Regards, Phil Johnson Internet Gateway Manager E-mail : johnstpa@az1.bp.com Ph 03 9268-4239 From owner-ipsec Thu Dec 10 10:45:48 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA20614 for ipsec-outgoing; Thu, 10 Dec 1998 10:43:26 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <199812100330.TAA01910@law-f54.hotmail.com> Date: Thu, 10 Dec 1998 10:56:24 -0500 To: "Ashutosh Jha" From: Stephen Kent Subject: Re: Authentication Header Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk The length of the ICV is deternined by the integrity/authenticity algorithm selected for the SA. The default algorithms for use with both AH and ESP use exaclty 96 bits, as a result of truncating the larger HMAC output, but that truncation is specified in the algorithm definitions, as profiled for use in the IPsec context. Steve From owner-ipsec Thu Dec 10 12:27:21 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA20982 for ipsec-outgoing; Thu, 10 Dec 1998 12:24:30 -0500 (EST) From: "Sumit" To: Subject: RE: Authentication Header Date: Thu, 10 Dec 1998 09:43:56 -0800 Message-ID: <000b01be2464$a9197520$8eec10ac@pc-svakil.internetdevices.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <199812100330.TAA01910@law-f54.hotmail.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Ashutosh, The length of the ICV is dictated by the authentication algorithm chosen for use with AH. The appropriate algorithm document would define the ICV length. For example, RFC 2403, "The Use of HMAC-MD5-96 within ESP and AH" explains how the 96 bit ICV is computed and verified. Sumit A. Vakil Internet Devices, Inc. > -----Original Message----- > From: owner-ipsec@ex.tis.com [mailto:owner-ipsec@ex.tis.com]On Behalf Of > Ashutosh Jha > Sent: Wednesday, December 09, 1998 7:31 PM > To: ipsec@tis.com > Subject: Authentication Header > > > Hi, > > In authentication header what should be length of ICV? Just depending on > algorithm selected or something more than that? In the > "*auth-header-07.txt" it talks about "standard" case of 96 bit. Does > this mean that in AH, I should put only 96 bit or consider only 96 bit > for verification. In ESP header it doesn't talk anything like this. So > looks like I will have to put complete ICV according to algorithm > selected. Am I right? If not please clarify. > > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > > From owner-ipsec Thu Dec 10 15:45:27 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA21704 for ipsec-outgoing; Thu, 10 Dec 1998 15:42:38 -0500 (EST) Message-ID: <31946FC09021D211BE9B00104BD1DEEE06420C@dukat.psti.com> From: Jerome Etienne To: "'ipsec@tis.com'" Subject: compression before encryption Date: Thu, 10 Dec 1998 16:13:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk apparently the ippcp list is closed, so i try here... quote from IP Payload Compression Protocol (IPComp) (RFC 2393) "5. Security Considerations When IPComp is used in the context of IPSec, it is believed not to have an effect on the underlying security functionality provided by the IPSec protocol; i.e., the use of compression is not known to degrade or alter the nature of the underlying security architecture or the encryption technologies used to implement it. " but in fact the compression increases the encryption scheme, because it reduces the redondancy of the plain text which is so usefull for cryptanalysis. did i miss something ? From owner-ipsec Thu Dec 10 17:09:13 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA22050 for ipsec-outgoing; Thu, 10 Dec 1998 17:06:38 -0500 (EST) To: Jerome Etienne Cc: "'ipsec@tis.com'" Subject: Re: compression before encryption References: <31946FC09021D211BE9B00104BD1DEEE06420C@dukat.psti.com> From: Derek Atkins Date: 10 Dec 1998 17:26:07 -0500 In-Reply-To: Jerome Etienne's message of Thu, 10 Dec 1998 16:13:32 -0500 Message-Id: Lines: 32 X-Mailer: Gnus v5.2.37/Emacs 19.34 Sender: owner-ipsec@ex.tis.com Precedence: bulk I believe the point is that "it is believed not to have [a negative] effect on the underlying security functionality...." -derek Jerome Etienne writes: > > apparently the ippcp list is closed, so i try here... > > quote from IP Payload Compression Protocol (IPComp) (RFC 2393) > > "5. Security Considerations > > When IPComp is used in the context of IPSec, it is believed not to > have an effect on the underlying security functionality provided by > the IPSec protocol; i.e., the use of compression is not known to > degrade or alter the nature of the underlying security architecture > or the encryption technologies used to implement it. > " > > but in fact the compression increases the encryption scheme, because > it reduces the redondancy of the plain text which is so usefull for > cryptanalysis. > did i miss something ? > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec Thu Dec 10 19:25:17 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA22406 for ipsec-outgoing; Thu, 10 Dec 1998 19:21:42 -0500 (EST) X-Authentication-Warning: keeks-gw.cyber.ee: helger owned process doing -bs Date: Fri, 11 Dec 1998 02:40:05 +0200 (EET) From: Helger Lipmaa X-Sender: helger@keeks To: Jerome Etienne cc: "'ipsec@tis.com'" Subject: Re: compression before encryption In-Reply-To: <31946FC09021D211BE9B00104BD1DEEE06420C@dukat.psti.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 10 Dec 1998, Jerome Etienne wrote: > but in fact the compression increases the encryption scheme, because > it reduces the redondancy of the plain text which is so usefull for > cryptanalysis. > did i miss something ? Note that there is actually very few known about the usage of cryptanalysis of the today's block ciphers with moderately reduntant sources. [BK98] does provide an evidence, that when using differentially weak ciphers, having only lot of ciphertexts is enough to find the key. Examples were provided for 8-round DES and RC5. (I don't have the paper atm so I may be wrong). [BK98] Alex Biryukov, Eyal Kushilevitz, "From Differential Cryptanalysis to Ciphertext-Only Attacks", Proceedings of CRYPTO '98. Helger http://home.cyber.ee/helger From owner-ipsec Thu Dec 10 19:42:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA22427 for ipsec-outgoing; Thu, 10 Dec 1998 19:40:41 -0500 (EST) Date: Thu, 10 Dec 1998 19:59:56 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: compression before encryption In-Reply-To: <31946FC09021D211BE9B00104BD1DEEE06420C@dukat.psti.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > ...but in fact the compression increases the encryption scheme, because > it reduces the redondancy of the plain text which is so usefull for > cryptanalysis. > did i miss something ? I haven't looked at IPCOMP yet, but many compression schemes are a very mixed bag in this regard: they reduce the overall redundancy of the bulk text, but they often put semi-predictable header material on the front, which can facilitate known-plaintext attacks. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Fri Dec 11 08:45:56 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA24699 for ipsec-outgoing; Fri, 11 Dec 1998 08:41:47 -0500 (EST) Message-ID: <01BE24E4.D820BC40.jcastonguay@motus.qc.ca> From: James Castonguay Reply-To: "jcastonguay@motus.qc.ca" To: "ipsec@tis.com" Date: Fri, 11 Dec 1998 09:01:30 -0000 Organization: Motus technologies inc X-Mailer: Messagerie Internet de Microsoft/MAPI - 8.0.0.4211 Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm currently involved in IPSec implementation, and i'd like to find a book or article about IPSec. James From owner-ipsec Fri Dec 11 09:48:32 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA24911 for ipsec-outgoing; Fri, 11 Dec 1998 09:42:47 -0500 (EST) Message-ID: <31946FC09021D211BE9B00104BD1DEEE064228@dukat.psti.com> From: Jerome Etienne To: "'Helger Lipmaa'" Cc: "'ipsec@tis.com'" Subject: RE: compression before encryption Date: Fri, 11 Dec 1998 10:11:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk i didnt find the paper, but you say it is applied only to differentially weak cyphers. Anyway being vulnerable to cyphertext-only attacks and less vulnerable to known plain texts attacks is safer than being "fully" vulnerable to cypher-text-only and known plan texts attacks. no ? On Thursday, December 10, 1998 7:40 PM, Helger Lipmaa [SMTP:helger@cyber.ee] wrote: > Note that there is actually very few known about the usage of > cryptanalysis of the today's block ciphers with moderately reduntant > sources. [BK98] does provide an evidence, that when using differentially > weak ciphers, having only lot of ciphertexts is enough to find the key. > Examples were provided for 8-round DES and RC5. (I don't have the paper > atm so I may be wrong). > > [BK98] Alex Biryukov, Eyal Kushilevitz, "From Differential Cryptanalysis > to Ciphertext-Only Attacks", Proceedings of CRYPTO '98. > > Helger > http://home.cyber.ee/helger From owner-ipsec Fri Dec 11 11:50:37 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA00392 for ipsec-outgoing; Fri, 11 Dec 1998 11:42:43 -0500 (EST) Message-Id: <4.1.19981210113341.036f2c00@idi-fk-gw.abhiweb.com> Message-Id: <4.1.19981210113341.036f2c00@idi-fk-gw.abhiweb.com> X-Sender: rodney@idi-fk-gw.abhiweb.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 10 Dec 1998 08:38:19 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: IPsec implementation survey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm putting together an implementation survey for the IPsec working group. If you have any suggestions as to what data should be surveyed, please send mail, to me directly or to the list. I'm going to regenerate the form we did for the last survey and update that, for a start. In my opinion, adding questions about some of these proposed new variations, such as DHCP, Kerberos, and XAUTH, is appropriate. Any comments? In case you never saw it, the last IPsec survey is a link off of Ted's IPsec web page. The surveys before that were rolled in, as is the convention, that's why there are old implementations there. From owner-ipsec Fri Dec 11 11:50:40 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA00391 for ipsec-outgoing; Fri, 11 Dec 1998 11:42:40 -0500 (EST) Message-Id: <4.1.19981210113219.036f2cf0@idi-fk-gw.abhiweb.com> Message-Id: <4.1.19981210113219.036f2cf0@idi-fk-gw.abhiweb.com> X-Sender: rodney@idi-fk-gw.abhiweb.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 10 Dec 1998 08:33:39 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: PKI Requirements doc Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Per my presentation at the IPsec meeting yesterday here's the URL to the current snapshot of the IPsec PKI Requirements document: http://www2.internetdevices.com/arch-lab/ietf/draft-ietf-ipsec-pki-req-02e.txt From owner-ipsec Fri Dec 11 14:13:32 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA01063 for ipsec-outgoing; Fri, 11 Dec 1998 14:12:41 -0500 (EST) From: sspillai@teil.soft.net (S Subramonia Pillai) Message-Id: <199812112107.PAA01113@teil.soft.net> Subject: Hi To: ipsec@tis.com Date: Fri, 11 Dec 1998 15:37:14 -0530 (IST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Can any one please point out the latest draft or rfc for "Security Architecture for the Internet protocol (IPSec)" If you are replying include my mail id also, since I not registered to IPSec working group. Thanks Pillai From owner-ipsec Mon Dec 14 15:04:40 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA12847 for ipsec-outgoing; Mon, 14 Dec 1998 14:49:41 -0500 (EST) Message-ID: <00ad01be279d$c61a1760$0100010a@irish1> From: "John Irish" To: "IPSEC" Subject: ISAKMP identification types Date: Mon, 14 Dec 1998 15:10:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk Does anyone know why the identification types specified for ISAKMP Phase-1 within RFC-2408 (See Section A.4) is only a small subset of those specified for the Internet DOI. Here are the types specified within the ISAKMP RFC: ID_IPV4_ADDR=0 ID_IPV4_ADDR_SUBNET=1 ID_IPV6_ADDR=2 ID_IPV6_ADDR_SUBNET=3 As you can see, all the named identification types, plus the range identification types are missing. Is there a real reason behind this inconsistency? John Irish From owner-ipsec Mon Dec 14 18:21:11 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA13671 for ipsec-outgoing; Mon, 14 Dec 1998 18:19:43 -0500 (EST) Message-Id: <199812142339.PAA14108@gallium.network-alchemy.com> To: "John Irish" cc: "IPSEC" Subject: Re: ISAKMP identification types In-reply-to: Your message of "Mon, 14 Dec 1998 15:10:18 EST." <00ad01be279d$c61a1760$0100010a@irish1> Date: Mon, 14 Dec 1998 15:39:27 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk The short answer is, yes. They were a subset by design. The interpretation of an IKE endpoint identity that is not an IP address or subnet is somewhat nebulous. To ensure interoperability amongst initial IKE implementations we wanted to keep it simple. Note that the Phase 1 identity list is constrained by the DOI specified in the associated Phase 1 negotiation. If you specify the IPSEC DOI, you are free to use the identity types defined in the IPSEC DOI. It's only when you specify a DOI of zero that you're constrained by the "generic" ISAKMP identity type list in Appendix A. Derrell From owner-ipsec Tue Dec 15 05:42:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA15485 for ipsec-outgoing; Tue, 15 Dec 1998 05:40:40 -0500 (EST) X-Authentication-Warning: keeks-gw.cyber.ee: helger owned process doing -bs Date: Tue, 15 Dec 1998 12:59:23 +0200 (EET) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@tis.com Subject: RE: compression before encryption In-Reply-To: <31946FC09021D211BE9B00104BD1DEEE064228@dukat.psti.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 11 Dec 1998, Jerome Etienne wrote: > i didnt find the paper, but you say it is applied only to differentially > weak cyphers. The authors are accessible from: http://www.cs.technion.ac.il/~albi/ http://www.cs.technion.ac.il/~eyalk/ AFAIK the paper is not online, but it should be available by emailing to them. Sorry, haven't had time to fetch the proceedings and reread the paper myself lately. Helger From owner-ipsec Tue Dec 15 09:42:11 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA16384 for ipsec-outgoing; Tue, 15 Dec 1998 09:40:39 -0500 (EST) Date: Tue, 15 Dec 1998 17:00:14 +0200 (EET) From: Markku Savela Message-Id: <199812151500.RAA11145@anise.tte.vtt.fi> To: ipsec@tis.com Subject: Selectors and Transport Layer Protocol Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk Reading the documetation non-sequentially, as happens when one implements things and needs to check on one issue here and there, I happened on Architecture (RFC 2401), page 17 NOTE: To locate the transport protocol, a system has to chain through the packet headers checking the "Protocol" or "Next Header" field until it encounters either one it recognizes as a transport protocol, or until it reaches one that isn't on its list of extension headers, or until it encounters an ESP header that renders the transport protocol opaque. The questions arise - why not just define it as a check on topmost protocol (in next header), forget the loop? If I don't wan't any funny wrapping and tunneling protocols pass, my policy explicitly allows only known protocols (or a separate firewall does). The "topmost" protocol is known even for the fragments. - what is transport protocol anyway? Only UDP or TCP? What if I want to have selector specifically for IPIP or ESP or AH? (e.g. for example, for some odd reason, gateway policy might be to do only AH for packets that already have ESP). Or, if I wanted to do some kinky IPSEC with fragmented packets? This just caught my "fuzzy detector" while reading it, at least with IPv4. "Test the topmost" would remove the fuzzy feeling... Perhaps it makes more sense with IPv6, but then the wording should be "skipping non-protocol extension headers" or somesuch? (I don't know IPv6 well enough at this point). -- Some additional discussion.. If my policy says to use a specific security bundle for TCP, do I really intend the same bundle to apply when someone wraps TCP inside a IPIP tunnel? (Moot question, if IPIP is transport protocol). -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Wed Dec 16 06:36:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id GAA20464 for ipsec-outgoing; Wed, 16 Dec 1998 06:28:03 -0500 (EST) Message-Id: <3.0.1.32.19981216171523.00959df4@172.16.1.10> X-Sender: rohit@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 16 Dec 1998 17:15:23 +0500 To: ipsec@tis.com From: rohit Subject: Inter-Op sites Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Can any one please point out is there any other interoperability sites for IKE and IPSEC implemenations apart from SSH and NIST sites. -Thanks in Advance Rohit From owner-ipsec Wed Dec 16 16:24:06 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA22957 for ipsec-outgoing; Wed, 16 Dec 1998 16:18:10 -0500 (EST) Message-ID: <004901be293c$7dfa8820$0100010a@irish1> From: "John Irish" To: "IPSEC" Subject: Anycast Date: Wed, 16 Dec 1998 16:38:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk Has there been any discussion regarding support of Anycast with IPSec and ISAKMP? Due to the address change which occurs on response packets, conducting SA negotiations for a remote Anycast address creates some unique problems for ISAKMP and the SA/policy database. Is the general practice in IPSec implementations just to leave out support for Anycast? Please post any pointers or thoughts on this. Thanks! John Irish From owner-ipsec Wed Dec 16 17:17:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA23510 for ipsec-outgoing; Wed, 16 Dec 1998 17:15:12 -0500 (EST) From: Dan McDonald Message-Id: <199812162233.OAA27474@kebe.eng.sun.com> Subject: Re: Anycast To: irishjd@erols.com (John Irish) Date: Wed, 16 Dec 1998 14:33:53 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <004901be293c$7dfa8820$0100010a@irish1> from "John Irish" at Dec 16, 98 04:38:58 pm X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Has there been any discussion regarding support of Anycast with IPSec and > ISAKMP? Historically, no. > Due to the address change which occurs on response packets, conducting SA > negotiations for a remote Anycast address creates some unique problems for > ISAKMP and the SA/policy database. Is the general practice in IPSec > implementations just to leave out support for Anycast? Anycast kinda/sorta starts its life out not unlike multicast, which we already know is a Hard Problem (TM). > Please post any pointers or thoughts on this. Assuming my understanding of anycast is still up to snuff (it may not be), and that you've solve multicast key distribution, what you can have happen is this: 0.) Anycast keys are distributed, a node sends to the anycast address using that IPsec SA. 1.) The node that handles the anycast traffic accepts the packet, and turns around a response. This response is to a unicast address, and if you use source address as a selector, it comes from a "different" source address. This should kick off an IKE negotiation. 2.) The remaining traffic is protected with a pair of unicast SAs that were negotiatied by the anycast handler and the original node. The way I see it, decoupling the ISKAMP "initiator" from the traffic "initiator" will help here. Like I said, I'm assuming my anycast understanding is complete, which it might not be. Also like I said, getting the anycast keys out reduces to the problem of getting multicast keys out, which is very HARD. Dan From owner-ipsec Wed Dec 16 18:10:16 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA23666 for ipsec-outgoing; Wed, 16 Dec 1998 18:09:10 -0500 (EST) Date: Wed, 16 Dec 1998 18:44:41 -0800 (PST) From: "Hilarie K. Orman" Message-Id: <199812170244.SAA17406@earth.hpc.org> To: danmcd@Eng.Sun.Com Cc: irishjd@erols.com, ipsec@tis.com In-reply-to: Yourmessage <199812162233.OAA27474@kebe.eng.sun.com> Subject: Re: Anycast Sender: owner-ipsec@ex.tis.com Precedence: bulk It would be particularly efficient to use a multicast SA out, and a PGP-style reply. That allows you to skip the step of the second SA negotiation. Initial multicast key distribution might be heavyweight, it might be cumbersome, but it's not HARD or even hard. Hilarie From owner-ipsec Thu Dec 17 11:11:49 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA26853 for ipsec-outgoing; Thu, 17 Dec 1998 11:02:26 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Message-Id: In-Reply-To: <199812162233.OAA27474@kebe.eng.sun.com> References: <004901be293c$7dfa8820$0100010a@irish1> from "John Irish" at Dec 16, 98 04:38:58 pm Date: Thu, 17 Dec 1998 10:05:40 -0500 To: Dan McDonald , irishjd@erols.com (John Irish) From: "Carl F. Muckenhirn" Subject: Re: Anycast Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Multicast key management isn't hard, just complex. There are already several RFC's on the topic (1949, 2093, 2094), with more on the way, as well as several current ID's. (http://search.ietf.org/internet-drafts/draft-ietf-ipsec-intragkm-00.txt, http://search.ietf.org/internet-drafts/draft-canetti-secure-multicast-taxonomy-0 0.txt, http://search.ietf.org/internet-drafts/draft-wallner-key-arch-01.txt) There is most definitely a lack of consensus as to how to implement various approaches, and which are more "efficient," if that - gaining consensus - is the "Hard Problem (tm)" then I might agree. carl. On 12/16/98 at 2:33 PM -0800, Dan McDonald wrote: >> Has there been any discussion regarding support of Anycast with IPSec and >> ISAKMP? > > Historically, no. > >> Due to the address change which occurs on response packets, conducting SA >> negotiations for a remote Anycast address creates some unique problems for >> ISAKMP and the SA/policy database. Is the general practice in IPSec >> implementations just to leave out support for Anycast? > > Anycast kinda/sorta starts its life out not unlike multicast, which we > already know is a Hard Problem (TM). > >> Please post any pointers or thoughts on this. > > Assuming my understanding of anycast is still up to snuff (it may not be), > and that you've solve multicast key distribution, what you can have happen is > this: > > 0.) Anycast keys are distributed, a node sends to the anycast > address using that IPsec SA. > > 1.) The node that handles the anycast traffic accepts the packet, and > turns around a response. This response is to a unicast address, > and if you use source address as a selector, it comes from a > "different" source address. This should kick off an IKE > negotiation. > > 2.) The remaining traffic is protected with a pair of unicast SAs > that were negotiatied by the anycast handler and the original > node. > > The way I see it, decoupling the ISKAMP "initiator" from the traffic > "initiator" will help here. > > Like I said, I'm assuming my anycast understanding is complete, which it > might not be. Also like I said, getting the anycast keys out reduces to the > problem of getting multicast keys out, which is very HARD. > > Dan Carl F. Muckenhirn Director, Engineering and Integration SPARTA, Inc. Secure Systems Engineering Division 9861 Broken Land Parkway, Suite 300 Columbia, Maryland 21046 410.381.9400 x208 410.381.5559 (fax) From owner-ipsec Thu Dec 17 12:35:05 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA27266 for ipsec-outgoing; Thu, 17 Dec 1998 12:32:29 -0500 (EST) Date: Thu, 17 Dec 1998 12:50:30 -0500 From: canetti Message-Id: <9812171750.AA22264@ornavella.watson.ibm.com> To: cfm@columbia.sparta.com, danmcd@Eng.Sun.Com, irishjd@erols.com Subject: Re: Anycast Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Multicast key management, along with other multicast security issues, is currently being discussed at the Secure Multicast Group (SMuG) of the IRTF. See http://www.ipmulticast.com/community/smug/ for details. A primary goal of this IRTF group is to come up with a first-cut prototype that can be handed over to an IETF group for standardization. Ran > From owner-ipsec@portal.ex.tis.com Thu Dec 17 12:33:06 1998 > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > In-Reply-To: <199812162233.OAA27474@kebe.eng.sun.com> > References: <004901be293c$7dfa8820$0100010a@irish1> from "John Irish" at > Dec 16, 98 04:38:58 pm > Date: Thu, 17 Dec 1998 10:05:40 -0500 > To: Dan McDonald , irishjd@erols.com (John Irish) > From: "Carl F. Muckenhirn" > Subject: Re: Anycast > Cc: ipsec@tis.com > Precedence: bulk > > Multicast key management isn't hard, just complex. There are already > several RFC's on the topic (1949, 2093, 2094), with more on the way, as > well as several current ID's. > (http://search.ietf.org/internet-drafts/draft-ietf-ipsec-intragkm-00.txt, > http://search.ietf.org/internet-drafts/draft-canetti-secure-multicast-taxonomy-0 > 0.txt, http://search.ietf.org/internet-drafts/draft-wallner-key-arch-01.txt) > > There is most definitely a lack of consensus as to how to implement various > approaches, and which are more "efficient," if that - gaining consensus - > is the "Hard Problem (tm)" then I might agree. > > carl. > > On 12/16/98 at 2:33 PM -0800, Dan McDonald wrote: > > > >> Has there been any discussion regarding support of Anycast with IPSec and > >> ISAKMP? > > > > Historically, no. > > > >> Due to the address change which occurs on response packets, conducting SA > >> negotiations for a remote Anycast address creates some unique problems for > >> ISAKMP and the SA/policy database. Is the general practice in IPSec > >> implementations just to leave out support for Anycast? > > > > Anycast kinda/sorta starts its life out not unlike multicast, which we > > already know is a Hard Problem (TM). > > > >> Please post any pointers or thoughts on this. > > > > Assuming my understanding of anycast is still up to snuff (it may not be), > > and that you've solve multicast key distribution, what you can have happen is > > this: > > > > 0.) Anycast keys are distributed, a node sends to the anycast > > address using that IPsec SA. > > > > 1.) The node that handles the anycast traffic accepts the packet, and > > turns around a response. This response is to a unicast address, > > and if you use source address as a selector, it comes from a > > "different" source address. This should kick off an IKE > > negotiation. > > > > 2.) The remaining traffic is protected with a pair of unicast SAs > > that were negotiatied by the anycast handler and the original > > node. > > > > The way I see it, decoupling the ISKAMP "initiator" from the traffic > > "initiator" will help here. > > > > Like I said, I'm assuming my anycast understanding is complete, which it > > might not be. Also like I said, getting the anycast keys out reduces to the > > problem of getting multicast keys out, which is very HARD. > > > > Dan > > Carl F. Muckenhirn > Director, Engineering and Integration > SPARTA, Inc. > Secure Systems Engineering Division > 9861 Broken Land Parkway, Suite 300 > Columbia, Maryland 21046 > 410.381.9400 x208 > 410.381.5559 (fax) > From owner-ipsec Thu Dec 17 14:00:23 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA27833 for ipsec-outgoing; Thu, 17 Dec 1998 13:57:29 -0500 (EST) To: "Carl F. Muckenhirn" Cc: Dan McDonald , irishjd@erols.com (John Irish), ipsec@tis.com Subject: Multicast Key Management (was Re: Anycast) References: <004901be293c$7dfa8820$0100010a@irish1> from "John Irish" at Dec 16, 98 04:38:58 pm Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 17 Dec 1998 14:16:28 -0500 In-Reply-To: "Carl F. Muckenhirn"'s message of "Thu, 17 Dec 1998 10:05:40 -0500" Message-ID: <87btl2k29f.fsf_-_@jekyll.piermont.com> Lines: 33 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@ex.tis.com Precedence: bulk "Carl F. Muckenhirn" writes: > Multicast key management isn't hard, just complex. I dispute that. We've had the topic come up on several occasions of the problem of what it means for a group to share a multicast key. In general, any secret known by more than two people isn't much of a secret any more. If we find ourselves wanting to authenticate wide scale routing advertisements and such, this issue becomes critical. Conventional methods end up providing no security -- just latency. Anyone remember the amusing discussion at the D.C. IETF where someone proposed a multicast key management system to deal with television broadcasts, and folks kept coming up to say "sorry, but how will you keep anything known by a million people a secret? how does your "authentication" authenticate anything worth mentioning?" Multicast key management is only "not hard" in the context of a very small group of multicast participants all of whom intensely want to keep the conversation secret and who trust each other not to forge messages. It might be "obvious" how to do this if you have eight guys who need to keep a top secret teleconference secure. If you want to authenticate a message going to 8,000 hosts, on the other hand, the problem is not nearly so simple. In the wide scale problem, the only likely solution is the use of public key for authentication, and at best, encryption is going to buy you some time keeping away the ankle biters without giving you real privacy. Perry From owner-ipsec Thu Dec 17 14:46:13 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA27969 for ipsec-outgoing; Thu, 17 Dec 1998 14:44:31 -0500 (EST) Date: Thu, 17 Dec 1998 14:44:31 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199812171944.OAA27969@portal.ex.tis.com> [132.245.135.83]) by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id OAA03536; Thu, 17 Dec 1998 14:10:23 -0500 for Message-Id: <3.0.5.32.19981217141018.00812820@bl-mail2.corpeast.baynetworks.com> X-Sender: thardjon@bl-mail2.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 17 Dec 1998 14:10:18 -0500 To: "Hilarie K. Orman" From: Thomas_Hardjono@BayNetworks.COM (Thomas Hardjono) Subject: Re: Anycast Cc: ipsec@tis.com In-Reply-To: <199812170244.SAA17406@earth.hpc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Hi, I tend to agree with Hilarie. Its not such a HARD/hard problem. Just to put a plug on the work we are doing: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-intragkm-00.txt Slides on this topic from the Orlando-IETF should be available soon on: http://www.ipmulticast.com/community/smug/ At 06:44 PM 12/16/98 -0800, Hilarie K. Orman wrote: > >Initial multicast key distribution might be heavyweight, it might >be cumbersome, but it's not HARD or even hard. > >Hilarie > ---------------------------------------------------------------------- Thomas Hardjono 3 Federal Street, BL3-03 Bay Architecture Lab Billerica, MA 01821, USA Nortel Networks Tel: 978-916-4538 email: thardjono@baynetworks.com Fax: 978-916-0620 ---------------------------------------------------------------------- From owner-ipsec Fri Dec 18 08:44:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA00578 for ipsec-outgoing; Fri, 18 Dec 1998 08:38:27 -0500 (EST) Date: Fri, 18 Dec 1998 08:38:27 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199812181338.IAA00578@portal.ex.tis.com> forged)) by smtp-gw.BayNetworks.COM (8.9.1/BNET-98/09/30-E) with ESMTP id MAA21864; Thu, 17 Dec 1998 12:29:07 -0800 (PST) [132.245.135.83]) by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id PAA14808; Thu, 17 Dec 1998 15:30:01 -0500 for Message-Id: <3.0.5.32.19981217152523.008cb9f0@bl-mail2.corpeast.baynetworks.com> X-Sender: thardjon@bl-mail2.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 17 Dec 1998 15:25:23 -0500 To: perry@piermont.com, "Carl F. Muckenhirn" From: Thomas_Hardjono@BayNetworks.COM (Thomas Hardjono) Subject: Re: Multicast Key Management (was Re: Anycast) Cc: Dan McDonald , irishjd@erols.com (John Irish), ipsec@tis.com, thardjono@BayNetworks.COM In-Reply-To: <87btl2k29f.fsf_-_@jekyll.piermont.com> References: <"Carl F. Muckenhirn"'s message of "Thu, 17 Dec 1998 10:05:40 -0500"> <004901be293c$7dfa8820$0100010a@irish1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk At 02:16 PM 12/17/98 -0500, Perry E. Metzger wrote: > >"Carl F. Muckenhirn" writes: >> Multicast key management isn't hard, just complex. > >I dispute that. Let me join-in. The problem is multi-faceted and is dependent on (among others): - the multicast application-type (1-to-M or M-to-M) - whether traffic unidirectional or bidirectional - the economic-value of the content being delivered >We've had the topic come up on several occasions of the problem of >what it means for a group to share a multicast key. In general, any >secret known by more than two people isn't much of a secret any >more. If we find ourselves wanting to authenticate wide scale routing >advertisements and such, this issue becomes critical. Conventional >methods end up providing no security -- just latency. There are 3 immediate problems for now: (1) group key management (getting the keys to the end-users/hosts) (2) applying the key to the payload/content (modify/enhance IPsec?) (3) the problem of "infrastructure security" (which you refered to as "authenticate wide scale routing advertisements). Problem (3) is harder and includes: - denial of service attacks (injection of bogus packets and random joining/grafting to the multicast tree) - key management for the routers - authentication vs encryption of control messages All of these may be dependent on the multicast routing protocol. >Multicast key management is only "not hard" in the context of a very >small group of multicast participants all of whom intensely want to >keep the conversation secret and who trust each other not to forge >messages. It might be "obvious" how to do this if you have eight guys >who need to keep a top secret teleconference secure. If you want to >authenticate a message going to 8,000 hosts, on the other hand, the >problem is not nearly so simple. Again, this depends on the application type. In the case of subscriber/PayPerView (PPV), the wishes of the content-producer is to ensure that only paying subscribers get access to the encrypted content. While getting 100% water-tightness is rather impossible (since users may still be able to store and re-sell the content), perhaps other solutions exist at the user-end (eg. decryptor built-into application/viewer software). Agreed, the problem is much "harder" with the M-to-M multicast for conferencing (in which privacy is a *real* issue). ---------------------------------------------------------------------- Thomas Hardjono 3 Federal Street, BL3-03 Bay Architecture Lab Billerica, MA 01821, USA Nortel Networks Tel: 978-916-4538 email: thardjono@baynetworks.com Fax: 978-916-0620 ---------------------------------------------------------------------- From owner-ipsec Fri Dec 18 18:17:44 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA03277 for ipsec-outgoing; Fri, 18 Dec 1998 18:13:38 -0500 (EST) Message-Id: <199812182329.PAA02069@chip.cisco.com> To: perry@piermont.com cc: "Carl F. Muckenhirn" , Dan McDonald , irishjd@erols.com (John Irish), ipsec@tis.com Subject: Re: Multicast Key Management (was Re: Anycast) In-reply-to: Your message of "17 Dec 1998 14:16:28 EST." <87btl2k29f.fsf_-_@jekyll.piermont.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2067.914023755.1@cisco.com> Date: Fri, 18 Dec 1998 15:29:15 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Yes, I remember that. (I also remember the last time you referred to me as "somebody" in a post to this list. Talk about amusing! I've received idle threats before but never have my friends been contacted....) The example I chose was poor but note that that application already accepts a certain amount of key piracy-- acceptable loss, it's calculated into their anticipated profits. They still make a sizable amount of money in spite of it and it doesn't stop them from doing the whole thing over again. I suggest you look into the DOCSIS protocol to see what the cable content providers settle for, the bar is pretty low. Also, one million set-top boxes running an embedded OS which contains a decryption key does not necessarily mean that that key is _known_ to one million in a manner that would allow for key leakage. It is not beyond the realm of possibility that access to the key will be enforced (imbedded certs in the set-top box as a for instance) and that my laptop would not be able to acquire the key even if it's running code from the same base as my set-top box which is able to acquire the key. By putting authentication in quotes are you implying that the key is not distributed in a mutually authenticated manner? Would you mind pointing out where in the protocol this is happening? Dan. On 17 Dec 1998 14:16:28 EST you wrote > > Anyone remember the amusing discussion at the D.C. IETF where someone > proposed a multicast key management system to deal with television > broadcasts, and folks kept coming up to say "sorry, but how will you > keep anything known by a million people a secret? how does your > "authentication" authenticate anything worth mentioning?" From owner-ipsec Fri Dec 18 18:30:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA03307 for ipsec-outgoing; Fri, 18 Dec 1998 18:29:40 -0500 (EST) To: Daniel Harkins Cc: "Carl F. Muckenhirn" , Dan McDonald , irishjd@erols.com (John Irish), ipsec@tis.com Subject: Re: Multicast Key Management (was Re: Anycast) References: <199812182329.PAA02069@chip.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 18 Dec 1998 18:49:18 -0500 In-Reply-To: Daniel Harkins's message of "Fri, 18 Dec 1998 15:29:15 -0800" Message-ID: <87ww3pau4h.fsf@jekyll.piermont.com> Lines: 30 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > The example I chose was poor but note that that application already > accepts a certain amount of key piracy-- acceptable loss, it's calculated > into their anticipated profits. If all you want is a fake protocol to deter piracy, well, you don't need a real IETF multicast key distribution protocol to do that. I was under the impression, though, that we all wanted multicast for issues like wide scale internet infrastructure protocols, and that we needed it secure, not "secure". > > Anyone remember the amusing discussion at the D.C. IETF where someone > > proposed a multicast key management system to deal with television > > broadcasts, and folks kept coming up to say "sorry, but how will you > > keep anything known by a million people a secret? how does your > > "authentication" authenticate anything worth mentioning?" > By putting authentication in quotes are you implying that the key > is not distributed in a mutually authenticated manner? Would you mind > pointing out where in the protocol this is happening? I believe an example stated was "The President gets on television and everyone wants to know that it is really the President." If anyone knows a way to do that with a symmetric key shared among twenty million end stations, please tell me now. Perry From owner-ipsec Fri Dec 18 18:57:18 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA03631 for ipsec-outgoing; Fri, 18 Dec 1998 18:56:50 -0500 (EST) Message-Id: <199812190012.QAA04666@chip.cisco.com> To: perry@piermont.com cc: "Carl F. Muckenhirn" , Dan McDonald , irishjd@erols.com (John Irish), ipsec@tis.com Subject: Re: Multicast Key Management (was Re: Anycast) In-reply-to: Your message of "18 Dec 1998 18:49:18 EST." <87ww3pau4h.fsf@jekyll.piermont.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4664.914026331.1@cisco.com> Date: Fri, 18 Dec 1998 16:12:11 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On 18 Dec 1998 18:49:18 EST you wrote > > Daniel Harkins writes: > > The example I chose was poor but note that that application already > > accepts a certain amount of key piracy-- acceptable loss, it's calculated > > into their anticipated profits. > > If all you want is a fake protocol to deter piracy, well, you don't > need a real IETF multicast key distribution protocol to do that. > > I was under the impression, though, that we all wanted multicast for > issues like wide scale internet infrastructure protocols, and that we > needed it secure, not "secure". We do but there is not going to be a one-size-fits-all multicast key management protocol any more than there is a single multicast routing protocol, or unicast routing protocol for that matter. Is RIP a fake protocol because it can't be used as a border gateway protocol? > > > Anyone remember the amusing discussion at the D.C. IETF where someone > > > proposed a multicast key management system to deal with television > > > broadcasts, and folks kept coming up to say "sorry, but how will you > > > keep anything known by a million people a secret? how does your > > > "authentication" authenticate anything worth mentioning?" > > > By putting authentication in quotes are you implying that the key > > is not distributed in a mutually authenticated manner? Would you mind > > pointing out where in the protocol this is happening? > > I believe an example stated was "The President gets on television and > everyone wants to know that it is really the President." Wrong somebody then. I never said any such thing. My example was multicast PPVing a Tyson fight. But now your talking about *use* of the key which is different than the implied criticism of a protocol that distributes the key. So I'll take your changing the subject as meaning that it was just a flippant remark. Dan. From owner-ipsec Mon Dec 21 10:56:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA10226 for ipsec-outgoing; Mon, 21 Dec 1998 10:47:40 -0500 (EST) To: "Hilarie K. Orman" Cc: danmcd@Eng.Sun.Com, irishjd@erols.com, ipsec@tis.com Subject: Re: Anycast References: <199812170244.SAA17406@earth.hpc.org> From: Ben Rogers Date: 21 Dec 1998 11:06:33 -0500 In-Reply-To: "Hilarie K. Orman"'s message of "Wed, 16 Dec 1998 18:44:41 -0800 (PST)" Message-ID: Lines: 21 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk "Hilarie K. Orman" writes: > Initial multicast key distribution might be heavyweight, it might > be cumbersome, but it's not HARD or even hard. The hard part is making it lightweight and efficient. If your goal is to provide _a_ solution, then we've already got several not-hard alternatives (albeit still in their infancy). It becomes a significantly more difficult problem when we think about making an efficient and effective solution for the different imagined scenarios. Regardless, the pointers to SMUG: http://www.ipmulticast.com/community/smug/ indicate the right forum for this discussion. ben From owner-ipsec Mon Dec 21 15:27:48 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA11434 for ipsec-outgoing; Mon, 21 Dec 1998 15:26:46 -0500 (EST) Message-ID: <001601be2d23$2b75d380$0100010a@irish1> From: "John Irish" To: "Hilarie K. Orman" , "Ben Rogers" , Cc: Subject: Re: Anycast Date: Mon, 21 Dec 1998 15:47:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk If an Anycast utilizes a Unicast address, how would a client system know to treat it any differently than a Unicast (i.e., use a Mutilcast group key management server instead of ISAKMP). For Multicast addresses, the address type is clearly an indicator. For Anycast, is it presumed that the security policy must identitify it as such? John Irish From owner-ipsec Mon Dec 21 17:59:50 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA12142 for ipsec-outgoing; Mon, 21 Dec 1998 17:58:46 -0500 (EST) Date: Mon, 21 Dec 1998 18:35:39 -0800 (PST) From: "Hilarie K. Orman" Message-Id: <199812220235.SAA04959@earth.hpc.org> To: irishjd@erols.com Cc: danmcd@Eng.Sun.Com, ben@ascend.com, ipsec@tis.com In-reply-to: Yourmessage <001601be2d23$2b75d380$0100010a@irish1> Subject: Re: Anycast Sender: owner-ipsec@ex.tis.com Precedence: bulk > If an Anycast utilizes a Unicast address, how would a client system know to > treat it any differently than a Unicast (i.e., use a Mutilcast group key > management server instead of ISAKMP). For Multicast addresses, the address > type is clearly an indicator. For Anycast, is it presumed that the security > policy must identitify it as such? 1. This seems like a decision to be made at the application level; it's not part of the security policy at the IP layer. 2. The IKE umbrella can certainly be stretched to include multicast group keys. I'd think that the location of a server would be part of directory services that the application used in order to find out about the session in the first place. That information would be passed to IKE as part of the API call for opening a multicast session as a participant. Hilarie From owner-ipsec Mon Dec 21 21:18:28 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA12702 for ipsec-outgoing; Mon, 21 Dec 1998 21:16:45 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Paul Lambert" To: IP Security List Message-ID: <882566E1.007654EB.00@domino2.certicom.com> Date: Mon, 21 Dec 1998 18:31:35 -0800 Subject: Elliptic Curve Performance in IPsec Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk I've had many requests to document the benefits of elliptic curve in IPsec. A paper on this subject is available at: http://www.certicom.com/ecc/ipsec.htm Please note that the curves used in this benchmark are not those in the current specification. It's the old adage that "... you can lead a mathematician to a formula, but you can't make them implement something they don't feel is secure .." :-( I will try to have the reference code used in this benchmark available in January. Paul From owner-ipsec Tue Dec 22 12:40:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA15442 for ipsec-outgoing; Tue, 22 Dec 1998 12:34:45 -0500 (EST) Date: Tue, 22 Dec 1998 12:34:45 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199812221734.MAA15442@portal.ex.tis.com> SMTP id LAA12232 for ; Tue, 22 Dec 1998 11:39:51 -0600 Date: Tue, 22 Dec 1998 11:39:57 -0600 (CST) From: Ananth Nagarajan To: ipsec@tis.com Subject: minutes of the Orlando IETF meeting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Hello, Are the minutes of the IPSEC WG meeting at Orlando earlier this month, available on-line? If so, I'd appreciate it if I get a pointer to the URL. Thanks Ananth Ananth Nagarajan, Phone: (913)-534-3973 MTS, TP&I, Fax: (913)-534-5087 Sprint Corporation E-mail: ananth@sprintcorp.com From owner-ipsec Tue Dec 22 16:11:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA16161 for ipsec-outgoing; Tue, 22 Dec 1998 16:10:22 -0500 (EST) Message-Id: <199812222129.QAA08425@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-02.txt Date: Tue, 22 Dec 1998 16:29:23 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A GSS-API Authentication Mode for IKE Author(s) : D. Piper Filename : draft-ietf-ipsec-isakmp-gss-auth-02.txt Pages : 10 Date : 16-Dec-98 This document describes an alternate authentication method for IKE which makes use of GSS-API to authenticate the Diffie-Hellman exchange. The mechanism described here extends the authentication modes defined in RFC-2409 without introducing any modifications to the IKE key exchange protocol. This constraint however, necessarily restricts the number of GSS-API exchanges and may limit the broader applicability of this method. Additional work is needed to provide a fully generalized solution. Such a solution will require IKE protocol modifications. For a list of changes since the previous version of this document, please see Section 5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-02.txt 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-ipsec-isakmp-gss-auth-02.txt". Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-02.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: <19981222143439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-gss-auth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981222143439.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Dec 22 16:34:34 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA16236 for ipsec-outgoing; Tue, 22 Dec 1998 16:34:23 -0500 (EST) Message-Id: <199812222154.QAA09910@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-mib-03.txt Date: Tue, 22 Dec 1998 16:54:15 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPSec Monitoring MIB Author(s) : T. Jenkins Filename : draft-ietf-ipsec-mib-03.txt Pages : 58 Date : 16-Dec-98 This document defines monitoring and status MIBs for IPSec. It does not define MIBs that may be used for configuring IPSec implementations or for providing low-level diagnostic or debugging information. Further, it does not provide policy information. Those MIBs may be defined in later versions of this document or in other documents. The purpose of the MIBs is to allow system administrators to determine operating conditions and perform system operational level monitoring of the IPSec portion of their network. Statistics are provided as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-mib-03.txt 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-ipsec-mib-03.txt". Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-mib-03.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: <19981222150427.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981222150427.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Dec 24 09:44:00 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA21845 for ipsec-outgoing; Thu, 24 Dec 1998 09:36:20 -0500 (EST) Message-Id: <368255DB.1263942C@lucent.com> Date: Thu, 24 Dec 1998 08:55:23 -0600 From: "David W. Faucher" Organization: Lucent Technologies X-Mailer: Mozilla 4.03 [en] (WinNT; U) Mime-Version: 1.0 To: ipsec@tis.com Subject: REPLAY-STATUS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The DOI states that: The REPLAY-STATUS status message may be used for positive confirmation of the responder's election on whether or not he is to perform anti-replay detection. There is no mention as to whether the same applies to the initiator. Has anyone implemented this for the initiator's side? thanks, David Faucher From owner-ipsec Thu Dec 24 10:25:15 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA21912 for ipsec-outgoing; Thu, 24 Dec 1998 10:23:23 -0500 (EST) Message-Id: <199812241546.KAA28008@crypto.isolation.com> X-Sender: cfilson@mail.isolation.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 24 Dec 1998 10:44:24 -0500 To: ipsec@tis.com From: Chuck Filson Subject: Definition of ID_DER_ASN1_GN Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I am having difficulties finding the reference for the GeneralName identification type. >From RFC 2407 : 4.6.2.11 ID_DER_ASN1_GN The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1 X.500 GeneralName [X.509] of the principal whose certificates are being exchanged to establish the SA. I have searched X.509 and can not find any references to a "General Name". Is this name actually the Distinguished Name of the owner of the certificate or am I missing something here ? Chuck From owner-ipsec Thu Dec 24 10:46:09 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA21959 for ipsec-outgoing; Thu, 24 Dec 1998 10:43:18 -0500 (EST) Message-Id: <199812241602.LAA01482@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-hybrid-auth-01.txt Date: Thu, 24 Dec 1998 11:02:51 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A Hybrid Authentication Mode for IKE Author(s) : M. Litvin, R. Shamir, T. Zegman Filename : draft-ietf-ipsec-isakmp-hybrid-auth-01.txt Pages : 9 Date : 23-Dec-98 This document describes a set of new authentication methods to be used within Phase 1 of the Internet Key Exchange (IKE). The proposed methods assume an asymmetry between the authenticating entities. One entity, typically an Edge Device (e.g. firewall), authenticates using standard public key techniques (in signature mode), while the other entity, typically a remote User, authenticates using challenge response techniques. These authentication methods are used to establish, at the end of Phase 1, an IKE SA which is unidirectional authenticated. To make this IKE bi-directional authenticated, this Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The X-Auth Exchange is used to authenticate the remote User. The use of these authentication methods is referred to as Hybrid mode. This proposal is designed to provide a solution for environments where a legacy authentication system exists, yet a full public key infrastructure is not deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-01.txt 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-ipsec-isakmp-hybrid-auth-01.txt". Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-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: <19981223133058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-hybrid-auth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981223133058.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Dec 24 11:13:45 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA22011 for ipsec-outgoing; Thu, 24 Dec 1998 11:12:18 -0500 (EST) Date: Thu, 24 Dec 1998 11:49:40 -0800 (PST) From: "Hilarie K. Orman" Message-Id: <199812241949.LAA29663@earth.hpc.org> To: plambert@certicom.com Cc: ipsec@tis.com In-reply-to: Yourmessage <882566E1.007654EB.00@domino2.certicom.com> Subject: Re: Elliptic Curve Performance in IPsec Sender: owner-ipsec@ex.tis.com Precedence: bulk Certicom certainly has performance numbers for EC operations over the 155-bit field. Don't be shy. Hilarie From owner-ipsec Mon Dec 28 10:52:51 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA29290 for ipsec-outgoing; Mon, 28 Dec 1998 10:41:01 -0500 (EST) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199812281600.IAA12911@kc.livingston.com> Subject: Re: Selectors and Transport Layer Protocol To: msa@hemuli.tte.vtt.fi Date: Mon, 28 Dec 1998 08:00:44 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199812151500.RAA11145@anise.tte.vtt.fi> from "Markku Savela" at Dec 15, 98 05:00:14 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk "Is IPIP a transport protocol?" is a good queston - Certainly one that many firewall vendors grapple with. Unlike other protocols in the transport category (such as TCP, UDP, AH and ESP), IPIP does not have a header of its own and certainly does not have a multiplexing handle on top of IP. Clearly, IPIP is a network layer redirection technique and as such, an exception amongst transport protocols. Different firewall vendors deal with IPIP differently with regard to applying firewall policies. As for IPsec, RFC 2401 quote below seems to imply that IPIP should not be perceived as a "true" transport protocol and that it should be circumvented. Makes sense to me. cheers, suresh > > Reading the documetation non-sequentially, as happens when one > implements things and needs to check on one issue here and there, I > happened on Architecture (RFC 2401), page 17 > > NOTE: To locate the transport protocol, a system has to chain > through the packet headers checking the "Protocol" or "Next > Header" field until it encounters either one it recognizes as > a transport protocol, or until it reaches one that isn't on > its list of extension headers, or until it encounters an ESP > header that renders the transport protocol opaque. > > The questions arise > > - why not just define it as a check on topmost protocol (in next > header), forget the loop? If I don't wan't any funny wrapping and > tunneling protocols pass, my policy explicitly allows only known > protocols (or a separate firewall does). The "topmost" protocol is > known even for the fragments. > > - what is transport protocol anyway? Only UDP or TCP? What if I want > to have selector specifically for IPIP or ESP or AH? (e.g. for > example, for some odd reason, gateway policy might be to do only AH > for packets that already have ESP). Or, if I wanted to do some kinky > IPSEC with fragmented packets? > > This just caught my "fuzzy detector" while reading it, at least with > IPv4. "Test the topmost" would remove the fuzzy feeling... > > Perhaps it makes more sense with IPv6, but then the wording should be > "skipping non-protocol extension headers" or somesuch? (I don't know > IPv6 well enough at this point). > > -- > Some additional discussion.. > > If my policy says to use a specific security bundle for TCP, > do I really intend the same bundle to apply when someone wraps > TCP inside a IPIP tunnel? (Moot question, if IPIP is transport > protocol). > > -- > Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland > Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ > From owner-ipsec Wed Dec 30 15:03:30 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA07877 for ipsec-outgoing; Wed, 30 Dec 1998 14:48:59 -0500 (EST) Date: Wed, 30 Dec 1998 15:08:28 -0500 (EST) From: Ramon Hontanon To: ipsec@tis.com Subject: Basic IKE authentication question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I've read RFC2408 and RFC2409 searching for the answer to this (albeit basic) question, but haven't come up with an authoritative answer. What are the available options for peer authentication before an IPsec tunnel can be established? I suspect that they are: - Pre-shared keys (i.e. some string that both peers agree upon in advance) - X.509 certs from a Certificate Authority But how about: - Unverified public key exchange (like ssh) - Manual distribution of public keys (Cisco's IKE implementation) Thanks a lot, & happy new year to all! -- ramon From owner-ipsec Wed Dec 30 15:30:13 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA08042 for ipsec-outgoing; Wed, 30 Dec 1998 15:22:00 -0500 (EST) Message-Id: <199812302041.MAA15975@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins owned process doing -bs X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins@localhost didn't use HELO protocol To: Ramon Hontanon cc: ipsec@tis.com Subject: Re: Basic IKE authentication question In-reply-to: Your message of "Wed, 30 Dec 1998 15:08:28 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15973.915050495.1@cisco.com> Date: Wed, 30 Dec 1998 12:41:36 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk You don't necessarily need a certificate to do any of the public key authentication methods in IKE, you just need the peer's public key. They just have to be exchanged in some out-of-band mechanism (like manual exchange the way cisco's freeware code does it) if you're not using certs. IKE provides a mechanism to distribute exchange certs but not untrusted public keys. Dan. On Wed, 30 Dec 1998 15:08:28 EST you wrote > I've read RFC2408 and RFC2409 searching for the answer to this > (albeit basic) question, but haven't come up with an authoritative answer. > > What are the available options for peer authentication before an IPsec > tunnel can be established? I suspect that they are: > > - Pre-shared keys (i.e. some string that both peers agree upon in advance) > - X.509 certs from a Certificate Authority > > But how about: > > - Unverified public key exchange (like ssh) > - Manual distribution of public keys (Cisco's IKE implementation) > > Thanks a lot, & happy new year to all! > > -- ramon > From owner-ipsec Wed Dec 30 16:34:42 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA08292 for ipsec-outgoing; Wed, 30 Dec 1998 16:26:02 -0500 (EST) Message-Id: <199812302145.QAA25619@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Basic IKE authentication question In-Reply-To: Your message of "Wed, 30 Dec 1998 15:08:28 EST." Date: Wed, 30 Dec 1998 16:45:33 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Ramon" == Ramon Hontanon writes: Ramon> - Pre-shared keys (i.e. some string that both peers agree upon in advance) Ramon> - X.509 certs from a Certificate Authority Ramon> But how about: Ramon> - Manual distribution of public keys (Cisco's IKE implementation) If you already have the public key in your trusted certificate cache, (i.e. via manual distribution of public keys), then you don't care if the keys are signed by a CA or not. All that matters is that you have the key in the right format so that it has a DN/altName that corresponds to the value in ID payload. Ramon> - Unverified public key exchange (like ssh) I don't think this is quite a fair comparison. SSH does verify the public key --- provided you already have it. It simply provides a non-manual way to get an unverified public key into its trusted store. I don't see a problem with implementing this policy with IKE: the initiator simply always provides their certificate (asked for or not), and the responder uses its "anonymous" policy. I.e. this is in the realm of implementations to deal with opportunistic encryption. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Wed Dec 30 19:07:41 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA08581 for ipsec-outgoing; Wed, 30 Dec 1998 19:07:00 -0500 (EST) Date: Wed, 30 Dec 1998 19:46:23 -0800 (PST) From: "Hilarie K. Orman" Message-Id: <199812310346.TAA28678@earth.hpc.org> To: ipsec@tis.com Subject: mixed mode datagrams Sender: owner-ipsec@ex.tis.com Precedence: bulk I think you've already been over this, but just to be sure: Is it the intention of the specifications to allow an IP datagram to be reassembled from a combination of ESP-protected fragments tunnelled through different security associations (including the possibility of no ESP protection)? Hilarie From owner-ipsec Wed Dec 30 20:12:38 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA08742 for ipsec-outgoing; Wed, 30 Dec 1998 20:12:02 -0500 (EST) Message-Id: <199812310132.UAA26072@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: mixed mode datagrams In-Reply-To: Your message of "Wed, 30 Dec 1998 19:46:23 PST." <199812310346.TAA28678@earth.hpc.org> Date: Wed, 30 Dec 1998 20:32:01 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Hilarie" == Hilarie K Orman writes: Hilarie> I think you've already been over this, but just to be sure: Hilarie> Is it the intention of the specifications to allow an IP Hilarie> datagram to be reassembled from a combination of ESP-protected Hilarie> fragments tunnelled through different security associations Hilarie> (including the possibility of no ESP protection)? Before anyone says that this situation should never occur, consider the following case: SPD: src dst protocol src-port dst-port alg 1 me/32 you/32 tcp >1024 80 ESP 2 me/32 you/32 tcp * * AH What does one do with the non-initial fragments? They clearly match the second rule. However, page 19 of rfc2401 says: If the packet has been fragmented, then the port information may not be available in the current fragment. If so, discard the fragment. An ICMP PMTU should be sent for the first fragment, which will have the port information. [MAY be supported] But, this isn't even really sufficient. If rule #2 alone existed, there would be no harm in sending out the fragments, since they all match. Due to the existence of rules #1, however, *all* fragments must be treated in this way. This is one reason that I didn't like the use of explicit priorities in the SPD. Had we used implicit priorities (i.e. all src masks has higher sort priority than dst masks, protocol is higher priority than src, and wildcard has lower priority than explcite value) we would have had to write a clear listing of all ambiguous cases, and how they are to be resolved. I heard a Raptor presenter at Interop talking about about how their firewall resolves these issues, and the BlackHole manual spent 30+ pages documenting how rules interacted. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNorUENiXVu0RiA21AQHyPgMAvPEJ8K+J2NHHFVqCm+7IEJMjB8obIUg8 JJGMz4YZumn8hfwETHDVvKg/G0eAC9mdj5GtB+uB1/97yawz7mMJ2mRG6XyhX2yt wTpfEs2SK3w8YQ6pqES2g3BLgxfBzkVn =Qm7E -----END PGP SIGNATURE----- From owner-ipsec Wed Dec 30 20:23:11 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA08781 for ipsec-outgoing; Wed, 30 Dec 1998 20:23:02 -0500 (EST) Message-Id: <3.0.5.32.19981230204327.00b6cc80@cpcug.org> X-Sender: jaubert@cpcug.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 30 Dec 1998 20:43:27 -0500 To: Ramon Hontanon , ipsec@tis.com From: Jack Aubert Subject: Re: Basic IKE authentication question In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I had what amounts to the same question, and turned it into a very modest paper for a graduate course in network security I just finished. The issue is, in essence: how can you manage a very large VPN using IP sec? Suppose you want to set up a world-wide VPN with approximately 200 entry points into a public cloud. This is more than theoretical. I work at the State Department, where it would be useful to use IP sec to set up encrypted tunnels between more than 200 posts throughout the world. This works out to be a large number of bilateral relationships. They can each be negotiated, but some central authority still has to keep track of who can talk to whom, even if the ky distribution is handled by IKI. If you have 200 posts and want to add (or modify) post 201, the existing 200 need to know that it's OK to talk to number 201, but they have to netotiate an encrypted tunnel and verify each other's certificates. The existing protocols allow use of route summarization and wild cards, but if each tunnel point is a local ISP in a different country, this doesn't help much since you have 200 unrelated IP addresses to deal with. So the conclusion I drew was that most of the building blocks are available, (including some new drafts dealing security policy specification language) to manage a very large VPN, but a lot of manual assembly work is still required until somebody implements a system to integrate it all. Jack Aubert At 03:08 PM 12/30/98 -0500, Ramon Hontanon wrote: >I've read RFC2408 and RFC2409 searching for the answer to this >(albeit basic) question, but haven't come up with an authoritative answer. > >What are the available options for peer authentication before an IPsec >tunnel can be established? I suspect that they are: > >- Pre-shared keys (i.e. some string that both peers agree upon in advance) >- X.509 certs from a Certificate Authority > >But how about: > >- Unverified public key exchange (like ssh) >- Manual distribution of public keys (Cisco's IKE implementation) > >Thanks a lot, & happy new year to all! > >-- ramon > > > From owner-ipsec Thu Dec 31 14:11:40 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA11256 for ipsec-outgoing; Thu, 31 Dec 1998 14:10:03 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.5.32.19981230204327.00b6cc80@cpcug.org> References: Date: Thu, 31 Dec 1998 14:22:45 -0500 To: Jack Aubert From: Stephen Kent Subject: Re: Basic IKE authentication question Cc: Ramon Hontanon , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Jack, aper for a graduate course in network security I just finished. > >The issue is, in essence: how can you manage a very large VPN using IP >sec? Suppose you want to set up a world-wide VPN with approximately 200 >entry points into a public cloud. This is more than theoretical. I work >at the State Department, where it would be useful to use IP sec to set up >encrypted tunnels between more than 200 posts throughout the world. This >works out to be a large number of bilateral relationships. They can each >be negotiated, but some central authority still has to keep track of who >can talk to whom, even if the ky distribution is handled by IKI. If you >have 200 posts and want to add (or modify) post 201, the existing 200 need >to know that it's OK to talk to number 201, but they have to netotiate an >encrypted tunnel and verify each other's certificates. I trhink there is some confusion between authentication and authorization here. In your example, each of the sites has an SPD which determines with whom it is willing to communicate. The addition of the 201st site does not necessarily affect all 200 other sites. It is of interest only to those who wish to communicate with it, and vice versa. Use of a central authority, e.g., a CA, to issue authentication credentials to all sites provides a reliable basis for making the access control decision, but that decision is enforced locally, at each site's IPsec implementation(s). if one wants to centralize the authorization function, that too may be done, but the IPsec architecture makes no explicit provision for this. One could imagine centrally managing SPDs for each site and distributing them securely, but that is beyond the scope of the current requirements. >The existing protocols allow use of route summarization and wild cards, >but if each tunnel point is a local ISP in a different country, this >doesn't help much since you have 200 unrelated IP addresses to deal with. >So the conclusion I drew was that most of the building blocks are >available, (including some new drafts dealing security policy specification >language) to manage a very large VPN, but a lot of manual assembly work is >still required until somebody implements a system to integrate it all. Route summarization? Where do you see that in IPsec? The use of wild cards in the SPD is for access control purposes, not for route management. Also, the fact that different ISPs in different countries provide services does not seem directly relevant here. In any use of IPsec in tunnel mode, there is a requirement to determine the address of the security gateway(s) that serve the client systems. This problem is not addressed in an automated fashion in the current architecture, because we wanted to issue the specs and address these problems later, but it is identified as a topic for further study. It seem to grow lineraly in complexity with the number of security gateways, irrespective of whether they connect to the same ISP, or different ones. Steve From owner-ipsec Thu Dec 31 14:20:12 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA11305 for ipsec-outgoing; Thu, 31 Dec 1998 14:20:03 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199812310346.TAA28678@earth.hpc.org> Date: Thu, 31 Dec 1998 14:40:54 -0500 To: "Hilarie K. Orman" From: Stephen Kent Subject: Re: mixed mode datagrams Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, >Is it the intention of the specifications to allow an IP datagram to >be reassembled from a combination of ESP-protected fragments tunnelled >through different security associations (including the possibility >of no ESP protection)? ESP operates on fragments if the fragments arrive at a security gateway and are then encapsulated in ESP. Thus it is possible for fragments to arrive at multiple SGs outbound and be passed on multiple SAs, and even arrive at multiple receiving SGs. However, there is no requirement that these fragments be reassembled prior to deliver to the ultimate recipient. The problem, as Mike points out, is that if one has SPD entries at the destination SG(s) that want to look at port fields, this scenario will fail. However, contrary to what Mike suggests, implicit ordering of the SPD would not address this problem, as my example above illustrates, in more complex topologies. (Mike's example also seems to make use of a range for port values [>1024], a feature that was once present in the SPD, but was dropped because IKE cannot negitiate it.) Steve From owner-ipsec Thu Dec 31 14:22:10 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA11322 for ipsec-outgoing; Thu, 31 Dec 1998 14:22:03 -0500 (EST) Date: Thu, 31 Dec 1998 14:41:45 -0500 From: yjj@cw.net (Yuan John Jiang) Subject: Re: Basic IKE authentication question To: ipsec@tis.com, jaubert@cpcug.org Message-id: <199812311941.OAA02103@cletus.cw.net> X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk >From owner-ipsec@portal.ex.tis.com Wed Dec 30 22:53:33 1998 >Date: Wed, 30 Dec 1998 20:43:27 -0500 >From: Jack Aubert >Subject: Re: Basic IKE authentication question >X-Sender: jaubert@cpcug.org (Unverified) >To: Ramon Hontanon , ipsec@tis.com >MIME-version: 1.0 > >I had what amounts to the same question, and turned it into a very modest >paper for a graduate course in network security I just finished. > >The issue is, in essence: how can you manage a very large VPN using IP >sec? Suppose you want to set up a world-wide VPN with approximately 200 >entry points into a public cloud. This is more than theoretical. I work >at the State Department, where it would be useful to use IP sec to set up >encrypted tunnels between more than 200 posts throughout the world. This >works out to be a large number of bilateral relationships. They can each >be negotiated, but some central authority still has to keep track of who >can talk to whom, even if the ky distribution is handled by IKI. If you >have 200 posts and want to add (or modify) post 201, the existing 200 need >to know that it's OK to talk to number 201, but they have to netotiate an >encrypted tunnel and verify each other's certificates. > >The existing protocols allow use of route summarization and wild cards, >but if each tunnel point is a local ISP in a different country, this >doesn't help much since you have 200 unrelated IP addresses to deal with. >So the conclusion I drew was that most of the building blocks are >available, (including some new drafts dealing security policy specification >language) to manage a very large VPN, but a lot of manual assembly work is >still required until somebody implements a system to integrate it all. > >Jack Aubert Your last statement has answered your question. IPsec is the car engine, and someones still have to put together the rest of the car and pave the road. However, it'll be obsurd to ask this group to together the rest. John >At 03:08 PM 12/30/98 -0500, Ramon Hontanon wrote: >>I've read RFC2408 and RFC2409 searching for the answer to this >>(albeit basic) question, but haven't come up with an authoritative answer. >> >>What are the available options for peer authentication before an IPsec >>tunnel can be established? I suspect that they are: >> >>- Pre-shared keys (i.e. some string that both peers agree upon in advance) >>- X.509 certs from a Certificate Authority >> >>But how about: >> >>- Unverified public key exchange (like ssh) >>- Manual distribution of public keys (Cisco's IKE implementation) >> >>Thanks a lot, & happy new year to all! >> >>-- ramon >> >> >> >