From owner-ipsec@lists.tislabs.com Sun Aug 1 16:32:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA01672; Sun, 1 Aug 1999 16:32:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04515 Sun, 1 Aug 1999 17:56:03 -0400 (EDT) Date: Mon, 2 Aug 1999 00:56:32 +0300 (EET DST) Message-Id: <199908012156.AAA05231@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Valery Smyslov" Cc: Stephane Beaulieu , ipsec@lists.tislabs.com, ipsra Subject: RE: XAUTH is broken In-Reply-To: <199907270635.KAA07497@relay1.trustworks.com> References: <319A1C5F94C8D11192DE00805FBBADDFC41344@exchange> <199907270635.KAA07497@relay1.trustworks.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 11 min X-Total-Time: 13 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov writes: > But the usage of Attribute payload id in XAUTH is still unclear. > Should it be the same for all attribute payloads within one XAUTH > exchange or should it be changed with every REQUEST/REPLY SET/ACK > pair (as ISAKMP-CFG requires)? The former seems to simplify I think it should remain same all the time. I could not find any reference from the ISAKMP-CFG saying it must be changed every time. The draft-ietf-ipsec-isakmp-mode-cfg-04.txt just says it is "An identifier used to reference a configuration transaction within the individual messages." > processing a bit while the latter more strictly follows ISAKMP-CFG > draft (is it really needed if we define XAUTH as new exchange?). I don't think it is good idea to define new XAUTH exchange. There is no need for that. We can just use multiple configuration mode exchanges using the same attribute payload id, but different message id, until we see SET(STATUS=OK) message. The state machine is quite simple, and it does not interfare any way with the configuration modes used to implement the transport system (sending/receiving those attribute payloads). I think it makes things much easier if we just use cfg-mode as transport layer, without any modifications to it, and use "upper level state machine" to drive the xauth. This same "upper level state machine" is also used to decide things like do we need to get ip-address from the server, when can we start quick mode exchange etc. > > As for your question about concurrent XAUTHs. The answer is no. There's > > only one way end an XAUTH for a user and that's to send an SET(STATUS(OK)) > > message. If you were to have multiple XAUTH transactions, how could you > > tell when it's "really" done. There are mechanisms that allow you to send 2 > > REQUESTs within 1 XAUTH transaction. If there is multiple xauth transactions going, they all should have different attribute payload id. Only reason for that I can think of is if the server does not know what client is capable of doing. I.e server might start multiple xauths and see which of those the client selects, and when any one of those is successfully finished, then the server will allow quick mode exchange for that user. -- 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@lists.tislabs.com Sun Aug 1 17:40:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA02234; Sun, 1 Aug 1999 17:39:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04605 Sun, 1 Aug 1999 19:14:30 -0400 (EDT) Date: Mon, 2 Aug 1999 02:15:01 +0300 (EET DST) Message-Id: <199908012315.CAA16209@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Heyman, Michael" Cc: ipsec@lists.tislabs.com Subject: Processing multiple phase 2 SA payloads In-Reply-To: References: X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Heyman, Michael writes: > The document does not specify that the SA payloads returning to the > initiator are in the same order as the SA payloads transmitted (they RFC 2409 doesn't seem to state that, but I think that is only way to get it working. I think we should add text to draft-ietf-ipsec-ike-xx to say that. > If the responder must send the SA payload responses back in the same > order that the SA payloads they were derived from were received, does > that mean that the negotiation must proceed all or nothing? That is, I would say yes. All or nothing. > A new attribute could be defined with the sole purpose of > distinguishing otherwise identical transforms (this attribute must > have a different value every time it is used). I think it is easier to just clarify the draft, and add text saying that the reply SA payloads must be in same order than the proposal SA payloads. -- 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@lists.tislabs.com Sun Aug 1 18:25:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA08289; Sun, 1 Aug 1999 18:25:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04719 Sun, 1 Aug 1999 19:59:17 -0400 (EDT) Date: Mon, 2 Aug 1999 02:59:50 +0300 (EET DST) Message-Id: <199908012359.CAA04562@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: John Shriver Cc: ipsec@lists.tislabs.com Subject: weakness in IKE/DOI specs In-Reply-To: <199907281929.PAA20474@brill.shiva.com> References: <199907281929.PAA20474@brill.shiva.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 11 min X-Total-Time: 13 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk John Shriver writes: > I think it is perfectly appropriate to limit these to 32 bits, with > the range being 0 to (2^32)-1. I don't think there is any sensible > justification to allow 64 bit values, that's just too long a > lifetime. I think we should allow 64 bit values also. In 30 years (2.8.2029 23:48 GMT) those sending data using 10 gigabit radio link to mars using ipsec are quite sure to curse us we, because we force them to wait for 33 minutes every 7 minutes (the distance between earth and Mars is 1.38 AU). Of course they will create those SAs beforehand and create 20 of them at once, but still I think they might want to use bigger lifetimes... Of course we can define that support for 16 and 32 bit lifetimes is mandatory, and implemenations may support 64 bit lifetimes for kilobytes. > Also, are there any restrictions on the value of an Attribute Length? Currently no. > Is 1 a legal? Or must you use the short form when Attribute Length > would be less than 3? Also, is an attribute length of 3 legal for a > lifetime? I could want a lifetime of 128 Kbytes, I could choose to > code that as "00 02 00 03 01 00 00", rather than the far more sensible > "00 02 00 04 00 01 00 00". Can ANYONE parse that 3 byte lifetime? I > doubt it! Should we allow it? I don't think so! We currently parse anything that is shorter than 4 bytes (from 0 bytes up to 4 bytes). > This issue partly comes up because we've coded these as Unsigned32 in > the MIB, but there's nothing in the protocol definitions that assures > us that Unsigned32 is sufficient. I think we should not be limited to Unsigned32 there. -- 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@lists.tislabs.com Mon Aug 2 13:15:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA11383; Mon, 2 Aug 1999 13:15:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07383 Mon, 2 Aug 1999 14:15:45 -0400 (EDT) Message-ID: <37A5E060.2856AF18@thawte.com> Date: Mon, 02 Aug 1999 20:16:00 +0200 From: Mark Shuttleworth Reply-To: marks@thawte.com Organization: Thawte Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: PKIX vs draft-ietf-ipsec-pki-req-02.txt Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDAC96A2F0298384402C91FC5" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msDAC96A2F0298384402C91FC5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all I'm busy adding support for IPSEC server and client certificates to our certificate services portfolioand have run into a conflict between PKIX RFC2459 and draft-ietf-ipsec-pki-req-02.txt. Specifically, with regard to the OID's used in an ExtendedKeyUsage extension, there are two different proposals. PKIX has: id-kp-ipsecUser id-kp-ipsecTunnel id-kp-ipsecServer draft-ietf-ipsec-pki-req-02.txt has: iKEEnd iKEIntermediate Are these two complementary or conflicting? My immediate reaction based on experience in the SSL world is that it is very important to distinguish between servers and clients and so the PKIX mdoel makes more sense to me. Is this done differently in the draft-ietf-ipsec-pki-req-02.txt model? Do you use subjectAltNames for this (email vs domainname for example)? Also, we're very keen to test interoperability between our certs and your products. If you'd liek to do this please just let me know! Regards, -- Mark Shuttleworth Thawte --------------msDAC96A2F0298384402C91FC5 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIEgYJKoZIhvcNAQcCoIIIAzCCB/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BjUwggL0MIICXaADAgECAgJarDANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5 OC45LjE2MB4XDTk4MTIxODEyMzgyOFoXDTk5MTIxODEyMzgyOFowczEVMBMGA1UEBBMMU2h1 dHRsZXdvcnRoMRUwEwYDVQQqEwxNYXJrIFJpY2hhcmQxIjAgBgNVBAMTGU1hcmsgUmljaGFy ZCBTaHV0dGxld29ydGgxHzAdBgkqhkiG9w0BCQEWEG1hcmtzQHRoYXd0ZS5jb20wXDANBgkq hkiG9w0BAQEFAANLADBIAkEA4IQUDeMHoSSClHPcZgNMePwYJhJRfS/P+7Wl66ZOxzdw0Dso +hDBFmTt0y1z7TKnbkV9dWnLcSK6pRqPOd7/tQIDAQABo4GTMIGQMBEGCWCGSAGG+EIBAQQE AwIFoDAOBgNVHQ8BAf8EBAMCBaAwPAYFK2UBBAEEMzAxAgEAMCwwCgIBAQQFbWFya3MwDAIB AgQHZGVtb2lkMTAQAgEDBAtnaG9zdGJ1c3RlcjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FP4+YJxrjA+w2DPGysYeWLBxOLXgMA0GCSqGSIb3DQEBBAUAA4GBAFWcg41Aoa1I+6etNhbr IILnoHF6lBPX99T9oOHDKEUcQmXpxpYcp1tJB7vu64UzWWN+P+1z0NY8nc/XASzQddmx56z8 Op0eOsinIsWIj5LZuo6WgExe0gck1wjgvmHyA+JVPIWTdS6kZ/t8I/95fOhPCR+jPT+EMNzM rHbfW9wcMIIDOTCCAqKgAwIBAgIBCjANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFU aGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp c2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk4MDkxNjE3NTUzNFoXDTAw MDkxNTE3NTUzNFowgbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDAS BgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UE CxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKXl1NTQXwgC7gchfSS/q2uOHusgBwIVhGuP0JMkHxud7miyuSxP6ZNn FxAXHqH5Q0EjuTCqdpe78+f9gcC1MYv2plAmVPKVKOsZpB6XHrDiuJvBBJoy0DwJbE/kNU/w dr8AEwNPRQhg8/y00JABihLJnLp/UuoqkzU2PDzkNS8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQAsx4IfAUM+B4/uaVypZIL4wJatkyvLm1DXQJqBwrqmdp08lUDcVcHhVYJ5qwopptUM 4VcoPo/5u9XfDZNYqlsti48z5N1YFTV2chUpvUL0WpILd1+dJ9uaLU4bggaO0o1Wu5Xe2wxl Bd6VngLdUxe+vvxrwxoiehQrYb3Cn156WjGCAaUwggGhAgEBMIHAMIG5MQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45 LjE2IDE3OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3Vl ciAxOTk4LjkuMTYCAlqsMAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw05OTA4MDIxODE2MDFaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZI hvcNAwICASgwIwYJKoZIhvcNAQkEMRYEFE/WJZ+CLA3FazHyvFq358VEwQahMA0GCSqGSIb3 DQEBAQUABEClgP0K3tGe0PS7+FwyGb7ZO18C4n5jvVA1NOLE2hTygBam4K5DB8jrZWheW5g6 GbWbij5fjBXfASq3UpAsasxt --------------msDAC96A2F0298384402C91FC5-- From owner-ipsec@lists.tislabs.com Mon Aug 2 13:15:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA11391; Mon, 2 Aug 1999 13:15:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07467 Mon, 2 Aug 1999 14:50:04 -0400 (EDT) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="============_-1278502685==_ma============" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <37A5E060.2856AF18@thawte.com> Date: Mon, 2 Aug 1999 14:40:44 -0400 To: marks@thawte.com From: Stephen Kent Subject: Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1278502685==_ma============ Content-Type: text/plain; charset="us-ascii" Mark, IPsec, unlike SSL, has no client or server roles. It is a peer communication protocol. So, I am not so keen to put in distinctions of the sort you mentioned. Aslo, the following OIDs are from 2459, and they don't contain an "ipsec server" entry: KeyPurposeId ::= OBJECT IDENTIFIER -- extended key purpose OIDs id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } I hate to admit it, as co-chair of PKIX, but I'm not sure why we have an ipsecTunnel entry here. User and EndSystem make sense, but not tunnel. Steve --============_-1278502685==_ma============ Content-Type: text/enriched; charset="us-ascii" Mark, IPsec, unlike SSL, has no client or server roles. It is a peer communication protocol. So, I am not so keen to put in distinctions of the sort you mentioned. Aslo, the following OIDs are from 2459, and they don't contain an "ipsec server" entry: Courier_NewKeyPurposeId ::= OBJECT IDENTIFIER -- extended key purpose OIDs id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } I hate to admit it, as co-chair of PKIX, but I'm not sure why we have an ipsecTunnel entry here. User and EndSystem make sense, but not tunnel. Steve --============_-1278502685==_ma============-- From owner-ipsec@lists.tislabs.com Mon Aug 2 14:32:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA12449; Mon, 2 Aug 1999 14:32:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07736 Mon, 2 Aug 1999 15:52:18 -0400 (EDT) Message-ID: <37A5F6EB.FF654A15@thawte.com> Date: Mon, 02 Aug 1999 21:52:11 +0200 From: Mark Shuttleworth Reply-To: marks@thawte.com Organization: Thawte Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7607882CF8138DC1958C2576" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms7607882CF8138DC1958C2576 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Stephen Stephen Kent wrote: > IPsec, unlike SSL, has no client or server roles. It is a peer communication protocol. So, I am not so keen to put in distinctions of the sort you mentioned. I hear you. I'm still learning about IPSEC, and I like what I see. I'm not against peer to peer scenarios in any way, but I do think that the distinction is important. First, corporate security policies tend to be different for machines (web servers, routers) and for humans (s/mime, client auth). They tend to issue certificates differently to these broad groups. We see huge differences between S/MIME and SSL server certs. I believe that IPSEC to the desktop will become widespread. In that environment it makes sense to differentiate between the certificates you are issuing to people for desktop and remote-access authentication, and certs that you recognize for router authentication. If you don't make this distinction it is possible for someone to get a personal cert and use it to fake a router that wants to talk to your network. There are several ways you could differentiate: - different X.509 policy info - separate root or intermediate ca's - different EKUsages - different subjectAltNames I'm strongly in favour of the EKU approach, since EKU is widely used in other Internet apps. And you can have multiple EKUsages for a single cert if it makes business sense. I think X.509 policy info is largely wasted since very few implementations can use it. And it is cumbersome to force an organization to maintain separate CA's (MUCH easier to use separate EKU's). The subjectAltName method is promising. For example, a "server" could be defined as an object with a cert containing EKU:iKEEnd and a subjectAltName with a domain name that resolves to its IP address. Does all of this make sense, or am I missing the whole point entirely? > id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } > id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } > id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } You're right - I had an old version that had ipsecServer instead of EndSystem. Actually having Tunnel in there makes sense to me, since you definitely want to control certs that are ostensibly allowed to claim tunneling capability VERY tightly. I think ;-). What say you? -- Mark Shuttleworth Thawte --------------ms7607882CF8138DC1958C2576 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIEgYJKoZIhvcNAQcCoIIIAzCCB/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BjUwggL0MIICXaADAgECAgJarDANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5 OC45LjE2MB4XDTk4MTIxODEyMzgyOFoXDTk5MTIxODEyMzgyOFowczEVMBMGA1UEBBMMU2h1 dHRsZXdvcnRoMRUwEwYDVQQqEwxNYXJrIFJpY2hhcmQxIjAgBgNVBAMTGU1hcmsgUmljaGFy ZCBTaHV0dGxld29ydGgxHzAdBgkqhkiG9w0BCQEWEG1hcmtzQHRoYXd0ZS5jb20wXDANBgkq hkiG9w0BAQEFAANLADBIAkEA4IQUDeMHoSSClHPcZgNMePwYJhJRfS/P+7Wl66ZOxzdw0Dso +hDBFmTt0y1z7TKnbkV9dWnLcSK6pRqPOd7/tQIDAQABo4GTMIGQMBEGCWCGSAGG+EIBAQQE AwIFoDAOBgNVHQ8BAf8EBAMCBaAwPAYFK2UBBAEEMzAxAgEAMCwwCgIBAQQFbWFya3MwDAIB AgQHZGVtb2lkMTAQAgEDBAtnaG9zdGJ1c3RlcjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FP4+YJxrjA+w2DPGysYeWLBxOLXgMA0GCSqGSIb3DQEBBAUAA4GBAFWcg41Aoa1I+6etNhbr IILnoHF6lBPX99T9oOHDKEUcQmXpxpYcp1tJB7vu64UzWWN+P+1z0NY8nc/XASzQddmx56z8 Op0eOsinIsWIj5LZuo6WgExe0gck1wjgvmHyA+JVPIWTdS6kZ/t8I/95fOhPCR+jPT+EMNzM rHbfW9wcMIIDOTCCAqKgAwIBAgIBCjANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFU aGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp c2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk4MDkxNjE3NTUzNFoXDTAw MDkxNTE3NTUzNFowgbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDAS BgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UE CxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKXl1NTQXwgC7gchfSS/q2uOHusgBwIVhGuP0JMkHxud7miyuSxP6ZNn FxAXHqH5Q0EjuTCqdpe78+f9gcC1MYv2plAmVPKVKOsZpB6XHrDiuJvBBJoy0DwJbE/kNU/w dr8AEwNPRQhg8/y00JABihLJnLp/UuoqkzU2PDzkNS8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQAsx4IfAUM+B4/uaVypZIL4wJatkyvLm1DXQJqBwrqmdp08lUDcVcHhVYJ5qwopptUM 4VcoPo/5u9XfDZNYqlsti48z5N1YFTV2chUpvUL0WpILd1+dJ9uaLU4bggaO0o1Wu5Xe2wxl Bd6VngLdUxe+vvxrwxoiehQrYb3Cn156WjGCAaUwggGhAgEBMIHAMIG5MQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45 LjE2IDE3OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3Vl ciAxOTk4LjkuMTYCAlqsMAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw05OTA4MDIxOTUyMTNaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZI hvcNAwICASgwIwYJKoZIhvcNAQkEMRYEFErB11m9ITo31ym7A43/bROsumyeMA0GCSqGSIb3 DQEBAQUABECxy5NCIECCuW01kez1cCaTk13B0Duq7q9TF+5AZ1OgdUv5IWp/p87u6TvgQJt3 dKzRrije5GDeFxrAX1vvAUEi --------------ms7607882CF8138DC1958C2576-- From owner-ipsec@lists.tislabs.com Mon Aug 2 15:03:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA12894; Mon, 2 Aug 1999 15:03:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07921 Mon, 2 Aug 1999 16:30:37 -0400 (EDT) Message-Id: <3.0.6.32.19990802132815.00a59680@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 02 Aug 1999 13:28:15 -0700 To: rodney@ssh.fi From: Rodney Thayer Subject: Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt Cc: ipsec@lists.tislabs.com In-Reply-To: References: <37A5E060.2856AF18@thawte.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk well, if we're re-opening this worm can, then... why end system and not gateway? If I have a router that is a gateway in front of 3000 hosts, do I claim to be an End System? I certainly shouldn't claim to be a 'user' as there's no human associated with it, right? I thought we had consensus that we wanted to say "IPsec thing" or something non-commital as to user, end system, gateway, garage door opener, or anything else running IPsec. Do we want to pull the OID's out of my draft (and what, deprecate them out of the IANA registry?), or do we want to pull/alter the ones in 2459? At 02:40 PM 8/2/99 -0400, Stephen Kent wrote: >Mark, > >IPsec, unlike SSL, has no client or server roles. It is a peer >communication protocol. So, I am not so keen to put in distinctions of the >sort you mentioned. Aslo, the following OIDs are from 2459, and they don't >contain an "ipsec server" entry: > >KeyPurposeId ::= OBJECT IDENTIFIER > >-- extended key purpose OIDs >id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } >id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } >id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } >id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } >id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } >id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } >id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } >id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } > > >I hate to admit it, as co-chair of PKIX, but I'm not sure why we have an >ipsecTunnel entry here. User and EndSystem make sense, but not tunnel. > >Steve From owner-ipsec@lists.tislabs.com Tue Aug 3 02:22:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA25825; Tue, 3 Aug 1999 02:22:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA09246 Tue, 3 Aug 1999 03:01:59 -0400 (EDT) Message-ID: <37A69269.EC642A95@thawte.com> Date: Tue, 03 Aug 1999 08:55:37 +0200 From: Mark Shuttleworth Reply-To: marks@thawte.com Organization: Thawte Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Rodney Thayer CC: ipsec@lists.tislabs.com Subject: Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt References: <37A5E060.2856AF18@thawte.com> <3.0.6.32.19990802132815.00a59680@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms38552A01C52028147924C810" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms38552A01C52028147924C810 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Rodney Thayer wrote: > > why end system and not gateway? If I have a router that > is a gateway in front of 3000 hosts, do I claim to > be an End System? I certainly shouldn't claim to be > a 'user' as there's no human associated with it, right? I think ipsecTunnel makes perfect sense here. You are specifically saying that this device is allowed to offer tunneling. > I thought we had consensus that we wanted to say "IPsec thing" > or something non-commital as to user, end system, gateway, > garage door opener, or anything else running IPsec. You definitely want to have SOME way to differentiate, so that you can issue certificates to users under a different policy easily, and have your infrastructure recognize and act on the differentiation. But perhaps this differentiationshould be done based on the subjectAltName? Here's my concern. Say we want to issue 5,000 IPSEC certs to clients for remote access. And we have 10 routers that need to talk to one another. We install the CA cert on the routers. Now someone steals the key for one of our client certs (usually not hard to do if any one of the 5,000 will work). Can they install that "client" cert on a router and make it insert itself as a magical router number 11, since it has a cert issued by the CA? How will the other routers know to reject the client cert when it tries to behave like a router? Is it because it might have an emailAddress subjectAltName instead of an iPAddress/dNSName? > Do we want to pull the OID's out of my draft (and what, > deprecate them out of the IANA registry?), or do we want > to pull/alter the ones in 2459? I think your draft and RFC2459 should be consistent with one another, and I think the question of "how do you tell a router cert from a client cert" needs to be addressed. Cheers, -- Mark Shuttleworth Thawte --------------ms38552A01C52028147924C810 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIEgYJKoZIhvcNAQcCoIIIAzCCB/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BjUwggL0MIICXaADAgECAgJarDANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5 OC45LjE2MB4XDTk4MTIxODEyMzgyOFoXDTk5MTIxODEyMzgyOFowczEVMBMGA1UEBBMMU2h1 dHRsZXdvcnRoMRUwEwYDVQQqEwxNYXJrIFJpY2hhcmQxIjAgBgNVBAMTGU1hcmsgUmljaGFy ZCBTaHV0dGxld29ydGgxHzAdBgkqhkiG9w0BCQEWEG1hcmtzQHRoYXd0ZS5jb20wXDANBgkq hkiG9w0BAQEFAANLADBIAkEA4IQUDeMHoSSClHPcZgNMePwYJhJRfS/P+7Wl66ZOxzdw0Dso +hDBFmTt0y1z7TKnbkV9dWnLcSK6pRqPOd7/tQIDAQABo4GTMIGQMBEGCWCGSAGG+EIBAQQE AwIFoDAOBgNVHQ8BAf8EBAMCBaAwPAYFK2UBBAEEMzAxAgEAMCwwCgIBAQQFbWFya3MwDAIB AgQHZGVtb2lkMTAQAgEDBAtnaG9zdGJ1c3RlcjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FP4+YJxrjA+w2DPGysYeWLBxOLXgMA0GCSqGSIb3DQEBBAUAA4GBAFWcg41Aoa1I+6etNhbr IILnoHF6lBPX99T9oOHDKEUcQmXpxpYcp1tJB7vu64UzWWN+P+1z0NY8nc/XASzQddmx56z8 Op0eOsinIsWIj5LZuo6WgExe0gck1wjgvmHyA+JVPIWTdS6kZ/t8I/95fOhPCR+jPT+EMNzM rHbfW9wcMIIDOTCCAqKgAwIBAgIBCjANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFU aGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp c2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk4MDkxNjE3NTUzNFoXDTAw MDkxNTE3NTUzNFowgbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDAS BgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UE CxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKXl1NTQXwgC7gchfSS/q2uOHusgBwIVhGuP0JMkHxud7miyuSxP6ZNn FxAXHqH5Q0EjuTCqdpe78+f9gcC1MYv2plAmVPKVKOsZpB6XHrDiuJvBBJoy0DwJbE/kNU/w dr8AEwNPRQhg8/y00JABihLJnLp/UuoqkzU2PDzkNS8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQAsx4IfAUM+B4/uaVypZIL4wJatkyvLm1DXQJqBwrqmdp08lUDcVcHhVYJ5qwopptUM 4VcoPo/5u9XfDZNYqlsti48z5N1YFTV2chUpvUL0WpILd1+dJ9uaLU4bggaO0o1Wu5Xe2wxl Bd6VngLdUxe+vvxrwxoiehQrYb3Cn156WjGCAaUwggGhAgEBMIHAMIG5MQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45 LjE2IDE3OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3Vl ciAxOTk4LjkuMTYCAlqsMAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw05OTA4MDMwNjU1MzhaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZI hvcNAwICASgwIwYJKoZIhvcNAQkEMRYEFHb8P/CEModZkwNGKzTkhaCcX/WdMA0GCSqGSIb3 DQEBAQUABEBPIx5CizLLKtRhhWXeyM2AQQVWs7vLJx7ddKhOsB0y4UiCWWj2QIbL/SPAxqw9 7T0YKvbtO37+KGJjmyIwanDw --------------ms38552A01C52028147924C810-- From owner-ipsec@lists.tislabs.com Tue Aug 3 07:42:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA07459; Tue, 3 Aug 1999 07:42:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11016 Tue, 3 Aug 1999 09:06:37 -0400 (EDT) Message-ID: <37A6E90E.78A96F63@ennovatenetworks.com> Date: Tue, 03 Aug 1999 09:05:18 -0400 From: Daniel Fox X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: Tero Kivinen , John Shriver Subject: Re: weakness in IKE/DOI specs References: <199907281929.PAA20474@brill.shiva.com> <199908012359.CAA04562@torni.ssh.fi> Content-Type: multipart/mixed; boundary="------------6E90BFB6EC5A317D545BC8AF" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------6E90BFB6EC5A317D545BC8AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If we need bigger numbers, we can simply add a new SA Life Type of, say, days or GB. I think that 32 bits is more than enough granularity. -Dan Tero Kivinen wrote: >I think we should allow 64 bit values also. In 30 years (2.8.2029 >23:48 GMT) those sending data using 10 gigabit radio link to mars >using ipsec are quite sure to curse us we, because we force them to >wait for 33 minutes every 7 minutes (the distance between earth and >Mars is 1.38 AU). >Of course we can define that support for 16 and 32 bit lifetimes is >mandatory, and implemenations may support 64 bit lifetimes for >kilobytes. --------------6E90BFB6EC5A317D545BC8AF Content-Type: text/x-vcard; charset=us-ascii; name="dfox.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Daniel Fox Content-Disposition: attachment; filename="dfox.vcf" begin:vcard n:Fox;Daniel tel;fax:978-263-1099 tel;work:978-263-2002 x-mozilla-html:FALSE url:http://www.ennovatenetworks.com org:Ennovate Networks adr:;;330 Codman Hill Road;Boxborough;MA;01719;USA version:2.1 email;internet:dfox@ennovatenetworks.com title:Senior Software Engineer fn:Daniel Fox end:vcard --------------6E90BFB6EC5A317D545BC8AF-- From owner-ipsec@lists.tislabs.com Tue Aug 3 10:20:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA11150; Tue, 3 Aug 1999 10:20:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11512 Tue, 3 Aug 1999 10:14:33 -0400 (EDT) Date: Tue, 3 Aug 1999 17:14:56 +0300 (EET DST) Message-Id: <199908031414.RAA15130@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Daniel Fox Cc: ipsec@lists.tislabs.com, John Shriver Subject: Re: weakness in IKE/DOI specs In-Reply-To: <37A6E90E.78A96F63@ennovatenetworks.com> References: <199907281929.PAA20474@brill.shiva.com> <199908012359.CAA04562@torni.ssh.fi> <37A6E90E.78A96F63@ennovatenetworks.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Daniel Fox writes: > If we need bigger numbers, we can simply add a new SA Life Type of, say, > days or GB. I think that 32 bits is more than enough granularity. Which will mean that all current distributed products must be updated to support that. It is quite easy to write a code to support 64 bit numbers initially (in our code I need to change something like 20 lines of code (c-compiler must have support for 64 bit integers)). I don't really think it is good idea to add new life types for that kind of things. -- 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@lists.tislabs.com Tue Aug 3 13:22:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA14868; Tue, 3 Aug 1999 13:22:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13503 Tue, 3 Aug 1999 14:52:19 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC98D95@exchange> From: Stephane Beaulieu To: ipsec , ipsra Subject: the next rev of XAUTH Date: Tue, 3 Aug 1999 14:55:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, Sorry to keep bringing XAUTH up, but I just want to make sure everyone is in agreement before we proceed. A few weeks ago, there was a thread going on about modifying XAUTH to make it's state machine cleaner. I asked for comments and got quite a few, both private and public. I'd like to resolve this ASAP so that vendors who are interested in doing XAUTH can test interop at the next bakeoff. I've narrowed it down to 2 proposed changes which have both received a fair amount of support, and I'd like to get input as to which we should push forward. I would really like to hear from those who have already implemented, and who plan on implementing this in the near future on which proposal they prefer. Proposal 1: Use a new Exchange ID for XAUTH, with the same Isakmp Message ID, and XAUTH identifier throughout the transaction. Pros: - Easier to make the IKE state transitions because it is easier to tell whether we're really doing XAUTH or IKE-Config (we don't have to look inside the packet to figure it out) - State machine for Isakmp Processing is simple: if it is an IKE-Config exchange it is 2 messages, if it is an XAUTH exchange it is multiples of 2, until STATUS and ACK are done, then you can clean up your states. Cons: - Will have to use a new ISAKMP Exchange ID (240?), this will cause problems for those with an implementation already out there. - Exchange ID will change once/if XAUTH becomes an RFC, this means that we'll have to switch the Exchange ID once again and use Vendor ID payloads to maintain backwards compatibility. - Code re-use isn't as easy, because XAUTH and Ike-Config would have different behaviors. Proposal 2: Use IKE-Config as a transport (as it is today) but force the use of a new Isakmp Message ID for each REQUEST/REPLY, SET/ACK pair, and keep the identifier in the Ike-Config attribute payload consistent for all the XAUTH messages. Pros: - State machine for Isakmp Processing is simple: an IKE-Config transaction is always 2 messages. - Code re-use is much easier; little code needed to write new code if you already have Ike-Config - the Isakmp Exchange ID is more likely to remain as it is today (no backwards compatibility issues in the future) - Easier transition for those who already have XAUTH implemented. Cons: - Your IKE state machine doesn't know what it is processing (Ike-Config, or XAUTH) unless it looks inside the Ike-Config message or is notified by some other handler. Again, I'd like to get this resolved in the next 2 weeks, so if you've got an opinion on this matter, speak up now. Let me know what it is that you prefer. Thanks, Stephane. Stephane Beaulieu TimeStep Corporation sbeaulieu@timestep.com http://www.timestep.com (613) 599-3610 x4709 Fax: (613) 599-3617 From owner-ipsec@lists.tislabs.com Tue Aug 3 17:44:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA03377; Tue, 3 Aug 1999 17:44:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA14367 Tue, 3 Aug 1999 19:17:49 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <37A69269.EC642A95@thawte.com> References: <37A5E060.2856AF18@thawte.com> <3.0.6.32.19990802132815.00a59680@127.0.0.1> Date: Tue, 3 Aug 1999 16:21:01 -0400 To: marks@thawte.com From: Stephen Kent Subject: Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark & Rodney, Certs are inputs to access control decisions, but one must be careful to not overload a cert. It is not a place to put eveything one might wish to express in terms of A/C policy. Extended key usage flags should represent simple differentiators for key usage, with some security basis. In S/MIME, one can see a good reason to distinguish keys used for signatures vs. key transport, for example. The flag for ipsecTunnel strikes me as an example of overloading. In IPsec we may need to distinguish between an end system and a security gateway. But, I don't know if we need to do this via use of these flags. I'd like to hear some cogent arguments. If we can't define a set of flags that we all agree are appropriate for IPsec, then 2459, when revised for Proposed, may drop all of them and leave it to the IPsec WG to define its own. steve From owner-ipsec@lists.tislabs.com Tue Aug 3 17:44:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA03388; Tue, 3 Aug 1999 17:44:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA14361 Tue, 3 Aug 1999 19:17:21 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: Date: Tue, 3 Aug 1999 14:50:48 -0400 To: "Linn, John" From: Stephen Kent Subject: RE: Using Legacy Authentication for IPSRA (was : xauth requiremen ts: vulnerabilities) Cc: IPSec mailing list Sender: owner-ipsec@lists.tislabs.com Precedence: bulk John, Your taxonomy is a nice one, but I think another way to view this issue is to remember that the primary reason for authentication in IPsec is as input to an iddentity-based access control decision that is enforced by the IPsec receiver. RFC 2401 defines a set of ID forms for use in the SPD, and they define the types of principles to which access is granted. This includes both devices (based on IP address or DNS name or DN) and people (based on RFC822 name or DN). [Often there is an assumption that if one authenticates an end system, and it is a single user end system, then there is a one-to-one mapping to a specific user, even if that mapping is not expressed in the SPD by the choice of name form.] IPsec does not support authentication of a compound principle, or of a user and a system independently. It would not sense to do so unless there was a corresponding SPD entry type for compound principles. Steve P.S. I avoid using the term "client" with IPsec as the protocols do not have clients and servers. We have end systems and security gateways. From owner-ipsec@lists.tislabs.com Wed Aug 4 02:00:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA06558; Wed, 4 Aug 1999 02:00:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA15458 Wed, 4 Aug 1999 03:14:18 -0400 (EDT) Message-ID: <37A7E859.DF16767D@thawte.com> Date: Wed, 04 Aug 1999 09:14:33 +0200 From: Mark Shuttleworth Reply-To: marks@thawte.com Organization: Thawte Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt References: <37A5E060.2856AF18@thawte.com> <3.0.6.32.19990802132815.00a59680@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms1796262BE0F24CA2F3AF3BD4" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms1796262BE0F24CA2F3AF3BD4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Stephen I'm certainly in agreement with you about overloading. But I think that organizations will want to build SIMPLE rules to differentiate between routers, gateways and end-users. They should be able to do this JUST by looking at the cert, and not by referring to a directory or other source (otherwise you add another fragile link in the chain). So, there needs to be some broad agreement about how this is done so that these policies can work in a heterogenous environment. For example, in many of the current implementations I've seen you have to explicitly manually trust the certificates of each of the devices you want to talk to. This is a configuration nightmare in larger-scale deployments. Each device needs to be manually told about n other certificates (and updated each time one of them expires). You really want to be able to say "look at the iPAddress or dNSName in the cert and make sure it matches the iPAddress with which you are exchanging packets". This way there is no manual configuration of certificates - each router has a normal set of routing tables and expects the routers it talks to securely to be able to produce a valid cert signed by one of the trusted CA's with a subjectAltName that matches its dNSName or iPAddress. The preferred way for us would be subjectAltName. In other words, for machine, router and gateway certificates we put an IPaddress or dNSName in the cert, while for user certificates we put one or more email addresses. If this was the rule, then we could differentiate between "machine" certificates and "human" certificates on the basis of the subjectAltName. Then I would be happy with Rodney's proposal of iKEEnd and iKEIntermediate. Servers and point-to-point routers would have iKEEnd with a subjectAltName iPAddress or dNSName, while end-users would have iKEEnd with a subjectAltName rfc822Name. Firewalls would have iKEIntermediate with a dNSName or iPAddress. Does this make sense? -- Mark Shuttleworth Thawte --------------ms1796262BE0F24CA2F3AF3BD4 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIEgYJKoZIhvcNAQcCoIIIAzCCB/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BjUwggL0MIICXaADAgECAgJarDANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5 OC45LjE2MB4XDTk4MTIxODEyMzgyOFoXDTk5MTIxODEyMzgyOFowczEVMBMGA1UEBBMMU2h1 dHRsZXdvcnRoMRUwEwYDVQQqEwxNYXJrIFJpY2hhcmQxIjAgBgNVBAMTGU1hcmsgUmljaGFy ZCBTaHV0dGxld29ydGgxHzAdBgkqhkiG9w0BCQEWEG1hcmtzQHRoYXd0ZS5jb20wXDANBgkq hkiG9w0BAQEFAANLADBIAkEA4IQUDeMHoSSClHPcZgNMePwYJhJRfS/P+7Wl66ZOxzdw0Dso +hDBFmTt0y1z7TKnbkV9dWnLcSK6pRqPOd7/tQIDAQABo4GTMIGQMBEGCWCGSAGG+EIBAQQE AwIFoDAOBgNVHQ8BAf8EBAMCBaAwPAYFK2UBBAEEMzAxAgEAMCwwCgIBAQQFbWFya3MwDAIB AgQHZGVtb2lkMTAQAgEDBAtnaG9zdGJ1c3RlcjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FP4+YJxrjA+w2DPGysYeWLBxOLXgMA0GCSqGSIb3DQEBBAUAA4GBAFWcg41Aoa1I+6etNhbr IILnoHF6lBPX99T9oOHDKEUcQmXpxpYcp1tJB7vu64UzWWN+P+1z0NY8nc/XASzQddmx56z8 Op0eOsinIsWIj5LZuo6WgExe0gck1wjgvmHyA+JVPIWTdS6kZ/t8I/95fOhPCR+jPT+EMNzM rHbfW9wcMIIDOTCCAqKgAwIBAgIBCjANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFU aGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp c2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk4MDkxNjE3NTUzNFoXDTAw MDkxNTE3NTUzNFowgbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDAS BgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UE CxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKXl1NTQXwgC7gchfSS/q2uOHusgBwIVhGuP0JMkHxud7miyuSxP6ZNn FxAXHqH5Q0EjuTCqdpe78+f9gcC1MYv2plAmVPKVKOsZpB6XHrDiuJvBBJoy0DwJbE/kNU/w dr8AEwNPRQhg8/y00JABihLJnLp/UuoqkzU2PDzkNS8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQAsx4IfAUM+B4/uaVypZIL4wJatkyvLm1DXQJqBwrqmdp08lUDcVcHhVYJ5qwopptUM 4VcoPo/5u9XfDZNYqlsti48z5N1YFTV2chUpvUL0WpILd1+dJ9uaLU4bggaO0o1Wu5Xe2wxl Bd6VngLdUxe+vvxrwxoiehQrYb3Cn156WjGCAaUwggGhAgEBMIHAMIG5MQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45 LjE2IDE3OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3Vl ciAxOTk4LjkuMTYCAlqsMAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw05OTA4MDQwNzE0MzRaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZI hvcNAwICASgwIwYJKoZIhvcNAQkEMRYEFIRkZYrgnr1X1mNQ2TFZgUUcVstbMA0GCSqGSIb3 DQEBAQUABEBgfdkHGAIHXadjas1YEAHrhiZQeBwfOt8rqiUVlSxtS1X6nhAfQr+eKHlLiDRA aMSebvLlmn0mV7095N94K2jA --------------ms1796262BE0F24CA2F3AF3BD4-- From owner-ipsec@lists.tislabs.com Wed Aug 4 09:56:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA28133; Wed, 4 Aug 1999 09:56:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00913 Wed, 4 Aug 1999 11:10:43 -0400 (EDT) Message-Id: <37A85787.C3BC7B88@radguard.com> Date: Wed, 04 Aug 1999 18:08:56 +0300 From: Sara Bitan Organization: RADGUARD X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: Stephen Kent Cc: IPSec mailing list , ipsra Subject: Re: Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, Stephen Kent wrote: > John, > > Your taxonomy is a nice one, but I think another way to view this issue is > to remember that the primary reason for authentication in IPsec is as input > to an iddentity-based access control decision that is enforced by the IPsec > receiver. RFC 2401 defines a set of ID forms for use in the SPD, and they > define the types of principles to which access is granted. This includes > both devices (based on IP address or DNS name or DN) and people (based on > RFC822 name or DN). [Often there is an assumption that if one > authenticates an end system, and it is a single user end system, then there > is a one-to-one mapping to a specific user, even if that mapping is not > expressed in the SPD by the choice of name form.] When an IPSec implementation is examining an IP packet against the SPD it has no clue which DNS name or DN name matches the IP addresses in the header. I think that the purpose of the authentication process is to bind a DN or DNS name to an IP address so that matching of a packet against the SPD is possible. > IPsec does not support > authentication of a compound principle, or of a user and a system > independently. It would not sense to do so unless there was a > corresponding SPD entry type for compound principles. I don't think IPSec needs to support compound principles. I do think that we need to define requirements from the authentication process that binds between the DN and the IP address. I think this should be an IPSec extension, and part of the IPSRA work. In this context I think this taxonomy is helpful. > > > Steve > > P.S. I avoid using the term "client" with IPsec as the protocols do not > have clients and servers. We have end systems and security gateways. Sara. From owner-ipsec@lists.tislabs.com Wed Aug 4 10:59:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA00260; Wed, 4 Aug 1999 10:59:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00865 Wed, 4 Aug 1999 10:57:02 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC99051@exchange> From: Tim Jenkins To: ipsec@lists.tislabs.com Subject: Retransmits in traffic count? Date: Wed, 4 Aug 1999 10:59:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk All, In the last version of the IPsec SA monitoring MIB, I put in that the counters for traffic against the SA lifetime (when limited by traffic) should include all re-transmits. The logic was that this was a conservative usage and that (hopefully) re-transmits would not be common. No one has made any comment on this one way or the other. Are the any opinions on this, or should I leave the MIB draft as it is in this regard? Thanks, Tim --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 From owner-ipsec@lists.tislabs.com Wed Aug 4 14:09:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA10209; Wed, 4 Aug 1999 14:09:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01629 Wed, 4 Aug 1999 14:53:57 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC99268@exchange> From: Tim Jenkins To: ipsec@lists.tislabs.com Subject: RE: Retransmits in traffic count? Date: Wed, 4 Aug 1999 14:56:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA01626 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry, I meant the ISAKMP DOI-independent MIB. Re-transmissions due to time-outs in negotiation. -----Original Message----- From: Tim Jenkins [mailto:tjenkins@TimeStep.com] Sent: August 4, 1999 11:00 AM To: ipsec@lists.tislabs.com Subject: Retransmits in traffic count? All, In the last version of the IPsec SA monitoring MIB, I put in that the counters for traffic against the SA lifetime (when limited by traffic) should include all re-transmits. The logic was that this was a conservative usage and that (hopefully) re-transmits would not be common. No one has made any comment on this one way or the other. Are the any opinions on this, or should I leave the MIB draft as it is in this regard? Thanks, Tim --- Tim Jenkins                       TimeStep Corporation tjenkins@timestep.com          http://www.timestep.com (613) 599-3610 x4304               Fax: (613) 599-3617 From owner-ipsec@lists.tislabs.com Wed Aug 4 15:16:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA15268; Wed, 4 Aug 1999 15:16:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02686 Wed, 4 Aug 1999 16:36:39 -0400 (EDT) Content-return: allowed Date: Wed, 04 Aug 1999 19:12:05 +0000 From: "Pizzimenti, Joe" Subject: When was last bakeoff - next bakeoff? To: "'ipsec@lists.tislabs.com'" Message-id: <93496446F5EDD211A8C100805FEAD7490162D3@nsrip00207.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2571.0) Content-type: multipart/alternative; boundary="----_=_NextPart_001_01BEDEAD.37346D26" Sender: owner-ipsec@lists.tislabs.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_01BEDEAD.37346D26 Content-Type: text/plain; charset="iso-8859-1" Could anyone supply me with the date of the next ipsec bakeoff? Also, would anyone tell me where I could find information - recaps of previous bakeoffs? I'm new to the mailing list, just registered, and possibly will not receive e-mail directed to the ipsec mailing list, so please copy my e-mail address with any responses. Thanks. - Joe Pizzimenti Senior Engineer MCIWorldCom joe.pizzimenti@wcom.com ------_=_NextPart_001_01BEDEAD.37346D26 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When was last bakeoff - next bakeoff?

Could anyone supply me with the date = of the next ipsec bakeoff?
Also, would anyone tell me where I = could find information - recaps of
previous bakeoffs?

I'm new to the mailing list, just = registered, and possibly will not receive e-mail directed to the ipsec = mailing list, so please copy my e-mail address with

any responses.

Thanks.

- Joe Pizzimenti
Senior Engineer
MCIWorldCom
joe.pizzimenti@wcom.com

------_=_NextPart_001_01BEDEAD.37346D26-- From owner-ipsec@lists.tislabs.com Wed Aug 4 16:05:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA18708; Wed, 4 Aug 1999 16:05:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02894 Wed, 4 Aug 1999 17:38:18 -0400 (EDT) From: Dan McDonald Message-Id: <199908042138.OAA03809@kebe.Eng.Sun.COM> Subject: Re: Retransmits in traffic count? To: tjenkins@TimeStep.com (Tim Jenkins) Date: Wed, 4 Aug 1999 14:38:50 -0700 (PDT) Cc: ipsec@lists.tislabs.com In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFC99268@exchange> from "Tim Jenkins" at Aug 4, 99 02:56:42 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@lists.tislabs.com Precedence: bulk > Sorry, I meant the ISAKMP DOI-independent MIB. Re-transmissions due to > time-outs in negotiation. What negotiation and retransmission are you talking about? If there are time-outs in the IKE negotiation how will there be any relevant IPsec SAs to monitor? If you mean TCP retransmission, those retransmitted packets should _definitely_ be included in any IPsec SA byte-lifetime counters. Dan From owner-ipsec@lists.tislabs.com Wed Aug 4 19:08:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA01626; Wed, 4 Aug 1999 19:08:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03401 Wed, 4 Aug 1999 20:27:44 -0400 (EDT) Message-Id: <3.0.5.32.19990804172951.009b8ec0@10.1.10.20> X-Sender: fletcher@10.1.10.20 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 04 Aug 1999 17:29:51 -0700 To: ipsec@lists.tislabs.com From: fletcher@cylink.com (Fergus Fletcher) Subject: DF / PMTU Question Cc: fletcher@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello all, I'm unclear as to the required/desired handling by a security gateway of: 1. the DF (DONT-FRAGMENT) flag, and its interaction with 2. the PMTU stored for SAs in the SAD (Studying RFC-2401 and searching through the IPSEC-list archive, has not helped). 1. According to RFC-2401 when a SGW tunnels a packet, it uses local policy to decide the DF value to use in the outer header: (a) copy DF bit from inner packet (b) set DF bit (c) clear DF bit In line with how a router handles traffic, when the outer DF value = set, the packet should be dropped if the tunneled packet exceeded the MTU of the next hop. An ICMP message "Fragmentation needed and DF set" should then be returned to the sending host. When Outer DF value = clear , the packet should be fragmented if the tunneled packet exceeded the MTU of the next hop. 2. According to RFC-2401 when an SGW receives an ICMP error message "Fragmentation needed and DF set", but it cannot determine the originating host, it should store the PMTU (reduced by any IPsec overhead) with the SA. When subsequent packets are received on this SA and they exceed the PMTU stored for the SA, the packet should be dropped and an ICMP message "Fragmentation needed and DF set" should then be returned to the sending host. Since RFC-2401 makes no mention of consulting DF, I assume this should be done regardless of the value of DF. After some local configurable time, the PMTU value stored with the SA should be aged and replaced with the interface MTU. There is a conflict between the behavior 1 and 2 described above. e.g. Suppose a packet which has DF clear in its outer header exceeds the interface MTU / SA PMTU. Should the packet be fragmented, or dropped and an ICMP error generated ? Should this be a configurable local policy ? I would appreciate any comments. Thanks, Fergus Fletcher -- Tel. : (408) 328-5445 E-mail: fletcher@cylink.com -- Fax. : (408) 735-6645 -- Cylink Corporation, -- 910 Hermosa Court , Sunnyvale, CA 94086 From owner-ipsec@lists.tislabs.com Thu Aug 5 08:11:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA24510; Thu, 5 Aug 1999 08:11:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05790 Thu, 5 Aug 1999 08:41:40 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC993A6@exchange> From: Tim Jenkins To: Dan McDonald Cc: ipsec@lists.tislabs.com Subject: RE: Retransmits in traffic count? Date: Thu, 5 Aug 1999 08:44:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Let me start again. Should the traffic used in re-transmitting packets used in phase 1 SAs while negotiating anything be counted against the traffic-based lifetime of the SA? In other words, if I have to send the first quick mode 1 message three times before I get a response from the peer, should that first packet's traffic be counted one time or three times against the phase 1 SA's lifetime (by traffic) limitation? The current ISAKMP DOI-independent MIB does: ==> saInPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the ISAKMP phase 1 SA, including un-encrypted packets used to negotiate the ISAKMP phase 1 SA, and any re-transmissions." ::= { saEntry 13 } saOutPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets sent by the ISAKMP phase 1 SA, including un-encrypted packets used to negotiate the ISAKMP phase 1 SA, and any re-transmissions received." ::= { saEntry 14 } saInOctets OBJECT-TYPE SYNTAX Counter32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of encrypted traffic measured in bytes received by the ISAKMP phase 1 SA. This includes encrypted traffic used to negotiate the ISAKMP phase 1 SA, and any re-transmissions received." ::= { saEntry 15 } saOutOctets OBJECT-TYPE SYNTAX Counter32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of encrypted traffic measured in bytes sent by the ISAKMP phase 1 SA. This includes encrypted traffic used to negotiate the ISAKMP phase 1 SA, and any re-transmissions." ::= { saEntry 16 } <== I'm thinking I should remove the "including re-transmissions" part of those and related objects. Other objects are the global counters. Should they include re-transmissions if the individual SAs don't? That's what I'm asking about. -----Original Message----- From: Dan McDonald [mailto:danmcd@Eng.Sun.Com] Sent: August 4, 1999 5:39 PM To: tjenkins@TimeStep.com Cc: ipsec@lists.tislabs.com Subject: Re: Retransmits in traffic count? > Sorry, I meant the ISAKMP DOI-independent MIB. Re-transmissions due to > time-outs in negotiation. What negotiation and retransmission are you talking about? If there are time-outs in the IKE negotiation how will there be any relevant IPsec SAs to monitor? If you mean TCP retransmission, those retransmitted packets should _definitely_ be included in any IPsec SA byte-lifetime counters. Dan From owner-ipsec@lists.tislabs.com Thu Aug 5 10:22:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA28278; Thu, 5 Aug 1999 10:22:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06277 Thu, 5 Aug 1999 10:13:28 -0400 (EDT) Date: Thu, 5 Aug 1999 09:13:25 -0500 (CDT) From: David Borman Message-Id: <199908051413.JAA24818@frantic.bsdi.com> To: fletcher@cylink.com, ipsec@lists.tislabs.com Subject: Re: DF / PMTU Question Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Date: Wed, 04 Aug 1999 17:29:51 -0700 > From: fletcher@cylink.com (Fergus Fletcher) > Subject: DF / PMTU Question > ... > Hello all, > > I'm unclear as to the required/desired handling by a security > gateway of: > > 1. the DF (DONT-FRAGMENT) flag, and its interaction with > 2. the PMTU stored for SAs in the SAD >... > 2. According to RFC-2401 when an SGW receives an ICMP error > message "Fragmentation needed and DF set", but it cannot > determine the originating host, it should store the PMTU > (reduced by any IPsec overhead) with the SA. > > When subsequent packets are received on this SA and they > exceed the PMTU stored for the SA, the packet should be > dropped and an ICMP message "Fragmentation needed and DF > set" should then be returned to the sending host. > > Since RFC-2401 makes no mention of consulting DF, I assume > this should be done regardless of the value of DF. That is not a good assumption. RFC-2401 deals with both IPv4 and IPv6. IPv6 does not have a DF bit, it is just assumed. For IPv4, if the incoming packet does not have the DF bit set, it should be fragmented and sent along its way. Failure to do so can break lots of things (like anything that isn't TCP...). You do *not* want to generate an "ICMP fragmentation needed and DF set" message unless you know that the host will understand it properly, and the only way you know that is by the presence of the DF bit. -David Borman, dab@bsdi.com From owner-ipsec@lists.tislabs.com Thu Aug 5 10:31:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA28561; Thu, 5 Aug 1999 10:31:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06377 Thu, 5 Aug 1999 10:36:56 -0400 (EDT) Message-Id: <199908051434.KAA19538@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt In-reply-to: Your message of "Wed, 04 Aug 1999 09:14:33 +0200." <37A7E859.DF16767D@thawte.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Thu, 05 Aug 1999 10:34:08 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Mark" == Mark Shuttleworth writes: Mark> I'm certainly in agreement with you about overloading. But I think Mark> that organizations will want to build SIMPLE rules to differentiate Mark> between routers, gateways and end-users. They should be able to do Mark> this JUST by looking at the cert, and not by referring to a Mark> directory or other source (otherwise you add another fragile link Mark> in the chain). So, sign these three things with different CAs. Better yet, attach attribute authority or SPKI certs to the plain certificate. Mark> For example, in many of the current implementations I've seen you Mark> have to explicitly manually trust the certificates of each of the Mark> devices you want to talk to. This is a configuration nightmare in Mark> larger-scale deployments. Each device needs to be manually told That is why you want AA or SPKI certificates. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Aug 5 11:43:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA01012; Thu, 5 Aug 1999 11:43:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07115 Thu, 5 Aug 1999 13:13:49 -0400 (EDT) From: Dan McDonald Message-Id: <199908051713.KAA05877@kebe.Eng.Sun.COM> Subject: Re: Retransmits in traffic count? To: tjenkins@TimeStep.com (Tim Jenkins) Date: Thu, 5 Aug 1999 10:13:59 -0700 (PDT) Cc: ipsec@lists.tislabs.com In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFC993A6@exchange> from "Tim Jenkins" at Aug 5, 99 08:44:32 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@lists.tislabs.com Precedence: bulk > Let me start again. > > Should the traffic used in re-transmitting packets used in phase 1 SAs while > negotiating anything be counted against the traffic-based lifetime of the > SA? > > In other words, if I have to send the first quick mode 1 message three times > before I get a response from the peer, should that first packet's traffic be > counted one time or three times against the phase 1 SA's lifetime (by > traffic) limitation? Sorry 'bout parsing the original question wrong. IMHO, yes, count those QM retransmissions. A bad guy/girl doing traffic analysis can put 2+2 together and probably see that it's QM retransmissions, and it may aid in his/her cryptanalysis. Just my $0.02. Dan From owner-ipsec@lists.tislabs.com Thu Aug 5 11:44:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA01033; Thu, 5 Aug 1999 11:44:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07085 Thu, 5 Aug 1999 13:07:44 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC99575@exchange> From: Tim Jenkins To: Ricky Charlet Cc: ipsec@lists.tislabs.com Subject: RE: Retransmits in traffic count? Date: Thu, 5 Aug 1999 13:08:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Ricky Charlet [mailto:rcharlet@redcreek.com] > Sent: August 5, 1999 12:06 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Retransmits in traffic count? > > Actually, I can't think of a reason not to count the > retransmissions in > all of these counters. (that don't mean there ain't one!) > Could you tell > us about the potential motivations you see for > this? > Potential reasons why not: It doesn't really count against the lifetime of the keying material, since there is no new information offered to an attacker since the re-transmits are identical. (I'd like a crypto expert to confirm or dispute this, if possible.) It might be more difficult to implement, since the process of encryption (and thus counting expirations) is likely to be in a completely different process/thread/chunk-of-code than the process of handling the time-outs and re-transmissions. That's all I can think of. Neither of them are very strong one way or the other; perhaps that's why I didn't get any objections to the original wording in the MIB. But on the other hand, I got so few comments, I wasn't sure anyone had read it... From owner-ipsec@lists.tislabs.com Thu Aug 5 11:44:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA01034; Thu, 5 Aug 1999 11:44:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07008 Thu, 5 Aug 1999 12:59:42 -0400 (EDT) Message-ID: <37A9B671.5C89BEE1@redcreek.com> Date: Thu, 05 Aug 1999 16:06:09 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: ipsec@lists.tislabs.com Subject: Re: Retransmits in traffic count? References: <319A1C5F94C8D11192DE00805FBBADDFC993A6@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim Jenkins wrote: > > Let me start again. > > Should the traffic used in re-transmitting packets used in phase 1 SAs while > negotiating anything be counted against the traffic-based lifetime of the > SA? > > In other words, if I have to send the first quick mode 1 message three times > before I get a response from the peer, should that first packet's traffic be > counted one time or three times against the phase 1 SA's lifetime (by > traffic) limitation? Three Times! > > The current ISAKMP DOI-independent MIB does: > > ==> > > saInPackets OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of packets received by the ISAKMP phase 1 > SA, including un-encrypted packets used to negotiate the ISAKMP phase 1 SA, > and any re-transmissions." > ::= { saEntry 13 } > > saOutPackets OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The total number of packets sent by the ISAKMP phase 1 SA, > including un-encrypted packets used to negotiate the ISAKMP phase 1 SA, and > any re-transmissions received." > ::= { saEntry 14 } > > saInOctets OBJECT-TYPE > SYNTAX Counter32 > UNITS "bytes" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The amount of encrypted traffic measured in bytes received > by the ISAKMP phase 1 SA. This includes encrypted traffic used to negotiate > the ISAKMP phase 1 SA, and any re-transmissions received." > ::= { saEntry 15 } > > saOutOctets OBJECT-TYPE > SYNTAX Counter32 > UNITS "bytes" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The amount of encrypted traffic measured in bytes sent by > the ISAKMP phase 1 SA. This includes encrypted traffic used to negotiate the > ISAKMP phase 1 SA, and any re-transmissions." > ::= { saEntry 16 } > > <== > > I'm thinking I should remove the "including re-transmissions" part of those > and related objects. > > Other objects are the global counters. Should they include re-transmissions > if the individual SAs don't? I assume you refer to isakmpTotal(In/Out)(Packets/Octests). I beleive that the retransmissions (packets and octets) should be counted in both the global counters and the individual phase1 SA counters. I anticipate this will be the natural expectation of Operantions-and-Maintenance shops who will not want to see deffinitions of counters like "all traffic except for ..." I also think this is well matched to what the SA lifetime counters are tracking. (rfc2409 says "a number of kbytes protected." in Appendix A. under Lifetype). Actually, I can't think of a reason not to count the retransmissions in all of these counters. (that don't mean there ain't one!) Could you tell us about the potential motivations you see for this? -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Thu Aug 5 12:24:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA02210; Thu, 5 Aug 1999 12:24:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07315 Thu, 5 Aug 1999 13:57:45 -0400 (EDT) Message-Id: <199908051757.KAA27752@potassium.network-alchemy.com> To: Tim Jenkins cc: Dan McDonald , ipsec@lists.tislabs.com Subject: Re: Retransmits in traffic count? In-reply-to: Your message of "Thu, 05 Aug 1999 08:44:32 EDT." <319A1C5F94C8D11192DE00805FBBADDFC993A6@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27749.933875836.1@network-alchemy.com> Date: Thu, 05 Aug 1999 10:57:16 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I thought that we were doing away with traffic-based lifetime for the IKE SA? That was suggested by Kivinen about 2 months ago. It sounded reasonable to me and no one complained. I was going to replace the traffic-based lifetime by "negotiations". Dan. On Thu, 05 Aug 1999 08:44:32 EDT you wrote > Let me start again. > > Should the traffic used in re-transmitting packets used in phase 1 SAs while > negotiating anything be counted against the traffic-based lifetime of the > SA? > From owner-ipsec@lists.tislabs.com Thu Aug 5 12:42:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA02578; Thu, 5 Aug 1999 12:42:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07512 Thu, 5 Aug 1999 14:25:07 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC995E4@exchange> From: Tim Jenkins To: Paul Koning Cc: ipsec@lists.tislabs.com Subject: RE: Retransmits in traffic count? Date: Thu, 5 Aug 1999 14:27:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you change the IV in SA negotiations you'll get out of sync with the peer, since they're implicit, right? Are we talking about the same thing? Traffic in phase 1 SAs? > -----Original Message----- > From: Paul Koning [mailto:pkoning@xedia.com] > Sent: August 5, 1999 2:14 PM > To: tjenkins@TimeStep.com > Cc: rcharlet@redcreek.com; ipsec@lists.tislabs.com > Subject: RE: Retransmits in traffic count? > > > >>>>> "Tim" == Tim Jenkins writes: > > >> Actually, I can't think of a reason not to count the > >> retransmissions in all of these counters. (that don't mean there > >> ain't one!) Could you tell us about the potential motivations you > >> see for this? > > Tim> Potential reasons why not: > > Tim> It doesn't really count against the lifetime of the keying > Tim> material, since there is no new information offered to an > Tim> attacker since the re-transmits are identical. (I'd like a > Tim> crypto expert to confirm or dispute this, if possible.) > > IANACE, but anyway... the retransmit plaintext is identical but the > cyphertext probably not, since presumably the IV changes. So you do > get new information. > > paul > From owner-ipsec@lists.tislabs.com Thu Aug 5 12:43:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA02577; Thu, 5 Aug 1999 12:42:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07483 Thu, 5 Aug 1999 14:21:04 -0400 (EDT) Message-ID: <37A9D624.7AB7A832@thawte.com> Date: Thu, 05 Aug 1999 20:21:24 +0200 From: Mark Shuttleworth Reply-To: marks@thawte.com Organization: Thawte Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Michael Richardson CC: ipsec@lists.tislabs.com Subject: Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt References: <199908051434.KAA19538@pzero.sandelman.ottawa.on.ca> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms86F1909F1D14F978E786986F" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms86F1909F1D14F978E786986F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hiya > So, sign these three things with different CAs. We do. But I know at least one implementation from a major vendor that assumes the same CA across users, routers and firewalls. Strange but true. > Better yet, attach attribute authority or SPKI certs to the plain > certificate. Whoa. Who's implemented attribute authority? And who's implemented SPKI? I've no problem with alternatives like these, but I think EVERYONE does ExtendedKeyUsage (or can do trivially) and subjectAltName, so the solution should lie there. Do the majority of implementations out there today match the dNSName or iPAddress in a cert's subjectAltName against the ipaddress they are exchanging packets with? -- Mark Shuttleworth Thawte --------------ms86F1909F1D14F978E786986F Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIEgYJKoZIhvcNAQcCoIIIAzCCB/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BjUwggL0MIICXaADAgECAgJarDANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5 OC45LjE2MB4XDTk4MTIxODEyMzgyOFoXDTk5MTIxODEyMzgyOFowczEVMBMGA1UEBBMMU2h1 dHRsZXdvcnRoMRUwEwYDVQQqEwxNYXJrIFJpY2hhcmQxIjAgBgNVBAMTGU1hcmsgUmljaGFy ZCBTaHV0dGxld29ydGgxHzAdBgkqhkiG9w0BCQEWEG1hcmtzQHRoYXd0ZS5jb20wXDANBgkq hkiG9w0BAQEFAANLADBIAkEA4IQUDeMHoSSClHPcZgNMePwYJhJRfS/P+7Wl66ZOxzdw0Dso +hDBFmTt0y1z7TKnbkV9dWnLcSK6pRqPOd7/tQIDAQABo4GTMIGQMBEGCWCGSAGG+EIBAQQE AwIFoDAOBgNVHQ8BAf8EBAMCBaAwPAYFK2UBBAEEMzAxAgEAMCwwCgIBAQQFbWFya3MwDAIB AgQHZGVtb2lkMTAQAgEDBAtnaG9zdGJ1c3RlcjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FP4+YJxrjA+w2DPGysYeWLBxOLXgMA0GCSqGSIb3DQEBBAUAA4GBAFWcg41Aoa1I+6etNhbr IILnoHF6lBPX99T9oOHDKEUcQmXpxpYcp1tJB7vu64UzWWN+P+1z0NY8nc/XASzQddmx56z8 Op0eOsinIsWIj5LZuo6WgExe0gck1wjgvmHyA+JVPIWTdS6kZ/t8I/95fOhPCR+jPT+EMNzM rHbfW9wcMIIDOTCCAqKgAwIBAgIBCjANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFU aGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp c2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk4MDkxNjE3NTUzNFoXDTAw MDkxNTE3NTUzNFowgbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDAS BgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UE CxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKXl1NTQXwgC7gchfSS/q2uOHusgBwIVhGuP0JMkHxud7miyuSxP6ZNn FxAXHqH5Q0EjuTCqdpe78+f9gcC1MYv2plAmVPKVKOsZpB6XHrDiuJvBBJoy0DwJbE/kNU/w dr8AEwNPRQhg8/y00JABihLJnLp/UuoqkzU2PDzkNS8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQAsx4IfAUM+B4/uaVypZIL4wJatkyvLm1DXQJqBwrqmdp08lUDcVcHhVYJ5qwopptUM 4VcoPo/5u9XfDZNYqlsti48z5N1YFTV2chUpvUL0WpILd1+dJ9uaLU4bggaO0o1Wu5Xe2wxl Bd6VngLdUxe+vvxrwxoiehQrYb3Cn156WjGCAaUwggGhAgEBMIHAMIG5MQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45 LjE2IDE3OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3Vl ciAxOTk4LjkuMTYCAlqsMAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw05OTA4MDUxODIxMjVaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZI hvcNAwICASgwIwYJKoZIhvcNAQkEMRYEFOv5MzwfwwOVmSBEPNBZxzps+L4YMA0GCSqGSIb3 DQEBAQUABEClt2Z/Zs/pCqWRp6cbvx8yrXSas6Y+4ys08ht8GESGhyH259uEnGzEF3VuAqpc 6eal2aR6cUFudSw2TvTvelon --------------ms86F1909F1D14F978E786986F-- From owner-ipsec@lists.tislabs.com Thu Aug 5 12:52:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA02959; Thu, 5 Aug 1999 12:52:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07556 Thu, 5 Aug 1999 14:28:51 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC995F5@exchange> From: Andrew Krywaniuk To: Dan McDonald , Tim Jenkins Cc: ipsec@lists.tislabs.com Subject: RE: Retransmits in traffic count? Date: Thu, 5 Aug 1999 14:31:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't think this question is important enough for us to make a big issue about it, but let me present the other side of the coin: 1. Retranmsissions can, depending on implementation details and network traffic, comprise a significant portion of the Isakmp traffic. Some existing implementations automatically send multiple copies of one or more packets. For these implementations, counting the retransmits would degrade the SA lifetime by a fairly significant amount (say 20%). I'm not suggesting that sending multiple copies of the same packet is the best way to increase reliablity, but that's why we have multiple vendors -- different people come up with different solutions. 2. Let's face it: it's probably not that much work for an attacker to guess which Isakmp packets are which. Unless you are clouding your network with lots of fake Isakmp traffic, it doesn't take a lot of brains for an attacker to guess that the first message in an exchange is QM1 and the next is QM2 and if you see the same message twice in a row then it's a retransmit. 3. The IV doesn't change in a retransmit. How would the other side know which iv to use if they didn't receive the last packet? (which is presumably why you are retransmitting) You don't get any new information from a retransmit except that it is a retransmit. If there is a security issue here then it will be a scenario where the attacker will guess that QM1 is more likely to be dropped than any other packet so if this is a retransmit then it is probably QM1. If this does give the attacker additional information then it still won't have the same worth as traffic that actually contains new data. So what difference does counting the retransmits against the SA make to most of us? Not much. But it's theoretically incorrect and it will degrade implementations that send multiple copies of the same packet. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Dan McDonald [mailto:danmcd@Eng.Sun.Com] > Sent: Thursday, August 05, 1999 1:14 PM > To: tjenkins@TimeStep.com > Cc: ipsec@lists.tislabs.com > Subject: Re: Retransmits in traffic count? > > > > Let me start again. > > > > Should the traffic used in re-transmitting packets used in > phase 1 SAs while > > negotiating anything be counted against the traffic-based > lifetime of the > > SA? > > > > In other words, if I have to send the first quick mode 1 > message three times > > before I get a response from the peer, should that first > packet's traffic be > > counted one time or three times against the phase 1 SA's > lifetime (by > > traffic) limitation? > > Sorry 'bout parsing the original question wrong. > > IMHO, yes, count those QM retransmissions. A bad guy/girl > doing traffic > analysis can put 2+2 together and probably see that it's QM > retransmissions, > and it may aid in his/her cryptanalysis. > > Just my $0.02. > > Dan > From owner-ipsec@lists.tislabs.com Thu Aug 5 12:55:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA03064; Thu, 5 Aug 1999 12:55:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07412 Thu, 5 Aug 1999 14:13:28 -0400 (EDT) Date: Thu, 5 Aug 1999 14:14:02 -0400 Message-Id: <199908051814.OAA02630@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: tjenkins@TimeStep.com Cc: rcharlet@redcreek.com, ipsec@lists.tislabs.com Subject: RE: Retransmits in traffic count? References: <319A1C5F94C8D11192DE00805FBBADDFC99575@exchange> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tim" == Tim Jenkins writes: >> Actually, I can't think of a reason not to count the >> retransmissions in all of these counters. (that don't mean there >> ain't one!) Could you tell us about the potential motivations you >> see for this? Tim> Potential reasons why not: Tim> It doesn't really count against the lifetime of the keying Tim> material, since there is no new information offered to an Tim> attacker since the re-transmits are identical. (I'd like a Tim> crypto expert to confirm or dispute this, if possible.) IANACE, but anyway... the retransmit plaintext is identical but the cyphertext probably not, since presumably the IV changes. So you do get new information. paul From owner-ipsec@lists.tislabs.com Thu Aug 5 13:08:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA03303; Thu, 5 Aug 1999 13:08:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07470 Thu, 5 Aug 1999 14:20:39 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC995DB@exchange> From: Tim Jenkins To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Retransmits in traffic count? Date: Thu, 5 Aug 1999 14:23:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The particular MIB in question refers to the ISAKMP DOI-independent MIB. All of its objects are supposed to be based on RFC 2408. As it turns out, there are no SA lifetime attributes defined in RFC2408, suggesting that SA lifetime objects and the like should be removed from that MIB, and placed only in the DOI-dependent MIBs. However, that raises another issue. If I understand the document advancement process correctly, no document can go to RFC status if it refers to "works in progress". If John and I move the SA lifetime objects to the DOI of 1 MIB, we can only refer to RFC 2409, which defines SA lifetimes as time and traffic, not negotiations. Further, I'm not sure that removing traffic lifetime limitations is a good idea, for backwards compatibility if nothing else. I also don't understand why it's a bad thing. Did we also decide that traffic based expiration of phase 2 SAs was a bad thing? Don't they exist to allow users to limit the exposure of encrypted material, potentially based on the strength of the algorithm? The only difficulty that I can see with phase 1 SA traffic lifetimes is what to do if it expires in the middle of an exchange. I don't object to adding negotiation limits for lifetime, only object to removing the existing traffic expiration. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: August 5, 1999 1:57 PM > To: Tim Jenkins > Cc: Dan McDonald; ipsec@lists.tislabs.com > Subject: Re: Retransmits in traffic count? > > > I thought that we were doing away with traffic-based lifetime for > the IKE SA? That was suggested by Kivinen about 2 months ago. > It sounded > reasonable to me and no one complained. I was going to replace the > traffic-based lifetime by "negotiations". > > Dan. > > On Thu, 05 Aug 1999 08:44:32 EDT you wrote > > Let me start again. > > > > Should the traffic used in re-transmitting packets used in > phase 1 SAs while > > negotiating anything be counted against the traffic-based > lifetime of the > > SA? > > > From owner-ipsec@lists.tislabs.com Thu Aug 5 13:48:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA03967; Thu, 5 Aug 1999 13:48:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07729 Thu, 5 Aug 1999 15:07:26 -0400 (EDT) Message-Id: <199908051907.MAA27980@potassium.network-alchemy.com> To: Tim Jenkins cc: ipsec@lists.tislabs.com Subject: Re: Retransmits in traffic count? In-reply-to: Your message of "Thu, 05 Aug 1999 14:23:20 EDT." <319A1C5F94C8D11192DE00805FBBADDFC995DB@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27977.933880028.1@network-alchemy.com> Date: Thu, 05 Aug 1999 12:07:08 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 05 Aug 1999 14:23:20 EDT you wrote > The particular MIB in question refers to the ISAKMP DOI-independent MIB. All > of its objects are supposed to be based on RFC 2408. As it turns out, there > are no SA lifetime attributes defined in RFC2408, suggesting that SA > lifetime objects and the like should be removed from that MIB, and placed > only in the DOI-dependent MIBs. There are no SA attributes defined in RFC2408 at all. Problem solved! > However, that raises another issue. If I understand the document advancement > process correctly, no document can go to RFC status if it refers to "works > in progress". If John and I move the SA lifetime objects to the DOI of 1 > MIB, we can only refer to RFC 2409, which defines SA lifetimes as time and > traffic, not negotiations. Actually you could only refer to RFC2407 if you want to be a stickler for these things since that defines the DOI of 1. And if you want to refer to RFC2409 just don't include KB lifetime in IKE. It's not there now so just don't add it. > Further, I'm not sure that removing traffic lifetime limitations is a good > idea, for backwards compatibility if nothing else. I also don't understand > why it's a bad thing. Did we also decide that traffic based expiration of > phase 2 SAs was a bad thing? Don't they exist to allow users to limit the > exposure of encrypted material, potentially based on the strength of the > algorithm? Whoa! Nobody said anything about phase 2 SA lifetimes. That makes a whole lotta sense. The KB lifetime (defined in RFC2407 by the way) is there for the purpose you mention. But that purpose doesn't really make sense for IKE. Limiting exposure of IPSec traffic makes sense because cracking a key used with an IPSec SA gives the attacker all that traffic. But cracking a key used with an IKE SA gives you what? IKE traffic. Cracking SKEYID_e will not give the attacker any insight into SKEYID_d. > The only difficulty that I can see with phase 1 SA traffic lifetimes is what > to do if it expires in the middle of an exchange. Yes, that's a problem. The whole concept is a problem. A way to solve this problem is to do away with it. It just doesn't make sense to limit the life of an IKE SA by traffic. It's low volume, (relatively) uninteresting traffic. An attacker would learn the identities of the parties involved in the IPSec communication and learn the attributes (but not the key!) of the IPSec SA. It would not provide any insight into what was being protected by IPSec, which is the real target of any attack. Attacking IKE in this manner would be a waste of time. I don't see it happening. > I don't object to adding negotiation limits for lifetime, only object to > removing the existing traffic expiration. I don't think a MIB should dictate what a protocol does. It's the other way around. But since the MIB in question shouldn't have these attributes (as you pointed out) and the other MIB doesn't have this attribute already then there would be no problem, MIB-wise, in doing away with it. Getting rid of this attribute will get rid of a few headaches and cause none of its own. Maybe you could say why would you use KB expiry for an IKE SA? Dan. From owner-ipsec@lists.tislabs.com Thu Aug 5 14:02:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA04143; Thu, 5 Aug 1999 14:02:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07862 Thu, 5 Aug 1999 15:31:58 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC99660@exchange> From: Tim Jenkins To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Retransmits in traffic count? Date: Thu, 5 Aug 1999 15:34:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: August 5, 1999 3:07 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Retransmits in traffic count? > > > On Thu, 05 Aug 1999 14:23:20 EDT you wrote >> However, that raises another issue. If I understand the document advancement >> process correctly, no document can go to RFC status if it refers to "works >> in progress". If John and I move the SA lifetime objects to the DOI of 1 >> MIB, we can only refer to RFC 2409, which defines SA lifetimes as time and >> traffic, not negotiations. > >Actually you could only refer to RFC2407 if you want to be a stickler for >these things since that defines the DOI of 1. And if you want to refer to >RFC2409 just don't include KB lifetime in IKE. It's not there now so just >don't add it. > What do you mean "it's not there"? All I see in RFC2409 is a section saying there are life types that can define "a type of lifetime to which the ISAKMP Security Association applies." This says to me that I can use the traffic limit life type in phase 1. has the same thing. > > I don't object to adding negotiation limits for lifetime, > only object to > > removing the existing traffic expiration. > > I don't think a MIB should dictate what a protocol does. It's > the other > way around. But since the MIB in question shouldn't have > these attributes > (as you pointed out) and the other MIB doesn't have this > attribute already > then there would be no problem, MIB-wise, in doing away with it. Who was suggesting the MIB dictate what the protocol did? I mean backwards compatibility with implementations that can use traffic based lifetimes for phase 1. Our implementation currently allows the user to specify and negotiate phase 1 SA lifetime based on traffic. (I don't know our customers use it.) If it becomes removed from the 'standards', where does that put us? Do we need to use a vendor ID payload to see if we can negotiate it? I hope not. Maybe it's moot, since the existing Life Type attribute number will still exist, and SA lifetime negotiation seems to be to use your own limits anyway. But back to the MIB, it needs to be able to reflect usage. So if anyone continues to use phase 1 durations limited by traffic, the MIB needs to be able to reflect that. And as far as I can tell, the IKE DOI allows it to be used in phase 1, so the IKE DOI MIB should probably put it in. From owner-ipsec@lists.tislabs.com Thu Aug 5 15:05:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA04763; Thu, 5 Aug 1999 15:05:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08281 Thu, 5 Aug 1999 16:43:22 -0400 (EDT) Message-Id: <37A9F67E.75B74161@radguard.com> Date: Thu, 05 Aug 1999 23:39:26 +0300 From: Sara Bitan Organization: RADGUARD X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: "Scott G. Kelly" , ipsra , IPSec mailing list Subject: Re: Proposed Charter References: <319A1C5F94C8D11192DE00805FBBADDFC98E0B@exchange> <37A86C23.5B3089A0@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Scott! "Scott G. Kelly" wrote: > > Proposed Charter: > > > > The rapid growth of remote access and the subsequent transition from older > > direct-dial remote access to Internet-based remote access is making an > > impact on secure communications. > > > > IP Security (IPSec), as it is defined today, is missing key functionality > > needed to effectively support Internet-based secure remote access as well as > > being difficult to deploy to remote users such as road-warriors and > > telecommuters wishing to connect back to their corporate networks. > > I believe the first part of this sentence is incorrect, and the second > part is implementation dependent - I'll restrict my comments to the > first part. I believe that all the "needed" mechanisms are present > within IPsec as currently defined. PKI provides strong authentication, > preshared keys provide weaker password-based authentication, and DHCP > may be carried over the existing IPsec framework for other > configuration. It seems that the real problem you wish to address is > that some people are reluctant to deploy PKI and/or to abandon their > previously installed "legacy" mechanism, and as a result, you are > calling for us to integrate so-called legacy authentication mechanisms > into IPsec. I agree with you that we need to change the wording in the above sentence. IPSec does have the required functionality (i.e. certificates), but in the current status of PKI technology this functionality cannot yet be deployed in a scalable fashion. It doesn't matter if the reason is a financial one, an organizational one or just as you define it "people are reluctant to deploy PKI and/or to abandon their legacy mechanism". It is a legitimate requirement that we as IPSec vendors must provide an answer to. I don't think we have the power to force customers to abandon their legacy mechanism, and I prefer to see them use these mechanism within a framework that we sa working group will standardize, then to see allot of proprietary methods to use legacy authentication system with IPSec, some of them might turn out to be secure, but some probably will be insecure. > > > It should be the goal of this working group to determine how to provide > secure remote access using IPsec. If, in the course of researching this > problem, it is determined that the existing framework does not support > some required functionality, then these would be valid work items for > consideration. However, I believe that beginning with the premise that > IPsec does not provide the necessary and sufficient mechanisms is > incorrect. I agree that we should first define the problem, and then state the requirements, but I also argue that the current IPSec provide the required answers, not from the technology point of view but from other points of view. We are not going change the current framework, and I believe that providing support for legacy authentication systems will create a migration path that will lead us to deployment of IPSec with PKI. > > > > All these groups of users share the property that their IP address is > > temporary and doesn't give any information about the identity of the user. > > Although their temporary IP address is meaningless for IPSec, they still > > require to become a part of a virtual private network, and to have access to > > resources that are part of the private network. > > The statement "All these groups of users share..." is also incorrect. > Some telecommuters have ISP-assigned stationary IP addresses. Agreed, we'll change the wording. > And again, > PKI and preshared secrets makes this point moot - IP addresses are not > the only identifier types supported by IPsec. Preshared secrets with main mode with non IP address identifiers do not work. Certificate authentication with non IP address identifiers is exposed to denial of service attacks. From owner-ipsec@lists.tislabs.com Thu Aug 5 15:05:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA04781; Thu, 5 Aug 1999 15:05:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08310 Thu, 5 Aug 1999 16:49:37 -0400 (EDT) Message-Id: <199908052049.NAA28264@potassium.network-alchemy.com> To: Andrew Krywaniuk cc: Tim Jenkins , ipsec@lists.tislabs.com Subject: Re: Retransmits in traffic count? In-reply-to: Your message of "Thu, 05 Aug 1999 16:06:58 EDT." <319A1C5F94C8D11192DE00805FBBADDFC996A4@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28261.933886155.1@network-alchemy.com> Date: Thu, 05 Aug 1999 13:49:16 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 05 Aug 1999 16:06:58 EDT you wrote > Ahh, the wonderous diversity of a technical mailing list. On one hand, > you've got people complaining that a simple protocol like IKE-Config is too > risky simply because it adds complexity to your state machine (even though > there are no real plausible attacks). And now you've got people arguing that > Kb expiry of an IKE SA is useless simply because the attacks (which are easy > to envision) are too esoteric. I don't know what technical mailing list you've been reading but welcome to IPSec. No one was arguing about anything called IKE-Config (perhaps you mean ISAKMP-Config) it was XAUTH that's the risky protocol. And I never said an attack against SKEYID_d was too esoteric. > We're in the security business. We're supposed to be (at least a little bit) > paranoid. If people didn't care about identity protection then why would > they be using main mode? Because Main Mode has much richer negotiation capabilities (that is, if you actually parse the attributes and use the values in negotiation). > Organizations like the military collect and analyze > statistical data such as who is talking to who. The data to collect is the IPSec protected data since that will tell a whole lot more than just knowing the ID payloads used in IKE. And removing the KB lifetype value from the protocol will not make the life of the military (or any other bogyman you can think of) easier. > Deprecating features (especially a locally enforced feature like this one), > simply because a few parties can't see any use for thm, isn't what a > standards-determining organization is supposed to be about. Our customers > expect us to be forward-thinking; if we don't plan for an attack, simply > because we can't think of how to exploit it off the top of our heads, then > how can we be forward-thinking? Had I not added KB lifetime to IKE in the first place I seriously doubt you would be demanding it today. And this topic was brought up 2 months ago by a well-respected member of this WG and no one said anything. If KB lifetime is a locally enforced feature (as you say) which is not negotiated (and if the attribute appears in an offer it's ignored in favor of the locally configured value) then it is not part of the protocol. If the protocol removes the KB lifetime attribute and/or re-uses the lifetype value for a lifetype that actually makes sense it will not have any effect on implementations which happen to have this locally enforced value. You could have other locally enforced rules (like an idle timer which auto- matically deletes SAs if they have not been used in X seconds/minutes/hours) which you may want to have knobs to give your customers but that too is not part of the protocol. The only people arguing for KB lifetype in phase 1 are the ones that, admittedly, don't use the value in negotiation. That's pretty funny. Dan. From owner-ipsec@lists.tislabs.com Thu Aug 5 15:33:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA05113; Thu, 5 Aug 1999 15:33:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08078 Thu, 5 Aug 1999 16:04:17 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC996A4@exchange> From: Andrew Krywaniuk To: Dan Harkins , Tim Jenkins Cc: ipsec@lists.tislabs.com Subject: RE: Retransmits in traffic count? Date: Thu, 5 Aug 1999 16:06:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ahh, the wonderous diversity of a technical mailing list. On one hand, you've got people complaining that a simple protocol like IKE-Config is too risky simply because it adds complexity to your state machine (even though there are no real plausible attacks). And now you've got people arguing that Kb expiry of an IKE SA is useless simply because the attacks (which are easy to envision) are too esoteric. We're in the security business. We're supposed to be (at least a little bit) paranoid. If people didn't care about identity protection then why would they be using main mode? Organizations like the military collect and analyze statistical data such as who is talking to who. Deprecating features (especially a locally enforced feature like this one), simply because a few parties can't see any use for thm, isn't what a standards-determining organization is supposed to be about. Our customers expect us to be forward-thinking; if we don't plan for an attack, simply because we can't think of how to exploit it off the top of our heads, then how can we be forward-thinking? As for what happens when you run out of Kb in the middle of an exchange, what would you do if your time-based lifetime expired in the middle of an exchange? Or what if you ran out of Kb in the middle of encypting an IPSec packet? Simple: you drop the packet and next time you set your rekeying window to be a little wider. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > Sent: Thursday, August 05, 1999 3:07 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Retransmits in traffic count? > > > The only difficulty that I can see with phase 1 SA traffic > lifetimes is what > > to do if it expires in the middle of an exchange. > > Yes, that's a problem. The whole concept is a problem. A way > to solve this > problem is to do away with it. It just doesn't make sense to limit the > life of an IKE SA by traffic. It's low volume, (relatively) > uninteresting > traffic. An attacker would learn the identities of the > parties involved in > the IPSec communication and learn the attributes (but not the > key!) of the > IPSec SA. It would not provide any insight into what was > being protected > by IPSec, which is the real target of any attack. Attacking > IKE in this > manner would be a waste of time. I don't see it happening. > Getting rid of this attribute will get rid of a few headaches > and cause none > of its own. Maybe you could say why would you use KB expiry > for an IKE SA? > > Dan. > From owner-ipsec@lists.tislabs.com Thu Aug 5 15:41:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA05187; Thu, 5 Aug 1999 15:41:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08115 Thu, 5 Aug 1999 16:11:31 -0400 (EDT) Message-Id: <199908052011.NAA28155@potassium.network-alchemy.com> To: Tim Jenkins cc: ipsec@lists.tislabs.com Subject: Re: Retransmits in traffic count? In-reply-to: Your message of "Thu, 05 Aug 1999 15:34:35 EDT." <319A1C5F94C8D11192DE00805FBBADDFC99660@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28152.933883871.1@network-alchemy.com> Date: Thu, 05 Aug 1999 13:11:11 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 05 Aug 1999 15:34:35 EDT you wrote > > > > On Thu, 05 Aug 1999 14:23:20 EDT you wrote > > >> However, that raises another issue. If I understand the document > advancement > >> process correctly, no document can go to RFC status if it refers to > "works > >> in progress". If John and I move the SA lifetime objects to the DOI of 1 > >> MIB, we can only refer to RFC 2409, which defines SA lifetimes as time > and > >> traffic, not negotiations. > > > >Actually you could only refer to RFC2407 if you want to be a stickler for > >these things since that defines the DOI of 1. And if you want to refer to > >RFC2409 just don't include KB lifetime in IKE. It's not there now so just > >don't add it. > > > > What do you mean "it's not there"? All I see in RFC2409 is a section saying > there are life types that can define "a type of lifetime to which the ISAKMP > Security Association applies." This says to me that I can use the traffic > limit life type in phase 1. has the same > thing. I was talking about the MIB! There is nothing about phase 1 KB lifetime in the existing DOI of 1 MIB. So, don't add it and then there is no problem. > Our implementation currently allows the user to specify and negotiate phase > 1 SA lifetime based on traffic. (I don't know our customers use it.) If it > becomes removed from the 'standards', where does that put us? Do we need to > use a vendor ID payload to see if we can negotiate it? I hope not. What are you going to do if XAUTH gets another exchange value? Or if IANA does not give Config-Mode the exchange value you're using today? You must have a contingency plan for these possible occurances. > Maybe it's moot, since the existing Life Type attribute number will still > exist, and SA lifetime negotiation seems to be to use your own limits > anyway. If lifetime negotiation is as you say then what's the point of negotiating them? If your implementation ignores lifetimes in offers (and uses it's own limits anyway) then it won't matter what the lifetype is then right? It can be 2 or 87 or something else can become 2 since you're not using it. I think your problem is solved. As long as you don't change your code to actually use these attributes and you continue to ignore them you have no reason to be effected by the removal of KB lifetime from IKE. Since you're not really negotiating it the "phase 1 KB lifetime" knob you give your customers is just a no-op knob and it can continue to remain so. > But back to the MIB, it needs to be able to reflect usage. So if anyone > continues to use phase 1 durations limited by traffic, the MIB needs to be > able to reflect that. And as far as I can tell, the IKE DOI allows it to be > used in phase 1, so the IKE DOI MIB should probably put it in. And if the attribute is removed then the MIB can remain the way it is right now. You don't need to add anything to the MIB because the thing you want to add is going to be removed from IKE. Life is easier this way. (BTW, there is no "IKE DOI" so there should not be an "IKE DOI MIB"). I'll ask again: who uses phase 1 lifetime of KB? Can anyone think of a good reason to? Dan. From owner-ipsec@lists.tislabs.com Thu Aug 5 17:08:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA07180; Thu, 5 Aug 1999 17:08:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08816 Thu, 5 Aug 1999 18:43:30 -0400 (EDT) Date: Fri, 6 Aug 1999 01:44:02 +0300 (EET DST) Message-Id: <199908052244.BAA18609@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Andrew Krywaniuk Cc: Dan McDonald , Tim Jenkins , ipsec@lists.tislabs.com Subject: RE: Retransmits in traffic count? In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFC995F5@exchange> References: <319A1C5F94C8D11192DE00805FBBADDFC995F5@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk writes: > 2. Let's face it: it's probably not that much work for an attacker to guess > which Isakmp packets are which. Unless you are clouding your network with > lots of fake Isakmp traffic, it doesn't take a lot of brains for an attacker > to guess that the first message in an exchange is QM1 and the next is QM2 > and if you see the same message twice in a row then it's a retransmit. Attacker does not have to guess. He can see it immediately. The generic ISAKMP header is NOT encrypted which means that attacker can immediately see that this packet is first QM packet (exchange type qm, new message id), second QM packet (exchange type qm, same message id already sent by other end), or third QM packet (exchange type qm, same message id than older QM packet). It can also detect all retransmissions by just comparing the packets. > So what difference does counting the retransmits against the SA make to most > of us? Not much. But it's theoretically incorrect and it will degrade > implementations that send multiple copies of the same packet. I think the most important difference is that parties sent/received counts get out of sync very quickly. If sender retransmits a packet which didn't reach its destionation its sent counter is immediately out of sync from the other ends receive counter. If we do not count retransmissions then the only way to get counters out of sync is that the negotiation times out (sender sends packets several times, and none of them reaches the destination). I think we should not be counting retrasmitted packets. -- 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@lists.tislabs.com Thu Aug 5 17:50:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA08313; Thu, 5 Aug 1999 17:50:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08982 Thu, 5 Aug 1999 19:39:57 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <37A85787.C3BC7B88@radguard.com> References: Date: Thu, 5 Aug 1999 11:23:11 -0400 To: Sara Bitan From: Stephen Kent Subject: Re: Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities) Cc: IPSec mailing list , ipsra Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sara, > >When an IPSec implementation is examining an IP packet against the SPD it has >no clue which >DNS name or DN name matches the IP addresses in the header. >I think that the purpose of the authentication process is to bind a DN or DNS >name to an >IP address so that matching of a packet against the SPD is possible. This is true for a security gateway, but not for a native end system implementation. >> IPsec does not support >> authentication of a compound principle, or of a user and a system >> independently. It would not sense to do so unless there was a >> corresponding SPD entry type for compound principles. > >I don't think IPSec needs to support compound principles. >I do think that we need to define requirements from the authentication >process that binds between the DN and the IP address. I think this should >be an IPSec extension, and part of the IPSRA work. >In this context I think this taxonomy is helpful. I think that the existing architecture provides for binding between any of the approved name forms and the IP addresses used in an SA. In order to support name (vs. address) entries in an SPD in a security gateway, a compliant implementation must already be able to do this, so it's not an extension. Steve From owner-ipsec@lists.tislabs.com Thu Aug 5 17:56:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA08397; Thu, 5 Aug 1999 17:56:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09004 Thu, 5 Aug 1999 19:44:07 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <37A7E859.DF16767D@thawte.com> References: <37A5E060.2856AF18@thawte.com> <3.0.6.32.19990802132815.00a59680@127.0.0.1> Date: Thu, 5 Aug 1999 13:30:02 -0400 To: marks@thawte.com From: Stephen Kent Subject: Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, >I'm certainly in agreement with you about overloading. But I think that >organizations will want to build SIMPLE rules to differentiate between >routers, gateways and end-users. They should be able to do this JUST by >looking at the cert, and not by referring to a directory or other source >(otherwise you add another fragile link in the chain). > >So, there needs to be some broad agreement about how this is done so >that these policies can work in a heterogenous environment. EKUs have an advantage over names in that name conventions would be less likely to be uniforly enforced, and might otherwise impinge on local name conventions. >For example, in many of the current implementations I've seen you have >to explicitly manually trust the certificates of each of the devices you >want to talk to. This is a configuration nightmare in larger-scale >deployments. Each device needs to be manually told about n other >certificates (and updated each time one of them expires). You really >want to be able to say "look at the iPAddress or dNSName in the cert and >make sure it matches the iPAddress with which you are exchanging >packets". This way there is no manual configuration of certificates - >each router has a normal set of routing tables and expects the routers >it talks to securely to be able to produce a valid cert signed by one of >the trusted CA's with a subjectAltName that matches its dNSName or >iPAddress. I think you may be confusing two issues here. One needs to manually configure a set of (CA) certs to use as reference points for validation of certs received from other IPsec entities. The number of such "root" certs needed wil depend on the extent of the communication envisioned and the scope of the CAs in question. One creates individual SPD entries to authorize communication with specified IPsec entities. In the worst case, one might have a one-to-one correspondence betwee manually configured certs and SPD entries, if one could specify no CAs that could be used to provide validation bases for multiple IPsec entities. My limited experience suggests that this is not the usual case. However, one must be careful to ensure that each CA cannot issue certs for just any possible SPD entry. In our environment, we employ the nameConstraints extension to enforce this. This works pretty well because we deal with CAs that are per-organization and thus the certs issued by these CAs are appropriately constrained to issues certs for entities in that organization (either DNs or DNS altnames). One can even do this for certs using ipaddresses as altNames. >The preferred way for us would be subjectAltName. In other words, for >machine, router and gateway certificates we put an IPaddress or dNSName >in the cert, while for user certificates we put one or more email >addresses. If this was the rule, then we could differentiate between >"machine" certificates and "human" certificates on the basis of the >subjectAltName. Then I would be happy with Rodney's proposal of iKEEnd >and iKEIntermediate. Servers and point-to-point routers would have >iKEEnd with a subjectAltName iPAddress or dNSName, while end-users would >have iKEEnd with a subjectAltName rfc822Name. Firewalls would have >iKEIntermediate with a dNSName or iPAddress. I would not mnind this approach, but I wonder if anyone objects because it does not allow for DNs to identify any of these entities? Steve From owner-ipsec@lists.tislabs.com Thu Aug 5 18:02:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA08959; Thu, 5 Aug 1999 18:02:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09003 Thu, 5 Aug 1999 19:44:06 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <37A5F6EB.FF654A15@thawte.com> References: Date: Thu, 5 Aug 1999 13:06:42 -0400 To: marks@thawte.com From: Stephen Kent Subject: Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt Cc: Stephen Kent , ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, >I believe that IPSEC to the desktop will become widespread. In that >environment it makes sense to differentiate between the certificates you >are issuing to people for desktop and remote-access authentication, and >certs that you recognize for router authentication. If you don't make >this distinction it is possible for someone to get a personal cert and >use it to fake a router that wants to talk to your network. There are >several ways you could differentiate: > > - different X.509 policy info > - separate root or intermediate ca's > - different EKUsages > - different subjectAltNames > >I'm strongly in favour of the EKU approach, since EKU is widely used in >other Internet apps. And you can have multiple EKUsages for a single >cert if it makes business sense. I think X.509 policy info is largely >wasted since very few implementations can use it. And it is cumbersome >to force an organization to maintain separate CA's (MUCH easier to use >separate EKU's). The subjectAltName method is promising. For example, a >"server" could be defined as an object with a cert containing EKU:iKEEnd >and a subjectAltName with a domain name that resolves to its IP address. I don't think policy info is an appropriate way to distinguish among certs issued to these different classes of entities, nor is there a need for separate roots or CAs. I agree that EKU and names (primary or alternative) are the most appropriate choices. Yes, EKU is being used elsewhere, e.g., in S/MIME, but that doesn't help an IPsec implementation. One can use names to identify different classes of entities, and base access control decisions on that. >Does all of this make sense, or am I missing the whole point entirely? > >> id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 } >> id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 } >> id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 } > >You're right - I had an old version that had ipsecServer instead of >EndSystem. Actually having Tunnel in there makes sense to me, since you >definitely want to control certs that are ostensibly allowed to claim >tunneling capability VERY tightly. I think ;-). Why do I care about tunnel use? Gateways must use tunnels, but end systems may use tunnels as well. Steve From owner-ipsec@lists.tislabs.com Fri Aug 6 05:58:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA22086; Fri, 6 Aug 1999 05:58:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA10391 Fri, 6 Aug 1999 07:08:50 -0400 (EDT) Message-ID: <37AAC221.93DB1EA2@thawte.com> Date: Fri, 06 Aug 1999 13:08:17 +0200 From: Mark Shuttleworth Reply-To: marks@thawte.com Organization: Thawte Consulting X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Stephen Kent CC: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCA51B450CB625CDD3E30116A" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msCA51B450CB625CDD3E30116A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hiya > Why do I care about tunnel use? Gateways must use tunnels, but end > systems may use tunnels as well. I had thought that many companies might consider tunnels more risky and want to be able to differentiate clearly between devices that can offer tunneling and those that cannot. This is difficult to do based purely on subjectAltName. -- Mark Shuttleworth Thawte --------------msCA51B450CB625CDD3E30116A Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIEgYJKoZIhvcNAQcCoIIIAzCCB/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BjUwggL0MIICXaADAgECAgJarDANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5 OC45LjE2MB4XDTk4MTIxODEyMzgyOFoXDTk5MTIxODEyMzgyOFowczEVMBMGA1UEBBMMU2h1 dHRsZXdvcnRoMRUwEwYDVQQqEwxNYXJrIFJpY2hhcmQxIjAgBgNVBAMTGU1hcmsgUmljaGFy ZCBTaHV0dGxld29ydGgxHzAdBgkqhkiG9w0BCQEWEG1hcmtzQHRoYXd0ZS5jb20wXDANBgkq hkiG9w0BAQEFAANLADBIAkEA4IQUDeMHoSSClHPcZgNMePwYJhJRfS/P+7Wl66ZOxzdw0Dso +hDBFmTt0y1z7TKnbkV9dWnLcSK6pRqPOd7/tQIDAQABo4GTMIGQMBEGCWCGSAGG+EIBAQQE AwIFoDAOBgNVHQ8BAf8EBAMCBaAwPAYFK2UBBAEEMzAxAgEAMCwwCgIBAQQFbWFya3MwDAIB AgQHZGVtb2lkMTAQAgEDBAtnaG9zdGJ1c3RlcjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FP4+YJxrjA+w2DPGysYeWLBxOLXgMA0GCSqGSIb3DQEBBAUAA4GBAFWcg41Aoa1I+6etNhbr IILnoHF6lBPX99T9oOHDKEUcQmXpxpYcp1tJB7vu64UzWWN+P+1z0NY8nc/XASzQddmx56z8 Op0eOsinIsWIj5LZuo6WgExe0gck1wjgvmHyA+JVPIWTdS6kZ/t8I/95fOhPCR+jPT+EMNzM rHbfW9wcMIIDOTCCAqKgAwIBAgIBCjANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFU aGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp c2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk4MDkxNjE3NTUzNFoXDTAw MDkxNTE3NTUzNFowgbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDAS BgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UE CxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKXl1NTQXwgC7gchfSS/q2uOHusgBwIVhGuP0JMkHxud7miyuSxP6ZNn FxAXHqH5Q0EjuTCqdpe78+f9gcC1MYv2plAmVPKVKOsZpB6XHrDiuJvBBJoy0DwJbE/kNU/w dr8AEwNPRQhg8/y00JABihLJnLp/UuoqkzU2PDzkNS8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQAsx4IfAUM+B4/uaVypZIL4wJatkyvLm1DXQJqBwrqmdp08lUDcVcHhVYJ5qwopptUM 4VcoPo/5u9XfDZNYqlsti48z5N1YFTV2chUpvUL0WpILd1+dJ9uaLU4bggaO0o1Wu5Xe2wxl Bd6VngLdUxe+vvxrwxoiehQrYb3Cn156WjGCAaUwggGhAgEBMIHAMIG5MQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45 LjE2IDE3OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3Vl ciAxOTk4LjkuMTYCAlqsMAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw05OTA4MDYxMTA4MjBaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZI hvcNAwICASgwIwYJKoZIhvcNAQkEMRYEFPapxYaYJC5ANLfS+UICKd+t7QGRMA0GCSqGSIb3 DQEBAQUABEAbrNUCJriJ0ug3gyRGt8SUn06qO1/5e9VulO5Kc9ls05uRikiS5gaT6k5wRwyf Oz6mzOdM5PtcOWtL0fdv1O28 --------------msCA51B450CB625CDD3E30116A-- From owner-ipsec@lists.tislabs.com Fri Aug 6 07:54:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA24485; Fri, 6 Aug 1999 07:54:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10645 Fri, 6 Aug 1999 09:13:54 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC997EC@exchange> From: Tim Jenkins To: ipsec@lists.tislabs.com Subject: phase 1 lifetime by traffic (was RE: Retransmits in traffic count? ) Date: Fri, 6 Aug 1999 09:15:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA10642 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I said this before: our implementation has the "knob" (as Dan puts it) to allow the customer to do this. Why? Because it was part of the specs, so it was done. Do our customers use it? I have no idea.   But it doesn't matter. My entire point is that the number 2 for life type of traffic must not be changed to mean something else, since there are implementations out there legitimately using that value. It's not clear to me that is going to be changed; I just want to make it clear that it shouldn't be changed.   Just because it is ignored during negotiations is not an excuse to change it. What if we send a lifetime notification when we have traffic limited expiration and the peer doesn't? What does the value 2 mean to the peer versus our implementation if it gets changed?   I don't care if the new IKE says don't do phase 1 expiration using traffic. I don't have a problem if implementations don't support that capability. But the value needs to be held for backwards compatibility for lifetime notification parsing if nothing else. -----Original Message----- From: Dan Harkins [mailto:dharkins@network-alchemy.com] Sent: August 5, 1999 4:11 PM To: Tim Jenkins Cc: ipsec@lists.tislabs.com Subject: Re: Retransmits in traffic count? I'll ask again: who uses phase 1 lifetime of KB? Can anyone think of a good reason to?   Dan. From owner-ipsec@lists.tislabs.com Fri Aug 6 08:28:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA25345; Fri, 6 Aug 1999 08:28:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10826 Fri, 6 Aug 1999 10:02:33 -0400 (EDT) Message-Id: <3.0.5.32.19990806170321.00bc9500@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 06 Aug 1999 17:03:21 +0300 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Retransmits in traffic count? Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA10823 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >I'll ask again: who uses phase 1 lifetime of KB? Can anyone think of a >good reason to? > > Dan. > > We use KB lifetimes for phase 1, the default is 1000. Retransmits do not increment the byte counter. KB lifetimes are not really useful. but the limit is in to make to program compatible with older versions. If the responder has 1000 KB limits and the initiator does not send a limit, responder sends "no proposal chosen". Our customers love it. Jörn From owner-ipsec@lists.tislabs.com Fri Aug 6 08:55:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA26346; Fri, 6 Aug 1999 08:55:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10954 Fri, 6 Aug 1999 10:21:29 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <37AAC221.93DB1EA2@thawte.com> References: Date: Fri, 6 Aug 1999 10:20:00 -0400 To: marks@thawte.com From: Stephen Kent Subject: Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, > >> Why do I care about tunnel use? Gateways must use tunnels, but end >> systems may use tunnels as well. > >I had thought that many companies might consider tunnels more risky and >want to be able to differentiate clearly between devices that can offer >tunneling and those that cannot. This is difficult to do based purely on >subjectAltName. Well, it depends. An ESP transport connection hides porty and protocol info, just not address info. Many of the folks who express concern about IPsec traffic traversing a firewall are bothered because of that level of concealment, so I think we have alreday cross the threshold, without invoking tunnel mode. Also, I ahve to agree with another list member who observed that if we want to mark certs to simplify access control decisions, we are moving into the realm where ACs are the most appropriate choice. This is consistent with my earlier observation about not overloading a cert, or a field in a cert. I should have been more precise and said that I was thinking of a public key cert. Steve From owner-ipsec@lists.tislabs.com Fri Aug 6 09:00:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA26419; Fri, 6 Aug 1999 09:00:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11053 Fri, 6 Aug 1999 10:35:45 -0400 (EDT) Message-ID: <37AAF2EC.9A3E4436@raleigh.ibm.com> Date: Fri, 06 Aug 1999 10:36:28 -0400 From: Phuong Nguyen Organization: IBM Research Triangle Park X-Mailer: Mozilla 4.6 [en] (X11; I; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: ipsec@lists.tislabs.com Subject: Re: phase 1 lifetime by traffic (was RE: Retransmits in traffic count? ) References: <319A1C5F94C8D11192DE00805FBBADDFC997EC@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, our implementation has it. I agree that it shouldn't be changed. We have it and I have no idea whether or not our customers use it. Thanks, Phuong Tim Jenkins wrote: > > I said this before: our implementation has the "knob" (as Dan puts it) to > allow the customer to do this. Why? Because it was part of the specs, so it > was done. Do our customers use it? I have no idea. > > But it doesn't matter. My entire point is that the number 2 for life type of > traffic must not be changed to mean something else, since there are > implementations out there legitimately using that value. It's not clear to > me that is going to be changed; I just want to make it clear that it > shouldn't be changed. > > Just because it is ignored during negotiations is not an excuse to change > it. What if we send a lifetime notification when we have traffic limited > expiration and the peer doesn't? What does the value 2 mean to the peer > versus our implementation if it gets changed? > > I don't care if the new IKE says don't do phase 1 expiration using traffic. > I don't have a problem if implementations don't support that capability. But > the value needs to be held for backwards compatibility for lifetime > notification parsing if nothing else. > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > Sent: August 5, 1999 4:11 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Retransmits in traffic count? > > I'll ask again: who uses phase 1 lifetime of KB? Can anyone think of a > good reason to? > > Dan. From owner-ipsec@lists.tislabs.com Fri Aug 6 14:45:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA01226; Fri, 6 Aug 1999 14:45:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA12120 Fri, 6 Aug 1999 15:41:20 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFCC4731@exchange> From: Andrew Krywaniuk To: Dan Harkins , Andrew Krywaniuk Cc: Tim Jenkins , ipsec@lists.tislabs.com Subject: RE: Retransmits in traffic count? Date: Fri, 6 Aug 1999 15:44:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Look at it this way. You are not denying that increased traffic on an Isakmp SA will theoretically make it easier to break, you are just saying that if it does get broken then who cares? In that case, why do we bother encrypting the last few messages of Main Mode? And why do we even bother with phase 1 rekeying? Obviously we are placing some value in the protection of encrypted Isakmp SA data. And maybe we are concerned that there will eventually be a viable attack on SKEYID_d. When building a security system, you generally decide that you're either going to protect a given piece of data or you're not. You don't say that this data is only a little bit sensitive so let's just make a half-hearted attempt to protect it. Probably the majority of attacks we are concerned about are brute force attacks that are facilitated more by time than by traffic. But we can't be sure that no one in the future is going to come up with an attack that is greatly facilitated by increased traffic. If an attacker can find a loophole in the user's security system that allows them to continually force the renegotiation of IPSec SAs then they can artificially increase the traffic count on the Isakmp SA, thus giving themselves a lot more encrypted traffic to work with. If we have Kb-based expiry then this kind of attack doesn't work. The Isakmp SA gets renegotiated continually and this hopefully sets off alarm bells in the network monitoring department somewhere. Whether or not Kb-based expiry needs to be in the spec, well that's a bit different issue. Presumably, there is some value in informing the other party of the expiry constraints, or why do we support the notify for time-based expiry? (I'm just extrapolating here.) Probably some implementations want to know when to anticipate a rekey, and if so then they should be able to do so regardless of the expiration constraints. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: Thursday, August 05, 1999 4:49 PM > To: Andrew Krywaniuk > Cc: Tim Jenkins; ipsec@lists.tislabs.com > Subject: Re: Retransmits in traffic count? > > > On Thu, 05 Aug 1999 16:06:58 EDT you wrote > > Ahh, the wonderous diversity of a technical mailing list. > On one hand, > > you've got people complaining that a simple protocol like > IKE-Config is too > > risky simply because it adds complexity to your state > machine (even though > > there are no real plausible attacks). And now you've got > people arguing that > > Kb expiry of an IKE SA is useless simply because the > attacks (which are easy > > to envision) are too esoteric. > > I don't know what technical mailing list you've been reading > but welcome > to IPSec. No one was arguing about anything called IKE-Config > (perhaps you > mean ISAKMP-Config) it was XAUTH that's the risky protocol. > And I never said > an attack against SKEYID_d was too esoteric. > > > We're in the security business. We're supposed to be (at > least a little bit) > > paranoid. If people didn't care about identity protection > then why would > > they be using main mode? > > Because Main Mode has much richer negotiation capabilities > (that is, if > you actually parse the attributes and use the values in negotiation). > > > Organizations like the military > collect and analyze > > statistical data such as who is talking to who. > > The data to collect is the IPSec protected data since that will tell a > whole lot more than just knowing the ID payloads used in IKE. > And removing > the KB lifetype value from the protocol will not make the life of the > military (or any other bogyman you can think of) easier. > > > Deprecating features (especially a locally enforced feature > like this one), > > simply because a few parties can't see any use for thm, isn't what a > > standards-determining organization is supposed to be about. > Our customers > > expect us to be forward-thinking; if we don't plan for an > attack, simply > > because we can't think of how to exploit it off the top of > our heads, then > > how can we be forward-thinking? > > Had I not added KB lifetime to IKE in the first place I > seriously doubt > you would be demanding it today. And this topic was brought > up 2 months > ago by a well-respected member of this WG and no one said anything. > > If KB lifetime is a locally enforced feature (as you say) > which is not > negotiated (and if the attribute appears in an offer it's > ignored in favor > of the locally configured value) then it is not part of the > protocol. If > the protocol removes the KB lifetime attribute and/or re-uses > the lifetype > value for a lifetype that actually makes sense it will not > have any effect > on implementations which happen to have this locally enforced > value. You > could have other locally enforced rules (like an idle timer > which auto- > matically deletes SAs if they have not been used in X > seconds/minutes/hours) > which you may want to have knobs to give your customers but > that too is not > part of the protocol. > > The only people arguing for KB lifetype in phase 1 are the ones that, > admittedly, don't use the value in negotiation. That's pretty funny. > > Dan. > From owner-ipsec@lists.tislabs.com Fri Aug 6 18:17:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA07451; Fri, 6 Aug 1999 18:17:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12817 Fri, 6 Aug 1999 19:43:38 -0400 (EDT) Message-Id: <199908062343.QAA01044@potassium.network-alchemy.com> To: Andrew Krywaniuk cc: Tim Jenkins , ipsec@lists.tislabs.com Subject: Re: Retransmits in traffic count? In-reply-to: Your message of "Fri, 06 Aug 1999 15:44:12 EDT." <319A1C5F94C8D11192DE00805FBBADDFCC4731@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1041.933983002.1@network-alchemy.com> Date: Fri, 06 Aug 1999 16:43:23 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 06 Aug 1999 15:44:12 EDT you wrote > Look at it this way. You are not denying that increased traffic on an Isakmp > SA will theoretically make it easier to break, you are just saying that if > it does get broken then who cares? In that case, why do we bother encrypting > the last few messages of Main Mode? And why do we even bother with phase 1 > rekeying? No, I'm saying that to break an IKE SA (to acquire knowledge of SKEYID_d) is not dependant on the amount of traffic the IKE SA protects with SKEYID_e. And I don't know why you bother with phase 1 rekeying but I do because the entropy in SKEYID_d is finite. It is just this point that makes the new lifetype suggested by Kivenen valuable. Dan. From owner-ipsec@lists.tislabs.com Sat Aug 7 18:18:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA27264; Sat, 7 Aug 1999 18:18:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14071 Sat, 7 Aug 1999 16:27:51 -0400 (EDT) Message-Id: <199908072011.NAA06141@potassium.network-alchemy.com> To: Joern Sierwald cc: ipsec@lists.tislabs.com Subject: Re: Retransmits in traffic count? In-reply-to: Your message of "Fri, 06 Aug 1999 17:03:21 +0300." <3.0.5.32.19990806170321.00bc9500@smtp.datafellows.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6138.934056679.1@network-alchemy.com> Date: Sat, 07 Aug 1999 13:11:20 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alright! Someone who actually uses KB lifetime (but also admits it's not a really useful feature). Although I wasn't too serious about removing the KB lifetype this statement of utility should be enough to end this rediculous thread. This should probably answer the MIB question too. The only person who actually uses this attribute in the protocol does not increment the counter on retransmits. Dan. On Fri, 06 Aug 1999 17:03:21 +0300 you wrote > >I'll ask again: who uses phase 1 lifetime of KB? Can anyone think of a > >good reason to? > > > > We use KB lifetimes for phase 1, the default is 1000. > Retransmits do not increment the byte counter. > > KB lifetimes are not really useful. but the limit > is in to make to program compatible with older versions. > If the responder has 1000 KB limits and the initiator > does not send a limit, responder sends "no proposal chosen". > Our customers love it. From owner-ipsec@lists.tislabs.com Mon Aug 9 06:17:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA10136; Mon, 9 Aug 1999 06:17:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA17812 Mon, 9 Aug 1999 07:21:56 -0400 (EDT) Message-Id: <199908091122.HAA00824@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-ext-meth-02.txt Date: Mon, 09 Aug 1999 07:22:07 -0400 Sender: owner-ipsec@lists.tislabs.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 : ISAKMP & IKE Extensions Methods Author(s) : T. Kivinen Filename : draft-ietf-ipsec-ike-ext-meth-02.txt Pages : 13 Date : 06-Aug-99 This document describes the multiple extension methods of the ISAKMP [RFC-2408] and IKE [RFC-2409] protocols and how the older versions should respond when they receive such extensions. This document mainly tries to describe the best common practice of the extensions handling in ISAKMP [RFC-2408] and IKE [RFC-2409]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ext-meth-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-ike-ext-meth-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-ext-meth-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: <19990806100931.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-ext-meth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-ext-meth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990806100931.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Aug 9 11:34:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA13236; Mon, 9 Aug 1999 11:34:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19124 Mon, 9 Aug 1999 12:42:17 -0400 (EDT) Message-Id: <4.1.19990809124215.00a20320@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 09 Aug 1999 12:42:42 -0400 To: ipsec@lists.tislabs.com From: Robert Moskowitz Subject: FW: AES Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >X-Sender: foti@csmes.ncsl.nist.gov >X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) >Date: Mon, 09 Aug 1999 10:45:15 -0400 >To: all@csmes.ncsl.nist.gov >From: Jim Foti >Subject: AES > >Hi Folks- > >It's now official! Our FIVE finalists for the AES are: > >MARS >RC6 >Rijndael >Serpent >Twofish > >More info is available at ... > >Jim > > Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Tue Aug 10 07:29:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA06704; Tue, 10 Aug 1999 07:29:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22436 Tue, 10 Aug 1999 08:41:57 -0400 (EDT) Message-Id: <3.0.5.32.19990810154249.00af8300@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 10 Aug 1999 15:42:49 +0300 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: ESP over UDP Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA22433 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is there a well-known port that I could use to run esp over udp? ISAKMP runs fine over IP maskerading, but ESP does not. Jörn From owner-ipsec@lists.tislabs.com Tue Aug 10 07:33:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA06809; Tue, 10 Aug 1999 07:33:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22519 Tue, 10 Aug 1999 09:05:17 -0400 (EDT) To: Joern Sierwald Cc: ipsec@lists.tislabs.com Subject: Re: ESP over UDP References: <3.0.5.32.19990810154249.00af8300@smtp.datafellows.com> From: Derek Atkins Date: 10 Aug 1999 09:05:46 -0400 In-Reply-To: Joern Sierwald's message of Tue, 10 Aug 1999 15:42:49 +0300 Message-Id: Lines: 26 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You've got it backwards -- UDP runs over ESP, not the other way around. Although you are correct in saying that ISAKMP runs over UDP. That is true. The problem is that you are using IP Masquerade. You will have trouble with IPSec across a NAT. There are a couple of patches that exist for Linux to try to get IPSec working across the NAT: ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html -derek Joern Sierwald writes: > > Is there a well-known port that I could use to run esp over udp? > ISAKMP runs fine over IP maskerading, but ESP does not. > > J=F6rn > -- 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 N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Aug 10 07:43:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA07037; Tue, 10 Aug 1999 07:43:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22576 Tue, 10 Aug 1999 09:22:23 -0400 (EDT) Message-Id: <3.0.5.32.19990810162325.00996dd0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 10 Aug 1999 16:23:25 +0300 To: Derek Atkins From: Joern Sierwald Subject: Re: ESP over UDP Cc: ipsec@lists.tislabs.com In-Reply-To: References: <3.0.5.32.19990810154249.00af8300@smtp.datafellows.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA22573 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:05 10.8.1999 -0400, you wrote: >You've got it backwards -- UDP runs over ESP, not the >other way around. Although you are correct in saying that >ISAKMP runs over UDP. That is true. > >The problem is that you are using IP Masquerade. You will have >trouble with IPSec across a NAT. There are a couple of patches >that exist for Linux to try to get IPSec working across the NAT: > >ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html > >-derek > I need to run IPsec over every available IP masquerading implementation in the world, and therefore I have to send ESP packets as UDP payloads. Trust me, I know what I'm doing. (tm) Jörn From owner-ipsec@lists.tislabs.com Tue Aug 10 09:29:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA09040; Tue, 10 Aug 1999 09:29:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22925 Tue, 10 Aug 1999 10:43:29 -0400 (EDT) From: Richard Guy Briggs Message-Id: <199908101458.KAA16992@grendel.conscoop.ottawa.on.ca> Subject: Re: ESP over UDP To: joern.sierwald@datafellows.com (Joern Sierwald) Date: Tue, 10 Aug 1999 10:58:54 -0400 (EDT) Cc: warlord@MIT.EDU, ipsec@lists.tislabs.com In-Reply-To: <3.0.5.32.19990810162325.00996dd0@smtp.datafellows.com> from "Joern Sierwald" at Aug 10, 99 04:23:25 pm X-Mailer: ELM [version 2.4 PL25 PGP8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > At 09:05 10.8.1999 -0400, you wrote: > >You've got it backwards -- UDP runs over ESP, not the > >other way around. Although you are correct in saying that > >ISAKMP runs over UDP. That is true. > > > >The problem is that you are using IP Masquerade. You will have > >trouble with IPSec across a NAT. There are a couple of patches > >that exist for Linux to try to get IPSec working across the NAT: > > > >ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html > > > >-derek > > I need to run IPsec over every available IP masquerading > implementation in the world, and therefore I have to send > ESP packets as UDP payloads. Trust me, I know what I'm doing. (tm) What you might try doing is ESP inside AH, for which the patch above may work, I'm not crazy about it.... I understood what you were trying to do when you first posted and thought this was a clever workaround. The only problem is that udp connections time out, so you would have to do port forwarding, statically, or possibly NAT. Masquerading IPSEC is frought with frustration. I don't see why it wouldn't work, but I suspect you will have to code it yourself. > Jörn slainte mhath, RGB - -- The first Ottawa Linux Symposium was a huge success! This SunRayce was a wet one! DroughtRelief_99? -- Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada Prevent Internet Wiretapping! -- FreeS/WAN: Thanks for voting Green! -- Marillion: -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBN7A+K9+sBuIhFagtAQEReAP/bRxot0yanIt0KeMBXvfv9Xz/mip2Vc7j QttOX+FidV0lDBLp/mvIoE+zIQ5CZos5rQ87KhRa59CLTvYdzp7MII2IAl090OEt dq2v7Km0U/V7JOXMfkXiT4Ryy+I7nKGBU6nh/rtOsi3FqaAiF/FLuiiwlvV2k+JA MzQieYi0cak= =adMy -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Aug 10 10:40:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA10015; Tue, 10 Aug 1999 10:40:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23246 Tue, 10 Aug 1999 11:47:08 -0400 (EDT) Message-Id: <3.0.5.32.19990810184811.00c21530@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 10 Aug 1999 18:48:11 +0300 To: Paul Koning , ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: ESP over UDP In-Reply-To: <199908101526.LAA29235@tonga.xedia.com> References: <3.0.5.32.19990810154249.00af8300@smtp.datafellows.com> <3.0.5.32.19990810162325.00996dd0@smtp.datafellows.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA23243 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:26 10.8.1999 -0400, you wrote: >>>>>> "Joern" == Joern Sierwald writes: > > Joern> At 09:05 10.8.1999 -0400, you wrote: > >> You've got it backwards -- UDP runs over ESP, not the other way > >> around. Although you are correct in saying that ISAKMP runs over > >> UDP. That is true. > >> > >> The problem is that you are using IP Masquerade. You will have > >> trouble with IPSec across a NAT. There are a couple of patches > >> that exist for Linux to try to get IPSec working across the NAT: > >> > >> ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html > >> > >> -derek > >> > > Joern> I need to run IPsec over every available IP masquerading > Joern> implementation in the world, and therefore I have to send ESP > Joern> packets as UDP payloads. Trust me, I know what I'm doing. (tm) > >Well, yes, but unfortunately ESP just doesn't work that way. ESP runs >over IP, not over UDP. It's like asking TCP to run over UDP. It >doesn't, never has, never will. > One informational RFC and ESP runs over UDP, or TCP runs over UDP. No problem. I hacked the "ESP over UDP" into our implemention and it survives the usual masquerading boxes like FW-1 (NAT method "hide"). I am just asking if other people do this as well and if there is a port number (private area 49152 through 65535?). >You could, I suppose, run ESP inside an L2TP tunnel. Ugh. > Ugh. My opinion exactly. Jörn Sierwald From owner-ipsec@lists.tislabs.com Tue Aug 10 14:12:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA13886; Tue, 10 Aug 1999 14:12:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23900 Tue, 10 Aug 1999 14:49:15 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Tue, 10 Aug 1999 12:49:23 -0600 From: "Hilarie Orman" To: , Subject: Re: ESP over UDP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA23897 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I suppose you could run IP over SMTP with PGP and avoid the need for IPSEC altogether. ipv4@foo.bar Hilarie From owner-ipsec@lists.tislabs.com Tue Aug 10 14:12:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA13894; Tue, 10 Aug 1999 14:12:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24016 Tue, 10 Aug 1999 15:25:14 -0400 (EDT) Message-Id: <199908101922.PAA01877@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: ESP over UDP In-reply-to: Your message of "Tue, 10 Aug 1999 16:23:25 +0300." <3.0.5.32.19990810162325.00996dd0@smtp.datafellows.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Tue, 10 Aug 1999 15:22:10 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Joern" == Joern Sierwald writes: Joern> At 09:05 10.8.1999 -0400, you wrote: >> You've got it backwards -- UDP runs over ESP, not the other way >> around. Although you are correct in saying that ISAKMP runs over UDP. >> That is true. >> >> The problem is that you are using IP Masquerade. You will have >> trouble with IPSec across a NAT. There are a couple of patches that >> exist for Linux to try to get IPSec working across the NAT: >> >> ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html >> >> -derek >> Joern> I need to run IPsec over every available IP masquerading Joern> implementation in the world, and therefore I have to send ESP Joern> packets as UDP payloads. Trust me, I know what I'm doing. (tm) You may know what you are doing, but you aren't doing IPsec. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Aug 10 14:43:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA14466; Tue, 10 Aug 1999 14:43:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24291 Tue, 10 Aug 1999 16:07:20 -0400 (EDT) Message-Id: <199908102008.UAA00200@orchard.arlington.ma.us> To: Joern Sierwald cc: Paul Koning , ipsec@lists.tislabs.com Subject: Re: ESP over UDP In-Reply-To: Message from Joern Sierwald of "Tue, 10 Aug 1999 18:48:11 +0300." <3.0.5.32.19990810184811.00c21530@smtp.datafellows.com> Date: Tue, 10 Aug 1999 16:07:59 -0400 From: Bill Sommerfeld Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Something vaguely like this topic came up a little while ago. It seems like an excellent approach to enable deployment of ipsec. Craig Metz mentioned something about wanting to write up an IP-over-UDP tunnel internet draft a couple months ago; he said he'd been using it off-and-on for a while to deal with NAT's and brain-damaged firewalls. - Bill From owner-ipsec@lists.tislabs.com Tue Aug 10 16:36:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA16130; Tue, 10 Aug 1999 16:36:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24834 Tue, 10 Aug 1999 18:14:02 -0400 (EDT) Message-Id: <4.2.0.58.19990810151306.00a04de0@mail.vpnc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 10 Aug 1999 15:14:05 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: ESP over UDP In-Reply-To: <199908102008.UAA00200@orchard.arlington.ma.us> References: <3.0.5.32.19990810184811.00c21530@smtp.datafellows.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 04:07 PM 8/10/1999 -0400, Bill Sommerfeld wrote: >Something vaguely like this topic came up a little while ago. It >seems like an excellent approach to enable deployment of ipsec. Or you could tunnel IPsec through MIME, maybe through SMTP. Don Eastlake has just put out an, er, interesting draft on this. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Aug 11 06:01:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA05324; Wed, 11 Aug 1999 06:01:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA26971 Wed, 11 Aug 1999 07:42:25 -0400 (EDT) Message-Id: <199908110134.VAA21042@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: ESP over UDP In-reply-to: Your message of "Tue, 10 Aug 1999 12:49:23 MDT." Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Tue, 10 Aug 1999 21:34:32 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Hilarie" == Hilarie Orman writes: Hilarie> I suppose you could run IP over SMTP with PGP and avoid the Hilarie> need for IPSEC altogether. ipv4@foo.bar I believe that Marcus Ranum did run NFS over IP over SMTP in the early '90s as proof that no firewall is completedly secure. It didn't do encryption, that I remember, but clearly you could run NFS over IPsec over IP over SMTP. He just used uuencode. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Wed Aug 11 06:01:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA05354; Wed, 11 Aug 1999 06:01:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA26930 Wed, 11 Aug 1999 07:30:42 -0400 (EDT) Message-ID: <37B15F4B.31A93A12@mitre.org> Date: Wed, 11 Aug 1999 07:32:27 -0400 From: "Brian W. McKenney" Reply-To: mckenney@mitre.org Organization: The MITRE Corporation X-Mailer: Mozilla 4.5 [en]C-19990120M (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IPsec software implementations for Sun Solaris Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB88E617FF6DA13669EF46CCF" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msB88E617FF6DA13669EF46CCF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Looking for commercial off-the-shelf (COTS) IPsec software implementations for Sun Solaris. Most of desktop software implementations are based on MS Windows platforms. Would appreciate any pointers. Thanks. Brian -- Brian W. McKenney The MITRE Corporation 1820 Dolley Madison Blvd. McLean, VA 22102 http://www.mitre.org --------------msB88E617FF6DA13669EF46CCF Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKDQYJKoZIhvcNAQcCoIIJ/jCCCfoCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B6gwggRyMIID26ADAgECAhAFX3X1EaiwpeTZ2Ivea5IfMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MDYyOTAwMDAw MFoXDTAwMDYyODIzNTk1OVowggEWMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGjAYBgNVBAMUEUJyaWFuIFcuIE1jS2VubmV5MSEwHwYJ KoZIhvcNAQkBFhJtY2tlbm5leUBtaXRyZS5vcmcwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAMl7imvmtP0pLy1MNTD2g+2iAKxmtsBuOAH+PuO//NjQJ/5YvzDAexp14TJHQXv7Pwhq T1ZXNLrr8ZIpqc8xMsmNWefhKQ9JMB7zhJHgEuwOIww7GDam8wUwfWiKijZjyPCOO/aER8C/ hkth8gSiWFwdODxngxb2q8cVCKo8Nyy5AgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNV HSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9 VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBW ZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Ny bC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCQB8VvLpSCcDbK Qa0TeOyTuDh+TTdkHFP1YmSPDt3160Gcu9VpiPCg+WTuebfFAeLpF5UbBAyZusdoPFqkS0SD vwfYgGnttDANq3Lf5IciK5kKm83JyDVDEELfJwckuDHwDAgoPM4ICrYSry4iyQ652nPG5MQE I/IcYfa58CE5QTCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEB AgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMu Q2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1 MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYG A1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u YSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0D eootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCC DgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J 2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8Bgtg hkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkv UlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4 Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKe wz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4Km saiSxVhqwY0DPOvDzQWikK5uMYICLTCCAikCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAVfdfURqLCl5NnYi95rkh8wCQYFKw4DAhoFAKCB ojAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw05OTA4MTExMTMy MjdaMCMGCSqGSIb3DQEJBDEWBBTBc3uKlesUd8ovolmWWJAIBuB0NDBDBgkqhkiG9w0BCQ8x NjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIB QDANBgkqhkiG9w0BAQEFAASBgEAIkKNAkTE7C+muwUxh8/5K1B3QiQVZ5rhTbRd8mBVJLchs g69cPYkvKhUDoiBQPiR5OdDP4u1apyEstOraSKq1GU8WcKTxsV3crAsailL0zDUs9siNnM5F 3HN58GXor8HzaBYwD2YDx31MRY8cTzqwVQWMrId6Bs45+FY1oDPF --------------msB88E617FF6DA13669EF46CCF-- From owner-ipsec@lists.tislabs.com Wed Aug 11 07:30:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA07332; Wed, 11 Aug 1999 07:30:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27253 Wed, 11 Aug 1999 08:49:35 -0400 (EDT) X-Map-MIXER-Originators: false To: ipsec@lists.tislabs.com From: "Riittinen Heikki" MIME-Version: 1.0 Date: 11 Aug 1999 09:20:00 +0200 Subject: ESP over UDP Envelope-ID: JA8AAAAAALynaAABYQADSOwLQb5U@teamware.com Message-Id: Disposition-Notification-To: heikki.riittinen@teamware.com X-Mailer: TeamWARE Connector for MIME Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id CAA26162 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joern Sierwald writes: > Is there a well-known port that I could use to run esp over udp? > ISAKMP runs fine over IP maskerading, but ESP does not. Joern, As far as I know, there is no well-known port for this purpose, but the IPSEC over UDP itself solves nicely the NAT problem. Our commecial VPN product has used this succesfully now for three years. (See:http://www.teamware.com/teamware/Products/) Regards Heikki Riittinen heikki.riittinen@teamware.com From owner-ipsec@lists.tislabs.com Wed Aug 11 12:49:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA15867; Wed, 11 Aug 1999 12:49:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28777 Wed, 11 Aug 1999 13:46:32 -0400 (EDT) Message-ID: <002601bee420$ef759720$e994afc7@dcrowe.x509.com> From: "David Crowe" To: Subject: Certs Offer for IPSec Testing Date: Wed, 11 Aug 1999 10:42:41 -0700 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.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Xcert is adding support for the current draft of "PKI Requirements for IP Security" (draft-ietf-ipsec-pki-req-02.txt) in our CAs. We were wondering if any of you would like to test with us. Our CA supports RSA, DSA, & ECC certificates. We would like to invite you to send us a certificate request. For now, we are set up for "offline" certificate transmission, i.e., you email me a request in PKCS#10 format, and I will send you back a signed certificate in PKCS#7 format. Thanks. /David Crowe. ----------------------------------------------------- David R. Crowe Project Manager, Interoperability Lab Xcert International Inc. #1001, 701 West Georgia Street P.O. Box 10145, Pacific Centre tel: +1(604)640-6210 ext 239 Vancouver, B.C. V7Y 1C6, Canada fax: +1(604)640-6220 http://www.xcert.com email: dcrowe@xcert.com From owner-ipsec@lists.tislabs.com Wed Aug 11 15:45:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA18172; Wed, 11 Aug 1999 15:45:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29209 Wed, 11 Aug 1999 16:10:27 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFCC529B@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: RE: Retransmits in traffic count? Date: Wed, 11 Aug 1999 16:11:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I feel I need to make one more comment on this subject, since I don't think we reached a sensible conclusion. (Dan's conclusion thus far was "Although I wasn't too serious about removing the KB lifetype this statement of utility should be enough to end this rediculous thread.") I want to point out that there are, in fact, some important uses for KB lifetimes on IKE SAs. First, let me say that I didn't intend to start an argument about the value of KB lifetimes for IKE. I simply suggested to Tim (offline) that it didn't make sense to count retransmits against the SA lifetime. Tim posed the question to the list and the reaction was mixed. Then Dan started a tangential thread about whether KB lifetimes were useful. I said they were. My reasoning here was by extrapolation, but the argument got bogged down in the details. The two questions that I don't feel Dan made any attempt to answer are the following: 1. If IKE packets are not sensitive enough to warrant strong protection then why do we encrypt them at all? 2. If notifies for KB lifetimes are not important then why do we send notifies for time-based expiry? As I said, this was just argument by extrapolation. If we do X then why wouldn't we do Y? The answer could be that we should do Y or possibly that we don't really need to do X. ----------------------- My feeling on (1) is that IKE packets are worth protecting. They contain some sensitive information (identities, nonces) and some not so senstitive stuff (SA proposals). The identities are worth protecting in their own right. The nonces are worth encrypting because they seed the QM keymat (and if you're doing PFS then the KE is worth protecting because it makes it just that much harder to crack the QM DH when the whole exchange is encrypted). As for SKEYID_a, cracking it doesn't provide a lot of information towards SKEYID_d. They are related, but not in any way that can forseeably be exploited (to the best of my knowledge). On the other hand, while an attacker who had access to SKEYID_e and SKEYID_a couldn't read any IPSec traffic, they could still play havoc with your network by frivolously negotiating and deleting SAs. Dan doesn't see this as much of a threat: "To note how rediculous this is, if [Dan's conditions for SKEYID_e being broken] happened then why would the "attacker" want to _increase_ the renegotiation of the IPSec SAs. Given the incredibly low volume of IKE traffic to IPSec traffic for a given flow it would make more sense that the "attacker" would use his advance in cryptanalysis to attack the IPSec traffic." My concern is that the intruder will attack the weakest link in the chain of security. If we make IKE traffic easier to crack than IPSec traffic then the intruder may very well focus on what they can get rather than what they really want. Plus, I don't think it is fair to assume that breaking an IKE SA would require ciphertext-only cryptanalysis, since a large percentage of the data (SA proposals, etc.) is both easily guessable and highly consistent across exchanges. It is relatively difficult to screw around with the traffic on an IPSec SA (of course it depends on the other aspects of network security -- firewalls, locks on the door, etc.), but it is much easier to screw with an IKE SA. For example, could an attacker force one of the nodes to generate encrypted info mode traffic on an IKE SA? Probably. Would this attack be detected by the system? Maybe, maybe not. ----------------------- Don't get me wrong -- I am all for defining a third expiry constraint like the one you mentioned. But as I see it, there are three factors that contribute to the gradual degradation of an IKE SA's security: 1. Time. 2. The number of phase 2s which have keymat based on SKEYID_d. 3. Traffic on the IKE SA. In many situations, these three factors are highly correlated. As so often happens, we have to resort to traffic analysis: For example, a sgw on a 100 mb link with relatively even traffic density proposing the same set of security descriptors with other peers who have similar configurations. In this situation, phase 2 rekeys occur at regular time intervals and the size of the QM negotiation packets are always the same size (and I imagine that one could make the same assumption about config mode exchanges). In this case, a time-based SA expiry is sufficient (assuming, yet again, that the attacker doesn't force the negotiation of extra phase 2 SAs). There are other situations where this traffic pattern does not make sense. Imagine a more diverse S/WAN -- one where much of the traffic is sent on a fast 100 mb connection, but some of the traffic is on a 56k modem link. Also, some of the SA proposal payloads are large and others are small. Now, the three determining factors have become decoupled and it is much harder to set a simple time-based expiry. An expiry based only on 1 & 2 or only on 1 & 3 might be practical, since you can only decouple 2 & 3 so far (unless the attacker can force the generation of info modes, which I think is possible), but it is still theoretically unsound. ----------------------- My feeling on (2) is that notifies for expiry constraints aren't particularly useful, but if we support them then we should at least be consistent. I was hoping that someone would suggest a reason why these notifies are important (because I can't think of a good one) -- perhaps for auditing purposes or maybe to negotiate an intelligent jitter condition to avoid rekey collisions. Besides, it doesn't seem to do much harm to send expiry constraints that the other side doesn't understand (since, as we have already discussed, pretty much everyone discards them without using them). But apparently it does do damage to some vendors' implementations if we remove constraints that already exist. As far as I can tell, this should be a MAY clause in the spec (which it probably already is, but I can't be bothered to look it up). Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Aug 11 17:17:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA19175; Wed, 11 Aug 1999 17:17:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29631 Wed, 11 Aug 1999 18:42:34 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Wed, 11 Aug 1999 16:42:43 -0600 From: "Hilarie Orman" To: , Subject: RE: Retransmits in traffic count? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA29628 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The identity protection is the only important aspect of the discussion, but it is not tied to KB lifetime. The risk factor depends on how many identities would be exposed by breaking one key. It is reasonable to assume that there is enough redundancy in the plaintext to warrant an exhaustive search, so even one encrypted exchange makes the key vulnerable, and thus all the identities encrypted under it. The volume of data is irrelevant. So I'd limit the number of exchanges that involve identities; that's probably closely related to time, so maybe it's already covered (and Dan is right about killing the KB lifetime). Note also that this only applies to passive attacks; active attackers can arrange to see the identities with only a little bit of clumsiness. The passive scenario seems very important, though. I don't see much value in applying weak protections for adding security to strong methods (e.g. encrypting the DH exponentials). I suppose you could argue that sometimes this will hide errors in implementation or certain kinds of hardware failures, but implementors should embrace the concept of "bug transparency." Errors in security protocols should be glaringly visible on the wire, so that they can be detected and fixed. Hilarie From owner-ipsec@lists.tislabs.com Wed Aug 11 17:25:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA19285; Wed, 11 Aug 1999 17:25:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29667 Wed, 11 Aug 1999 19:09:46 -0400 (EDT) Message-ID: <37B1F64B.C3EA77C8@redcreek.com> Date: Wed, 11 Aug 1999 22:16:43 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Krywaniuk CC: ipsec@lists.tislabs.com Subject: Re: Retransmits in traffic count? References: <319A1C5F94C8D11192DE00805FBBADDFCC529B@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk wrote: > > First, let me say that I didn't intend to start an argument about the value > of KB lifetimes for IKE. I simply suggested to Tim (offline) that it didn't > make sense to count retransmits against the SA lifetime. Tim posed the > question to the list and the reaction was mixed. > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. I am curious why you think that it does not make sense to count retranmits against the SA lifetime in IKE. If you counted the first packet (not a retransmit) then why not count the retransmits. All the QM negotiations are traveling under the protection of a particular phase one SA. This is not a major issue to me, and I would be happy with either resolution to the question. I'm just trying to see your prespective. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Wed Aug 11 22:44:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA17770; Wed, 11 Aug 1999 22:44:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA00142 Thu, 12 Aug 1999 00:00:24 -0400 (EDT) Message-Id: <199908120400.VAA14771@potassium.network-alchemy.com> To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: Re: Retransmits in traffic count? In-reply-to: Your message of "Wed, 11 Aug 1999 16:11:44 EDT." <319A1C5F94C8D11192DE00805FBBADDFCC529B@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14768.934430413.1@network-alchemy.com> Date: Wed, 11 Aug 1999 21:00:13 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 11 Aug 1999 16:11:44 EDT Andrew Krywaniuk wrote, where (2) is the "# of negotiations" type of life that is being proposed for IKE: > > My feeling on (2) is that notifies for expiry constraints aren't > particularly useful, but if we support them then we should at least be > consistent. I was hoping that someone would suggest a reason why these > notifies are important (because I can't think of a good one) -- perhaps for > auditing purposes or maybe to negotiate an intelligent jitter condition to > avoid rekey collisions. > > Besides, it doesn't seem to do much harm to send expiry constraints that the > other side doesn't understand (since, as we have already discussed, pretty > much everyone discards them without using them). But apparently it does do > damage to some vendors' implementations if we remove constraints that > already exist. As far as I can tell, this should be a MAY clause in the spec > (which it probably already is, but I can't be bothered to look it up). Wow! With an attitude like that ("I can't be bothered to look it up") I'm not surprised you don't understand. If you never use something then it is worthless to you. A gearshift is not a useful part of a car if you never get out of 1st gear. But not everyone (and I hope not "pretty much everyone") discards lifetime offers and responder-notifies, and for those of us who do parse lifetime offers and send responder-notifies (when needed) they are quite useful. By using these two features each side is able to keep their SAs in sync. If A offers B a lifetime _less_ than what B has configured B will accept it and respect it. If A offers B a lifetime _more_ than what B has configured B sends A a "responder-notify" stating the lesser lifetime which A is expected to respect. That way both sides are in sync when rekeying comes around and each side knows that the other side is going to delete the SA when it will. That is the reason why these features are part of the protocol. For a variety of reasons-- a reluctance to write a variable memcmp routine to parse TLVs of (possibly) different length and return -1,0,1 depending on the result of the comparison, or perhaps a "my way or the hiway" type of enforcement of lifetime policy-- some people are reluctant to engage in this behavior and instead just ignore these very useful features. They ignore an offered lifetime and any responder-notify message they receive and they never send responder-notify messages regardless of the contents of the protection suite they receive. But the result is that some complicated re-keying regime is necessary and interoperability is not ensured. This complicated protocol is easier if these common sense features are used and not ignored. I encourage you to find the time to "be bothered" to read the RFCs. Dan. From owner-ipsec@lists.tislabs.com Thu Aug 12 07:04:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA03654; Thu, 12 Aug 1999 07:04:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA01360 Thu, 12 Aug 1999 08:24:49 -0400 (EDT) Message-Id: <4.1.19990811162330.00b2d360@intotoinc.com> X-Sender: sathyan@intotoinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 11 Aug 1999 16:33:16 -0700 To: mckenney@mitre.org, ipsec@lists.tislabs.com From: Sathyan Iyengar Subject: Re: IPsec software implementations for Sun Solaris In-Reply-To: <37B15F4B.31A93A12@mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Brian, Intoto has IPSEC and IKE software implemented for Embedded systems running RTOS such as pSOS, VxWorks, Nucleus etc. Our IPSEC implementation supports both software crypto library(SSLeay) and hardware crypto accelerators from Hifn and VLSI. IKE will be available for Linux next month. We can work with you to implement IPSEC on Sun Solaris OS. Please contact me for more information at 408-844-0480 x:302. Thanks, -Sathyan At 07:32 AM 8/11/99 -0400, Brian W. McKenney wrote: > >Looking for commercial off-the-shelf (COTS) IPsec software >implementations for Sun Solaris. Most of desktop software >implementations are based on MS Windows platforms. Would appreciate any >pointers. Thanks. > >Brian >-- >Brian W. McKenney The MITRE Corporation >1820 Dolley Madison Blvd. McLean, VA 22102 >http://www.mitre.org > > /********************************************************************** Embedded Solutions for Network Security and Interconnectivity Intoto Inc. Ph : 408-844-0480 Ext:302 3160, De La Cruz Blvd. Fax : 408-844-0488 Suite #100/101, Santa Clara e-mail : sathyan@intotoinc.com CA - 95054, USA Web : www.intotoinc.com ***********************************************************************/ From owner-ipsec@lists.tislabs.com Sat Aug 14 18:29:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA20670; Sat, 14 Aug 1999 18:29:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08895 Sat, 14 Aug 1999 19:33:19 -0400 (EDT) Date: Sun, 15 Aug 1999 02:33:56 +0300 (EET DST) Message-Id: <199908142333.CAA09532@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Ricky Charlet Cc: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: Retransmits in traffic count? In-Reply-To: <37B1F64B.C3EA77C8@redcreek.com> References: <319A1C5F94C8D11192DE00805FBBADDFCC529B@exchange> <37B1F64B.C3EA77C8@redcreek.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ricky Charlet writes: > I am curious why you think that it does not make sense to count > retranmits against the SA lifetime in IKE. If you counted the first > packet (not a retransmit) then why not count the retransmits. All the QM > negotiations are traveling under the protection of a particular phase > one SA. Because the retransmission packets are identical to the original packets. There is no reason to count them to KB limit, because of that (they do not offer attacker any new encrypted data to attack). -- 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@lists.tislabs.com Mon Aug 16 03:37:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA26865; Mon, 16 Aug 1999 03:37:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA12029 Mon, 16 Aug 1999 05:00:32 -0400 (EDT) Message-Id: <199908160901.SAA12586@swan.png.flab.fujitsu.co.jp> To: ipsec@lists.tislabs.com cc: kubota@flab.fujitsu.co.jp From: Makoto Kubota Subject: about Selecter Parameter Date: Mon, 16 Aug 1999 18:01:16 +0900 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello everybody, I would like to ask about selector in RFC2401. In RFC2401; > > 4.4.2 Selectors > ..... > - Destination IP Address (IPv4 or IPv6): this may be a single IP > address (unicast, anycast, broadcast (IPv4 only), or multicast > group), a range of addresses (high and low values (inclusive), > address + mask, or a wildcard address. The last three are used > ..... > transport'd packet, there will be only one IP header and this > ambiguity does not exist. [REQUIRED for all implementations] Is this sentence saying, when implementing SPD, the implementor Must support *ALL* parameters setting below for dest-IP ? - single IP - multicast - a range of addresses (high and low values - address + mask - a wildcard address or, are these only candidate of dest-IP setting and whole parameter's support being not mandatory? Thanks in advance. -- Makoto From owner-ipsec@lists.tislabs.com Mon Aug 16 06:49:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA28627; Mon, 16 Aug 1999 06:49:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12471 Mon, 16 Aug 1999 08:25:35 -0400 (EDT) Message-ID: <37B6E859.9F5AF33E@americasm01.nt.com> Date: Sun, 15 Aug 1999 12:18:33 -0400 From: "Amal Maalouf" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: SA bundles including IPCOMP. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, If an SA bundle includes tunnel mode AH and ESP, and IPCOMP; for an incoming packet [IP1][upper], will the resulting packet be: [IP2][AH][ESP][IPCOMP][IP1][upper] or [IP2][AH][ESP][IP1][IPCOMP][upper] ? >From Rfc 2393 I would guess the second case is the answer, am I missing anything? Thanks. -- Amal Maalouf Nortel Networks Tel: (613) 765-5649 Fax: (613) 765-2186 e-mail: amalmaal@nortelnetworks.com From owner-ipsec@lists.tislabs.com Mon Aug 16 06:49:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA28635; Mon, 16 Aug 1999 06:49:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12467 Mon, 16 Aug 1999 08:25:34 -0400 (EDT) Message-ID: <37B6EA52.B8678E8C@americasm01.nt.com> Date: Sun, 15 Aug 1999 12:26:58 -0400 From: "Amal Maalouf" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: inbound Spd lookup for IPsec packets. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Just curious to know which practical security violations are being guarded against (an example would be appreciated) when checking an inbound IPsec packet - after it has been handled by the SA and checked against the SA selectors - against the inbound spd. Thanks. -- Amal Maalouf Nortel Networks Tel: (613) 765-5649 Fax: (613) 765-2186 e-mail: amalmaal@nortelnetworks.com From owner-ipsec@lists.tislabs.com Mon Aug 16 07:18:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA28985; Mon, 16 Aug 1999 07:18:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12832 Mon, 16 Aug 1999 08:59:39 -0400 (EDT) Message-Id: <3.0.5.32.19990816160038.00b57a30@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 16 Aug 1999 16:00:38 +0300 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: SA bundles including IPCOMP. In-Reply-To: <37B6E859.9F5AF33E@americasm01.nt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA12829 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:18 15.8.1999 -0400, you wrote: >Hello, > >If an SA bundle includes tunnel mode AH and ESP, and IPCOMP; >for an incoming packet [IP1][upper], will the resulting packet be: > [IP2][AH][ESP][IPCOMP][IP1][upper] >or > [IP2][AH][ESP][IP1][IPCOMP][upper] ? > >>From Rfc 2393 I would guess the second case is the answer, >am I missing anything? > >Thanks. >-- >Amal Maalouf >Nortel Networks >Tel: (613) 765-5649 Fax: (613) 765-2186 >e-mail: amalmaal@nortelnetworks.com > It's the first. At the santa barbara interops the problem was discussed. Jörn From owner-ipsec@lists.tislabs.com Mon Aug 16 10:56:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA01908; Mon, 16 Aug 1999 10:56:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13545 Mon, 16 Aug 1999 12:18:23 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199908160901.SAA12586@swan.png.flab.fujitsu.co.jp> Date: Mon, 16 Aug 1999 12:18:21 -0400 To: Makoto Kubota From: Stephen Kent Subject: Re: about Selecter Parameter Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Makoto, >In RFC2401; >> >> 4.4.2 Selectors >> ..... >> - Destination IP Address (IPv4 or IPv6): this may be a single IP >> address (unicast, anycast, broadcast (IPv4 only), or multicast >> group), a range of addresses (high and low values (inclusive), >> address + mask, or a wildcard address. The last three are used >> ..... >> transport'd packet, there will be only one IP header and this >> ambiguity does not exist. [REQUIRED for all implementations] > >Is this sentence saying, >when implementing SPD, the implementor Must support *ALL* parameters >setting below for dest-IP ? > - single IP > - multicast > - a range of addresses (high and low values > - address + mask > - a wildcard address > >or, >are these only candidate of dest-IP setting and whole parameter's support >being not mandatory? It is mandatory (REQUIRED) for an implementation to support ALL of these parameter types, to facilitate interoperability. Steve From owner-ipsec@lists.tislabs.com Mon Aug 16 10:56:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA01910; Mon, 16 Aug 1999 10:56:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13514 Mon, 16 Aug 1999 12:12:47 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <37B6EA52.B8678E8C@americasm01.nt.com> Date: Mon, 16 Aug 1999 12:08:42 -0400 To: "Amal Maalouf" From: Stephen Kent Subject: Re: inbound Spd lookup for IPsec packets. Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Amal, If we fail to check the inbound packet header against the selectors after IPsec processing, then anyone who is authorized to connect to an IPsec site can masquerade as any other connected user, and they can send traffic not authorized by the negotiation carried out by IKE. This can happen for both transport and tunel mode SAs, although it it potentially more serious for the latter as there are more opportunities to devite from the SA profile. Steve From owner-ipsec@lists.tislabs.com Wed Aug 18 09:24:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA18146; Wed, 18 Aug 1999 09:24:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22334 Wed, 18 Aug 1999 10:46:27 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <37B96CDE.603B4BB5@americasm01.nt.com> References: Date: Wed, 18 Aug 1999 10:45:16 -0400 To: "Amal Maalouf" From: Stephen Kent Subject: Re: inbound Spd lookup for IPsec packets. Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Amal, >What I am wondering about is not whether to check the selectors against >the inbound traffic or not. For ipsec inbound processing, the architecture >mentions that the SA (once located in the inbound SAD using the spi,prot,addr) >is applied to the packet (decrypt/verify), then the packet is 1) matched >against >the SA selectors, and then 2) matched against the inbound Spd. > >What I was wondering about, is if we've done the check of the inbound >traffic against the SA selectors (1) and that passed, what is the check >against the inbound Spd (2) going to further guard us against? Let me try again, with an example. If all traffic between two hosts is supposed to be protected by AH and by ESP (transport mode), then an attacker could trsip off the AH, and modify parts of the IP header that were covered by AH. Since, in transport mode, this header info is passed to the ULPs, this might result in unintended consequences, which is why the traffic was protected with AH to begin with. The fact that AH was stripped from the packet by an attacker would not be detected by inbound IPsec processing unless we check against the SPD, which would show that all traffic was supposed to be protected by BOTH AH and ESP. Steve From owner-ipsec@lists.tislabs.com Wed Aug 18 09:25:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA18158; Wed, 18 Aug 1999 09:25:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22249 Wed, 18 Aug 1999 10:15:43 -0400 (EDT) Message-ID: <37B96CDE.603B4BB5@americasm01.nt.com> Date: Tue, 17 Aug 1999 10:08:30 -0400 From: "Amal Maalouf" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: inbound Spd lookup for IPsec packets. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > Amal, > > If we fail to check the inbound packet header against the selectors after > IPsec processing, then anyone who is authorized to connect to an IPsec site > can masquerade as any other connected user, and they can send traffic not > authorized by the negotiation carried out by IKE. This can happen for both > transport and tunel mode SAs, although it it potentially more serious for > the latter as there are more opportunities to devite from the SA profile. > > Steve Steve, What I am wondering about is not whether to check the selectors against the inbound traffic or not. For ipsec inbound processing, the architecture mentions that the SA (once located in the inbound SAD using the spi,prot,addr) is applied to the packet (decrypt/verify), then the packet is 1) matched against the SA selectors, and then 2) matched against the inbound Spd. What I was wondering about, is if we've done the check of the inbound traffic against the SA selectors (1) and that passed, what is the check against the inbound Spd (2) going to further guard us against? Amal. From owner-ipsec@lists.tislabs.com Thu Aug 19 06:00:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA07904; Thu, 19 Aug 1999 06:00:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA25554 Thu, 19 Aug 1999 07:05:56 -0400 (EDT) Message-Id: <199908191106.HAA21402@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-mode-cfg-05.txt Date: Thu, 19 Aug 1999 07:06:21 -0400 Sender: owner-ipsec@lists.tislabs.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 : The ISAKMP Configuration Method Author(s) : R. Pereira, S. Anand, B. Patel Filename : draft-ietf-ipsec-isakmp-mode-cfg-05.txt Pages : 13 Date : 18-Aug-99 This document describes a new ISAKMP method that allows configuration items to be exchanged securely by using both push/acknowledge or request/reply paradigms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-05.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-mode-cfg-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-05.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: <19990818113054.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-mode-cfg-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-mode-cfg-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990818113054.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Aug 19 06:50:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA08350; Thu, 19 Aug 1999 06:50:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25666 Thu, 19 Aug 1999 08:16:53 -0400 (EDT) Message-ID: <37BBF5F6.38C50A59@bintec.de> Date: Thu, 19 Aug 1999 12:17:58 +0000 From: Michael Boehmer Organization: BinTec Communications AG X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: de-DE, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: SA selectors Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello! I have a question concerning the SA selectors: RFC 2401 requires support for the following SA selectors: - single source/dest address - source/dest address range - source/dest subnet with netmask - wildcard for source/dest address Does anyone support an SA to have multiple of these selector values at the same time? This is mainly a configuration issue: consider a huge corporate network and a policy affording the traffic of some selected machines to be protected with ipsec when traversing the internet to some remote site, protected by a security gateway. This would result in as many entries in the SAD as there are machines which must be protected. It would be much easier to configure -especially with manual keying- and much easier to monitor, if this setup would result in only one SA (which defines the same security parameters for all machines). All comments appreciated! Thanks, Michael. From owner-ipsec@lists.tislabs.com Thu Aug 19 08:51:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA09843; Thu, 19 Aug 1999 08:51:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26065 Thu, 19 Aug 1999 10:06:09 -0400 (EDT) Message-ID: <004901beea4d$6ea374e0$634cf526@east.isi.edu> From: "Aaron Griggs" To: "Michael Boehmer" Cc: References: <37BBF5F6.38C50A59@bintec.de> Subject: Re: SA selectors Date: Thu, 19 Aug 1999 10:16:29 -0400 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Hello! > > I have a question concerning the SA selectors: > > RFC 2401 requires support for the following SA selectors: > - single source/dest address > - source/dest address range > - source/dest subnet with netmask > - wildcard for source/dest address > > Does anyone support an SA to have multiple of these selector values at > the same time? By multiple do you mean the source address could be say wildcard while the destination address could be a subnet? The answer is yes. The SA entry is an instantiation of the SP entry. Or at least, that is how I view it. I show an example below. > > This is mainly a configuration issue: > consider a huge corporate network and a policy affording the traffic of > some selected machines to be protected with ipsec when traversing the > internet to some remote site, protected by a security gateway. > This would result in as many entries in the SAD as there are machines > which must be protected. It would be much easier to configure > -especially with manual keying- and much easier to monitor, if this > setup would result in only one SA (which defines the same security > parameters for all machines). > > All comments appreciated! > I assume SG1 for corporate network 1 and SG2 for corporate network 2. ------- -------- -------- -------- So, you want SG1 to have say one policy and one SA to protect many hosts sending traffic over the Internet to hosts behind SG2, right? To do this, SG1 has the following: Security Policy on SG1: PolicyNum RmtAddr LclAddr OtherSelectors InSA OutSA Direction 5 CorpNet2(policy) *(policy) * * * 9 8 BIDIRECT Security Assoc on SG1: SA Num SADestAddr DestAddr LclAddr OtherSelectors Direction 9 SG1 POLICY POLICY POLICY INBOUND 8 SG2 POLICY POLICY POLICY OUTBOUND I probably should explain the SP and SAs I show. The SP entry says for traffic originating from any hosts to corporate network 2 use this policy. Since "Direction" is bidirectional, the opposite is also true. That is, for traffic from SG2 to any host use this policy. The "RmtAddr" selector says take from policy, which doesn't require an individual SA for every host sending to corporate network 2. The other selectors are all wildcard and take from policy. So, two SAs are required for this policy. SA "9" is for inbound traffic and SA "8" for outbound. You'll note the "SADestAddr" is the one used for the triple lookup. I don't include the SPI or IPSec protocol. This example handles many machines from one network to the other without an SA for each machine. Aaron From owner-ipsec@lists.tislabs.com Thu Aug 19 10:59:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA11665; Thu, 19 Aug 1999 10:59:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26539 Thu, 19 Aug 1999 11:42:51 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <37BBF5F6.38C50A59@bintec.de> Date: Thu, 19 Aug 1999 11:36:06 -0400 To: Michael Boehmer From: Stephen Kent Subject: Re: SA selectors Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael, >I have a question concerning the SA selectors: > >RFC 2401 requires support for the following SA selectors: >- single source/dest address >- source/dest address range >- source/dest subnet with netmask >- wildcard for source/dest address > >Does anyone support an SA to have multiple of these selector values at >the same time? > >This is mainly a configuration issue: >consider a huge corporate network and a policy affording the traffic of >some selected machines to be protected with ipsec when traversing the >internet to some remote site, protected by a security gateway. >This would result in as many entries in the SAD as there are machines >which must be protected. It would be much easier to configure >-especially with manual keying- and much easier to monitor, if this >setup would result in only one SA (which defines the same security >parameters for all machines). I'm a bit puzzled by the question. An SPD entry cannot have multiple values for the same selector, but the widlcard, range, and netmask facilities allow multiple sets of specific values to map to the same SPD entry and, if desired, to the same SA. Is this what you were asking about? Steve From owner-ipsec@lists.tislabs.com Thu Aug 19 14:42:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA15165; Thu, 19 Aug 1999 14:42:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27575 Thu, 19 Aug 1999 15:45:31 -0400 (EDT) Message-ID: <37BC5FBF.4CA45E41@ibm.net> Date: Thu, 19 Aug 1999 15:49:19 -0400 From: Mike Williams X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IPSec Subject: Non-IP type Client IDs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There seems to be some confusion with regards to the use of Non-IP type client IDs (i.e. USER_FQDN) in a quick mode exchange. We have seen that some implementations will send non-IP type Client IDs and we have also seen some implementations that will not properly handle non-IP type Client IDs. >From reviewing the relevant RFCs, I am not able to see anything that indicates that there are restrictions on the IPSec DOI ID types in quick mode. What I see is that section 4.6.2 of RFC2407 says "The identity of the initiator SHOULD be used by the responder to determine the correct host system security policy requirement for the association." This says that IDs (both phase 1 and phase 2) should be used to help lookup policy. I also see in section 5.5 of RFC2409 that "The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode. If ISAKMP is acting as a client negotiator on behalf of another party, the identities of the parties MUST be passed as IDci and then IDcr. Local policy will dictate whether the proposals are acceptable for the identities specified."....."The client identities are used to identify and direct traffic to the appropriate tunnel in cases where multiple tunnels exist between two peers and also to allow for unique and shared SAs with different granularity." I understand this to say that the client IDs are not only used to lookup policy, but are also used in determining the selectors used by IPSec which must be IP types (i.e. IPV4_ADDR, IPV4_ADDR_SUBNET or IPV4_ADDR_RANGE). In the case of remote access when the initiating system will not have a fixed IP address, allowing the client (initiating) system to send something like user@fqdn would allow the responding system (host or gateway) to define different policies for the different users that will be allowed to connect. For example, it may be desirable to have a different policy for some user mikewill@ibm.net than for the user mdw@us.ibm.com when both of these users will have an arbitrarily assigned IP address every time they attempt to connect. This is only addresses half the problem, that being how to lookup phase 2 policy. The second half of the problem that client IDs solve, is helping to define the selectors that will be used by IPSec to direct traffic to different IPSec tunnels. When the client IDs are IP type IDs (i.e. IPV4_ADDR, IPV4_ADDR_SUBNET or IPV4_ADDR_RANGE) the obvious answer is to use the client IDs as the selectors. The problem is what are the selectors when the client IDs are not IP type IDs (i.e. UASER_FQDN). What we have done is assume that the client ID has been sent to assist in policy lookup and create the selector based on the IP address of the IKE peer as if the client IDs had not been sent at all. There is one exception to this... If the ID is of type FQDN, we first attempt to resolve this using DNS to determine the value for the selector. If we are unable to resolve the name, then we will use the IP address of the IKE peer. How have others handle this problem? Any information that can be provided would be greatly appreciated. Mike Williams From owner-ipsec@lists.tislabs.com Thu Aug 19 16:03:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA16480; Thu, 19 Aug 1999 16:03:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27911 Thu, 19 Aug 1999 17:27:05 -0400 (EDT) Message-Id: <199908192127.RAA18463@pasilla.bbnplanet.com> Subject: RFC 2459 To: ipsec@lists.tislabs.com Date: Thu, 19 Aug 1999 17:27:25 -0400 (EDT) From: "Matthew Fredette" 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@lists.tislabs.com Precedence: bulk My apologies if this is super-inappropriate for the list. (I know it is a little :). Has anyone taken a good look at Appendix D.3 of RFC 2459? If you have, did you find the certificate there to have many encoding errors? I did, but I'm brand-new to ASN.1 so I need a sanity-check. For example, around line 6980 there's an encoding of a SEQUENCE that is smaller than its parts: 0480 30 19 25: . . . . SEQUENCE 0482 06 03 3: . . . . . OID 2.5.29.32: certificatePolicies : 55 1d 20 0487 04 21 33: . . . . . OCTET STRING : 30 1f 30 1d 06 04 2a 84 80 00 30 15 30 07 06 05 : 2a 84 80 00 01 30 0a 06 05 2a 84 80 00 02 02 01 : 0a Matt -- Matt Fredette http://mit.edu/fredette/www fredette@bbnplanet.com, fredette@mit.edu, fredette@theory.lcs.mit.edu "[Peter] Banks' career waned after joining `Flash' in 1972 and recording three albums all called `Two Sides Of Peter Banks.'" From owner-ipsec@lists.tislabs.com Thu Aug 19 17:03:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA17411; Thu, 19 Aug 1999 17:03:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28250 Thu, 19 Aug 1999 18:46:35 -0400 (EDT) From: John Pliam Message-Id: <199908192247.RAA31947@red.ima.umn.edu> Subject: Weak authentication in Xauth and IKE To: ipsec@lists.tislabs.com Date: Thu, 19 Aug 1999 17:47:29 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL37 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have read the previous threads on Xauth (/hybrid) and IKE and while I think this horse has been well-flogged, for me it is not yet dead. The idea in the following article is that Xauth's laudable goal of strong authentication without user certificates is not quite achieved in its current draft. However, I think it can and should be extended to provide authentication which is neither "insecure" nor "superfluous". This is easily done... Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets John Pliam pliam@ima.umn.edu http://www.ima.umn.edu/~pliam Introduction ------------ IPSec demands strong authentication resistant to active attacks [MSST]. The primary purpose of strong authentication in IPSec is to ensure integrity in the key exchanges. It is well-known, for example, that unauthenticated Diffie-Hellman is vulnerable to a simple active attack (see [Stin], cf. [HAC]). However, without issuing public keys for every user (or some other elaborate key management system) the only available authentication mechanism in the Internet Key Exchange (IKE) [IKE] is the pre-shared key mechanism. Unfortunately, pre-shared secrets are often implemented as passwords and it is demonstrated below that IKE is vulnerable to offline dictionary attacks when weak passwords are used. Vendors have attempted to strengthen IPSec authentication with extensions to IKE or ISAKMP which support various unilateral authentication schemes such as username/password, token card, 1-time passwords or challenge-response (see [Mam], [OR] and [XAUTH]). In particular, Xauth has made its way into the IPSec working group. However, virtually all of these unilateral authentication protocols fall trivially to active attacks unless they are protected by a layer of strong encryption (reason: the attacker merely passes token-codes, passwords and correct responses along to the authenticating peer as if the attacker were their owner). There is clearly a nasty catch-22 here: We need strong authentication to establish a strong session key. We need a strong session key in order to protect unilateral authentication schemes and thereby provide strong authentication. Relying on weak phase 1 authentication followed by traditional unilateral schemes in Xauth (protected by suspect session keys derived in phase 1) must be considered a violation of ISAKMP [MSST]. In other words, Two weak authentications != A single strong authentication. On the other hand, Xauth provides the means to solve this dilemma: Public key schemes such as SSL and 1-way Diffie-Hellman (aka El Gamal key exchange) [HAC] provide both strong confidentiality and strong unilateral authentication of one peer (usually the edge device) with minimal key management. Remote users don't need their own public keys. If (strong) legacy unilateral authentication schemes anticipated in [XAUTH] were used *after* 1-way public-key protocols, then phase 2 would not proceed unless the remote peer were truly strongly authenticated. The remainder of this document presents further details. First we describe attacks which exploit the vulnerabilities of IKE with weak pre-shared secrets followed by Xauth. After that we propose a secure Xauth authentication mechanism which could be used to protect a weak phase 1 authentication. Discovering a Weak Pre-Shared Secret in IKE ------------------------------------------- The following attack works against both Main Mode and Aggressive Mode, but we present the details for Aggressive Mode only. Ignoring most of the irrelevant data, phase 1 establishes a session key k (aka SKEYID_e) between initiator I and responder R as follows: 1). I -> R: (CKYi, SAi, g^i, Ni, IDi), 2). R -> I: (CKYr, SAr, g^r, Nr, IDr, digr), 3). I -> R: (digi), where we employ the following notation: ------------------------------------------------------------------ I Symbol for initiator in the protocol. R Symbol for responder in the protocol. pw Shared secret. g^i Initiator's DH message: g multiplied with itself a random number i times. The number i is kept secret. g^r Initiator's DH message: g multiplied with itself a random number r times. The number r is kept secret. g^ir The DH negotiated secret = (g^i)^r = (g^r)^i. CKYi Initiator's randomly generated cookie from its ISAKMP header. CKYr Responder's randomly generated cookie from its ISAKMP header. SAi Various ISAKMP information. SAr Various ISAKMP information. Ni Initiator's nonce (randomly generated number). Nr Responder's nonce (randomly generated number). IDi Initiator's identification payload. IDr Responder's identification payload. f A pseudo-random function. s An intermediate secret, formed by s = f(pw, (Ni, Nr)). sd An intermediate secret, f(s, (g^ir, CKYi, CKYr, 0)). sa An intermediate secret, f(s, (sd, g^ir, CKYi, CKYr, 1)). digi Initiator's digest used to authenticate the DH exchange. It is formed by, digi = f(s, (g^i, g^r, CKYi, CKYr, SAi, IDi)). digr Responder's digest used to authenticate the DH exchange. It is formed by, digr = f(s, (g^r, g^i, CKYr, CKYi, SAr, IDr)). k Final session key, f(s, (sa, g^ir, CKYi, CKYr, 2)). ------------------------------------------------------------------ We claim that the initiator digest message digi contains enough information to rule out incorrectly guessed passwords. The adversary conducts an off-line dictionary attack, enumerating all candidates pw* and for each computing: s* = f(pw*, (Ni, Nr)), and digi* = f(s*, (g^i, g^r, CKYi, CKYr, SAi, IDi)). If digi = digi*, then with high probability pw = pw*. Notice that all candidate computations use data which was sent in the clear. An Active Attack Against IKE Phase 1 Key Exchange ------------------------------------------------- Armed with the shared secret pw, the adversary can now carry out an active attack against the phase 1 key exchange. Now acting as an intruder in the middle, M, the adversary manipulates the IKE messages as follows: 1). I -> M: (CKYi, SAi, g^i, Ni, IDi), M computes random secret q. 2). M -> R: (CKYi, SAi, g^q, Ni, IDi). 3). R -> M: (CKYr, SAr, g^r, Nr, IDr, digr), M computes digr'. 4). M -> I: (CKYr, SAr, g^q, Nr, IDr, digr'), I checks digr' and then computes k'. 5). I -> M: (digi) M computes digi'. 6). M -> R: (digi') R checks digi' and computes k'', where the following additional notation is used: ------------------------------------------------------------------ M Symbol for the intruder in the middle. g^q Adversary's public DH key. sd' Forged intermediate secret during active phase: f(s, (g^rq, CKYi, CKYr, 0)). sd'' Forged intermediate secret during active phase: f(s, (g^iq, CKYi, CKYr, 0)). sa' Another forged secret: f(s, (sd', g^rq, CKYi, CKYr, 1)). sa'' Another forged secret: f(s, (sd'', g^iq, CKYi, CKYr, 1)). digi' Forged Initiator digest: digi' = f(s, (g^q, g^r, CKYi, CKYr, SAi, IDi)). digr' Forged Responder digest: digr' = f(s, (g^q, g^i, CKYr, CKYi, SAr, IDr)). k' Forged final session key: f(s, (sa', g^rq, CKYi, CKYr, 2)). k'' Forged final session key: f(s, (sa'', g^iq, CKYi, CKYr, 2)). ------------------------------------------------------------------ Aside from the digest forgeries, this is nothing but the standard active attack against Diffie-Hellman [Stin], after which I and M share secret g^iq and M and R share secret g^qr. Both established session keys k' and k'' are known to the adversary, and M can simulate an encrypted tunnel between I and R by repeated decryption and re-encryption. Notice that the two forged digests appear to be legitimate because the arguments used to compute them are correct as far as the legal parties I and R are concerned. Thwarting Xauth after IKE is Defeated ------------------------------------- If the adversary has defeated IKE and established mutual session keys k' and k'', unilateral authentication systems provide little protection. For a challenge-response authentication, the Xauth protocol is defeated as follows: 7). R -> M: ({challenge}_k'), M decrypts with k' and re-encrypts with k''. 8). M -> I: ({challenge}_k''). 9). I -> M: ({response}_k''), M decrypts with k'' and re-encrypts with k'. 10). M -> R: ({response}_k'). 11). I <-> M <-> R: exchange (ok) and (ack). After M presents the correct response, phase 2 begins between the adversary and the edge device. Protecting Unilateral Authentication with 1-Way Public Keys ----------------------------------------------------------- Assuming that the edge device R has a public key p which is signed by a trusted authority, I and R can engage in the following more elaborate Xauth protocol between phase 1 and phase 2: 1). R -> I: (cert = {p}_trusted-CA, challenge), I verifies p and generates random K. 2). I -> R: ({K}_p, {digi, response}_K), R decrypts K with p and checks both digi and response. 3). I <-> R: (ok) and (ack). Since only I and R know the value of K, the phase 1 digest is finally authenticated strongly, and phase 2 may securely proceed. Conclusion ---------- We recommend that the "Security Consideration" section of [IKE] include an explicit warning of the vulnerability when weak pre-shared secret authentication is used -- as in done in RFC 2288 [SKEY]. Xauth's goal of strong authentication without elaborate key management is easily achieved by minor additions to the Xauth functionality (which provide for checking digi as above). Our suggested solution is similar to the hybrid authentication described in [Hyb], but that document doesn't clearly indicate the need for confidentiality in the Xauth exchanges. References ---------- [HAC] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of Applied Cryptography", CRC Press, 1997. [Hyb] M. Litvin, R. Shamir, T. Zegman, "A Hybrid Authentication Mode for IKE", draft-ietf-ipsec-isakmp-hybrid-auth-02.txt, 1999. [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [Mam] Mamros, S., "Pre-shared key extensions for ISAKMP/OAKLEY", draft-mamros-pskeyext-00.txt, November 1997. [MSST] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [OR] J. O'Hara, M. Rosselli, "Token Card Extensions for ISAKMP/OAKLEY" Internet Draft: draft-ohara-tokencard-00.txt, 1997. [SKEY] N. Haller, et al., "A One-Time Password System", RFC 2289, 1998. [Sti] D. Stinson, Cryptography: Theory and Practice, CRC Press, 1995. [XAUTH] R. Pereira, S. Beaulieu, "Extended Authentication within ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-04.txt, 1999. From owner-ipsec@lists.tislabs.com Thu Aug 19 21:13:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id VAA06761; Thu, 19 Aug 1999 21:13:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA28758 Thu, 19 Aug 1999 22:41:18 -0400 (EDT) Date: Fri, 20 Aug 1999 10:37:40 +0800 (SGT) From: Jianying Zhou X-Sender: jyzhou@arizona To: John Pliam cc: ipsec@lists.tislabs.com Subject: Re: Weak authentication in Xauth and IKE In-Reply-To: <199908192247.RAA31947@red.ima.umn.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The attack can only be applied to the aggressive mode, not the main mode. In the main mode, digi, IDi and digr, IDr are encrypted with se (not listed in your notation). Hence, the off-line directory attack to the main mode is impossible. Jianying --------------------------------------------------------------------- Dr. Jianying Zhou | Tel: +65-8742585 Kent Ridge Digital Labs | Fax: +65-7744990 21 Heng Mui Keng Terrace | Email: jyzhou@krdl.org.sg Singapore 119613 | --------------------------------------------------------------------- On Thu, 19 Aug 1999, John Pliam wrote: > I have read the previous threads on Xauth (/hybrid) and IKE and while I > think this horse has been well-flogged, for me it is not yet dead. The > idea in the following article is that Xauth's laudable goal of strong > authentication without user certificates is not quite achieved in its > current draft. However, I think it can and should be extended to provide > authentication which is neither "insecure" nor "superfluous". This is > easily done... > > Authentication Vulnerabilities in IKE and Xauth with > Weak Pre-Shared Secrets > > > John Pliam > pliam@ima.umn.edu > http://www.ima.umn.edu/~pliam > > > Introduction > ------------ > > IPSec demands strong authentication resistant to active attacks [MSST]. > The primary purpose of strong authentication in IPSec is to ensure > integrity in the key exchanges. It is well-known, for example, that > unauthenticated Diffie-Hellman is vulnerable to a simple active attack (see > [Stin], cf. [HAC]). > > However, without issuing public keys for every user (or some other > elaborate key management system) the only available authentication > mechanism in the Internet Key Exchange (IKE) [IKE] is the pre-shared key > mechanism. Unfortunately, pre-shared secrets are often implemented as > passwords and it is demonstrated below that IKE is vulnerable to offline > dictionary attacks when weak passwords are used. > > Vendors have attempted to strengthen IPSec authentication with extensions > to IKE or ISAKMP which support various unilateral authentication schemes > such as username/password, token card, 1-time passwords or > challenge-response (see [Mam], [OR] and [XAUTH]). In particular, Xauth has > made its way into the IPSec working group. However, virtually all of these > unilateral authentication protocols fall trivially to active attacks unless > they are protected by a layer of strong encryption (reason: the attacker > merely passes token-codes, passwords and correct responses along to the > authenticating peer as if the attacker were their owner). > > There is clearly a nasty catch-22 here: We need strong authentication to > establish a strong session key. We need a strong session key in order to > protect unilateral authentication schemes and thereby provide strong > authentication. Relying on weak phase 1 authentication followed by > traditional unilateral schemes in Xauth (protected by suspect > session keys derived in phase 1) must be considered a violation of > ISAKMP [MSST]. In other words, > > Two weak authentications != A single strong authentication. > > > On the other hand, Xauth provides the means to solve this dilemma: Public > key schemes such as SSL and 1-way Diffie-Hellman (aka El Gamal key > exchange) [HAC] provide both strong confidentiality and strong unilateral > authentication of one peer (usually the edge device) with minimal key > management. Remote users don't need their own public keys. If (strong) > legacy unilateral authentication schemes anticipated in [XAUTH] were used > *after* 1-way public-key protocols, then phase 2 would not proceed unless > the remote peer were truly strongly authenticated. > > The remainder of this document presents further details. First we describe > attacks which exploit the vulnerabilities of IKE with weak pre-shared > secrets followed by Xauth. After that we propose a secure Xauth > authentication mechanism which could be used to protect a weak phase 1 > authentication. > > > Discovering a Weak Pre-Shared Secret in IKE > ------------------------------------------- > > The following attack works against both Main Mode and Aggressive Mode, but > we present the details for Aggressive Mode only. Ignoring most of the > irrelevant data, phase 1 establishes a session key k (aka SKEYID_e) between > initiator I and responder R as follows: > > 1). I -> R: (CKYi, SAi, g^i, Ni, IDi), > > 2). R -> I: (CKYr, SAr, g^r, Nr, IDr, digr), > > 3). I -> R: (digi), > > where we employ the following notation: > > ------------------------------------------------------------------ > I Symbol for initiator in the protocol. > > R Symbol for responder in the protocol. > > pw Shared secret. > > g^i Initiator's DH message: g multiplied with itself a random > number i times. The number i is kept secret. > > g^r Initiator's DH message: g multiplied with itself a random > number r times. The number r is kept secret. > > g^ir The DH negotiated secret = (g^i)^r = (g^r)^i. > > CKYi Initiator's randomly generated cookie from its ISAKMP header. > > CKYr Responder's randomly generated cookie from its ISAKMP header. > > SAi Various ISAKMP information. > > SAr Various ISAKMP information. > > Ni Initiator's nonce (randomly generated number). > > Nr Responder's nonce (randomly generated number). > > IDi Initiator's identification payload. > > IDr Responder's identification payload. > > f A pseudo-random function. > > s An intermediate secret, formed by s = f(pw, (Ni, Nr)). > > sd An intermediate secret, f(s, (g^ir, CKYi, CKYr, 0)). > > sa An intermediate secret, f(s, (sd, g^ir, CKYi, CKYr, 1)). > > digi Initiator's digest used to authenticate the DH exchange. It > is formed by, > digi = f(s, (g^i, g^r, CKYi, CKYr, SAi, IDi)). > > digr Responder's digest used to authenticate the DH exchange. It > is formed by, > digr = f(s, (g^r, g^i, CKYr, CKYi, SAr, IDr)). > > k Final session key, f(s, (sa, g^ir, CKYi, CKYr, 2)). > ------------------------------------------------------------------ > > We claim that the initiator digest message digi contains enough information > to rule out incorrectly guessed passwords. The adversary conducts an > off-line dictionary attack, enumerating all candidates pw* and for each > computing: > > s* = f(pw*, (Ni, Nr)), > and > digi* = f(s*, (g^i, g^r, CKYi, CKYr, SAi, IDi)). > > If digi = digi*, then with high probability pw = pw*. Notice that > all candidate computations use data which was sent in the clear. > > > An Active Attack Against IKE Phase 1 Key Exchange > ------------------------------------------------- > > Armed with the shared secret pw, the adversary can now carry out an active > attack against the phase 1 key exchange. Now acting as an intruder in the > middle, M, the adversary manipulates the IKE messages as follows: > > 1). I -> M: (CKYi, SAi, g^i, Ni, IDi), > M computes random secret q. > > 2). M -> R: (CKYi, SAi, g^q, Ni, IDi). > > 3). R -> M: (CKYr, SAr, g^r, Nr, IDr, digr), > M computes digr'. > > 4). M -> I: (CKYr, SAr, g^q, Nr, IDr, digr'), > I checks digr' and then computes k'. > > 5). I -> M: (digi) > M computes digi'. > > 6). M -> R: (digi') > R checks digi' and computes k'', > > where the following additional notation is used: > > ------------------------------------------------------------------ > M Symbol for the intruder in the middle. > > g^q Adversary's public DH key. > > sd' Forged intermediate secret during active phase: > f(s, (g^rq, CKYi, CKYr, 0)). > > sd'' Forged intermediate secret during active phase: > f(s, (g^iq, CKYi, CKYr, 0)). > > sa' Another forged secret: f(s, (sd', g^rq, CKYi, CKYr, 1)). > > sa'' Another forged secret: f(s, (sd'', g^iq, CKYi, CKYr, 1)). > > digi' Forged Initiator digest: > digi' = f(s, (g^q, g^r, CKYi, CKYr, SAi, IDi)). > > digr' Forged Responder digest: > digr' = f(s, (g^q, g^i, CKYr, CKYi, SAr, IDr)). > > k' Forged final session key: > f(s, (sa', g^rq, CKYi, CKYr, 2)). > > k'' Forged final session key: > f(s, (sa'', g^iq, CKYi, CKYr, 2)). > ------------------------------------------------------------------ > > Aside from the digest forgeries, this is nothing but the standard active > attack against Diffie-Hellman [Stin], after which I and M share secret g^iq > and M and R share secret g^qr. Both established session keys k' and k'' > are known to the adversary, and M can simulate an encrypted tunnel between > I and R by repeated decryption and re-encryption. Notice that the two > forged digests appear to be legitimate because the arguments used to > compute them are correct as far as the legal parties I and R are > concerned. > > > Thwarting Xauth after IKE is Defeated > ------------------------------------- > > If the adversary has defeated IKE and established mutual session keys k' > and k'', unilateral authentication systems provide little protection. For > a challenge-response authentication, the Xauth protocol is defeated as > follows: > > > 7). R -> M: ({challenge}_k'), > M decrypts with k' and re-encrypts with k''. > > 8). M -> I: ({challenge}_k''). > > 9). I -> M: ({response}_k''), > M decrypts with k'' and re-encrypts with k'. > > 10). M -> R: ({response}_k'). > > 11). I <-> M <-> R: exchange (ok) and (ack). > > After M presents the correct response, phase 2 begins between > the adversary and the edge device. > > > Protecting Unilateral Authentication with 1-Way Public Keys > ----------------------------------------------------------- > > Assuming that the edge device R has a public key p which is signed > by a trusted authority, I and R can engage in the following > more elaborate Xauth protocol between phase 1 and phase 2: > > 1). R -> I: (cert = {p}_trusted-CA, challenge), > I verifies p and generates random K. > > 2). I -> R: ({K}_p, {digi, response}_K), > R decrypts K with p and checks both digi and response. > > 3). I <-> R: (ok) and (ack). > > Since only I and R know the value of K, the phase 1 digest is > finally authenticated strongly, and phase 2 may securely proceed. > > Conclusion > ---------- > > We recommend that the "Security Consideration" section of [IKE] > include an explicit warning of the vulnerability when weak pre-shared > secret authentication is used -- as in done in RFC 2288 [SKEY]. > Xauth's goal of strong authentication without elaborate key > management is easily achieved by minor additions to the Xauth > functionality (which provide for checking digi as above). > > Our suggested solution is similar to the hybrid authentication > described in [Hyb], but that document doesn't clearly indicate > the need for confidentiality in the Xauth exchanges. > > > References > ---------- > > [HAC] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of Applied > Cryptography", CRC Press, 1997. > > [Hyb] M. Litvin, R. Shamir, T. Zegman, "A Hybrid Authentication Mode for > IKE", draft-ietf-ipsec-isakmp-hybrid-auth-02.txt, 1999. > > [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange > (IKE)", RFC 2409, November 1998. > > [Mam] Mamros, S., "Pre-shared key extensions for ISAKMP/OAKLEY", > draft-mamros-pskeyext-00.txt, November 1997. > > [MSST] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, > "Internet Security Association and Key Management Protocol > (ISAKMP)", RFC 2408, November 1998. > > [OR] J. O'Hara, M. Rosselli, "Token Card Extensions for ISAKMP/OAKLEY" > Internet Draft: draft-ohara-tokencard-00.txt, 1997. > > [SKEY] N. Haller, et al., "A One-Time Password System", RFC 2289, > 1998. > > [Sti] D. Stinson, Cryptography: Theory and Practice, CRC Press, > 1995. > > [XAUTH] R. Pereira, S. Beaulieu, "Extended Authentication within > ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-04.txt, 1999. > > From owner-ipsec@lists.tislabs.com Thu Aug 19 22:43:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA08441; Thu, 19 Aug 1999 22:43:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA29016 Fri, 20 Aug 1999 00:22:25 -0400 (EDT) Message-ID: <37BCD32A.3B3A9F2@ima.umn.edu> Date: Fri, 20 Aug 1999 04:01:47 +0000 From: John Pliam X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i586) X-Accept-Language: en MIME-Version: 1.0 To: Jianying Zhou CC: ipsec@lists.tislabs.com Subject: Re: Weak authentication in Xauth and IKE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jianying Zhou wrote: > The attack can only be applied to the aggressive mode, not the main mode. > In the main mode, digi, IDi and digr, IDr are encrypted with se (not > listed in your notation). Hence, the off-line directory attack to the > main mode is impossible. I disagree. I didn't mean to imply that the attack I presented for Aggressive Mode would apply verbatim to Main Mode, but rather mutatis mutandis (whatever that means :-). I'll give the painful details. Given my notation, Main Mode amounts to: 1). I -> R: (CKYi, SAi), 2). R -> I: (CKYr, SAr), 3). I -> R: (g^i, Ni), 4). R -> I: (g^r, Nr), 5). I -> R: {(IDi, digi)}_k, 6). R -> I: {(IDr, digr)}_k. Again digi would contain all we need for a dictionary attack if we could decrypt it. So the obvious thing to do is to actively force the secret used to encrypt digi to be common to I and adversary M. That is accomplished as follows: 1). I -> M -> R: (CKYi, SAi), 2). R -> M -> I: (CKYr, SAr), 3). I -> M -> R: (g^i, Ni), 4). R -> M: (g^r, Nr), 5). M -> I: (g^q, Nr), I computes: * shared secret g^iq, * sd = f(s, (g^iq, CKYi, CKYr, 0)), * sa = f(s, (sd, g^iq, CKYi, CKYr, 1)), * digi = f(s, (g^q, g^i, CKYi, CKYr, SAi, IDi)), * k = f(s, (sa, g^iq, CKYi, CKYr, 2)). 6). I -> R: {(IDi, digi)}_k, 7). M causes session failure through denial of service. After the adversary computes k (knowing everything) she decrypts digi and again conducts an off-line dictionary attack. For all candidate passwords pw*, she computes: s* = f(pw*, (Ni, Nr)), and digi* = f(s*, (g^i, g^q, CKYi, CKYr, SAi, IDi)). If digi = digi*, then with high probability pw = pw*. The only difference is that we must now bring in part of the active attack early. Note: There is also a way to do this without being detected. If the active attack against Diffie-Hellman described in [HAC] is used during phase 1, the adversary can conduct an brute-force search for pw and k together... Cheers, John From owner-ipsec@lists.tislabs.com Thu Aug 19 22:54:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA08749; Thu, 19 Aug 1999 22:54:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA29078 Fri, 20 Aug 1999 00:44:55 -0400 (EDT) Date: Fri, 20 Aug 1999 12:41:58 +0800 (SGT) From: Jianying Zhou X-Sender: jyzhou@arizona To: John Pliam cc: ipsec@lists.tislabs.com Subject: Re: Weak authentication in Xauth and IKE In-Reply-To: <37BCD32A.3B3A9F2@ima.umn.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 20 Aug 1999, John Pliam wrote: > Jianying Zhou wrote: > > > The attack can only be applied to the aggressive mode, not the main mode. > > In the main mode, digi, IDi and digr, IDr are encrypted with se (not > > listed in your notation). Hence, the off-line directory attack to the > > main mode is impossible. > > I disagree. I didn't mean to imply that the attack I presented > for Aggressive Mode would apply verbatim to Main Mode, but > rather mutatis mutandis (whatever that means :-). I'll give > the painful details. Given my notation, Main Mode amounts to: > > 1). I -> R: (CKYi, SAi), > > 2). R -> I: (CKYr, SAr), > > 3). I -> R: (g^i, Ni), > > 4). R -> I: (g^r, Nr), > > 5). I -> R: {(IDi, digi)}_k, > > 6). R -> I: {(IDr, digr)}_k. > > Again digi would contain all we need for a dictionary attack if > we could decrypt it. So the obvious thing to do is to actively > force the secret used to encrypt digi to be common to I and > adversary M. That is accomplished as follows: > > 1). I -> M -> R: (CKYi, SAi), > > 2). R -> M -> I: (CKYr, SAr), > > 3). I -> M -> R: (g^i, Ni), > > 4). R -> M: (g^r, Nr), > > 5). M -> I: (g^q, Nr), > I computes: > * shared secret g^iq, > * sd = f(s, (g^iq, CKYi, CKYr, 0)), > * sa = f(s, (sd, g^iq, CKYi, CKYr, 1)), > * digi = f(s, (g^q, g^i, CKYi, CKYr, SAi, IDi)), > * k = f(s, (sa, g^iq, CKYi, CKYr, 2)). > > 6). I -> R: {(IDi, digi)}_k, > > 7). M causes session failure through denial of service. > > After the adversary computes k (knowing everything) she decrypts How does the adversary know everything to computer k ??? The initiator uses the pw shared with R (not M) to compute s and derive k. Does the adversary know pw in advance? > digi and again conducts an off-line dictionary attack. For all > candidate passwords pw*, she computes: > > s* = f(pw*, (Ni, Nr)), > and > digi* = f(s*, (g^i, g^q, CKYi, CKYr, SAi, IDi)). > > If digi = digi*, then with high probability pw = pw*. The only > difference is that we must now bring in part of the active > attack early. > > Note: There is also a way to do this without being detected. > If the active attack against Diffie-Hellman described in [HAC] > is used during phase 1, the adversary can conduct an > brute-force search for pw and k together... > > Cheers, > > John > > > From owner-ipsec@lists.tislabs.com Fri Aug 20 03:31:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA16184; Fri, 20 Aug 1999 03:31:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA29965 Fri, 20 Aug 1999 05:07:29 -0400 (EDT) Message-Id: <3.0.5.32.19990820102206.00be0e60@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 20 Aug 1999 10:22:06 +0300 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Non-IP type Client IDs In-Reply-To: <37BC5FBF.4CA45E41@ibm.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id FAA29962 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The use of Phase 2 IDs is indeed a bit unclear and implementations use them differently. In my opinion, phase 2 IDs should be limited to the IP address types: IPSEC_ID_IPV4_ADDR = 1, IPSEC_ID_IPV4_ADDR_SUBNET = 4, IPSEC_ID_IPV6_ADDR = 5, IPSEC_ID_IPV6_ADDR_SUBNET = 6, IPSEC_ID_IPV4_ADDR_RANGE = 7, IPSEC_ID_IPV6_ADDR_RANGE = 8, If you are a mobile user, you send your current IP address as IDci. The gateway has to remember the source address of the ISAKMP packets and compares that with IDci. If they match, the SA is allowed. Problem remains, what to do with NAT between two IPsec hosts. Now the IDci and the source IP address of ISAKMP packets never match. Using USER_FQDN would indeed solve this, but I'd rather assign a fixed private IP address for the client, so the IDci is always 192.168.7.9, no matter from where he dials in. Or use cfg-mode. Jörn From owner-ipsec@lists.tislabs.com Fri Aug 20 07:09:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA27859; Fri, 20 Aug 1999 07:09:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00710 Fri, 20 Aug 1999 08:37:50 -0400 (EDT) Message-ID: <37BD4D00.702D4206@ibm.net> Date: Fri, 20 Aug 1999 08:41:36 -0400 From: Mike Williams X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Joern Sierwald CC: ipsec@lists.tislabs.com Subject: Re: Non-IP type Client IDs References: <3.0.5.32.19990820102206.00be0e60@smtp.datafellows.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk See my comments below. Mike Williams IBM Corporation Joern Sierwald wrote: > The use of Phase 2 IDs is indeed a bit unclear and implementations > use them differently. > > In my opinion, phase 2 IDs should be limited to the IP address types: > IPSEC_ID_IPV4_ADDR = 1, > IPSEC_ID_IPV4_ADDR_SUBNET = 4, > IPSEC_ID_IPV6_ADDR = 5, > IPSEC_ID_IPV6_ADDR_SUBNET = 6, > IPSEC_ID_IPV4_ADDR_RANGE = 7, > IPSEC_ID_IPV6_ADDR_RANGE = 8, > > If you are a mobile user, you send your current IP address as IDci. > The gateway has to remember the source address of the ISAKMP packets > and compares that with IDci. If they match, the SA is allowed. > I don't believe that this is a valid check. The responder in this case has no way of knowing that the initiator is a client. Making this check would prevent the initiator from ever being a gateway. It is valid for IDci to be different than the IP address of the initiating IKE system when the initiator is a gateway. > > Problem remains, what to do with NAT between two IPsec hosts. > Now the IDci and the source IP address of ISAKMP packets never > match. Using USER_FQDN would indeed solve this, but I'd rather > assign a fixed private IP address for the client, so the IDci > is always 192.168.7.9, no matter from where he dials in. > Or use cfg-mode. > Without using something like USER_FQDN or KEYID, how can you have different phase 2 policies for different remote users. I also believe that there are many cases when you will not be able to assign a fixed private IP address to the client. Config Mode does help, but I don't know why we should preclude other options. > > Jörn From owner-ipsec@lists.tislabs.com Fri Aug 20 07:58:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA29793; Fri, 20 Aug 1999 07:58:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01002 Fri, 20 Aug 1999 09:27:48 -0400 (EDT) Message-ID: <007501beeaf3$ddae6920$0201a8c0@nec.oleane.com> From: "Peter lewis" To: Subject: From firewall to IPSec VPNs Date: Fri, 20 Aug 1999 12:07:52 +0200 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.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Security services and protection mechanisms IPv6 promises regarding IPSec Certification infrastructure Standardization update Case Studies: ISPs, carriers, private networks AH and ESP protocols description Possible future extensions and modifications of the IKE protocol Complementarity between IPSec and firewalls Global Site-to-Site IPSec VPN's with End-to-End SLA's Managing widespread IPSEC virtual private networks Solving IPSec VPNs scalability Results of some interoperability tests IPSec architectures and non-standardized aspects of IPSec Adding IPSec VPN functions in an existing router network Impact of fragmentation on the performance of IPSec coding IPSEC 99 Conference >From Firewall to IPSec VPNs October 26, 27, 28, 29, 1999 Paris - France More infos: www.upperside.fr/baipsec.htm Sorry to post this message on the list. Thanks From owner-ipsec@lists.tislabs.com Fri Aug 20 08:46:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA00934; Fri, 20 Aug 1999 08:46:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01173 Fri, 20 Aug 1999 10:08:41 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05D131@md-exchange1.nai.com> From: "Mason, David" To: "'Mike Williams'" , Joern Sierwald Cc: ipsec@lists.tislabs.com Subject: RE: Non-IP type Client IDs Date: Fri, 20 Aug 1999 07:04:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [snip] >Without using something like USER_FQDN or KEYID, how can you have >different phase 2 policies for different remote users. I also believe >that there are many cases when you will not be able to assign a fixed >private IP address to the client. Config Mode does help, but I don't >know why we should preclude other options. The certificate used in phase 1 differentiates between remote users. If you're relying on a USER_FQDN in phase 2 to determine policy such that user1@xxx.com is allowed access to all machines behind the gateway and user2@yyy.com is only allowed access to a subset of machines, user2@yyy.com will just stick user1@xxx.com in its phase 2 ID. I'd prefer to restrict phase 2 IDs to IP addresses. The certificate is the identity of the remote peer, duplicating this identity in various parts of the exchange(s) is redundant and unnecessary. -dave From owner-ipsec@lists.tislabs.com Fri Aug 20 09:18:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA01523; Fri, 20 Aug 1999 09:18:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01274 Fri, 20 Aug 1999 10:41:23 -0400 (EDT) Message-ID: <37BD69EF.497CE861@ibm.net> Date: Fri, 20 Aug 1999 10:45:03 -0400 From: Mike Williams X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Mason, David" CC: Joern Sierwald , ipsec@lists.tislabs.com Subject: Re: Non-IP type Client IDs References: <447A3F40A07FD211BA2700A0C99D759B05D131@md-exchange1.nai.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You have mentioned the two alternatives that need to be handled. The first alternative is that the initiating system sends the USER_FQDN as IDci in quick mode. This allows the gateway to lookup policy based on client IDs, however the gateway must then assume that the selectors to use in IPSec are the initiators IP Address (rather than IDci) and IDcr. The second alternative is that the initiator send it's dynamically assigned IP address in IDci. In this case, the assumption is that IDii used in phase 1 will be something like USER_FQDN or KEYID and IDii together with IDcr can be used to lookup phase 2 policy. In this case, the selector values used by IPSec will be IDci and IDcr directly. We have decided that we need to be able to handle either of these situations, however we have seen that some implementation will not support the first. What I am trying to understand is whether or not both are allowed. From reading the RFCs, I believe they are. Mike "Mason, David" wrote: > [snip] > > >Without using something like USER_FQDN or KEYID, how can you have > >different phase 2 policies for different remote users. I also believe > >that there are many cases when you will not be able to assign a fixed > >private IP address to the client. Config Mode does help, but I don't > >know why we should preclude other options. > > The certificate used in phase 1 differentiates between remote users. > If you're relying on a USER_FQDN in phase 2 to determine policy such > that user1@xxx.com is allowed access to all machines behind the gateway > and user2@yyy.com is only allowed access to a subset of machines, > user2@yyy.com will just stick user1@xxx.com in its phase 2 ID. I'd > prefer to restrict phase 2 IDs to IP addresses. The certificate is > the identity of the remote peer, duplicating this identity in various > parts of the exchange(s) is redundant and unnecessary. > > -dave From owner-ipsec@lists.tislabs.com Fri Aug 20 09:19:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA01544; Fri, 20 Aug 1999 09:19:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01307 Fri, 20 Aug 1999 10:50:26 -0400 (EDT) Message-Id: <3.0.5.32.19990820175149.00b571c0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 20 Aug 1999 17:51:49 +0300 To: Mike Williams From: Joern Sierwald Subject: Re: Non-IP type Client IDs Cc: ipsec@lists.tislabs.com In-Reply-To: <37BD4D00.702D4206@ibm.net> References: <3.0.5.32.19990820102206.00be0e60@smtp.datafellows.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA01304 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 08:41 20.8.1999 -0400, Mike Williams wrote: >See my comments below. > >Mike Williams >IBM Corporation > > >Joern Sierwald wrote: > >> The use of Phase 2 IDs is indeed a bit unclear and implementations >> use them differently. >> >> In my opinion, phase 2 IDs should be limited to the IP address types: >> IPSEC_ID_IPV4_ADDR = 1, >> IPSEC_ID_IPV4_ADDR_SUBNET = 4, >> IPSEC_ID_IPV6_ADDR = 5, >> IPSEC_ID_IPV6_ADDR_SUBNET = 6, >> IPSEC_ID_IPV4_ADDR_RANGE = 7, >> IPSEC_ID_IPV6_ADDR_RANGE = 8, >> >> If you are a mobile user, you send your current IP address as IDci. >> The gateway has to remember the source address of the ISAKMP packets >> and compares that with IDci. If they match, the SA is allowed. >> > >I don't believe that this is a valid check. The responder in this case >has no way of knowing that the initiator is a client. Why not? Phase 1 is finished. You have the phase 1 ID, which is USER@FQDN or ASN1_DN. >Making this check >would prevent the initiator from ever being a gateway. Yes. That's the point. You don't want mobile users to be gateways. >It is valid for >IDci to be different than the IP address of the initiating IKE system >when the initiator is a gateway. Well, sure. Your GW policy says "remote ID (phase 1) 100.100.100.100 is a gateway, the LAN behind it is 100.100.101.0/24" and "remote ID me@somewhere is a client". I perform the abovementioned "ISAKMP IP address == IDci" test only for the client, right? 100.100.100.100 will send a subset of 100.100.101.0/24 as IDci. > >> >> Problem remains, what to do with NAT between two IPsec hosts. >> Now the IDci and the source IP address of ISAKMP packets never >> match. Using USER_FQDN would indeed solve this, but I'd rather >> assign a fixed private IP address for the client, so the IDci >> is always 192.168.7.9, no matter from where he dials in. >> Or use cfg-mode. >> > >Without using something like USER_FQDN or KEYID, how can you have >different phase 2 policies for different remote users. For mobile users, I use USER@FQDN or ASN1_DN in phase 1 with aggressive mode. >I also believe >that there are many cases when you will not be able to assign a fixed >private IP address to the client. Config Mode does help, but I don't >know why we should preclude other options. Well, I don't recommend cfg-mode, you can usually live without it. Jörn From owner-ipsec@lists.tislabs.com Fri Aug 20 09:58:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA01942; Fri, 20 Aug 1999 09:58:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01447 Fri, 20 Aug 1999 11:21:24 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05D133@md-exchange1.nai.com> From: "Mason, David" To: "'Mike Williams'" Cc: ipsec@lists.tislabs.com Subject: RE: Non-IP type Client IDs Date: Fri, 20 Aug 1999 08:17:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No. What I was saying is that I'd prefer that the phase 2 IDs be the IP addresses used in packets within the IPSEC tunnel. Policy lookup should be done based upon the identity of the peer (her certificate) and these IP addresses. Duplicating part of the certificate in the phase 1 ID payload simplifies policy lookup for some implementations and also allows retrieval of the peers certificate via some non-IKE method. In the case of doing policy lookup based upon the ID contents, the ID contents MUST be verified against the certificate. Since by phase 2 you have already obtained the peers certificate (within an IKE phase 1 exchange or by some other means), you know the identity of the peer and there is no benefit that I can see for duplicating part of the certificate in the phase 2 ID. I don't see the benefit of your alternative 1. 1) What does it provide that alternative 2 doesn't? 2) How do you verify IDci for alternative 1? 3) Why would IDii not also be USER_FQDN for alternative 1 and what would be the benefit of having IDii different than IRci for alternative 1? -dave -----Original Message----- From: Mike Williams [mailto:mikewill@ibm.net] Sent: Friday, August 20, 1999 10:45 AM To: Mason, David Cc: Joern Sierwald; ipsec@lists.tislabs.com Subject: Re: Non-IP type Client IDs You have mentioned the two alternatives that need to be handled. The first alternative is that the initiating system sends the USER_FQDN as IDci in quick mode. This allows the gateway to lookup policy based on client IDs, however the gateway must then assume that the selectors to use in IPSec are the initiators IP Address (rather than IDci) and IDcr. The second alternative is that the initiator send it's dynamically assigned IP address in IDci. In this case, the assumption is that IDii used in phase 1 will be something like USER_FQDN or KEYID and IDii together with IDcr can be used to lookup phase 2 policy. In this case, the selector values used by IPSec will be IDci and IDcr directly. We have decided that we need to be able to handle either of these situations, however we have seen that some implementation will not support the first. What I am trying to understand is whether or not both are allowed. From reading the RFCs, I believe they are. Mike "Mason, David" wrote: > [snip] > > >Without using something like USER_FQDN or KEYID, how can you have > >different phase 2 policies for different remote users. I also believe > >that there are many cases when you will not be able to assign a fixed > >private IP address to the client. Config Mode does help, but I don't > >know why we should preclude other options. > > The certificate used in phase 1 differentiates between remote users. > If you're relying on a USER_FQDN in phase 2 to determine policy such > that user1@xxx.com is allowed access to all machines behind the gateway > and user2@yyy.com is only allowed access to a subset of machines, > user2@yyy.com will just stick user1@xxx.com in its phase 2 ID. I'd > prefer to restrict phase 2 IDs to IP addresses. The certificate is > the identity of the remote peer, duplicating this identity in various > parts of the exchange(s) is redundant and unnecessary. > > -dave From owner-ipsec@lists.tislabs.com Fri Aug 20 10:12:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA02096; Fri, 20 Aug 1999 10:12:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01490 Fri, 20 Aug 1999 11:31:48 -0400 (EDT) Message-Id: <3.0.32.19990820111358.00a77cb0@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Aug 1999 11:13:59 -0400 To: Mike Williams From: Shawn Mamros Subject: Re: Non-IP type Client IDs Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >The first alternative is that the initiating system sends the USER_FQDN as >IDci in quick mode. This allows the gateway to lookup policy based on >client IDs, however the gateway must then assume that the selectors to use >in IPSec are the initiators IP Address (rather than IDci) and IDcr. But in that "first alternative", what is being used for IDii in Phase 1? If you're really authenticating the user, it MUST be the same as what you propose to use as IDci, or else something that maps one-for-one to that user. Otherwise, you're not authenticating the user at all, as the authentication that is taking place isn't based on any user credentials, but rather on the credentials for IDii, whatever that may be. You would then be implicitly trusting IDii to act as a "proxy" for that user somehow. Is that really what you want to do? -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Fri Aug 20 10:38:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA02485; Fri, 20 Aug 1999 10:38:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01619 Fri, 20 Aug 1999 12:08:25 -0400 (EDT) Message-ID: <37BD78A2.53B6CC01@ima.umn.edu> Date: Fri, 20 Aug 1999 15:47:46 +0000 From: John Pliam X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i586) X-Accept-Language: en MIME-Version: 1.0 To: Jianying Zhou CC: ipsec@lists.tislabs.com Subject: Re: Weak authentication in Xauth and IKE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 20 Aug 1999, John Pliam wrote: > Jianying Zhou wrote: > > How does the adversary know everything to computer k ??? > The initiator uses the pw shared with R (not M) to compute s > and derive k. Does the adversary know pw in advance? Ha ... very good point! Thanks. :-) I need to be more careful here... Consider the same eavesdropping attack: 1). I -> M -> R: (CKYi, SAi), 2). R -> M -> I: (CKYr, SAr), 3). I -> M -> R: (g^i, Ni), 4). R -> M: (g^r, Nr), 5). M -> I: (g^q, Nr), I computes: * shared secret g^iq, * sd = f(s, (g^iq, CKYi, CKYr, 0)), * sa = f(s, (sd, g^iq, CKYi, CKYr, 1)), * digi = f(s, (g^q, g^i, CKYi, CKYr, SAi, IDi)), * k = f(s, (sa, g^iq, CKYi, CKYr, 2)). 6). I -> R: {(IDi, digi)}_k, Now, we must modify the dictionary computations, using trial keys k* computed from trial passwords pw*. For each pw* in Dict do s* = f(pw*, (Ni, Nr)). sd* = f(s*, (g^iq, CKYi, CKYr, 0)). sa* = f(s*, (sd*, g^iq, CKYi, CKYr, 1)). k* = f(s*, (sa*, g^iq, CKYi, CKYr, 2)). decrypt with k* to obtain IDi and digi. digi* = f(s*, (g^q, g^i, CKYi, CKYr, SAi, IDi)). if digi == digi* then return pw* endif done I still claim that if digi = digi*, then with high probability pw = pw*. The point is that the work factor is much less that you might expect. Nice Catch. John Pliam pliam@ima.umn.edu http://www.ima.umn.edu/~pliam From owner-ipsec@lists.tislabs.com Fri Aug 20 10:39:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA02495; Fri, 20 Aug 1999 10:39:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01678 Fri, 20 Aug 1999 12:17:45 -0400 (EDT) Message-ID: <37BD802E.8B1B2C81@redcreek.com> Date: Fri, 20 Aug 1999 09:19:58 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Williams CC: "Mason, David" , Joern Sierwald , ipsec@lists.tislabs.com Subject: Re: Non-IP type Client IDs References: <447A3F40A07FD211BA2700A0C99D759B05D131@md-exchange1.nai.com> <37BD69EF.497CE861@ibm.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think a critical point is being overlooked, or perhaps just not being voiced: policy selectors are not the same as SA selectors. That is, you may use one thing to select the appropriate policy, e.g. FQDN, DN, etc., and use something entirely different to map flows into SAs. You really have no choice but to use flow identifiers such as IP addresses, protocol, and ports to map active flows to the appropriate SA, but you may not know these when constructing your policy. The remote user presents a good example. In many cases, the remote user's IP address is dynamically assigned somehow, and in configuring policy, you have no idea whatsoever as to what this will be. You MUST rely on some other mechanism. Furthermore, the address used in the phase 2 SA may not be the same as the one assigned by the ISP and used to negotiate in phase 1, in which case you have the effect of superimposing a security gateway with the ISP address between the user and the ISP, as in the following diagram: USER SYSTEM CORP NET +--------------------------------------+ |10.0.1.x | | ISP IP: | internet +-------+ | | virtual IP: 10.0.1.26 | 192.x.y.z |==========| sgw |----| +----+ +--------------------------------------+ +-------+ |-----| | +----+ In this case, the user has a virtual presence on the internal net, and packets containing the virtual IP are tunneled to the sgw, with the ISP IP in the outer header. I grant that in this case the phase 1 SA is uniquely tied to the phase 2 SA, so that the phase 2 ID could be omitted, as it is redundant to specify the DN again (assuming that is what was used to authenticate the phase 1 SA). However, that's different than REQUIRING that the phase 2 ID be only IP addresses. Another question I have is, do we really want to close the door on the possibility that someday we might want to add a mechanism whereby users somehow authenticate themselves to the sgw, and the sgw subsequently passes on this disjoint DN in a common phase 1 SA (as a phase 2 ID payload)? Scott From owner-ipsec@lists.tislabs.com Fri Aug 20 10:52:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA02914; Fri, 20 Aug 1999 10:52:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01759 Fri, 20 Aug 1999 12:30:22 -0400 (EDT) Message-ID: <37BD8326.35A7A66E@redcreek.com> Date: Fri, 20 Aug 1999 09:32:38 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Williams CC: "Mason, David" , Joern Sierwald , ipsec@lists.tislabs.com Subject: Re: Non-IP type Client IDs References: <447A3F40A07FD211BA2700A0C99D759B05D131@md-exchange1.nai.com> <37BD69EF.497CE861@ibm.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry about the mangled ascii diagram, it should have looked more like this: USER SYSTEM CORP NET +----------------------------+ |10.0.1.x/24 | virtual IP: | ISP IP: | internet +-------+ | | 10.0.1.26 | 192.x.y.z |==========| sgw |----| +----+ +----------------------------+ +-------+ |--| | +----+ From owner-ipsec@lists.tislabs.com Fri Aug 20 11:20:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA03202; Fri, 20 Aug 1999 11:20:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01906 Fri, 20 Aug 1999 13:01:51 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <37BD802E.8B1B2C81@redcreek.com> References: <447A3F40A07FD211BA2700A0C99D759B05D131@md-exchange1.nai.com> <37BD69EF.497CE861@ibm.net> Date: Fri, 20 Aug 1999 12:54:33 -0400 To: "Scott G. Kelly" From: Stephen Kent Subject: Re: Non-IP type Client IDs Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, RFC 2401 embodies the notion that one can use a non-address ID type as a selector in the SPD search. If the user ID is found in thge SPD, then one creates a temporary SPD entry populated with IP addresses that have been dynamically assigned, e.g., in the remote user scenario. The document notes, near the top of page 19, the requirement to support user names for INBOUND SA creation in security gateways, motivated by this scenario. Steve From owner-ipsec@lists.tislabs.com Fri Aug 20 11:22:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA03231; Fri, 20 Aug 1999 11:22:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01911 Fri, 20 Aug 1999 13:01:53 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <447A3F40A07FD211BA2700A0C99D759B05D135@md-exchange1.nai.com> Date: Fri, 20 Aug 1999 12:58:37 -0400 To: "Mason, David" From: Stephen Kent Subject: Re: ID Policy: was RE: Non-IP type Client IDs Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dave, The scenario you descibed cis most apprpopriately averted by having the Corp. A cross certificate for Corp. B employ the name constraints extension, to ensure that certs issued under Corp B, and presented to the Corp. A SG, are suitable restricted in the range of IDs that they assert. Steve From owner-ipsec@lists.tislabs.com Fri Aug 20 11:26:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA03279; Fri, 20 Aug 1999 11:25:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01849 Fri, 20 Aug 1999 12:48:34 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05D135@md-exchange1.nai.com> From: "Mason, David" To: ipsec@lists.tislabs.com Subject: ID Policy: was RE: Non-IP type Client IDs Date: Fri, 20 Aug 1999 09:44:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since the lookup of policy based on ID payload has been mentioned. I'd like comments on the following. Corporation A uses CA CAa and has a gateway that allows userA@corpA.com access to the accounting machine. Corp A then has a joint development project with Corp B that uses CAb and allows access for userB@corpB.com to a joint development machine behind the gateway, so it loads the root for CAb and sets up a policy that allows userB@corpB.com access the dev machine. Corp B finds out that Corp A is using a gateway that does policy lookup based on ID payload contents so Corp B has its CAb issue a certificate with subAltName userA@corpA.com and uses this in it's ID payload. The certificate will verify against the loaded CA root certificates (CAb) and the ID payload will match what's in the certificate. If policy lookup is based strictly upon the ID payload, Corp B gets access to the accounting machine. Because of this I feel policy lookup should be based on all of the certificate and not just the portion of the certificate that is placed in the ID payload. Or in the very least, policy lookup should be based on rootCA+IDpayload. -dave From owner-ipsec@lists.tislabs.com Fri Aug 20 14:12:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA05887; Fri, 20 Aug 1999 14:12:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02386 Fri, 20 Aug 1999 15:47:03 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 20 Aug 1999 11:09:35 -0700 (PDT) From: Jan Vilhuber Reply-To: Jan Vilhuber To: Jianying Zhou cc: John Pliam , ipsec@lists.tislabs.com Subject: Re: Weak authentication in Xauth and IKE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 20 Aug 1999, Jianying Zhou wrote: > > After the adversary computes k (knowing everything) she decrypts > > > How does the adversary know everything to computer k ??? > The initiator uses the pw shared with R (not M) to compute s > and derive k. Does the adversary know pw in advance? > Isn't this exactly the case, if people start using the dreaded group-pre-shared-secret, i.e. assign a single shared-secret to all their dial-in customers? jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Aug 20 14:32:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA06342; Fri, 20 Aug 1999 14:32:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02425 Fri, 20 Aug 1999 16:13:52 -0400 (EDT) Message-ID: <37BDA58B.2C598522@ima.umn.edu> Date: Fri, 20 Aug 1999 18:59:23 +0000 From: John Pliam X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i586) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: ipsec@lists.tislabs.com Subject: Re: Weak authentication in Xauth and IKE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > Isn't this exactly the case, if people start using the dreaded > group-pre-shared-secret, i.e. assign a single shared-secret to all their > dial-in customers? I think there really are 2 distinct issues here: i. Unless you assign every user to a distinct group, there is a serious risk that a lost laptop etc will yield the desired password. (This risk has been discussed on various threads.) ii. Even if you assign every user a distinct group password, and you diligently revoke these as soon as they become compromised, there is still the risk that an adversary will carry out an attack to *discover* your password. (This risk is not so clear from the threads I have read.) So a "group password" is a bad thing, both because it is a password (has "low entropy") and because it is shared among some group (regardless of its strength). Jianying correctly pointed out a flaw in my attack which was corrected is a separate post. But dictionary attacks are always possible against weak shared secrets even if they are shared between users. John From owner-ipsec@lists.tislabs.com Sun Aug 22 06:13:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA04650; Sun, 22 Aug 1999 06:13:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA05376 Sun, 22 Aug 1999 07:38:09 -0400 (EDT) Message-ID: <37BFE216.A097CEF@checkpoint.com> Date: Sun, 22 Aug 1999 14:42:14 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: John Pliam CC: ipsec@lists.tislabs.com Subject: Re: Weak authentication in Xauth and IKE References: <199908192247.RAA31947@red.ima.umn.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Let me start by saying that I agree that a Phase1 exchange authenticated by a guessable pre-shared key followed by an XAUTH exchange is weak. However, this weakness is not shared by Hybrid since if Hybrid authentication is used, the edge device is authenticated by public keys. You wrote: "Our suggested solution is similar to the hybrid authentication described in [Hyb], but that document doesn't clearly indicate the need for confidentiality in the Xauth exchanges." I'm a bit puzzled by this remark since the Hybrid draft explicitly says: "The Phase 1 Exchange MUST be immediately followed by a Transaction Exchange whose initiator is the Edge Device. The Transaction Exchange MUST be protected by the IKE SA negotiated in the preceding Phase 1 Exchange. This IKE SA MUST NOT be used for any other exchange before the Transaction Exchange terminates successfully and the User is authenticated. If the User fails to authenticate the IKE SA MUST be discarded." By proposing Hybrid more than a year ago we tried to solve the same problems you are raising. Was there any weakness or drawback you found in Hybrid that made you come up with a different proposal? Furthermore, your proposal does not clearly state what happens if XAUTH needs more than one exchange to complete. I think you should encrypt all responses since the first challenge could be a simple "User Name" challenge which a man in the middle attacker can easily reply to. Tamir. John Pliam wrote: > I have read the previous threads on Xauth (/hybrid) and IKE and while I > think this horse has been well-flogged, for me it is not yet dead. The > idea in the following article is that Xauth's laudable goal of strong > authentication without user certificates is not quite achieved in its > current draft. However, I think it can and should be extended to provide > authentication which is neither "insecure" nor "superfluous". This is > easily done... > > Authentication Vulnerabilities in IKE and Xauth with > Weak Pre-Shared Secrets > > John Pliam > pliam@ima.umn.edu > http://www.ima.umn.edu/~pliam > > Introduction > ------------ > > IPSec demands strong authentication resistant to active attacks [MSST]. > The primary purpose of strong authentication in IPSec is to ensure > integrity in the key exchanges. It is well-known, for example, that > unauthenticated Diffie-Hellman is vulnerable to a simple active attack (see > [Stin], cf. [HAC]). > > However, without issuing public keys for every user (or some other > elaborate key management system) the only available authentication > mechanism in the Internet Key Exchange (IKE) [IKE] is the pre-shared key > mechanism. Unfortunately, pre-shared secrets are often implemented as > passwords and it is demonstrated below that IKE is vulnerable to offline > dictionary attacks when weak passwords are used. > > Vendors have attempted to strengthen IPSec authentication with extensions > to IKE or ISAKMP which support various unilateral authentication schemes > such as username/password, token card, 1-time passwords or > challenge-response (see [Mam], [OR] and [XAUTH]). In particular, Xauth has > made its way into the IPSec working group. However, virtually all of these > unilateral authentication protocols fall trivially to active attacks unless > they are protected by a layer of strong encryption (reason: the attacker > merely passes token-codes, passwords and correct responses along to the > authenticating peer as if the attacker were their owner). > > There is clearly a nasty catch-22 here: We need strong authentication to > establish a strong session key. We need a strong session key in order to > protect unilateral authentication schemes and thereby provide strong > authentication. Relying on weak phase 1 authentication followed by > traditional unilateral schemes in Xauth (protected by suspect > session keys derived in phase 1) must be considered a violation of > ISAKMP [MSST]. In other words, > > Two weak authentications != A single strong authentication. > > On the other hand, Xauth provides the means to solve this dilemma: Public > key schemes such as SSL and 1-way Diffie-Hellman (aka El Gamal key > exchange) [HAC] provide both strong confidentiality and strong unilateral > authentication of one peer (usually the edge device) with minimal key > management. Remote users don't need their own public keys. If (strong) > legacy unilateral authentication schemes anticipated in [XAUTH] were used > *after* 1-way public-key protocols, then phase 2 would not proceed unless > the remote peer were truly strongly authenticated. > > The remainder of this document presents further details. First we describe > attacks which exploit the vulnerabilities of IKE with weak pre-shared > secrets followed by Xauth. After that we propose a secure Xauth > authentication mechanism which could be used to protect a weak phase 1 > authentication. > > Discovering a Weak Pre-Shared Secret in IKE > ------------------------------------------- > > The following attack works against both Main Mode and Aggressive Mode, but > we present the details for Aggressive Mode only. Ignoring most of the > irrelevant data, phase 1 establishes a session key k (aka SKEYID_e) between > initiator I and responder R as follows: > > 1). I -> R: (CKYi, SAi, g^i, Ni, IDi), > > 2). R -> I: (CKYr, SAr, g^r, Nr, IDr, digr), > > 3). I -> R: (digi), > > where we employ the following notation: > > ------------------------------------------------------------------ > I Symbol for initiator in the protocol. > > R Symbol for responder in the protocol. > > pw Shared secret. > > g^i Initiator's DH message: g multiplied with itself a random > number i times. The number i is kept secret. > > g^r Initiator's DH message: g multiplied with itself a random > number r times. The number r is kept secret. > > g^ir The DH negotiated secret = (g^i)^r = (g^r)^i. > > CKYi Initiator's randomly generated cookie from its ISAKMP header. > > CKYr Responder's randomly generated cookie from its ISAKMP header. > > SAi Various ISAKMP information. > > SAr Various ISAKMP information. > > Ni Initiator's nonce (randomly generated number). > > Nr Responder's nonce (randomly generated number). > > IDi Initiator's identification payload. > > IDr Responder's identification payload. > > f A pseudo-random function. > > s An intermediate secret, formed by s = f(pw, (Ni, Nr)). > > sd An intermediate secret, f(s, (g^ir, CKYi, CKYr, 0)). > > sa An intermediate secret, f(s, (sd, g^ir, CKYi, CKYr, 1)). > > digi Initiator's digest used to authenticate the DH exchange. It > is formed by, > digi = f(s, (g^i, g^r, CKYi, CKYr, SAi, IDi)). > > digr Responder's digest used to authenticate the DH exchange. It > is formed by, > digr = f(s, (g^r, g^i, CKYr, CKYi, SAr, IDr)). > > k Final session key, f(s, (sa, g^ir, CKYi, CKYr, 2)). > ------------------------------------------------------------------ > > We claim that the initiator digest message digi contains enough information > to rule out incorrectly guessed passwords. The adversary conducts an > off-line dictionary attack, enumerating all candidates pw* and for each > computing: > > s* = f(pw*, (Ni, Nr)), > and > digi* = f(s*, (g^i, g^r, CKYi, CKYr, SAi, IDi)). > > If digi = digi*, then with high probability pw = pw*. Notice that > all candidate computations use data which was sent in the clear. > > An Active Attack Against IKE Phase 1 Key Exchange > ------------------------------------------------- > > Armed with the shared secret pw, the adversary can now carry out an active > attack against the phase 1 key exchange. Now acting as an intruder in the > middle, M, the adversary manipulates the IKE messages as follows: > > 1). I -> M: (CKYi, SAi, g^i, Ni, IDi), > M computes random secret q. > > 2). M -> R: (CKYi, SAi, g^q, Ni, IDi). > > 3). R -> M: (CKYr, SAr, g^r, Nr, IDr, digr), > M computes digr'. > > 4). M -> I: (CKYr, SAr, g^q, Nr, IDr, digr'), > I checks digr' and then computes k'. > > 5). I -> M: (digi) > M computes digi'. > > 6). M -> R: (digi') > R checks digi' and computes k'', > > where the following additional notation is used: > > ------------------------------------------------------------------ > M Symbol for the intruder in the middle. > > g^q Adversary's public DH key. > > sd' Forged intermediate secret during active phase: > f(s, (g^rq, CKYi, CKYr, 0)). > > sd'' Forged intermediate secret during active phase: > f(s, (g^iq, CKYi, CKYr, 0)). > > sa' Another forged secret: f(s, (sd', g^rq, CKYi, CKYr, 1)). > > sa'' Another forged secret: f(s, (sd'', g^iq, CKYi, CKYr, 1)). > > digi' Forged Initiator digest: > digi' = f(s, (g^q, g^r, CKYi, CKYr, SAi, IDi)). > > digr' Forged Responder digest: > digr' = f(s, (g^q, g^i, CKYr, CKYi, SAr, IDr)). > > k' Forged final session key: > f(s, (sa', g^rq, CKYi, CKYr, 2)). > > k'' Forged final session key: > f(s, (sa'', g^iq, CKYi, CKYr, 2)). > ------------------------------------------------------------------ > > Aside from the digest forgeries, this is nothing but the standard active > attack against Diffie-Hellman [Stin], after which I and M share secret g^iq > and M and R share secret g^qr. Both established session keys k' and k'' > are known to the adversary, and M can simulate an encrypted tunnel between > I and R by repeated decryption and re-encryption. Notice that the two > forged digests appear to be legitimate because the arguments used to > compute them are correct as far as the legal parties I and R are > concerned. > > Thwarting Xauth after IKE is Defeated > ------------------------------------- > > If the adversary has defeated IKE and established mutual session keys k' > and k'', unilateral authentication systems provide little protection. For > a challenge-response authentication, the Xauth protocol is defeated as > follows: > > 7). R -> M: ({challenge}_k'), > M decrypts with k' and re-encrypts with k''. > > 8). M -> I: ({challenge}_k''). > > 9). I -> M: ({response}_k''), > M decrypts with k'' and re-encrypts with k'. > > 10). M -> R: ({response}_k'). > > 11). I <-> M <-> R: exchange (ok) and (ack). > > After M presents the correct response, phase 2 begins between > the adversary and the edge device. > > Protecting Unilateral Authentication with 1-Way Public Keys > ----------------------------------------------------------- > > Assuming that the edge device R has a public key p which is signed > by a trusted authority, I and R can engage in the following > more elaborate Xauth protocol between phase 1 and phase 2: > > 1). R -> I: (cert = {p}_trusted-CA, challenge), > I verifies p and generates random K. > > 2). I -> R: ({K}_p, {digi, response}_K), > R decrypts K with p and checks both digi and response. > > 3). I <-> R: (ok) and (ack). > > Since only I and R know the value of K, the phase 1 digest is > finally authenticated strongly, and phase 2 may securely proceed. > > Conclusion > ---------- > > We recommend that the "Security Consideration" section of [IKE] > include an explicit warning of the vulnerability when weak pre-shared > secret authentication is used -- as in done in RFC 2288 [SKEY]. > Xauth's goal of strong authentication without elaborate key > management is easily achieved by minor additions to the Xauth > functionality (which provide for checking digi as above). > > Our suggested solution is similar to the hybrid authentication > described in [Hyb], but that document doesn't clearly indicate > the need for confidentiality in the Xauth exchanges. > > References > ---------- > > [HAC] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of Applied > Cryptography", CRC Press, 1997. > > [Hyb] M. Litvin, R. Shamir, T. Zegman, "A Hybrid Authentication Mode for > IKE", draft-ietf-ipsec-isakmp-hybrid-auth-02.txt, 1999. > > [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange > (IKE)", RFC 2409, November 1998. > > [Mam] Mamros, S., "Pre-shared key extensions for ISAKMP/OAKLEY", > draft-mamros-pskeyext-00.txt, November 1997. > > [MSST] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, > "Internet Security Association and Key Management Protocol > (ISAKMP)", RFC 2408, November 1998. > > [OR] J. O'Hara, M. Rosselli, "Token Card Extensions for ISAKMP/OAKLEY" > Internet Draft: draft-ohara-tokencard-00.txt, 1997. > > [SKEY] N. Haller, et al., "A One-Time Password System", RFC 2289, > 1998. > > [Sti] D. Stinson, Cryptography: Theory and Practice, CRC Press, > 1995. > > [XAUTH] R. Pereira, S. Beaulieu, "Extended Authentication within > ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-04.txt, 1999. From owner-ipsec@lists.tislabs.com Mon Aug 23 12:57:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA16822; Mon, 23 Aug 1999 12:57:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09104 Mon, 23 Aug 1999 13:24:54 -0400 (EDT) Message-ID: <37C17F06.92CED2BF@ima.umn.edu> Date: Mon, 23 Aug 1999 17:04:06 +0000 From: John Pliam X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i586) X-Accept-Language: en MIME-Version: 1.0 To: Tamir Zegman CC: ipsec@lists.tislabs.com Subject: Re: Weak authentication in Xauth and IKE References: <199908192247.RAA31947@red.ima.umn.edu> <37BFE216.A097CEF@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Tamir, I must first make clear that, IMHO, XAUTH/Hybrid is the only proposal for legacy authentication within IPSEC that can reasonably be said to provide strong authentication. By that standard, it is therefore the only one which is ISAKMP compliant. All others fall to variants of the attacks I have posted. Tamir Zegman wrote: > You wrote: > "Our suggested solution is similar to the hybrid authentication > described in [Hyb], but that document doesn't clearly indicate > the need for confidentiality in the Xauth exchanges." > > I'm a bit puzzled by this remark ... Please forgive the poor wording of this footnote at the end of my analysis of Xauth/IKE. What I probably should have said was: [Hyb] does not motivate the need for confidentiality in Xauth as clearly (to me) by providing attack details. This is *not* a criticism of [Hyb] because it is not the place of a WG draft to detail attack scenarios. To feel comfortable that [Hyb] resists these kinds of attacks one must read ISAKMP, IKE, ISACFG, XAUTH, and finally [Hyb]. One must also understand how the various cookies, IV's and key material are generated, protected and passed between the phases and transactions. In recent threads you have suggested "just use Xauth/Hybrib" and Bellovin has suggested "just use EKE". Both are reasonable approaches IMHO. I thought that these threads demonstrated a disconnect between those who consider weak secrets (even hardware tokens) adequate without some public key techniques and those who consider them inadequate. My suggestion was only meant to weigh into this debate with actual attack scenarios and a simple amendment to Xauth to fix the problem. (To feel comfortable that my suggestion resists these attacks, one need only assume that the client detects active rogue server attacks). My suggestion is certainly no better than Xauth/Hybrid or EKE, and it was included merely to point out that a better way exists *within* Xauth proper (by authenticating the phase 1 HASH_I). > Furthermore, your proposal does not clearly state what happens > if XAUTH needs more than one exchange to complete. I think you > should encrypt all responses since the first challenge could > be a simple "User Name" challenge which a man in the middle > attacker can easily reply to. Agreed. In fact I would require that all response be encrypted in the exact same way: R -> I: challenge1, I -> R: ({K}_p, {digi, response1}_K), R -> I: challenge2, I -> R: {digi, response1}_K, ... since this key K is only used for authentication of the SA and must therefore tie all responses to HASH_I. Respectfully, John From owner-ipsec@lists.tislabs.com Mon Aug 23 14:10:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA17784; Mon, 23 Aug 1999 14:10:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09537 Mon, 23 Aug 1999 15:37:34 -0400 (EDT) Message-Id: <199908231935.MAA21761@potassium.network-alchemy.com> To: John Pliam cc: Tamir Zegman , ipsec@lists.tislabs.com Subject: Re: Weak authentication in Xauth and IKE In-reply-to: Your message of "Mon, 23 Aug 1999 17:04:06 -0000." <37C17F06.92CED2BF@ima.umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21758.935436935.1@network-alchemy.com> Date: Mon, 23 Aug 1999 12:35:35 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 23 Aug 1999 17:04:06 -0000 John Pilam wrote > > I must first make clear that, IMHO, XAUTH/Hybrid is the only proposal for > legacy authentication within IPSEC that can reasonably be said to provide > strong authentication. By that standard, it is therefore the only one > which is ISAKMP compliant. All others fall to variants of the attacks I > have posted. Let me propose another technique then. One that doesn't require any asymmetry in the IKE negotiation, doesn't imply a weakly authenticated IKE SA, and allows for strong, mutual authentication. I believe that CMC allows for token card authentication; the token card credentials authenticate enrollment into a CA. This can be used to deliver a very short lived (or one-time) certificate. The client then uses this certificate in the standard way-- no modification to IKE is necessary. Due to the short lifetime of the certificate the client would be forced to use it immediately in a standard IKE exchange. The IKE implementation on the non-client end need not have any special hooks to understand an extended or asymmetric authentication. It's just a plain, vanilla, IKE. This solves the concern of a private key (whose public analog is contained in the certificate) from living on a transient device like a lap top for an extended period of time. The public/private key pair can be generated immediately prior to authentication using the token card and once the resulting certificate is used any exposure of the private key would not be catastrophic since the certificate would no longer be valid. It allows the issuing entity full flexibility in setting the lifetime of the certificates. It would not be necessary to have the device speaking IKE be the same device that is authenticating the remote client and issuing the certificate-- it could be, but need not be. It requires no hacks to IKE. Granted, it does require implementation of CMC, which is no small matter, but it seems to me that a profile of CMC-- some subset of the full CMC functionality-- could be defined to meet these needs. This subset need not be much greater than what is already required for XAUTH but with the added benefit of not having to modify IKE. It addresses the concern that people have that their token cards must be used in some manner as a way of amortizing the cost (this is largely a political arguement but one that is very compelling nonetheless). Since it uses certificates it is a must smoother transition to get people off the token card addiction than either XAUTH or XAUTH+Hybrid. Finally, it separates the two steps-- token card authentication and the IKE protocol-- and eliminates the need to change your IKE implementation. There is no need for a "remote access IKE" and a separate "VPN IKE". Is there any desire in the WG to pursue this? Dan. From owner-ipsec@lists.tislabs.com Mon Aug 23 22:26:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA19287; Mon, 23 Aug 1999 22:26:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA10689 Mon, 23 Aug 1999 23:29:11 -0400 (EDT) Date: Tue, 24 Aug 1999 11:25:59 +0800 (SGT) From: Jianying Zhou X-Sender: jyzhou@arizona To: ipsec@lists.tislabs.com cc: Jianying Zhou Subject: attack on identity protection in IKE In-Reply-To: <37BFE216.A097CEF@checkpoint.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Identity protection is a feature of the main mode protocol. However, an attack is possible for the main mode protocol using public key encryption for authentication (when RSA is the encryption algorithm). In that protocol, the peer's identity payload is encrypted with the other party's public key. When the ID is only a 32-bit IP address, it is easy to find the encrypted ID by the brute force attack. The main mode protocol using revised mode of public key encryption does not suffer from the attack. Jianying --------------------------------------------------------------------- Dr. Jianying Zhou | Tel: +65-8742585 Kent Ridge Digital Labs | Fax: +65-7744990 21 Heng Mui Keng Terrace | Email: jyzhou@krdl.org.sg Singapore 119613 | WWW: http://www.krdl.org.sg --------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Tue Aug 24 04:23:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA02769; Tue, 24 Aug 1999 04:23:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA11446 Tue, 24 Aug 1999 05:25:21 -0400 (EDT) Message-ID: <37C26605.4F87B22B@checkpoint.com> Date: Tue, 24 Aug 1999 12:29:41 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jianying Zhou CC: ipsec@lists.tislabs.com Subject: Re: attack on identity protection in IKE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jianying Zhou wrote: > Identity protection is a feature of the main mode protocol. However, > an attack is possible for the main mode protocol using public key > encryption for authentication (when RSA is the encryption algorithm). > > In that protocol, the peer's identity payload is encrypted with the > other party's public key. When the ID is only a 32-bit IP address, > it is easy to find the encrypted ID by the brute force attack. > According to PKCS#1, random bytes are used to pad the data before encryption, thus making a brute force attack impractical. > > The main mode protocol using revised mode of public key encryption > does not suffer from the attack. > > Jianying > --------------------------------------------------------------------- > Dr. Jianying Zhou | Tel: +65-8742585 > Kent Ridge Digital Labs | Fax: +65-7744990 > 21 Heng Mui Keng Terrace | Email: jyzhou@krdl.org.sg > Singapore 119613 | WWW: http://www.krdl.org.sg > --------------------------------------------------------------------- -- ========================================================================= This message may contain confidential and/or proprietary information, and is intended only for the person / entity to whom it was originally addressed. The content of this message may contain private views and opinions which do not constitute a formal disclosure or commitment unless specifically stated. From owner-ipsec@lists.tislabs.com Tue Aug 24 08:37:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA05951; Tue, 24 Aug 1999 08:37:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12365 Tue, 24 Aug 1999 09:20:53 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE204@new-exc1.ctron.com> From: "Waters, Stephen" To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Weak authentication in Xauth and IKE Date: Tue, 24 Aug 1999 14:17:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, A couple of questions on this CMC fetch of a shortlived certificate idea: I guess this does not aggravate CRL issues, since out-of-date certificate should not be published there anyway. One concern is the time it may take to acquire this 'per connection' certificate. Cheers, Steve. -----Original Message----- From: Dan Harkins [mailto:dharkins@network-alchemy.com] Sent: Monday, August 23, 1999 8:36 PM To: John Pliam Cc: Tamir Zegman; ipsec@lists.tislabs.com Subject: Re: Weak authentication in Xauth and IKE On Mon, 23 Aug 1999 17:04:06 -0000 John Pilam wrote > > I must first make clear that, IMHO, XAUTH/Hybrid is the only proposal for > legacy authentication within IPSEC that can reasonably be said to provide > strong authentication. By that standard, it is therefore the only one > which is ISAKMP compliant. All others fall to variants of the attacks I > have posted. Let me propose another technique then. One that doesn't require any asymmetry in the IKE negotiation, doesn't imply a weakly authenticated IKE SA, and allows for strong, mutual authentication. I believe that CMC allows for token card authentication; the token card credentials authenticate enrollment into a CA. This can be used to deliver a very short lived (or one-time) certificate. The client then uses this certificate in the standard way-- no modification to IKE is necessary. Due to the short lifetime of the certificate the client would be forced to use it immediately in a standard IKE exchange. The IKE implementation on the non-client end need not have any special hooks to understand an extended or asymmetric authentication. It's just a plain, vanilla, IKE. This solves the concern of a private key (whose public analog is contained in the certificate) from living on a transient device like a lap top for an extended period of time. The public/private key pair can be generated immediately prior to authentication using the token card and once the resulting certificate is used any exposure of the private key would not be catastrophic since the certificate would no longer be valid. It allows the issuing entity full flexibility in setting the lifetime of the certificates. It would not be necessary to have the device speaking IKE be the same device that is authenticating the remote client and issuing the certificate-- it could be, but need not be. It requires no hacks to IKE. Granted, it does require implementation of CMC, which is no small matter, but it seems to me that a profile of CMC-- some subset of the full CMC functionality-- could be defined to meet these needs. This subset need not be much greater than what is already required for XAUTH but with the added benefit of not having to modify IKE. It addresses the concern that people have that their token cards must be used in some manner as a way of amortizing the cost (this is largely a political arguement but one that is very compelling nonetheless). Since it uses certificates it is a must smoother transition to get people off the token card addiction than either XAUTH or XAUTH+Hybrid. Finally, it separates the two steps-- token card authentication and the IKE protocol-- and eliminates the need to change your IKE implementation. There is no need for a "remote access IKE" and a separate "VPN IKE". Is there any desire in the WG to pursue this? Dan. From owner-ipsec@lists.tislabs.com Tue Aug 24 09:57:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA06979; Tue, 24 Aug 1999 09:57:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12861 Tue, 24 Aug 1999 10:48:32 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 24 Aug 1999 10:48:12 -0400 Message-Id: <9908241448.AA23914@secpwr.watson.ibm.com> To: ipsec@lists.tislabs.com, jyzhou@krdl.org.sg Subject: Re: attack on identity protection in IKE Cc: jyzhou@krdl.org.sg Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: L15ELumaofOIlEbqBwbcFg== Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From owner-ipsec@lists.tislabs.com Tue Aug 24 00:09:03 1999 > Date: Tue, 24 Aug 1999 11:25:59 +0800 (SGT) > From: Jianying Zhou > X-Sender: jyzhou@arizona > To: ipsec@lists.tislabs.com > Cc: Jianying Zhou > Subject: attack on identity protection in IKE > In-Reply-To: <37BFE216.A097CEF@checkpoint.com> > Message-Id: > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Sender: owner-ipsec@lists.tislabs.com > Precedence: bulk > Content-Length: 859 > Status: RO > > Identity protection is a feature of the main mode protocol. However, > an attack is possible for the main mode protocol using public key > encryption for authentication (when RSA is the encryption algorithm). > > In that protocol, the peer's identity payload is encrypted with the > other party's public key. When the ID is only a 32-bit IP address, > it is easy to find the encrypted ID by the brute force attack. Yes. But IP addess is exposed anyway. It is in the IP header. > > The main mode protocol using revised mode of public key encryption > does not suffer from the attack. > > Jianying > --------------------------------------------------------------------- > Dr. Jianying Zhou | Tel: +65-8742585 > Kent Ridge Digital Labs | Fax: +65-7744990 > 21 Heng Mui Keng Terrace | Email: jyzhou@krdl.org.sg > Singapore 119613 | WWW: http://www.krdl.org.sg > --------------------------------------------------------------------- > > From owner-ipsec@lists.tislabs.com Tue Aug 24 10:27:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA07435; Tue, 24 Aug 1999 10:27:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13056 Tue, 24 Aug 1999 11:35:52 -0400 (EDT) To: pau@watson.ibm.com Cc: ipsec@lists.tislabs.com, jyzhou@krdl.org.sg Subject: Re: attack on identity protection in IKE References: <9908241448.AA23914@secpwr.watson.ibm.com> From: Derek Atkins Date: 24 Aug 1999 11:22:28 -0400 In-Reply-To: pau@watson.ibm.com's message of Tue, 24 Aug 1999 10:48:12 -0400 Message-Id: Lines: 48 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You can always see the IP address of the IKE hosts. But that's ok. The question is: can you see the identity of the authenticated entity (be it a host identification or user indentification)? The answer is: no. IKE isn't using raw RSA on the identity, that would be stupid (and insecure, as you point out). It would also lead to traffic-analysis attacks, where the same identity would encrypt to the same ciphertext. PKCS solves both of these problems, as already mentioned, by adding random padding to extend the actual message out to the size of the RSA key. -derek pau@watson.ibm.com writes: > > Date: Tue, 24 Aug 1999 11:25:59 +0800 (SGT) > > From: Jianying Zhou > > To: ipsec@lists.tislabs.com > > Cc: Jianying Zhou > > Subject: attack on identity protection in IKE > > > > Identity protection is a feature of the main mode protocol. However, > > an attack is possible for the main mode protocol using public key > > encryption for authentication (when RSA is the encryption algorithm). > > > > In that protocol, the peer's identity payload is encrypted with the > > other party's public key. When the ID is only a 32-bit IP address, > > it is easy to find the encrypted ID by the brute force attack. > > Yes. But IP addess is exposed anyway. It is in the IP header. > > > > The main mode protocol using revised mode of public key encryption > > does not suffer from the attack. > > > > Jianying > > --------------------------------------------------------------------- > > Dr. Jianying Zhou | Tel: +65-8742585 > > Kent Ridge Digital Labs | Fax: +65-7744990 > > 21 Heng Mui Keng Terrace | Email: jyzhou@krdl.org.sg > > Singapore 119613 | WWW: http://www.krdl.org.sg > > --------------------------------------------------------------------- > > > > -- 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 N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Aug 24 13:18:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA09700; Tue, 24 Aug 1999 13:18:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13580 Tue, 24 Aug 1999 13:53:29 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8FA53@sothmxs06.entrust.com> From: Greg Carter To: "'Dan Harkins'" Cc: ipsec@lists.tislabs.com, "'Xiaoyi'" Subject: RE: Weak authentication in Xauth and IKE, CMC token enroll Date: Tue, 24 Aug 1999 13:52:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sounds good to me, however the implementation described in CMC may not be providing the protection implied. But its nothing that can't be fixed, problem: Section 5.2 Identification and IdentityProof Control Attributes states: The CMC method starts with an out-of-band transfer of a token (the shared secret). The distribution of this token is beyond the scope of this document. The client then uses this token for an identity proof as follows: 1. The reqSequence field of the PKIData object (encoded exactly as it appears in the request message including the sequence type and length) is the value to be validated. 2. A SHA1 hash of the token is computed. 3. An HMAC-SHA1 value is then computed over the value produced in Step 1, as described in [HMAC], using the hash of the token from Step 2 as the shared secret value. 4. The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the value of the identityProof attribute. Note that with a regular shared secret (non hardware token) the shared secret also acts to protect the message since reqSequence can not be altered without the identityProof verification failing. In section 5.2.1 Hardware Shared Secret Token Generation it states: The shared secret between the end-entity and the identity verify is sometimes transferred using a hardware device that generates a series of tokens based on some shared secret value. The user can therefore prove their identity by transferring this token in plain text along with a name string. The above protocol can be used with a hardware shared-secret token generation device by the following modifications: 1. The identitification attribute MUST be included and MUST contain the hardware-generated token. 2. The shared secret value used above is the same hardware-generated token. 3. All certification requests MUST have a subject name and the subject name MUST contain the fields required to identify the holder of the hardware token device. Number 2 is confusing. "The shared secret value used above is the same hardware-generated token." To me this means use the hardware generated token as the shared secret in the algorithm described in 5.2 BUT then point 1 states "The identitification attribute MUST be included and MUST contain the hardware-generated token." If the "identitification attribute" is transmitted in the clear ("The user can therefore prove their identity by transferring this token in plain text along with a name string") than you are sending your shared secret in the clear. This allows anyone to modify reqSequence undetected, since they can then recalculate identityProof and sign the PKIData with their own key, placing their public key in reqSequence. And the server/CA still thinks its you since the token will validate. CMC does allow encryption of the signedData PKIData message, which would prevent this, but it is not required. But this can be fixed, and the same principle applied to CMP (rfc2510) shared secrets or any other PKI boot strap protocol. Possible solutions are to not transmit the 'token', or use CMC encryption. Not transmitting the 'token' works for DES challenge/response cards but not too well for SecurID but is doable with mods on their end, and would be preferable. Instead of asking their server "Is this response correct", their server would say "here are the acceptable responses for this minute in time" you would then calculate the HMAC with each returned response until you find a match. Alternatively they could modify their server to take as input a HMAC output and data and be able to tell you if the user could have generated that HMAC (using their response as the HMAC key). Requiring encryption in CMC requires support for RSA, and may have export issues... Also not addressed is that DES based challenge/response cards typically need to receive the "Challenge" so that it can be entered into the card to produce the "token"/shared secret. Some cards have a "guess next challenge" mode which would get around this but if the card/server become out of sync then you need a way for the server to "challenge" the user. Another draw back with the method described in CMC is that it does not allow the client to verify the CA, since the shared secret is sent in the message, and even if the shared secret was not sent in the message there is no corresponding "CA identityProof" on the response messages. However I am not sure if verifying the CA is a goal of CMC since its not even done with regular nonhardware based secrets(it should be but I will leave that to PKIX working group). If the above issues are addressed than its a great way to make use of the existing infrastructure, whether through CMC or CMP or .... Bye. -----Original Message----- From: Dan Harkins [mailto:dharkins@network-alchemy.com] Sent: Monday, August 23, 1999 3:36 PM To: John Pliam Cc: Tamir Zegman; ipsec@lists.tislabs.com Subject: Re: Weak authentication in Xauth and IKE On Mon, 23 Aug 1999 17:04:06 -0000 John Pilam wrote > > I must first make clear that, IMHO, XAUTH/Hybrid is the only proposal for > legacy authentication within IPSEC that can reasonably be said to provide > strong authentication. By that standard, it is therefore the only one > which is ISAKMP compliant. All others fall to variants of the attacks I > have posted. Let me propose another technique then. One that doesn't require any asymmetry in the IKE negotiation, doesn't imply a weakly authenticated IKE SA, and allows for strong, mutual authentication. I believe that CMC allows for token card authentication; the token card credentials authenticate enrollment into a CA. This can be used to deliver a very short lived (or one-time) certificate. The client then uses this certificate in the standard way-- no modification to IKE is necessary. Due to the short lifetime of the certificate the client would be forced to use it immediately in a standard IKE exchange. The IKE implementation on the non-client end need not have any special hooks to understand an extended or asymmetric authentication. It's just a plain, vanilla, IKE. This solves the concern of a private key (whose public analog is contained in the certificate) from living on a transient device like a lap top for an extended period of time. The public/private key pair can be generated immediately prior to authentication using the token card and once the resulting certificate is used any exposure of the private key would not be catastrophic since the certificate would no longer be valid. It allows the issuing entity full flexibility in setting the lifetime of the certificates. It would not be necessary to have the device speaking IKE be the same device that is authenticating the remote client and issuing the certificate-- it could be, but need not be. It requires no hacks to IKE. Granted, it does require implementation of CMC, which is no small matter, but it seems to me that a profile of CMC-- some subset of the full CMC functionality-- could be defined to meet these needs. This subset need not be much greater than what is already required for XAUTH but with the added benefit of not having to modify IKE. It addresses the concern that people have that their token cards must be used in some manner as a way of amortizing the cost (this is largely a political arguement but one that is very compelling nonetheless). Since it uses certificates it is a must smoother transition to get people off the token card addiction than either XAUTH or XAUTH+Hybrid. Finally, it separates the two steps-- token card authentication and the IKE protocol-- and eliminates the need to change your IKE implementation. There is no need for a "remote access IKE" and a separate "VPN IKE". Is there any desire in the WG to pursue this? Dan. From owner-ipsec@lists.tislabs.com Tue Aug 24 13:18:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA09701; Tue, 24 Aug 1999 13:18:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13719 Tue, 24 Aug 1999 14:16:39 -0400 (EDT) Date: Tue, 24 Aug 1999 14:17:13 -0400 Message-Id: <199908241817.OAA07246@brill.shiva.com> From: John Shriver To: ipsec@lists.tislabs.com Subject: inconsistencies in IKE specs Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are notational inconsistencies about the Phase 2 (Quick Mode) identities in IKE. These exist in both RFC 2409, and in draft-ietf-ipsec-ike-01.txt. In RFC 2409, they are initially defined as IDui and IDur. But, when used, they are cited as IDci and IDcr. In the I-D versions, they are initially defined as ID_i2 and ID_r2. But, when cited, they are still cited as IDci and IDcr. (Perhaps the victim of search & replace blindness to the prior error.) Also, is there any restriction on the allowable Identification Type for a Phase 2 identity? Would ID_IPV4_ADDR_RANGE be allowable? That would be defining an SA for a range of IP addresses, all using the same SPI. What would it possibly mean to have a Phase 2 Identification Type of ID_FQDN?! Personally, I think it would make a great deal of sense to say that Phase 2 ID's may only be ID_IPV4_ADDR or ID_IPV6_ADDR. I'd really love to see more MUST NOT's in these specs. From owner-ipsec@lists.tislabs.com Tue Aug 24 15:10:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA10934; Tue, 24 Aug 1999 15:10:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13931 Tue, 24 Aug 1999 15:36:03 -0400 (EDT) Message-Id: <199908241936.MAA26385@potassium.network-alchemy.com> To: John Shriver cc: ipsec@lists.tislabs.com Subject: Re: inconsistencies in IKE specs In-reply-to: Your message of "Tue, 24 Aug 1999 14:17:13 EDT." <199908241817.OAA07246@brill.shiva.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26382.935523360.1@network-alchemy.com> Date: Tue, 24 Aug 1999 12:36:00 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 24 Aug 1999 14:17:13 EDT you wrote > There are notational inconsistencies about the Phase 2 (Quick Mode) > identities in IKE. These exist in both RFC 2409, and in > draft-ietf-ipsec-ike-01.txt. > > In RFC 2409, they are initially defined as IDui and IDur. But, when > used, they are cited as IDci and IDcr. Good eye. > In the I-D versions, they are initially defined as ID_i2 and ID_r2. > But, when cited, they are still cited as IDci and IDcr. (Perhaps the > victim of search & replace blindness to the prior error.) Yup, the hash descriptions are wrong there (the textual description of Quick Mode though uses IDi2 and IDr2). Thanks for pointing that out. It'll get fixed in the next rev. > Also, is there any restriction on the allowable Identification Type > for a Phase 2 identity? Would ID_IPV4_ADDR_RANGE be allowable? That > would be defining an SA for a range of IP addresses, all using the > same SPI. What would it possibly mean to have a Phase 2 > Identification Type of ID_FQDN?! This has come up quite a bit on the list, most recently last week. > Personally, I think it would make a great deal of sense to say that > Phase 2 ID's may only be ID_IPV4_ADDR or ID_IPV6_ADDR. I'd really > love to see more MUST NOT's in these specs. Limiting these to only a single IP addr would mean that IKE would be unable to express selectors with wildcarded addresses. Since those are required for all implementation (i.e. you MUST support them per RFC2401) I don't think it would make too much sense to remove support for them from RFC2409 (or the draft that will hopefully depricate RFC2409). Dan. From owner-ipsec@lists.tislabs.com Tue Aug 24 16:44:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA12581; Tue, 24 Aug 1999 16:44:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14387 Tue, 24 Aug 1999 17:54:47 -0400 (EDT) Date: Tue, 24 Aug 1999 17:54:10 -0400 Message-Id: <199908242154.RAA07327@brill.shiva.com> From: John Shriver To: dharkins@network-alchemy.com CC: ipsec@lists.tislabs.com In-reply-to: <199908241936.MAA26385@potassium.network-alchemy.com> (message from Dan Harkins on Tue, 24 Aug 1999 12:36:00 -0700) Subject: Re: inconsistencies in IKE specs Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To: John Shriver cc: ipsec@lists.tislabs.com Subject: Re: inconsistencies in IKE specs Date: Tue, 24 Aug 1999 12:36:00 -0700 From: Dan Harkins On Tue, 24 Aug 1999 14:17:13 EDT you wrote > Personally, I think it would make a great deal of sense to say that > Phase 2 ID's may only be ID_IPV4_ADDR or ID_IPV6_ADDR. I'd really > love to see more MUST NOT's in these specs. Limiting these to only a single IP addr would mean that IKE would be unable to express selectors with wildcarded addresses. Since those are required for all implementation (i.e. you MUST support them per RFC2401) I don't think it would make too much sense to remove support for them from RFC2409 (or the draft that will hopefully depricate RFC2409). Of course, allowing these to address a range or subnet means that you have just defined "incoming" SA's with the same SPI and key for a large group of hosts. That's a very strange thing to do. Broad key sharing is not considered good for you. Dan. Perhaps we also should make it clear that ID_i2 and ID_r2 are the identity of the "outer" (endpoint) IP address when using transforms in tunnel mode. Someone might mistakenly think that they are used to negotiate the inner addresses for tunnel mode, and that the outer remains the ISAKMP peer's address. John. From owner-ipsec@lists.tislabs.com Tue Aug 24 16:48:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA12648; Tue, 24 Aug 1999 16:48:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA14552 Tue, 24 Aug 1999 18:22:03 -0400 (EDT) Message-Id: <199908242222.PAA26865@potassium.network-alchemy.com> To: John Shriver cc: ipsec@lists.tislabs.com Subject: Re: inconsistencies in IKE specs In-reply-to: Your message of "Tue, 24 Aug 1999 17:54:10 EDT." <199908242154.RAA07327@brill.shiva.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26862.935533324.1@network-alchemy.com> Date: Tue, 24 Aug 1999 15:22:04 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 24 Aug 1999 17:54:10 EDT John Shriver wrote > From: Dan Harkins > On Tue, 24 Aug 1999 14:17:13 EDT you wrote > > > Personally, I think it would make a great deal of sense to say that > > Phase 2 ID's may only be ID_IPV4_ADDR or ID_IPV6_ADDR. I'd really > > love to see more MUST NOT's in these specs. > > Limiting these to only a single IP addr would mean that IKE would be > unable to express selectors with wildcarded addresses. Since those > are required for all implementation (i.e. you MUST support them per > RFC2401) I don't think it would make too much sense to remove support > for them from RFC2409 (or the draft that will hopefully depricate RFC2409) >. > > Of course, allowing these to address a range or subnet means that you > have just defined "incoming" SA's with the same SPI and key for a > large group of hosts. That's a very strange thing to do. Broad key > sharing is not considered good for you. RFC2401 says that selectors with wildcarded addresss "are used to support more than one destination system sharing the same SA (e.g., behind a security gateway)." You may think it strange but for you to be a compliant IPSec device this is what you MUST do. You also MUST verify that what you take out of the tunnel matches what was negotiated, i.e. if IDi2 is 10.10.1/24 and IDr2 is 172.16.24/24 and what you take out is a packet from 10.10.1.87 to 172.16.23.8 you MUST drop it. Compliance with RFC2401 is not elective, even if it seems strange to you. > Perhaps we also should make it clear that ID_i2 and ID_r2 are the > identity of the "outer" (endpoint) IP address when using transforms in > tunnel mode. Someone might mistakenly think that they are used to > negotiate the inner addresses for tunnel mode, and that the outer > remains the ISAKMP peer's address. You have it backwards. IDi2 and IDr2 are used to define the inner addresses. The outer addresses are always the IKE peers' addresses. Again, referring to RFC2401: "Note that this selector is conceptually different from the 'Destination IP Address' field in the tuple used to uniquely identify an SA." Dan. From owner-ipsec@lists.tislabs.com Wed Aug 25 00:19:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id AAA17796; Wed, 25 Aug 1999 00:19:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA15388 Wed, 25 Aug 1999 01:35:01 -0400 (EDT) Message-ID: <37C4D461.16CDA619@mail1.sjtu.edu.cn> Date: Thu, 26 Aug 1999 13:45:06 +0800 From: Wang Huaibo X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: John Shriver , ipsec@lists.tislabs.com Subject: Re: inconsistencies in IKE specs References: <199908241817.OAA07246@brill.shiva.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk John Shriver wrote: > There are notational inconsistencies about the Phase 2 (Quick Mode) > identities in IKE. These exist in both RFC 2409, and in > draft-ietf-ipsec-ike-01.txt. > > In RFC 2409, they are initially defined as IDui and IDur. But, when > used, they are cited as IDci and IDcr. > > In the I-D versions, they are initially defined as ID_i2 and ID_r2. > But, when cited, they are still cited as IDci and IDcr. (Perhaps the > victim of search & replace blindness to the prior error.) > > Also, is there any restriction on the allowable Identification Type > for a Phase 2 identity? Would ID_IPV4_ADDR_RANGE be allowable? That > would be defining an SA for a range of IP addresses, all using the > same SPI. What would it possibly mean to have a Phase 2 > Identification Type of ID_FQDN?! > > Personally, I think it would make a great deal of sense to say that > Phase 2 ID's may only be ID_IPV4_ADDR or ID_IPV6_ADDR. I'd really > love to see more MUST NOT's in these specs. I agree with you. I think that there are many other needs of MUST NOT and MUST in these specs. o there must be security policy for ISAKMP SA's setup.between two SGW, what kind of SA should be built during phase I negotiation?for phase II negotiation,should I check whether the ISAKMP SA which carries on the communication is security enough?if different protocol SAs' setup between two SGW need different ISAKMP SA,such problem arises. o how to prepare the list of SA proposals? the intiator list proposals in descending order of his perference , how my ISAKMP daemon know such preference? is it implepmentation dependent? o Can I take it for granted that when I start a phase I negotiation, each SA proposal should list only one protocol(e.g. ISAKMP)?logically speaking, it is so. o during a session, if I receiv a message with different Exhange Type(other than Information Exhange Type),should I drop the message or cancel the session? Acrobat Today From owner-ipsec@lists.tislabs.com Wed Aug 25 03:23:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA29387; Wed, 25 Aug 1999 03:23:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA15728 Wed, 25 Aug 1999 04:32:36 -0400 (EDT) Message-ID: <37C4FDF3.7FCD654C@mail1.sjtu.edu.cn> Date: Thu, 26 Aug 1999 16:42:27 +0800 From: Wang Huaibo X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, all I have 2 questions to disscuss with you: o should a phase II SA's DOI be the same as that of the ISAKMP SA? say, can a non-IPSEC-DOI ISAKMP SA carry on a IPSEC-AH SA? o IKE is specific to IPSEC-DOI? why not mandate that all DOIs should implement the same set of key exchange protocols? THANKS Acrobat Today From owner-ipsec@lists.tislabs.com Wed Aug 25 06:22:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA05698; Wed, 25 Aug 1999 06:22:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16149 Wed, 25 Aug 1999 07:35:26 -0400 (EDT) Message-ID: <01BEEEF6.6D41B1E0.lisa@baltimore.ie> From: Lisa Wilkinson Reply-To: "lisa@baltimore.ie" To: "'ipsec@lists.tislabs.com'" Subject: RE: Weak authentication in Xauth and IKE, CMC token enroll Date: Wed, 25 Aug 1999 12:35:51 +0100 Organization: Baltimore Technologies X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just joined the list after a brief absence. Slainte, I wanted to raise the question of certificate managment, but I can see this discussion is undeway (Welcome to the war!) At the last bakeoff I (Baltimore) found the following - Of the 24 vendors we interoperated with (succesful IKE with certs) - CEP - 4 CRS -2 (probably more but we didnt support it at the time) Manual/LDAP retrieval - everyone else What is IPSec going to mandate for an enrollment/management protocol? Is it going to be CMC (backed by Cisco, M/Soft and Verisign) using PKCS formats or CMP (backed by Entrust)? We are supporting both (not by choice I might add). The question is are you...... Lisa From owner-ipsec@lists.tislabs.com Wed Aug 25 07:58:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA08461; Wed, 25 Aug 1999 07:58:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16659 Wed, 25 Aug 1999 09:15:08 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: RE: inconsistencies in IKE specs Date: Wed, 25 Aug 1999 12:25:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: Chris Trobridge Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81CF964@baltimore.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 24 Aug 1999 17:54:10 EDT John Shriver wrote > From: Dan Harkins > On Tue, 24 Aug 1999 14:17:13 EDT you wrote > > > Personally, I think it would make a great deal of sense to say that > > Phase 2 ID's may only be ID_IPV4_ADDR or ID_IPV6_ADDR. I'd really > > love to see more MUST NOT's in these specs. > > Limiting these to only a single IP addr would mean that IKE would be > unable to express selectors with wildcarded addresses. Since those > are required for all implementation (i.e. you MUST support them per > RFC2401) I don't think it would make too much sense to remove support > for them from RFC2409 (or the draft that will hopefully depricate RFC2409) >. > > Of course, allowing these to address a range or subnet means that you > have just defined "incoming" SA's with the same SPI and key for a > large group of hosts. That's a very strange thing to do. Broad key > sharing is not considered good for you. This really applies to IPSEC gateways, and the keys aren't being shared beyond the two gateways involved in the IKE exchange. Sure all the traffic is being protected by a common key, but I don't see this as being a great weakness. Consider the alternative for a VPN where the IPSEC gateways are each protecting a private subnet. Each gateway may be protecting, say, 10-100 IP addresses. If there are 10 such gateways the using ranges results in each gateway needing 9 SAs to be fully interconnected. If you only allow one address per SA then you potentially need thousands... Chris From owner-ipsec@lists.tislabs.com Thu Aug 26 02:29:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA01763; Thu, 26 Aug 1999 02:29:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21645 Thu, 26 Aug 1999 03:33:02 -0400 (EDT) Message-ID: <37C4EE14.8F0DAD7F@DataFellows.com> Date: Thu, 26 Aug 1999 10:34:44 +0300 From: Ari Huttunen Organization: DataFellows X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: attack on identity protection in IKE References: <9908241448.AA23914@secpwr.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tell me if I'm wrong, but I don't think main mode with either preshared keys or digital signatures protects the identity of the initiator against an active attack. Anybody capable of sending / receiving IP packets corresponding to the real responder will be able to get that identity. This does not apply to either encryption mode. Ari Derek Atkins wrote: > You can always see the IP address of the IKE hosts. But that's ok. > The question is: can you see the identity of the authenticated entity > (be it a host identification or user indentification)? The answer > is: no. IKE isn't using raw RSA on the identity, that would be > stupid (and insecure, as you point out). It would also lead to > traffic-analysis attacks, where the same identity would encrypt to > the same ciphertext. PKCS solves both of these problems, as already > mentioned, by adding random padding to extend the actual message > out to the size of the RSA key. > > -derek > > pau@watson.ibm.com writes: > > > > Date: Tue, 24 Aug 1999 11:25:59 +0800 (SGT) > > > From: Jianying Zhou > > > To: ipsec@lists.tislabs.com > > > Cc: Jianying Zhou > > > Subject: attack on identity protection in IKE > > > > > > Identity protection is a feature of the main mode protocol. However, > > > an attack is possible for the main mode protocol using public key > > > encryption for authentication (when RSA is the encryption algorithm). > > > > > > In that protocol, the peer's identity payload is encrypted with the > > > other party's public key. When the ID is only a 32-bit IP address, > > > it is easy to find the encrypted ID by the brute force attack. > > > > Yes. But IP addess is exposed anyway. It is in the IP header. > > > > > > The main mode protocol using revised mode of public key encryption > > > does not suffer from the attack. > > > > > > Jianying > > > --------------------------------------------------------------------- > > > Dr. Jianying Zhou | Tel: +65-8742585 > > > Kent Ridge Digital Labs | Fax: +65-7744990 > > > 21 Heng Mui Keng Terrace | Email: jyzhou@krdl.org.sg > > > Singapore 119613 | WWW: http://www.krdl.org.sg > > > --------------------------------------------------------------------- > > > > > > > > -- > 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 N1NWH > warlord@MIT.EDU PGP key available -- Ari Huttunen GSM: +358 40 5524634 Senior Software Engineer fax : +358 9 8599 xxxx Data Fellows Corporation http://www.DataFellows.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Aug 26 03:48:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA04884; Thu, 26 Aug 1999 03:48:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA21889 Thu, 26 Aug 1999 04:55:08 -0400 (EDT) Message-Id: <199908260856.MAA29892@relay1.trustworks.com> Comments: Authenticated sender is From: "Valery Smyslov" Organization: TWS To: ipsec@lists.tislabs.com, Ari Huttunen Date: Thu, 26 Aug 1999 12:55:42 +4 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: attack on identity protection in IKE In-reply-to: <37C4EE14.8F0DAD7F@DataFellows.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 26 Aug 99 at 10:34, Ari Huttunen wrote: > Tell me if I'm wrong, but I don't think main mode with > either preshared keys or digital signatures protects the > identity of the initiator against an active attack. Preshared keys do protect, while digital signatures don't. > Anybody capable of sending / receiving IP packets > corresponding to the real responder will be able to > get that identity. This does not apply to either > encryption mode. Correct. > Ari Regards, Valery Smyslov. > > Derek Atkins wrote: > > > You can always see the IP address of the IKE hosts. But that's ok. > > The question is: can you see the identity of the authenticated entity > > (be it a host identification or user indentification)? The answer > > is: no. IKE isn't using raw RSA on the identity, that would be > > stupid (and insecure, as you point out). It would also lead to > > traffic-analysis attacks, where the same identity would encrypt to > > the same ciphertext. PKCS solves both of these problems, as already > > mentioned, by adding random padding to extend the actual message > > out to the size of the RSA key. > > > > -derek > > > > pau@watson.ibm.com writes: > > > > > > Date: Tue, 24 Aug 1999 11:25:59 +0800 (SGT) > > > > From: Jianying Zhou > > > > To: ipsec@lists.tislabs.com > > > > Cc: Jianying Zhou > > > > Subject: attack on identity protection in IKE > > > > > > > > Identity protection is a feature of the main mode protocol. However, > > > > an attack is possible for the main mode protocol using public key > > > > encryption for authentication (when RSA is the encryption algorithm). > > > > > > > > In that protocol, the peer's identity payload is encrypted with the > > > > other party's public key. When the ID is only a 32-bit IP address, > > > > it is easy to find the encrypted ID by the brute force attack. > > > > > > Yes. But IP addess is exposed anyway. It is in the IP header. > > > > > > > > The main mode protocol using revised mode of public key encryption > > > > does not suffer from the attack. > > > > > > > > Jianying > > > > --------------------------------------------------------------------- > > > > Dr. Jianying Zhou | Tel: +65-8742585 > > > > Kent Ridge Digital Labs | Fax: +65-7744990 > > > > 21 Heng Mui Keng Terrace | Email: jyzhou@krdl.org.sg > > > > Singapore 119613 | WWW: http://www.krdl.org.sg > > > > --------------------------------------------------------------------- > > > > > > > > > > > > -- > > 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 N1NWH > > warlord@MIT.EDU PGP key available > > -- > Ari Huttunen GSM: +358 40 5524634 > Senior Software Engineer fax : +358 9 8599 xxxx > > Data Fellows Corporation http://www.DataFellows.com > > F-Secure products: Integrated Solutions for Enterprise Security > > > From owner-ipsec@lists.tislabs.com Thu Aug 26 11:38:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA12735; Thu, 26 Aug 1999 11:38:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23173 Thu, 26 Aug 1999 12:02:18 -0400 (EDT) From: "Luis A. Sanchez" Message-Id: <199908261554.LAA02876@nutmeg.bbn.com> Subject: Re: FYI In-Reply-To: <199908250341.XAA141532@northrelay03.pok.ibm.com> from Bert Wijnen at "Aug 25, 99 05:39:13 am" To: WIJNEN@vnet.IBM.COM (Bert Wijnen) Date: Thu, 26 Aug 1999 11:54:09 -0400 (EDT) Cc: raiken@cisco.com, POLICY@raleigh.ibm.com, rap@iphighway.com, diffserv@external.cisco.com, ipsec-policy@mail.timestep.com, ipsec@lists.tislabs.com, mleech@nortelnetworks.com, jis@MIT.EDU Reply-to: lsanchez@bbn.com 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@lists.tislabs.com Precedence: bulk Bert, One of the goals of IPSP is to specify a data model for supporting IP security policies. This task requires at a minimum that we work closely with the Policy Framework WG to ensure that the IPsec data model fits within the general Policy Framework. Our folks have been working on these issues for some time: we have authored several documents; and, we have running code. It would be a pity to be excluded from this meeting. We all know that QoS without security won't do the trick so we may as well start working together now. Luis > Ref: Your note of Mon, 23 Aug 1999 07:05:55 -0400 > > Subject: Re: FYI > > Bob wrote/asked w.r.t. diffserv/policy/rap meeting > > Given the interaction between policy wrt security , Diffserv and others should't > > the group also include security folks? > > > The reason we're getting these 3 WGs together is because they > have items in their charters that together will make up the > complete work for QoS. So it is to make sure QoS policy > work will be done properly and such that all pieces fit together > as one solution. So they/we have immediate need to get this > on the table. > > Also, the group is already bigger than I like, so I would prefer to > not get the IPSP people involved in this thing right now. > Of course they can provide input on the above 3 mailing lists > and they can also see the results/recomendations that will > come out of the meeting. > > Bert > From owner-ipsec@lists.tislabs.com Thu Aug 26 12:15:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA13797; Thu, 26 Aug 1999 12:15:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23428 Thu, 26 Aug 1999 13:36:14 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE236@new-exc1.ctron.com> From: "Waters, Stephen" To: ipsec@lists.tislabs.com Subject: IPSEC tunnels for LAN-to-LAN interop issue Date: Thu, 26 Aug 1999 18:36:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, An interop question for the folks out there that support LAN-to-LAN VPNs with routing. Network: Head-end-------VPN tunnel 1------- remote site 1 | -------VPN tunnel 2------- remote site 2 Assume these two VPN tunnels are carried (from the head-end) over the same T1 connection to the Internet. If I want to run RIP to both sites, these tunnels need to be treated as genuine IP interface with the head-end device. There are three models that can be used here (using the example of an IP-inIP tunnel): 1) IP tunnel device tunnels packets, IPSEC then applies transport-mode protection to the IP-in-IP packets as they leave. 2) IPSEC tunnel is modeled as an interface, and just negotiates tunnel mode and exposes the resulting tunnel as an interface. This is akin to marrying an SDP policy with an Interface. 3) IP tunnel device tunnels packets, IPSEC then applies tunnel mode protection. Option 3) seems wasteful since in most cases two identical header have been added. Option 1) is in the mould of L2TP tunnel protection and is a generalised way to protect pre-tunneled data Option 2) is mean and lean. What I want to know is what folk are doing - so I can interop. At the moment, we are opting for 1), could easily to 3) and would need to do a little tinkering to get 2) going. Cheers, Steve. From owner-ipsec@lists.tislabs.com Thu Aug 26 12:45:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA14274; Thu, 26 Aug 1999 12:45:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23508 Thu, 26 Aug 1999 14:04:41 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14277.33276.901200.407881@dee-e.isi.edu> Date: Thu, 26 Aug 1999 11:05:48 -0700 (PDT) From: Lars Eggert To: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue In-Reply-To: <29752A74B6C5D211A4920090273CA3DCCDE236@new-exc1.ctron.com> References: <29752A74B6C5D211A4920090273CA3DCCDE236@new-exc1.ctron.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- stephen> 1) IP tunnel device tunnels packets, IPSEC then applies stephen> transport-mode protection to the IP-in-IP packets as they leave. This is the option we choose for the X-Bone (http://www.isi.edu/x-bone), as the KAME and CAIRN stacks do not (yet?) support option 2. The only problem with this approach is of course that your IPsec selectors match on the outer header, i.e. there is no way to have different SAs based on the inner (virtual) addresses. For now, we circumvent this problem by encapsulating twice. stephen> 2) IPSEC tunnel is modeled as an interface, and just negotiates stephen> tunnel mode and exposes the resulting tunnel as an interface. This stephen> is akin to marrying an SDP policy with an Interface. We believe this would be the cleanest option, and we'd very much like to see it implemented. There was a discussion about this recently on the KAME snap-users mailing list (thread subject "RIP over IPsec tunnels?") accessible at http://www.kame.net/snap-users/. Lars ______________________________________________________________________________ Lars Eggert Information Sciences Institute http://www.isi.edu/~larse/ University of Southern California -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN8WB/NZcnpRveo1xAQHjegP/ZXivPv0OgBVPTb/FHPikxpy2Cp5MiTRo X8aRYO8Gm3t3tht2RSbVwhMfhh42HBhNdNyDO5DzLRHtLslMG6M7R2yt+EIvMVMx U4cMHiIpi4NPAUOhARbe+DnI3NOcOh2XREuwiiRf1RT9Hg+SbgxDYCFuRMbYz3kh p6bf2MKFY1c= =NAdw -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Aug 26 12:59:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA14592; Thu, 26 Aug 1999 12:59:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23616 Thu, 26 Aug 1999 14:30:46 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <29752A74B6C5D211A4920090273CA3DCCDE236@new-exc1.ctron.com> Date: Thu, 26 Aug 1999 14:27:40 -0400 To: "Waters, Stephen" From: Stephen Kent Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:36 PM +0100 8/26/99, Waters, Stephen wrote: >Hi, > >An interop question for the folks out there that support LAN-to-LAN VPNs >with routing. > >Network: > >Head-end-------VPN tunnel 1------- remote site 1 > | > -------VPN tunnel 2------- remote site 2 > >Assume these two VPN tunnels are carried (from the head-end) over the same >T1 connection to the Internet. > >If I want to run RIP to both sites, these tunnels need to be treated as >genuine IP interface with the head-end device. > >There are three models that can be used here (using the example of an >IP-inIP tunnel): > >1) IP tunnel device tunnels packets, IPSEC then applies transport-mode >protection to the IP-in-IP packets as they leave. Why transport mode here, vs. tunnel mode. The device looks more like an SG than an end system, does it not? Steve From owner-ipsec@lists.tislabs.com Thu Aug 26 13:00:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA14673; Thu, 26 Aug 1999 13:00:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23636 Thu, 26 Aug 1999 14:35:10 -0400 (EDT) X-Authentication-Warning: keeks-gw.cyber.ee: helger owned process doing -bs Date: Thu, 26 Aug 1999 21:35:07 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@lists.tislabs.com Subject: RSA-155 factored last weekend Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk More information is available (seen on the P1363 mailing list, for example). -------------------------------- PRESS RELEASE CWI, Amsterdam - August 26, 1999 Security of E-commerce threatened by 512-bit number factorization On August 22 1999, a team of scientists from six different countries, led by Herman te Riele of CWI (Amsterdam), found the prime factors of a 512-bit number, whose size models 95% of the keys used for protection of electronic commerce on the Internet. This result shows, much earlier than expected at the start of E-commerce, that the popular key-size of 512 bits is no longer safe against even a moderately powerful attacker. The amount of money protected by 512-bit keys is immense. Many billions of dollars per day are flowing through financial institutions such as banks and stock exchanges. The factored key is a model of a so-called "public key" in the well-known RSA cryptographic system which was designed in the mid-seventies by Rivest, Shamir and Adleman at the Massachusets Institute of Technology in Cambridge, USA. At present, this system is used extensively in hardware and software to protect electronic data traffic such as in the international version of the SSL (Security Sockets Layer) Handshake Protocol. Apart from its practical implications, the factorization is a scientific breakthrough: 25 years ago, 512-bit numbers (about 155 decimals) were thought virtually impossible to factor. Estimates based on the then-fastest known algorithms and computers predicted a CPU time of more than 50 billion (50 000 000 000) years. The factored number, indicated by RSA-155, was taken from the "RSA Challenge List", which is used as a yardstick for the security of the RSA cryptosystem. In order to find the prime factors of RSA-155, about 300 fast SGI and SUN workstations and Pentium PCs have spent about 35 years of computing time. The computers were running in parallel -- mostly overnight and at weekends -- and the whole task was finished in about seven calendar-months. The following organizations have made their workstation and PC computing power available to this project: Centre Charles Hermite (Nancy, France), Citibank (Parsippany, NJ, USA), CWI (Amsterdam), Ecole Polytechnique/CNRS (Palaiseau, France), Entrust Technologies (Ottawa, Canada), Lehigh University (Bethlehem, Pa, USA), the Medicis Center at Ecole Polytechnique (Palaiseau, France), Microsoft Research (Cambridge, UK), Sun Microsystems Professional Services (Camberley, UK), The Australian National University (Canberra, Australia), University of Sydney (Australia). In addition, an essential step of the project which requires 2 Gbytes of internal memory has been carried out on the Cray C916 supercomputer at SARA (Academic Computing Centre Amsterdam). Given the current big distributed computing projects on Internet with hundreds of thousands of participants, e.g., to break RSA's DES Challenge or trace extra-terrestrial messages, it is possible to reduce the time to factor a 512-bit number from seven months to one week. For comparison, the amount of computing time needed to factor RSA-155 was less than 2% of the time needed to break RSA's DES challenge. Coordinator of the project is Herman te Riele of CWI Amsterdam. The number and the found factors are: RSA-155 = 10941738641570527421809707322040357612003732945449205990913842131476349984288934784717997257891267332497625752899781833797076537244027146743531593354333897 = 102639592829741105772054196573991675900716567808038066803341933521790711307779 * 106603488380168454820927220360012878679207958575989291522270608237193062808643 From owner-ipsec@lists.tislabs.com Thu Aug 26 13:04:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA14895; Thu, 26 Aug 1999 13:04:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23649 Thu, 26 Aug 1999 14:36:04 -0400 (EDT) Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515879@RED-MSG-50> From: Richard Draves To: "'Waters, Stephen'" , ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Date: Thu, 26 Aug 1999 11:25:10 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 1) IP tunnel device tunnels packets, IPSEC then applies transport-mode > protection to the IP-in-IP packets as they leave. > > 2) IPSEC tunnel is modeled as an interface, and just > negotiates tunnel mode > and exposes the resulting tunnel as an interface. This is > akin to marrying > an SDP policy with an Interface. > > 3) IP tunnel device tunnels packets, IPSEC then applies tunnel mode > protection. What matters is how this looks to the other end of the tunnel. Your implementation can achieve that result however it wants. To the other end of the tunnel, shouldn't it look like / be negotiated as tunnel-mode IPSEC? Thus if I understand your options correctly, option 1 is ruled out because the packets look right on the wire but it's negotiating transport-mode instead of tunnel-mode. option 2 is OK - the packets look like IP-IPsec-IP-Transport, and it's negotiated as tunnel-mode. option 3 is ruled out because there is an extra IP header. Rich From owner-ipsec@lists.tislabs.com Thu Aug 26 13:16:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA15264; Thu, 26 Aug 1999 13:16:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23736 Thu, 26 Aug 1999 14:59:29 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14277.36563.940182.654758@dee-e.isi.edu> Date: Thu, 26 Aug 1999 12:00:35 -0700 (PDT) From: Lars Eggert To: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue In-Reply-To: References: <29752A74B6C5D211A4920090273CA3DCCDE236@new-exc1.ctron.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >> 1) IP tunnel device tunnels packets, IPSEC then applies transport-mode >> protection to the IP-in-IP packets as they leave. stephen> Why transport mode here, vs. tunnel mode. The device looks more stephen> like an SG than an end system, does it not? He wants to run RIP over the tunnels. IPsec tunnel mode (at least all implementations I have seen) is handled by packet filters/firewalls, which means the tunnel is not represented in the routing table and RIP won't see them. Using an IPIP tunnel device (which will show up in the routing table) plus IPsec transport mode is a way to circumvent this. Lars ______________________________________________________________________________ Lars Eggert Information Sciences Institute http://www.isi.edu/~larse/ University of Southern California -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN8WO09ZcnpRveo1xAQGxPQQArbJI1Y/wGLsFbMP0BXeY6+hc3pVRhCYr 22dpvc6lpNnWc7OMRJlgauKxfq8fpiCMQDOQfNj6+O7Rup5kkXvoZSwksaWTaEqE jzQBkqvIn5dm8I1EFzBJi8aMlW4wG7hI7Ik1XA88eAWpjLBMBNrRbM7BFev7JZZl InaaJ/8pIQc= =7NRI -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Aug 26 13:19:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA15366; Thu, 26 Aug 1999 13:19:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23717 Thu, 26 Aug 1999 14:56:29 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14277.36323.149834.851955@dee-e.isi.edu> Date: Thu, 26 Aug 1999 11:56:35 -0700 (PDT) From: Lars Eggert To: ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014515879@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D81014515879@RED-MSG-50> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- richard> To the other end of the tunnel, shouldn't it look like / be richard> negotiated as tunnel-mode IPSEC? Can the remote end distinguish if a tunneled IPsec packet was created by IPIP encapsulation + IPsec transport mode or IPsec tunnel mode? In either case, the incoming SA will have to match on the outer header. Also, how will an IPIP encapsulation + IPsec transport mode packet be decapsulated? By IPsec? Or by the IPIP tunnel device? This ambiguity is one of the reasons we would like to see IPsec tunnel mode be integrated with an IPIP tunnel device (option 2 in Richards mail). Lars ______________________________________________________________________________ Lars Eggert Information Sciences Institute http://www.isi.edu/~larse/ University of Southern California -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN8WN4tZcnpRveo1xAQEz/AQAtAT/UDE7WI1SqcRAmr4pT2lcF27l3aia ii81UEo+EfiWAh11UTIS3CiNlKk7o3wN7cA5KMyV2p1gkNfiM2JoCGlwh9ey038O MfGN632jqxGVkfp+o74Ew4tHx2sZidrZS62rj1VWrxCgiVp0QexqEBsaUtvyzsP+ OYhCT4OOH/8= =0KjO -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Aug 26 14:34:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA16521; Thu, 26 Aug 1999 14:33:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23911 Thu, 26 Aug 1999 16:00:29 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <14277.36323.149834.851955@dee-e.isi.edu> References: <4D0A23B3F74DD111ACCD00805F31D81014515879@RED-MSG-50> <4D0A23B3F74DD111ACCD00805F31D81014515879@RED-MSG-50> Date: Thu, 26 Aug 1999 15:55:18 -0400 To: Lars Eggert From: Stephen Kent Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Lars, >-----BEGIN PGP SIGNED MESSAGE----- > > richard> To the other end of the tunnel, shouldn't it look like / be > richard> negotiated as tunnel-mode IPSEC? > >Can the remote end distinguish if a tunneled IPsec packet was created by IPIP >encapsulation + IPsec transport mode or IPsec tunnel mode? In either case, the >incoming SA will have to match on the outer header. Yes, the outer header will be the same in either case, but transport mode calls for matching SA selectors aginst the outer IP header and the immdeiately following transport header (if port selectors are employed), whereas tunnel mode calls for matching the selectors against the inner IP and transport headers. Thus the processing si different for each case. Steve From owner-ipsec@lists.tislabs.com Thu Aug 26 14:34:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA16526; Thu, 26 Aug 1999 14:33:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23912 Thu, 26 Aug 1999 16:00:29 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <14277.36563.940182.654758@dee-e.isi.edu> References: <29752A74B6C5D211A4920090273CA3DCCDE236@new-exc1.ctron.com> Date: Thu, 26 Aug 1999 15:59:54 -0400 To: Lars Eggert From: Stephen Kent Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Lars, > >> 1) IP tunnel device tunnels packets, IPSEC then applies transport-mode > >> protection to the IP-in-IP packets as they leave. > > stephen> Why transport mode here, vs. tunnel mode. The device looks more > stephen> like an SG than an end system, does it not? > >He wants to run RIP over the tunnels. IPsec tunnel mode (at least all >implementations I have seen) is handled by packet filters/firewalls, which >means the tunnel is not represented in the routing table and RIP won't see >them. Using an IPIP tunnel device (which will show up in the routing table) >plus IPsec transport mode is a way to circumvent this. I see the basis for the concern, but the examples you cite are a result of some implementation instances, not intrinsic in the IPsec architecture. The question of how routing is implemented in a IPsec gateway is outside the scope of 2401, but the question of what mode to use in such a gateway, and what constitites a gateway vs. an end system, are addressed in 2401. Steve From owner-ipsec@lists.tislabs.com Thu Aug 26 14:39:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA16604; Thu, 26 Aug 1999 14:39:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23999 Thu, 26 Aug 1999 16:10:16 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14277.40812.742669.102648@dee-e.isi.edu> Date: Thu, 26 Aug 1999 13:11:24 -0700 (PDT) From: Lars Eggert To: ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue In-Reply-To: References: <4D0A23B3F74DD111ACCD00805F31D81014515879@RED-MSG-50> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >> Can the remote end distinguish if a tunneled IPsec packet was created by >> IPIP encapsulation + IPsec transport mode or IPsec tunnel mode? In either >> case, the incoming SA will have to match on the outer header. stephen> Yes, the outer header will be the same in either case, but stephen> transport mode calls for matching SA selectors aginst the outer IP stephen> header and the immdeiately following transport header (if port stephen> selectors are employed), whereas tunnel mode calls for matching the stephen> selectors against the inner IP and transport headers. Thus the stephen> processing si different for each case. That was my understanding for the sending side when an outgoing packet is tunneled. However, on the incoming side, the SA selectors must match against the outer header, because inner header and transport layer may be encrypted. Or am I missing something? If this is correct, I still think there is an ambiguity as to who is responsible for decapsulation. Lars ______________________________________________________________________________ Lars Eggert Information Sciences Institute http://www.isi.edu/~larse/ University of Southern California -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN8WfbNZcnpRveo1xAQEJRgP/Rwyc3PoSpTtZ12UyGi6oSDFzsy/7BUm2 nvXgiFDs+mjQ+7DnCvV0UPWXSEYyURPjtfVV5VfmJNl2OGUR+ktxCoOQmPA2qU/L HaHmItcyqTKpNC5e/yCSgwskfD55sBYmjCIAIBeWR7wFMNtr5kE6XtkzYwIYBvOu grZF9IY490M= =ty6q -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Aug 26 15:12:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA16962; Thu, 26 Aug 1999 15:12:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24144 Thu, 26 Aug 1999 16:49:53 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE23A@new-exc1.ctron.com> From: "Waters, Stephen" To: Richard Draves Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Date: Thu, 26 Aug 1999 21:48:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well, 1) still seems more 'natural'. IPIP tunnel device does its job of adding a tunnel header, and then forwards the new packet. IPSEC intercepts the packet and applies transport mode because it is now an originating packet. 2) is a hack because I no longer have an interface. IPSEC intercepts packet leaving the system, and, due to the fact that the contents is completely scrambled has to add a new header. The IPSEC-tunnel approach is a good model for client access, where no interface (interface MIB entry) is required, but when to want to run routing over an interface, it is not so useful: LAN-LAN routing model: Virtual IP Interface (with Intranet address, RIP enabled) | Tunnel 'device' - any IP-capable tunnel you like (L2TP, GRE, IPIP, others) | Real IP Interface with SPD applied | Internet Interface The virtual IP interface appears in the Interface MIB table. The Tunnel device appears in the Interface MIB table, with an associated Tunnel MIB entry. A packet arrives on some 'private' interface. It is forwarded by a routing look-up to the Virtual IP interface, from there to the lower data-link - the tunnel device - which does whatever that tunnel device does. The resulting IP packet is then put through the forwarding route engine again to be queued to a 'real' IP interface, where an IPSEC SPD policy matches the packet and applies transport-mode to protect originating traffic. The packet then proceeds to the PPP datalink, and out into the Internet. This is the model required to protect L2TP tunnels, and, I think, should be a supported way to protect all IP-capable tunnels. The question is - does anyone else support it? Can I hear from folk that can support routing over multiple tunnels (including L2TP and IPIP tunnels) with some indication on which model is used - so we can interop at some future bake-off that may cover this? Thanks, Steve. -----Original Message----- From: Richard Draves [mailto:richdr@microsoft.com] Sent: Thursday, August 26, 1999 7:25 PM To: 'Waters, Stephen'; ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue > 1) IP tunnel device tunnels packets, IPSEC then applies transport-mode > protection to the IP-in-IP packets as they leave. > > 2) IPSEC tunnel is modeled as an interface, and just > negotiates tunnel mode > and exposes the resulting tunnel as an interface. This is > akin to marrying > an SDP policy with an Interface. > > 3) IP tunnel device tunnels packets, IPSEC then applies tunnel mode > protection. What matters is how this looks to the other end of the tunnel. Your implementation can achieve that result however it wants. To the other end of the tunnel, shouldn't it look like / be negotiated as tunnel-mode IPSEC? Thus if I understand your options correctly, option 1 is ruled out because the packets look right on the wire but it's negotiating transport-mode instead of tunnel-mode. option 2 is OK - the packets look like IP-IPsec-IP-Transport, and it's negotiated as tunnel-mode. option 3 is ruled out because there is an extra IP header. Rich From owner-ipsec@lists.tislabs.com Thu Aug 26 15:15:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA16992; Thu, 26 Aug 1999 15:15:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24146 Thu, 26 Aug 1999 16:49:58 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE23B@new-exc1.ctron.com> From: "Waters, Stephen" To: Lars Eggert Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Date: Thu, 26 Aug 1999 21:48:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Many thanks for the reply Lars, very interesting (your original below still). The problem I have is that I think model 2) does not deliver LAN-LAN routing. If I have per-protocol/port policy that can create multiple IPSEC tunnels to the same remote LAN, which of these tunnels is an 'Interface'? The one that carries RIP traffic? All of them? This has consequences on routing updates, and re-routing of traffic. I am looking for a single entity like an IPIP tunnel device that can perform polling, QOS/SLA monitoring and routing to a remote router, while getting IPSEC protection on a per-packet basis. I think perhaps a new model is needed to cope: Virtual IP interface (RIP enabled) | IPIP Tunnel 'device' - with captive SPD This works as before, except that the SPD is tied to the IPIP tunnel device. The IPSEC peer is defined in the IPIP tunnel configuration, and all policies in the captive SPD relate to that peer. As IP packets are delivered to the IP tunnel device, it is passed through the captive SPD to determine what (if any) IPSEC protection is required. If none, the IP tunnel is added, and the packet sent. If transport, the IP tunnel is added, transport-mode IKE negotiated and applied, packet sent. If tunnel mode, the IP tunnel is added, tunnel mode IKE negotiated, 'transport mode' applied, packet sent. As well as forwarded traffic, the IPIP tunnel device can generate private polling messages (formatted pings say) to the peer tunnel device, and either have some default IPSEC protection applied, or put them through the captive SPD as well. RIP messages on the Virtual IP interface go the same way, and if the IPIP tunnel device detects the peer is dead, can communicate to the Virtual IP interface that the datalink is down. I think that gets us all possible combinations in the same model, with a true routing interface to play with. This is basically close interaction between the SPD and the tunnel device, and restricting the SPD to refer to the same peer for all policies, because it is subservient to the IPIP tunnel device. Thoughts? Cheers, Steve. -----Original Message----- From: Lars Eggert [mailto:larse@isi.edu] Sent: Thursday, August 26, 1999 7:06 PM To: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue -----BEGIN PGP SIGNED MESSAGE----- stephen> 1) IP tunnel device tunnels packets, IPSEC then applies stephen> transport-mode protection to the IP-in-IP packets as they leave. This is the option we choose for the X-Bone (http://www.isi.edu/x-bone), as the KAME and CAIRN stacks do not (yet?) support option 2. The only problem with this approach is of course that your IPsec selectors match on the outer header, i.e. there is no way to have different SAs based on the inner (virtual) addresses. For now, we circumvent this problem by encapsulating twice. stephen> 2) IPSEC tunnel is modeled as an interface, and just negotiates stephen> tunnel mode and exposes the resulting tunnel as an interface. This stephen> is akin to marrying an SDP policy with an Interface. We believe this would be the cleanest option, and we'd very much like to see it implemented. There was a discussion about this recently on the KAME snap-users mailing list (thread subject "RIP over IPsec tunnels?") accessible at http://www.kame.net/snap-users/. Lars ____________________________________________________________________________ __ Lars Eggert Information Sciences Institute http://www.isi.edu/~larse/ University of Southern California -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN8WB/NZcnpRveo1xAQHjegP/ZXivPv0OgBVPTb/FHPikxpy2Cp5MiTRo X8aRYO8Gm3t3tht2RSbVwhMfhh42HBhNdNyDO5DzLRHtLslMG6M7R2yt+EIvMVMx U4cMHiIpi4NPAUOhARbe+DnI3NOcOh2XREuwiiRf1RT9Hg+SbgxDYCFuRMbYz3kh p6bf2MKFY1c= =NAdw -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Aug 26 15:23:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA17063; Thu, 26 Aug 1999 15:22:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24156 Thu, 26 Aug 1999 16:50:20 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <14277.40812.742669.102648@dee-e.isi.edu> References: <4D0A23B3F74DD111ACCD00805F31D81014515879@RED-MSG-50> Date: Thu, 26 Aug 1999 16:49:59 -0400 To: Lars Eggert From: Stephen Kent Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Lars, > >> Can the remote end distinguish if a tunneled IPsec packet was created by > >> IPIP encapsulation + IPsec transport mode or IPsec tunnel mode? In either > >> case, the incoming SA will have to match on the outer header. > > stephen> Yes, the outer header will be the same in either case, but > stephen> transport mode calls for matching SA selectors aginst the outer IP > stephen> header and the immdeiately following transport header (if port > stephen> selectors are employed), whereas tunnel mode calls for matching the > stephen> selectors against the inner IP and transport headers. Thus the > stephen> processing si different for each case. > >That was my understanding for the sending side when an outgoing packet is >tunneled. However, on the incoming side, the SA selectors must match against >the outer header, because inner header and transport layer may be >encrypted. Or am I missing something? If this is correct, I still think there >is an ambiguity as to who is responsible for decapsulation. > Yes, you are missing something, but it's a subtle issue that has prompted similar messages on this list in the past. For inbound processing, one selects the right SA NOT based on selectors, but based on the dest IP address, the SPI, and the security protocol type (AH or ESP). Then one checks the processed packet against the selectors. To answer the question of which set of headers one uses in the checks, one must know whether the SA is for tunnel or transport mode, which is a part of the SAD, as per 2401. It is true that the port fields might not be accessible in the processed packet, e.g., if there is another layer of IPsec employed, and that's OK IF the SPD specifies these values as OPAQUE. Finally, after the selector comparison is done, it is also necessary to ensure that all of the required processing has been performed, by reference to the SPD or equivalent. Thus, for example, if the SPD called for this data stream to have both AH and ESP applied, one needs to ensure that both headers were present and processed, otherwise an attacker could strip off the AH and cause us to accept packets that did not meet all of the security criteria established for a given data stream. Hope this clarifies the wonderful world of inbound IPsec processing. Steve From owner-ipsec@lists.tislabs.com Thu Aug 26 15:43:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA17342; Thu, 26 Aug 1999 15:43:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24189 Thu, 26 Aug 1999 17:01:14 -0400 (EDT) Message-Id: <199908262100.OAA00933@potassium.network-alchemy.com> To: Lars Eggert cc: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue In-reply-to: Your message of "Thu, 26 Aug 1999 13:11:24 PDT." <14277.40812.742669.102648@dee-e.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <930.935701247.1@network-alchemy.com> Date: Thu, 26 Aug 1999 14:00:47 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 26 Aug 1999 13:11:24 PDT you wrote > > >> Can the remote end distinguish if a tunneled IPsec packet was created by > >> IPIP encapsulation + IPsec transport mode or IPsec tunnel mode? In eithe >r > >> case, the incoming SA will have to match on the outer header. > > stephen> Yes, the outer header will be the same in either case, but > stephen> transport mode calls for matching SA selectors aginst the outer IP > stephen> header and the immdeiately following transport header (if port > stephen> selectors are employed), whereas tunnel mode calls for matching th >e > stephen> selectors against the inner IP and transport headers. Thus the > stephen> processing si different for each case. > > That was my understanding for the sending side when an outgoing packet is > tunneled. However, on the incoming side, the SA selectors must match against > the outer header, because inner header and transport layer may be > encrypted. Or am I missing something? If this is correct, I still think there > is an ambiguity as to who is responsible for decapsulation. The selectors don't apply at that stage on the inbound side. The SA is looked up against the SPI, protocol (which would be 4), and destination address in the outer header. After decryption/decapsulation the receiver would make sure that the selector which was used in creation of the SA matches the decapsulated packet. There is no ambiguity for the receiver because the SAs are negotiated differently. After decapsulation of a tunnel mode protected packet or reconstruction of a transport mode protected packet the particular selector is applied. If it's a transport mode SA then that packet better be protocol 4 or you're supposed to drop it. If it's a tunnel mode SA then that packet better match the selector or you're supposed to drop it. Which brings up a problem in doing transport mode protected IPinIP. The selector would be for protocol 4 between the two boxes which means that _anything_ could be put into those tunnels. In tunnel mode the selector would be for whatever protocol in contained in the inner packet-- say, UDP port 520-- and then only that could be extracted from the tunnel. Dan. From owner-ipsec@lists.tislabs.com Thu Aug 26 15:49:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA17402; Thu, 26 Aug 1999 15:49:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24238 Thu, 26 Aug 1999 17:17:37 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14277.44852.326456.439496@dee-e.isi.edu> Date: Thu, 26 Aug 1999 14:18:44 -0700 (PDT) From: Lars Eggert To: ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue In-Reply-To: <29752A74B6C5D211A4920090273CA3DCCDE23B@new-exc1.ctron.com> References: <29752A74B6C5D211A4920090273CA3DCCDE23B@new-exc1.ctron.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- stephen> This works as before, except that the SPD is tied to the IPIP stephen> tunnel device. stephen> The IPSEC peer is defined in the IPIP tunnel configuration, and all stephen> policies in the captive SPD relate to that peer. stephen> As IP packets are delivered to the IP tunnel device, it is passed stephen> through the captive SPD to determine what (if any) IPSEC protection stephen> is required. stephen> If none, the IP tunnel is added, and the packet sent. stephen> If transport, the IP tunnel is added, transport-mode IKE negotiated stephen> and applied, packet sent. stephen> If tunnel mode, the IP tunnel is added, tunnel mode IKE negotiated, stephen> 'transport mode' applied, packet sent. Steve, we had essentially the same general idea of having "per-tunnel" SPDs, but have not really thought much about details. Also, I think Suresh Bhogavilli, who implemented the CAIRN IPsec stack, had plans to integrate his IPIP tunnels with the SPD. I think your proposal looks very promising. When I talked with the KAME people, they indicated they'd rather not change their current filter-based implementation too much. I believe they considered adding/deleting route entries for SPD tunnel rules. That might be another possible way of addressing this? Lars ______________________________________________________________________________ Lars Eggert Information Sciences Institute http://www.isi.edu/~larse/ University of Southern California -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN8WvNNZcnpRveo1xAQEDuwQAgKnRKPUUhfxMRKUgHUsK0zTdRrTrS1fY e3QxXRLMjmh4RxjX8hMqc0kK1T41v5nPSKquG0WJSmED5sufKpCekWRXcH2hpqTQ +XpsLmbBUxQsu+oceuRq3GYhvo8A6BCAUim99mPZW+CUEURQ3a5fyWiINjPJ18M2 vnDvD6Ly/e4= =qz1w -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Aug 26 16:27:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA18589; Thu, 26 Aug 1999 16:27:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24398 Thu, 26 Aug 1999 18:01:18 -0400 (EDT) Date: Thu, 26 Aug 1999 18:02:22 -0400 Message-Id: <199908262202.SAA13310@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Stephen.Waters@cabletron.com Cc: richdr@microsoft.com, ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue References: <29752A74B6C5D211A4920090273CA3DCCDE23A@new-exc1.ctron.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Waters," == Waters, Stephen writes: Waters,> 2) is a hack because I no longer have an interface. IPSEC Waters,> intercepts packet leaving the system, and, due to the fact Waters,> that the contents is completely scrambled has to add a new Waters,> header. Waters,> -----Original Message----- From: Richard Draves >> 1) IP tunnel device tunnels packets, IPSEC then applies >> transport-mode protection to the IP-in-IP packets as they leave. >> >> 2) IPSEC tunnel is modeled as an interface, and just negotiates >> tunnel mode and exposes the resulting tunnel as an interface. This >> is akin to marrying an SDP policy with an Interface. >> >> 3) IP tunnel device tunnels packets, IPSEC then applies tunnel >> mode protection. I'm not sure why you call (2) a hack. It is a perfectly reasonable way of doing things. Why did you say "I no longer have an interface"? (2) is, approximately, what we do in our product. One consequence is that routing protocols (RIP, OSPF, etc.) work normally across tunnels. paul From owner-ipsec@lists.tislabs.com Thu Aug 26 16:27:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA18598; Thu, 26 Aug 1999 16:27:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24499 Thu, 26 Aug 1999 18:16:58 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE23F@new-exc1.ctron.com> From: "Waters, Stephen" To: Lars Eggert Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Date: Thu, 26 Aug 1999 23:17:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On the receiving side, when transport mode is used to protect IP-in-IP or L2TP traffic, IPSEC is responsible for extracting the IPSEC headers, and the remaining packet is delivered to a local protocol listener on the SG - an L2TP or IPIP tunnel demultiplexor, and from there to the Virtual IP interface 'above' with full routing interface status. If IPSEC packets arrive at the SG, IPSEC's job is to take of an IP header and the IPSEC headers. For Intranet packets that are being routed between to LANs, what remains is a pure Intranet packet, with no convenient mechanism to count against a virtual IP interface, e.g. increment counters in an Interface MIB entry. If you think of an IP-IP tunnel with transport-mode protection as 'PPP with ECP', that is the effect I am after: IP Interface - RIP on | PPP - ECP DES IP packets have PPP header added by the PPP device, and are then ECP protected. Replace the PPP/ECP with IP-in-IP tunnel+transport mode, and you have the same result. IPSEC decrypts, IP-in-IP tunnel takes off the 'data-link' (just happens to be an IP header), and the datalink send the encapsulated IP packet 'up' to the IP/routing interface. If you are contented to protect all traffic between VPN LAN-LAN in with the same level of security (all 3DES+SHA+IPCOMP), then this model works fine, fits well with traditional router architecture, provides a common approach for all tunnel protocols, and offers the possibility of an empty SPD and no outbound policy lookups to do! The empty SPD thing: Consider a host that opens a TCP connection to a remote peer. There is no reason why it should not request an IPSEC policy to be created dynamically for each unique 'flow'. For example, TCP request a transport-mode policy to be protected to protect src:1.2.3.4/dst:4.3.2.1,prot:TCP,src-port:10,dst-port:20. IPSEC sets up the policy, returns a handle to it that TCP quotes for each packet sent, and there you have it - no predefined SPD, just a dynamic one. This model could be used in the same way by 'originating' tunnel (IPIP,L2TP,GRE) traffic on a Security Gateway. Steve. -----Original Message----- From: Lars Eggert [mailto:larse@isi.edu] Sent: Thursday, August 26, 1999 9:11 PM To: ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue -----BEGIN PGP SIGNED MESSAGE----- >> Can the remote end distinguish if a tunneled IPsec packet was created by >> IPIP encapsulation + IPsec transport mode or IPsec tunnel mode? In either >> case, the incoming SA will have to match on the outer header. stephen> Yes, the outer header will be the same in either case, but stephen> transport mode calls for matching SA selectors aginst the outer IP stephen> header and the immdeiately following transport header (if port stephen> selectors are employed), whereas tunnel mode calls for matching the stephen> selectors against the inner IP and transport headers. Thus the stephen> processing si different for each case. That was my understanding for the sending side when an outgoing packet is tunneled. However, on the incoming side, the SA selectors must match against the outer header, because inner header and transport layer may be encrypted. Or am I missing something? If this is correct, I still think there is an ambiguity as to who is responsible for decapsulation. Lars ____________________________________________________________________________ __ Lars Eggert Information Sciences Institute http://www.isi.edu/~larse/ University of Southern California -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN8WfbNZcnpRveo1xAQEJRgP/Rwyc3PoSpTtZ12UyGi6oSDFzsy/7BUm2 nvXgiFDs+mjQ+7DnCvV0UPWXSEYyURPjtfVV5VfmJNl2OGUR+ktxCoOQmPA2qU/L HaHmItcyqTKpNC5e/yCSgwskfD55sBYmjCIAIBeWR7wFMNtr5kE6XtkzYwIYBvOu grZF9IY490M= =ty6q -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Aug 26 16:35:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA18870; Thu, 26 Aug 1999 16:35:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24533 Thu, 26 Aug 1999 18:27:00 -0400 (EDT) From: Dan McDonald Message-Id: <199908262227.PAA19120@kebe.Eng.Sun.COM> Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue To: ipsec@lists.tislabs.com Date: Thu, 26 Aug 1999 15:27:24 -0700 (PDT) Cc: larse@ISI.EDU, dharkins@network-alchemy.com In-Reply-To: <199908262100.OAA00933@potassium.network-alchemy.com> from "Dan Harkins" at Aug 26, 99 02:00:47 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@lists.tislabs.com Precedence: bulk > Which brings up a problem in doing transport mode protected IPinIP. The > selector would be for protocol 4 between the two boxes which means that > _anything_ could be put into those tunnels. Some may have viewed that as a feature, but I'm well past that point myself... > In tunnel mode the selector would be for whatever protocol in contained in > the inner packet-- say, UDP port 520-- and then only that could be > extracted from the tunnel. Which means if you implement a tunnel as an interface, the tunnel interface will also have to become a policy enforcement point. This problem is in transport-mode already, BTW. TCP detaches connections when they close, so you don't have convienient socket state to look around for cached policy. Not just IP, or generic BSD-style inpcb demuxing, but TCP itself also has to look at the IPsec processing applied to the inbound packet, match it against any TCP retransmit state for those dying connections, and make a decision. (Not to mention little details like sending RSTs to ports that aren't there, etc.) This can apply analogously to a tunnel driver/module/whatever. It's a b*tch to implement right, but it's the only way to really enforce per-flow tunnel policy. Dan From owner-ipsec@lists.tislabs.com Thu Aug 26 16:35:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA18888; Thu, 26 Aug 1999 16:35:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24552 Thu, 26 Aug 1999 18:32:52 -0400 (EDT) Message-Id: <199908262233.PAA01225@potassium.network-alchemy.com> To: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue In-reply-to: Your message of "Thu, 26 Aug 1999 14:00:47 PDT." <199908262100.OAA00933@potassium.network-alchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1222.935706785.1@network-alchemy.com> Date: Thu, 26 Aug 1999 15:33:05 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 26 Aug 1999 14:00:47 PDT I wrote > > > > That was my understanding for the sending side when an outgoing packet is > > tunneled. However, on the incoming side, the SA selectors must match agains >t > > the outer header, because inner header and transport layer may be > > encrypted. Or am I missing something? If this is correct, I still think the >re > > is an ambiguity as to who is responsible for decapsulation. > > The selectors don't apply at that stage on the inbound side. The SA is > looked up against the SPI, protocol (which would be 4), and destination ^^^^^^^^^^^^^^^^^^ BBBZZZzzzttt! Wrong answer! Protocol is the IPSec protocol (AH or ESP), not the protocol of the protected packet. Dan. From owner-ipsec@lists.tislabs.com Thu Aug 26 17:33:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA20293; Thu, 26 Aug 1999 17:33:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24658 Thu, 26 Aug 1999 19:08:35 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE241@new-exc1.ctron.com> From: "Waters, Stephen" To: Paul Koning Cc: richdr@microsoft.com, ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Date: Thu, 26 Aug 1999 23:45:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul, I hope I have managed to explained clearly why the model of an IPIP tunnel device (or any other IP-capable tunnel) that then has transport mode protection added works for routing interfaces, can you have a crack at defining how Intranet packets that has IPSEC tunnel encapsulation added can be modeled as a LAN-LAN routing interface? I have tried, and it always seems to come out 'hacky'. The concern I have is that some folk have done it one way, and some another, and they will not interwork. Some will say "I want to send you RIP, but it must be with transport-mode", and others will say "no, tunnel mode". The mad thing is, both are identical, but the decapsulation logic is very different. Cheers, Steve. -----Original Message----- From: Paul Koning [mailto:pkoning@xedia.com] Sent: Thursday, August 26, 1999 11:02 PM To: Stephen.Waters@cabletron.com Cc: richdr@microsoft.com; ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue >>>>> "Waters," == Waters, Stephen writes: Waters,> 2) is a hack because I no longer have an interface. IPSEC Waters,> intercepts packet leaving the system, and, due to the fact Waters,> that the contents is completely scrambled has to add a new Waters,> header. Waters,> -----Original Message----- From: Richard Draves >> 1) IP tunnel device tunnels packets, IPSEC then applies >> transport-mode protection to the IP-in-IP packets as they leave. >> >> 2) IPSEC tunnel is modeled as an interface, and just negotiates >> tunnel mode and exposes the resulting tunnel as an interface. This >> is akin to marrying an SDP policy with an Interface. >> >> 3) IP tunnel device tunnels packets, IPSEC then applies tunnel >> mode protection. I'm not sure why you call (2) a hack. It is a perfectly reasonable way of doing things. Why did you say "I no longer have an interface"? (2) is, approximately, what we do in our product. One consequence is that routing protocols (RIP, OSPF, etc.) work normally across tunnels. paul From owner-ipsec@lists.tislabs.com Thu Aug 26 17:50:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA20647; Thu, 26 Aug 1999 17:50:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24723 Thu, 26 Aug 1999 19:37:44 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE242@new-exc1.ctron.com> From: "Waters, Stephen" To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Date: Fri, 27 Aug 1999 00:38:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I can appreciate how 'ACL-routing' can provide traffic selection with IPSEC, but I can't model an routing interface (RIP instance) onto IPSEC without separating the IPIP tunnel part into a device, and then protecting that with transport-mode (or tunnel mode - but that adds too many headers). Yes, the traffic protected across this LAN-LAN tunnels covers all traffic that the IP tunnel was willing to encapsulate - it make negotiating the IPSEC selectors nice and easy :) If you want to exclude traffic inbound or outbound, you can use standard packet filtering on the Virtual IP/routing interface 'above' the IPIP tunnel - these packet filters are capable of expressing far more sophisticated filters than can be expressed by an IPSEC tunnel anyway. If the alternative is to specify an IPSEC policy/tunnel that uses 'Intranet selectors', what will those selectors say? I am running routing because I want to discover what is there, not have to define it up front. To discover and use, the IPSEC-tunnel policy would need to be wide-open, and then we are back to the same place of having a single 'pipe' to a remote router. The [IPIP tunnel+tranposrt-mode IPSEC] model could be used to remove the need to negotiate payload description in IKE at all, and could also remove the need to define an SPD. If the peer address on the IPIP tunnel is unique (for most cases, this is true), you can run with no configured SPD, and, IKE permitting, you arrange a transport-mode pipe between a unique src/dest defaulting to the addresses specified on the IKE packets. For sites that you do not want to exchange routing with (SOHO, extranet) and for client access (don't even want an interface for these), then 'ACL-routing' is fine. I'm open minded (I hope) on this, I just want LAN-LAN routing to interop. If someone can model an IPSEC-tunnel policy approach that works as a routing interface, I'm happy to go along. Cheers, Steve. -----Original Message----- From: Dan Harkins [mailto:dharkins@network-alchemy.com] Sent: Thursday, August 26, 1999 10:01 PM To: Lars Eggert Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue On Thu, 26 Aug 1999 13:11:24 PDT you wrote > > >> Can the remote end distinguish if a tunneled IPsec packet was created by > >> IPIP encapsulation + IPsec transport mode or IPsec tunnel mode? In eithe >r > >> case, the incoming SA will have to match on the outer header. > > stephen> Yes, the outer header will be the same in either case, but > stephen> transport mode calls for matching SA selectors aginst the outer IP > stephen> header and the immdeiately following transport header (if port > stephen> selectors are employed), whereas tunnel mode calls for matching th >e > stephen> selectors against the inner IP and transport headers. Thus the > stephen> processing si different for each case. > > That was my understanding for the sending side when an outgoing packet is > tunneled. However, on the incoming side, the SA selectors must match against > the outer header, because inner header and transport layer may be > encrypted. Or am I missing something? If this is correct, I still think there > is an ambiguity as to who is responsible for decapsulation. The selectors don't apply at that stage on the inbound side. The SA is looked up against the SPI, protocol (which would be 4), and destination address in the outer header. After decryption/decapsulation the receiver would make sure that the selector which was used in creation of the SA matches the decapsulated packet. There is no ambiguity for the receiver because the SAs are negotiated differently. After decapsulation of a tunnel mode protected packet or reconstruction of a transport mode protected packet the particular selector is applied. If it's a transport mode SA then that packet better be protocol 4 or you're supposed to drop it. If it's a tunnel mode SA then that packet better match the selector or you're supposed to drop it. Which brings up a problem in doing transport mode protected IPinIP. The selector would be for protocol 4 between the two boxes which means that _anything_ could be put into those tunnels. In tunnel mode the selector would be for whatever protocol in contained in the inner packet-- say, UDP port 520-- and then only that could be extracted from the tunnel. Dan. From owner-ipsec@lists.tislabs.com Thu Aug 26 18:31:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA27387; Thu, 26 Aug 1999 18:31:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24846 Thu, 26 Aug 1999 20:21:54 -0400 (EDT) Message-Id: <199908270019.RAA01760@potassium.network-alchemy.com> To: "Waters, Stephen" cc: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue In-reply-to: Your message of "Fri, 27 Aug 1999 00:38:02 BST." <29752A74B6C5D211A4920090273CA3DCCDE242@new-exc1.ctron.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1757.935713180.1@network-alchemy.com> Date: Thu, 26 Aug 1999 17:19:41 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Perhaps RIP is not the right tool for this job. Can't you run BGP between the SGWs? Dan. On Fri, 27 Aug 1999 00:38:02 BST you wrote > I can appreciate how 'ACL-routing' can provide traffic selection with IPSEC, > but I can't model an routing interface (RIP instance) onto IPSEC without > separating the IPIP tunnel part into a device, and then protecting that with > transport-mode (or tunnel mode - but that adds too many headers). > > Yes, the traffic protected across this LAN-LAN tunnels covers all traffic > that the IP tunnel was willing to encapsulate - it make negotiating the > IPSEC selectors nice and easy :) If you want to exclude traffic inbound or > outbound, you can use standard packet filtering on the Virtual IP/routing > interface 'above' the IPIP tunnel - these packet filters are capable of > expressing far more sophisticated filters than can be expressed by an IPSEC > tunnel anyway. > > If the alternative is to specify an IPSEC policy/tunnel that uses 'Intranet > selectors', what will those selectors say? I am running routing because I > want to discover what is there, not have to define it up front. To discover > and use, the IPSEC-tunnel policy would need to be wide-open, and then we are > back to the same place of having a single 'pipe' to a remote router. > > The [IPIP tunnel+tranposrt-mode IPSEC] model could be used to remove the > need to negotiate payload description in IKE at all, and could also remove > the need to define an SPD. If the peer address on the IPIP tunnel is unique > (for most cases, this is true), you can run with no configured SPD, and, IKE > permitting, you arrange a transport-mode pipe between a unique src/dest > defaulting to the addresses specified on the IKE packets. > > For sites that you do not want to exchange routing with (SOHO, extranet) and > for client access (don't even want an interface for these), then > 'ACL-routing' is fine. > > I'm open minded (I hope) on this, I just want LAN-LAN routing to interop. If > someone can model an IPSEC-tunnel policy approach that works as a routing > interface, I'm happy to go along. > > Cheers, Steve. From owner-ipsec@lists.tislabs.com Fri Aug 27 06:48:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA15715; Fri, 27 Aug 1999 06:48:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26514 Fri, 27 Aug 1999 08:09:52 -0400 (EDT) Message-Id: <37C68118.88C63A5F@radguard.com> Date: Fri, 27 Aug 1999 15:14:16 +0300 From: Yael Dayan Organization: Radguard X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,hebrew Mime-Version: 1.0 To: Valery Smyslov Cc: ipsec@lists.tislabs.com, Ari Huttunen Subject: Re: attack on identity protection in IKE References: <199908260856.MAA29892@relay1.trustworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov wrote: > ... Preshared keys do protect, while digital signatures don't. > Preshared keys don't either, but not because of an attack. The identity of the initiator is it's IP address, otherwise, the responder will not know which preshared key to use to decrypt the fifth message. > > > Anybody capable of sending / receiving IP packets > > corresponding to the real responder will be able to > > get that identity. This does not apply to either > > encryption mode. > > Correct. > > > Ari > > Regards, > Valery Smyslov. > > > > > Derek Atkins wrote: > > > > > You can always see the IP address of the IKE hosts. But that's ok. > > > The question is: can you see the identity of the authenticated entity > > > (be it a host identification or user indentification)? The answer > > > is: no. IKE isn't using raw RSA on the identity, that would be > > > stupid (and insecure, as you point out). It would also lead to > > > traffic-analysis attacks, where the same identity would encrypt to > > > the same ciphertext. PKCS solves both of these problems, as already > > > mentioned, by adding random padding to extend the actual message > > > out to the size of the RSA key. > > > > > > -derek > > > > > > pau@watson.ibm.com writes: > > > > > > > > Date: Tue, 24 Aug 1999 11:25:59 +0800 (SGT) > > > > > From: Jianying Zhou > > > > > To: ipsec@lists.tislabs.com > > > > > Cc: Jianying Zhou > > > > > Subject: attack on identity protection in IKE > > > > > > > > > > Identity protection is a feature of the main mode protocol. However, > > > > > an attack is possible for the main mode protocol using public key > > > > > encryption for authentication (when RSA is the encryption algorithm). > > > > > > > > > > In that protocol, the peer's identity payload is encrypted with the > > > > > other party's public key. When the ID is only a 32-bit IP address, > > > > > it is easy to find the encrypted ID by the brute force attack. > > > > > > > > Yes. But IP addess is exposed anyway. It is in the IP header. > > > > > > > > > > The main mode protocol using revised mode of public key encryption > > > > > does not suffer from the attack. > > > > > > > > > > Jianying > > > > > --------------------------------------------------------------------- > > > > > Dr. Jianying Zhou | Tel: +65-8742585 > > > > > Kent Ridge Digital Labs | Fax: +65-7744990 > > > > > 21 Heng Mui Keng Terrace | Email: jyzhou@krdl.org.sg > > > > > Singapore 119613 | WWW: http://www.krdl.org.sg > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > > > > -- > > > 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 N1NWH > > > warlord@MIT.EDU PGP key available > > > > -- > > Ari Huttunen GSM: +358 40 5524634 > > Senior Software Engineer fax : +358 9 8599 xxxx > > > > Data Fellows Corporation http://www.DataFellows.com > > > > F-Secure products: Integrated Solutions for Enterprise Security > > > > > > From owner-ipsec@lists.tislabs.com Fri Aug 27 07:05:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA17363; Fri, 27 Aug 1999 07:05:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26680 Fri, 27 Aug 1999 08:45:37 -0400 (EDT) Message-Id: <199908271246.QAA16668@relay1.trustworks.com> Comments: Authenticated sender is From: "Valery Smyslov" Organization: TWS To: Yael Dayan Date: Fri, 27 Aug 1999 16:46:08 +4 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: attack on identity protection in IKE CC: ipsec@lists.tislabs.com, Ari Huttunen In-reply-to: <37C68118.88C63A5F@radguard.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 27 Aug 99 at 15:14, Yael Dayan wrote: > Valery Smyslov wrote: > > > ... Preshared keys do protect, while digital signatures don't. > > > > Preshared keys don't either, but not because of an attack. > The identity of the initiator is it's IP address, otherwise, the responder will > not know which preshared key to use to decrypt the fifth message. It need not necessary be so. The problem of selecting a proper key is a different issue and, under some circumstances, can be solved by different means. Eventually, responder can try every key he has (trying to decrypt fifth message and to verify HASH_I) untill he finds the key. After that he gets IDii and can verify whether the key he used does really belongs to initiator. In this case IDii can be of any type and is not exposed to attacker. This is NOT a good approach due to its non-scalability, but it is quite allowable. Note also, that with group shared secret individual identity does not exposed also (in this case attacker may only learn that somebody from the group is participating, but not who exactly). Regards, Valera. > > > Anybody capable of sending / receiving IP packets > > > corresponding to the real responder will be able to > > > get that identity. This does not apply to either > > > encryption mode. > > > > Correct. > > > > > Ari > > > > Regards, > > Valery Smyslov. > > > > > > > > Derek Atkins wrote: > > > > > > > You can always see the IP address of the IKE hosts. But that's ok. > > > > The question is: can you see the identity of the authenticated entity > > > > (be it a host identification or user indentification)? The answer > > > > is: no. IKE isn't using raw RSA on the identity, that would be > > > > stupid (and insecure, as you point out). It would also lead to > > > > traffic-analysis attacks, where the same identity would encrypt to > > > > the same ciphertext. PKCS solves both of these problems, as already > > > > mentioned, by adding random padding to extend the actual message > > > > out to the size of the RSA key. > > > > > > > > -derek > > > > > > > > pau@watson.ibm.com writes: > > > > > > > > > > Date: Tue, 24 Aug 1999 11:25:59 +0800 (SGT) > > > > > > From: Jianying Zhou > > > > > > To: ipsec@lists.tislabs.com > > > > > > Cc: Jianying Zhou > > > > > > Subject: attack on identity protection in IKE > > > > > > > > > > > > Identity protection is a feature of the main mode protocol. However, > > > > > > an attack is possible for the main mode protocol using public key > > > > > > encryption for authentication (when RSA is the encryption algorithm). > > > > > > > > > > > > In that protocol, the peer's identity payload is encrypted with the > > > > > > other party's public key. When the ID is only a 32-bit IP address, > > > > > > it is easy to find the encrypted ID by the brute force attack. > > > > > > > > > > Yes. But IP addess is exposed anyway. It is in the IP header. > > > > > > > > > > > > The main mode protocol using revised mode of public key encryption > > > > > > does not suffer from the attack. > > > > > > > > > > > > Jianying > > > > > > --------------------------------------------------------------------- > > > > > > Dr. Jianying Zhou | Tel: +65-8742585 > > > > > > Kent Ridge Digital Labs | Fax: +65-7744990 > > > > > > 21 Heng Mui Keng Terrace | Email: jyzhou@krdl.org.sg > > > > > > Singapore 119613 | WWW: http://www.krdl.org.sg > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > -- > > > > 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 N1NWH > > > > warlord@MIT.EDU PGP key available > > > > > > -- > > > Ari Huttunen GSM: +358 40 5524634 > > > Senior Software Engineer fax : +358 9 8599 xxxx > > > > > > Data Fellows Corporation http://www.DataFellows.com > > > > > > F-Secure products: Integrated Solutions for Enterprise Security > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Fri Aug 27 08:43:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA26564; Fri, 27 Aug 1999 08:43:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26980 Fri, 27 Aug 1999 09:54:16 -0400 (EDT) Message-ID: <37C69972.A6AFE92C@ibm.net> Date: Fri, 27 Aug 1999 09:58:10 -0400 From: Mike Williams X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IPSec Subject: IPCOMP Questions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a couple of easy questions with regards to IPCOMP. 1) When IPCOMP is negotiated with ISAKMP, what is used for the SPI in the proposal payload? My assumption is that SPIs are not exchanged, therefore the SPI size would be set to 0. My first guess was that the CPI (per RFC2393) would be sent as the SPI, however this does not make sense if the proposal contained different IPCOMP transforms. 2) What IPCOMP transforms use the Compress Dictionary Size attribute defined in IPSec DOI (RFC 2407)? From what I can tell, neither DEFLATE or LZS use this attribute. Thanks, Mike Williams From owner-ipsec@lists.tislabs.com Fri Aug 27 09:06:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA27853; Fri, 27 Aug 1999 09:06:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27087 Fri, 27 Aug 1999 10:33:31 -0400 (EDT) Date: Fri, 27 Aug 1999 10:34:00 -0400 Message-Id: <199908271434.KAA08666@brill.shiva.com> From: John Shriver To: dharkins@network-alchemy.com CC: Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com In-reply-to: <199908270019.RAA01760@potassium.network-alchemy.com> (message from Dan Harkins on Thu, 26 Aug 1999 17:19:41 -0700) Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To: "Waters, Stephen" cc: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue Date: Thu, 26 Aug 1999 17:19:41 -0700 From: Dan Harkins Perhaps RIP is not the right tool for this job. Can't you run BGP between the SGWs? Dan. The fundamental challenge is that we have redefined the IP protocol in adding IPSec to it. Packets are no longer forwarded based soley on their IP address. A security gateway has to forward packets at the connection level. This isn't IP, it's more like X.25 (with IKE as the call setup protocol). There is no defined IP routing protocol that routes to the connection level. Not RIP, not OSPF, not IGRP, not EGP, not GGP, not Dual IS-IS, not (please no!) BGP4. So, a "brutally honest" IP Security Gateway can only use static routes. (At least if each IPSec tunnel mode "connection" is an interface.) Anything else will violate RFC 2401. We've basically made a certain set of IP routers connection-oriented. If you want to stick with tunnel mode IPSec, and run real dynamic routing between a pair of security gateways, what I've figured you do is aggregate all the tunnel mode SA's between the two SG's into one "interface" that you present to the IP forwarder. One of those SA's has to be a tunnel (or transport?) one that allows the routing protocol itself to pass between the two SG's. Then, once it's time to forward a packet over the "interface", something below the IP forwarder picks the right SA in the SAD to send it over. If there is no SA (or entry in the SPD allowing the creation of the SA), then you drop the packet. Also, the user could configure the SPD with a rule of "everything I learn from OSPF as a type 1 internal route from this peer SG is allowable in the SPD, using these transforms." Now, what I think the market will do for Intranet over Internet LAN-to-LAN connections (due to Windows 2000) is use transport mode between security gateways, and run L2TP inside that, with IP over PPP inside L2TP. This lets them run their favorite IGP over that IP "interface". Now they have something just like their leased line, but it runs over a shared IP network between the sites. All the SPD says is that "L2TP is allowed in transport mode to/from these peer SGs". But, this is only suitable for a security gateway that will only speak to preconfigured peer security gateways under the same administrative ownership. It's not suitable for a security gateway that has an SPD or policy allowing it to "talk to strangers". (That's the general case that nobody has figured out how to practically express policy for yet, so it's just not happening yet.) From owner-ipsec@lists.tislabs.com Fri Aug 27 10:43:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA05784; Fri, 27 Aug 1999 10:43:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27318 Fri, 27 Aug 1999 12:11:23 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE252@new-exc1.ctron.com> From: "Waters, Stephen" To: John Shriver Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Date: Fri, 27 Aug 1999 17:11:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi John, I think I disagree with the statement that "Anything else will violate RFC 2401". A security gateway is perfectly entitled to protected 'originating traffic' with transport-mode, and if the traffic source is a tunnel device (IPIP, L2TP, GRE...), then IPSEC can quite fairly protect this with transport mode to a remote peer/security gateway: " Note that for the case where traffic is destined for a security gateway, e.g., SNMP commands, the security gateway is acting as a host and transport mode is allowed." It is convenient, I think, to model generic traffic between two security gateways as transport-mode, regardless of the protocol. The model you suggest below of a routing interface being represented by a 'collection of IPSEC SA going to the same peer' has some problems as a model, I think: o when has the interface failed, such that re-routing can occur? o you need to explicitly ensure that routing traffic can be exchanged, and this may depend on matching policy ordering o According to RFC 2401, IPSEC tunnel mode strips a header, and removes ESP/AH/IPCOMP. How do you then find the 'interface' to count this against? o how do I apply interface specific packet filtering to this 'interface'? o and so on... Basically, this is difficult to model, difficult to manage, and difficult to explain to customers. Whereas, an IPIP tunnel device that then has transport-mode protection applied, is not. Outbound processing: o Packet is forwarded to a Virtual IP interface which has an Intranet address, and RIP enabled. o Packet is queued to the data-link (generic tunnel device) o Tunnel device does the tunnel job, and delivers the packet to IP forwarding as a generated packet. o Packet is routed to a real IP interface (say, to the Internet ISP) o SPD on this interface enforces transport-mode protection o packet is sent to data-link (say PPP), and out into the Internet. Inbound processing: o IP packet arrives from Internet connection o SA look-up done, finds transport-mode policy o ESP or AH striped out to reveal an IP packet with next-prot of IP-in-IP (or whatever the tunnel is) addressed to a local IP address o packet delivered to the 'protocol listeners' o Tunnel demuxer delivers the tunnel packet to the appropriate tunnel device o tunnel device strips tunnel overhead, updates counters on device interface o tunnel device delivers resulting data 'up' to the Virtual IP interface o packet counted on virtual IP interface o packet put back to IP forwarder Cheers, Steve. -----Original Message----- From: John Shriver [mailto:jas@shiva.com] Sent: Friday, August 27, 1999 3:34 PM To: dharkins@network-alchemy.com Cc: Stephen.Waters@cabletron.com; ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue To: "Waters, Stephen" cc: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue Date: Thu, 26 Aug 1999 17:19:41 -0700 From: Dan Harkins Perhaps RIP is not the right tool for this job. Can't you run BGP between the SGWs? Dan. The fundamental challenge is that we have redefined the IP protocol in adding IPSec to it. Packets are no longer forwarded based soley on their IP address. A security gateway has to forward packets at the connection level. This isn't IP, it's more like X.25 (with IKE as the call setup protocol). There is no defined IP routing protocol that routes to the connection level. Not RIP, not OSPF, not IGRP, not EGP, not GGP, not Dual IS-IS, not (please no!) BGP4. So, a "brutally honest" IP Security Gateway can only use static routes. (At least if each IPSec tunnel mode "connection" is an interface.) Anything else will violate RFC 2401. We've basically made a certain set of IP routers connection-oriented. If you want to stick with tunnel mode IPSec, and run real dynamic routing between a pair of security gateways, what I've figured you do is aggregate all the tunnel mode SA's between the two SG's into one "interface" that you present to the IP forwarder. One of those SA's has to be a tunnel (or transport?) one that allows the routing protocol itself to pass between the two SG's. Then, once it's time to forward a packet over the "interface", something below the IP forwarder picks the right SA in the SAD to send it over. If there is no SA (or entry in the SPD allowing the creation of the SA), then you drop the packet. Also, the user could configure the SPD with a rule of "everything I learn from OSPF as a type 1 internal route from this peer SG is allowable in the SPD, using these transforms." Now, what I think the market will do for Intranet over Internet LAN-to-LAN connections (due to Windows 2000) is use transport mode between security gateways, and run L2TP inside that, with IP over PPP inside L2TP. This lets them run their favorite IGP over that IP "interface". Now they have something just like their leased line, but it runs over a shared IP network between the sites. All the SPD says is that "L2TP is allowed in transport mode to/from these peer SGs". But, this is only suitable for a security gateway that will only speak to preconfigured peer security gateways under the same administrative ownership. It's not suitable for a security gateway that has an SPD or policy allowing it to "talk to strangers". (That's the general case that nobody has figured out how to practically express policy for yet, so it's just not happening yet.) From owner-ipsec@lists.tislabs.com Fri Aug 27 10:44:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA05799; Fri, 27 Aug 1999 10:44:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27411 Fri, 27 Aug 1999 12:24:21 -0400 (EDT) Message-Id: <3.0.5.32.19990827192558.00c9b100@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 27 Aug 1999 19:25:58 +0300 To: IPSec From: Joern Sierwald Subject: Re: IPCOMP Questions In-Reply-To: <37C69972.A6AFE92C@ibm.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA27408 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:58 27.8.1999 -0400, Mike Williams wrote: >I have a couple of easy questions with regards to IPCOMP. > >1) When IPCOMP is negotiated with ISAKMP, what is used for the SPI in >the proposal payload? My assumption is that SPIs are not exchanged, >therefore the SPI size would be set to 0. My first guess was that the >CPI (per RFC2393) would be sent as the SPI, Send the CPI as SPI. SPI size should be 2 bytes, at least that was the common opinion at the last interop. In case of deflate that would be "0x00 0x02". >however this does not make >sense if the proposal contained different IPCOMP transforms. > Yea. If you want that, two possibilities: 1) Use random numbers for CPI, not the algorithm number. I've seen Timestep doing this. 2) Start a new proposal. (3DES and (deflate or lzs)) would be like Proposal 0, protocol ESP, transform 3DES Proposal 0, protocol IPCOMP, transform deflate Proposal 1, protocol ESP, transform 3DES Proposal 1, protocol IPCOMP, transform lzs. I've seen our implementation doing this. RFC2408, chapter 4.2. Jörn From owner-ipsec@lists.tislabs.com Fri Aug 27 12:10:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA11517; Fri, 27 Aug 1999 12:10:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27560 Fri, 27 Aug 1999 13:16:48 -0400 (EDT) Date: Fri, 27 Aug 1999 13:16:55 -0400 Message-Id: <199908271716.NAA08724@brill.shiva.com> From: John Shriver To: Stephen.Waters@cabletron.com CC: ipsec@lists.tislabs.com In-reply-to: <29752A74B6C5D211A4920090273CA3DCCDE252@new-exc1.ctron.com> (Stephen.Waters@cabletron.com) Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, what I think people want today for Security Gateways is VPN tunnel portals, with pre-defined point-to-point links. That's why we're going to see of lot of IP over PPP over L2TP over IPSec transport. PPP also addresses the link-up detection issue. Use echo request and reply, or full LQM. (Or trust OSPF hellos to detect what matters.) This won't address the issue of a Security Gateway at company A that wants to let host 2 at company B access host 1 in company A. But I think that involves many unsolved policy issues. (How do I know I should trust host 2. What if company B wants to keep the trustedness of host 2 a secret? What if company A wants to keep the accesibility of host 1 a secret from everyone but company B? Nightmare...) From owner-ipsec@lists.tislabs.com Fri Aug 27 14:21:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA14004; Fri, 27 Aug 1999 14:21:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28067 Fri, 27 Aug 1999 15:58:07 -0400 (EDT) Message-Id: <37C6EE12.65D97DBC@xedia.com> Date: Fri, 27 Aug 1999 15:59:14 -0400 From: Eric Bomarsi Organization: xedia.com X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: "Waters, Stephen" Cc: John Shriver , ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue References: <29752A74B6C5D211A4920090273CA3DCCDE252@new-exc1.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Waters, Stephen" wrote: > The model you suggest below of a routing interface being represented by a > 'collection of IPSEC SA going to the same peer' has some problems as a > model, I think: ... > > > Basically, this is difficult to model, difficult to manage, and difficult to > explain to customers. > Stephen, I don't think that's true. The Xedia router aggregates tunnels to a remote gateway on a virtual datalink interface beneath an IP interface. The fact that it's a virtual interface is transparent to IP and RIP and OSPF run just fine over it. It's analogous to an ATM or Frame interface but instead of circuits, it has tunnels. Eric From owner-ipsec@lists.tislabs.com Fri Aug 27 15:01:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA14352; Fri, 27 Aug 1999 15:01:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28328 Fri, 27 Aug 1999 16:38:04 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE257@new-exc1.ctron.com> From: "Waters, Stephen" To: Eric Bomarsi Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Date: Fri, 27 Aug 1999 21:34:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Not quite FR/ATM. When FR/ATM are used in 'LAN' mode, typically each circuit is to a different remote site - it is rare to have a bunch of circuits to the same site, let along collected as a bundle. The model you suggest is the conclusion I had come to for providing differential security between peer sites while incurring the least over-head, but I still think it is overly complicated for most folk, and it is a new 'thing' that will need careful explanation and generate some interesting support calls. For most cases, I think, folk will want a single policy for this virtual datalink. This will mean the selectors are likely to be wide open - any src, any dest, any prot, any port. This is now the same as having an IPIP tunnel device, that is protected by transport-mode on leaving a 'public' IP interface. One advantage of this model is that the tunnel protocol (L2TP, GRE, IPIP) does not have to have IPSEC protection if the exit interface does not require it, and the same mechanism (strip IPSEC transport mode, deliver to tunnel device) can be used for all IP-based tunnel protocols. Another advantage is that I can use Interface MIB and Tunnel MIB on the IPIP/Generic tunnel, and use IPSEC monitoring MIBs for tracking SA. I don't think there is any intention to support the model of a group of IPSEC tunnel SA being equated to an interface in the IPSEC MIB specs. The up-shot of this debate for me, is that I'll support negotiating either tunnel or transport (depending on the target device), but I'll always perform 'transport mode' processing on the already tunneled packets. I doubt if we will support the model of representing an interface as a collection of IPSEC tunnels, since the possible misconfiguration problems fill me with dread. Thanks for the comments Eric. Cheers, Steve. -----Original Message----- From: Eric Bomarsi [mailto:ebomarsi@xedia.com] Sent: Friday, August 27, 1999 8:59 PM To: Waters, Stephen Cc: John Shriver; ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue "Waters, Stephen" wrote: > The model you suggest below of a routing interface being represented by a > 'collection of IPSEC SA going to the same peer' has some problems as a > model, I think: ... > > > Basically, this is difficult to model, difficult to manage, and difficult to > explain to customers. > Stephen, I don't think that's true. The Xedia router aggregates tunnels to a remote gateway on a virtual datalink interface beneath an IP interface. The fact that it's a virtual interface is transparent to IP and RIP and OSPF run just fine over it. It's analogous to an ATM or Frame interface but instead of circuits, it has tunnels. Eric From owner-ipsec@lists.tislabs.com Fri Aug 27 15:42:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA14733; Fri, 27 Aug 1999 15:42:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA28539 Fri, 27 Aug 1999 17:26:28 -0400 (EDT) Date: Fri, 27 Aug 1999 17:27:35 -0400 Message-Id: <199908272127.RAA27698@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Stephen.Waters@cabletron.com Cc: ebomarsi@xedia.com, ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue References: <29752A74B6C5D211A4920090273CA3DCCDE257@new-exc1.ctron.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen, Keep in mind that many applications have no need for multiple tunnels between the same pair of security gateways. Given high speed crypto, a good argument can be made that the whole notion is overkill -- just protect all traffic with strong crypto. Standard examples of multiple tunnels show "important" traffic protected with 3DES and "unimportant" protected with 1DES, but why do that if you can do them both at wire speed, as you can with hardware assist? Apart from that, the virtual interfaces we're talking about live above the tunnels, and correspond to the entire connectivity (over the entire set of tunnels) to a particular remote security gateway. Thus they are a direct analog of a point to point connection. paul From owner-ipsec@lists.tislabs.com Fri Aug 27 17:51:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA16819; Fri, 27 Aug 1999 17:51:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28727 Fri, 27 Aug 1999 19:37:05 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE259@new-exc1.ctron.com> From: "Waters, Stephen" To: Paul Koning Cc: ipsec@lists.tislabs.com, ebomarsi@xedia.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Date: Fri, 27 Aug 1999 23:31:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul, I agree with keeping it simple, with the same level (3DES/SHA) for all tunnel traffic. I think I have an understanding of the two models now. I'm not trying to suggest how you've actually implemented, just get a model clear in my head: Virtual Data-link approach (your model Paul?): -------------------------------------------- IP Interface | SPD | Virtual Data link The remote peer for all IPSEC tunnels over this virtual data link is the same. In effect, the peer is tied to the Virtual Data Link. The SPD in this case contains one or more 'Secure' policies that share the same peer, or defer that information to the Virtual data link. Another way to look at this is to consider the SPD as the virtual Data Link: IP Interface | SPD Data Link The rules for this SPD data link is again that all policies have the same peer. In the simple case, the SPD will contain a single policy to allow all traffic to be send/received between the peers. Am I close? Both of these seem to present new concepts: Specialist SPDs, and Null tunnel data-links. Compared to the alternative, Tunnel Data-link model: --------------------------------------------------- IP Interface | SPD - optional | Tunnel device (IPIP, L2TP, GRE ...) | SPD - optional, e.g. transport-mode IPSEC (preferably, transport-mode), can optionally be applied to the output of the Tunnel device. I think this is a cleaner model, with no need for specialist SPDs, NULL virtual data links. Both work just as well for VPN IP tunnels, but this alternative model is more flexible for generic tunnel protection, and holds for unprotected tunnels as well. We'll probably code to this second model, and emulate the first to allow interop of LAN-LAN routing. Cheers, Steve. -----Original Message----- From: Paul Koning [mailto:pkoning@xedia.com] Sent: Friday, August 27, 1999 10:28 PM To: Stephen.Waters@cabletron.com Cc: ebomarsi@xedia.com; ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Stephen, Keep in mind that many applications have no need for multiple tunnels between the same pair of security gateways. Given high speed crypto, a good argument can be made that the whole notion is overkill -- just protect all traffic with strong crypto. Standard examples of multiple tunnels show "important" traffic protected with 3DES and "unimportant" protected with 1DES, but why do that if you can do them both at wire speed, as you can with hardware assist? Apart from that, the virtual interfaces we're talking about live above the tunnels, and correspond to the entire connectivity (over the entire set of tunnels) to a particular remote security gateway. Thus they are a direct analog of a point to point connection. paul From owner-ipsec@lists.tislabs.com Fri Aug 27 18:58:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA23776; Fri, 27 Aug 1999 18:58:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA28825 Fri, 27 Aug 1999 20:40:09 -0400 (EDT) Message-Id: <199908272305.TAA04266@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue In-Reply-To: Your message of "Fri, 27 Aug 1999 17:27:35 EDT." <199908272127.RAA27698@tonga.xedia.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 27 Aug 1999 19:05:59 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Koning writes: Paul> Keep in mind that many applications have no need for multiple tunnels Paul> between the same pair of security gateways. Given high speed crypto, Uh, this doesn't work if you want to provide different flows with different qualities of service. Well, it does if you can do the appropriate marking on the VPN box, but at present, this is not likely to be widely available until all the VPN and QOS suppliers catch up. Some worry about traffic analysis due to seperating the flows, but if you mark them for different QOS, then you give up that information already. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Mon Aug 30 08:10:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA05184; Mon, 30 Aug 1999 08:10:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04326 Mon, 30 Aug 1999 09:32:53 -0400 (EDT) Message-ID: <37CA886F.178A654C@DataFellows.com> Date: Mon, 30 Aug 1999 16:34:39 +0300 From: Ari Huttunen Organization: Data Fellows Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-list Subject: More DoS resistant Base Mode Content-Type: multipart/alternative; boundary="------------543F1AC65AE5FB90F422594B" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------543F1AC65AE5FB90F422594B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I read the base mode draft last week, and I was impressed in how much better it is against DoS attacks than either base mode or aggressive mode. (I'm not a cryptoanalyst(TM), though.) However, I think you could make it even more resistant to DoS attacks. The attack I am thinking about is what Simpson calls the Cookie Crumb Attack in his draft. Basically, I believe you can change base mode so that the responder creates no state after receiving the first message. Instead, the responder hashes all relevant information to the R-cookie. The initiator will then resend everything in the second message, and the responder will check everything by comparing the hash with the R-cookie. The initiator can't cheat because the responder hashes also some locally known secret in there. The modified exchanges are below. My intention is not to claim that what I've written is actually secure or works, but to show that this change is feasible to implement. The downside is that some of the messages become considerably larger than they were, and the ISAKMP base exchange will need to be modified more than the IKE base mode has done. Also, there are most likely better ways of achieving this than what I found. (One such way would be do define a Responder State Payload that responder could send to the initiator, to be subsequently sent back to the responder, and which could contain anything the responder wishes. This way you wouldn't have to modify the cookie generation at all.) I could do more work on this before sending this to the list, but I'd rather not in case the idea is totally rejected. Anyway, please feel free to punch holes in this. (I also can't claim the credit for this method of making a protocol stateless. I read it somewhere else in some other context...) Base Mode Authenticated with Signatures ======================================= Initiator Responder HDR, SA, Idii, Ni_b => <= HDR, SA, Idir, Nr_b HDR, KE, [CERT,] SIG_I => <= HDR, KE, [CERT,] SIG_R CHANGE TO: Initiator Responder HDR, SA, Idii, Ni_b => (1) <= HDR, SA, Idir, Nr_b (No state retained at Responder yet.) HDR, KE, [CERT,] SIG_I, (*)IDii, Ni_b, SA, NR_b => (2) <= HDR, KE, [CERT,] SIG_R (*) IDii, Ni_b, NR_b are copies of what was exchanged in the first messages. SA is what responder sent in the first reply. (1) The responder puts in the R-cookie a hash of all the information that would need to be retained as state in the responder in the ordinary protocol. This includes a private secret, SA, IDii, Ni_b, Nr_b, I-cookie. The current time and date ARE NOT included. The ISAKMP RFC mentions that they are to be hashed because the R-cookie needs to be unique. I think the R-cookie is similarly unique if the I-cookie is unique. (2) The responder now has all the information it had at point (1), since the information is retransmitted by the initiator. If the initiator tries to send incorrect values, this is caught by checking the hash of all information (including the secret value) and if this does not produce the R-cookie, the exchange is terminated. Base Mode Authenticated with Pre Shared Keys ============================================ Initiator Responder HDR, SA, Idii, Ni_b => <= HDR, SA, Idir, Nr_b HDR, KE, HASH_I => <= HDR, KE, HASH_R CHANGE TO: Initiator Responder HDR, SA, Idii, Ni_b => <= HDR, SA, Idir, Nr_b HDR, KE, HASH_I, (*)SA, IDii, Ni_b, Nr_b => <= HDR, KE, HASH_R As in signature mode.. Base Mode Authenticated with Public Key Encryption ================================================== Initiator Responder HDR, SA, [HASH(1),] Pubkey_r, Pubkey_r => HDR, SA, PubKey_i, <= PubKey_i HDR, KE, HASH_I => <= HDR, KE, HASH_R CHANGE TO: Initiator Responder HDR, SA, [HASH(1),] Pubkey_r, Pubkey_r => (1) HDR, SA, PubKey_i, PubKey_i, (*)localkey_r, localkey_r, localkey_r HDR, KE, HASH_I, (*)SA, [HASH(1),] localkey_r, localkey_r, localkey_r => (2) <= HDR, KE, HASH_R (*) Resent stuff follows this marker.. (1) Responder creates a locally known encryption key localkey_r. This can be the same for several initiators, so no initiator specific state is retained. (2) The localkey_r is used to decrypt the resent stuff. This is much faster than if the initiator would have resent Pubkey_r, etc, which would have required PK operations. Base Mode Authenticated with Revised Public Key Encryption ========================================================== Initiator Responder HDR, SA, [HASH(1),] Pubkey_r, Ke_i => HDR, SA, PubKey_i, <= Ke_r HDR, Ke_i, HASH_I => <= HDR, _Ke_r, HASH_R CHANGE TO: Initiator Responder HDR, SA, [HASH(1),] Pubkey_r, Ke_i => HDR, SA, PubKey_i, Ke_r, (*)localkey_r, localkey_r, <= localkey_r, HDR, Ke_i, HASH_I, (*)SA, [HASH(1),] localkey_r, localkey_r, localkey_r => <= HDR, _Ke_r, HASH_R As in authentication with encryption... -- Ari Huttunen GSM: +358 40 5524634 Senior Software Engineer fax : +358 9 8599 xxxx Data Fellows Corporation http://www.DataFellows.com F-Secure products: Integrated Solutions for Enterprise Security --------------543F1AC65AE5FB90F422594B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I read the base mode draft last week, and I was impressed in
how much better it is against DoS attacks than either base
mode or aggressive mode. (I'm not a cryptoanalyst(TM), though.)
However, I think you could make it even more resistant to DoS
attacks.

The attack I am thinking about is what Simpson calls
the Cookie Crumb Attack in his draft. Basically, I believe
you can change base mode so that the responder creates no
state after receiving the first message. Instead, the responder
hashes all relevant information to the R-cookie. The initiator
will then resend everything in the second message, and the responder
will check everything by comparing the hash with the R-cookie.
The initiator can't cheat because the responder hashes also some
locally known secret in there.

The modified exchanges are below. My intention is not to claim
that what I've written is actually secure or works, but to show
that this change is feasible to implement. The downside is that
some of the messages become considerably larger than they were,
and the ISAKMP base exchange will need to be modified more than
the IKE base mode has done. Also, there are most likely better
ways of achieving this than what I found. (One such way would
be do define a Responder State Payload that responder could send
to the initiator, to be subsequently sent back to the responder,
and which could contain anything the responder wishes. This way
you wouldn't have to modify the cookie generation at all.)

I could do more work on this before sending this to the list,
but I'd rather not in case the idea is totally rejected.
Anyway, please feel free to punch holes in this.

(I also can't claim the credit for this method of making
a protocol stateless. I read it somewhere else in some
other context...)

Base Mode Authenticated with Signatures
=======================================

   Initiator                       Responder

   HDR, SA, Idii, Ni_b     =>
                           <= HDR, SA, Idir, Nr_b
   HDR, KE, [CERT,] SIG_I  =>
                           <= HDR, KE, [CERT,] SIG_R
 

CHANGE TO:

   Initiator                       Responder

   HDR, SA, Idii, Ni_b     => (1)
                           <= HDR, SA, Idir, Nr_b
                              (No state retained at Responder yet.)
   HDR, KE, [CERT,] SIG_I,
(*)IDii, Ni_b, SA, NR_b    => (2)
                           <= HDR, KE, [CERT,] SIG_R

(*) IDii, Ni_b, NR_b are copies of what was exchanged in
    the first messages. SA is what responder sent in the first reply.

(1) The responder puts in the R-cookie a hash of all the information that would need
     to be retained as state in the responder in the ordinary protocol. This includes
     a private secret, SA, IDii, Ni_b, Nr_b, I-cookie. The current time and date ARE NOT
     included. The ISAKMP RFC mentions that they are to be hashed because the R-cookie
     needs to be unique. I think the R-cookie is similarly unique if the I-cookie is
     unique.

(2) The responder now has all the information it had at point (1), since the information
    is retransmitted by the initiator. If the initiator tries to send incorrect values,
    this is caught by checking the hash of all information (including the secret value)
    and if this does not produce the R-cookie, the exchange is terminated.

Base Mode Authenticated with Pre Shared Keys
============================================

  Initiator                               Responder

   HDR, SA, Idii, Ni_b     =>
                           <= HDR, SA, Idir, Nr_b
   HDR, KE, HASH_I         =>
                           <= HDR, KE, HASH_R
 

CHANGE TO:

   Initiator                               Responder

   HDR, SA, Idii, Ni_b     =>
                           <= HDR, SA, Idir, Nr_b
   HDR, KE, HASH_I,
(*)SA, IDii, Ni_b, Nr_b    =>
                           <= HDR, KE, HASH_R

As in signature mode..

Base Mode Authenticated with Public Key Encryption
==================================================

   Initiator                        Responder

   HDR, SA, [HASH(1),]
   <IDii_b>Pubkey_r,
   <Ni_b>Pubkey_r           =>
                                 HDR, SA, <IDir_b>PubKey_i,
                            <=   <Nr_b>PubKey_i
   HDR, KE, HASH_I          =>
                            <=   HDR, KE, HASH_R

CHANGE TO:

   Initiator                        Responder

   HDR, SA, [HASH(1),]
   <IDii_b>Pubkey_r,
   <Ni_b>Pubkey_r           => (1)
                                 HDR, SA, <IDir_b>PubKey_i,
                                 <Nr_b>PubKey_i,
                              (*)<IDii_b>localkey_r,
                                 <Ni_b>localkey_r,
                                 <Nr_b>localkey_r
   HDR, KE, HASH_I,
(*)SA, [HASH(1),]
   <IDii_b>localkey_r,
   <Ni_b>localkey_r,
   <Nr_b>localkey_r         => (2)
                            <=   HDR, KE, HASH_R

(*) Resent stuff follows this marker..

(1) Responder creates a locally known encryption key localkey_r. This can be the
    same for several initiators, so no initiator specific state is retained.

(2) The localkey_r is used to decrypt the resent stuff. This is much faster
    than if the initiator would have resent <IDii_b>Pubkey_r, etc, which would
    have required PK operations.

Base Mode Authenticated with Revised Public Key Encryption
==========================================================

   Initiator                        Responder

   HDR, SA, [HASH(1),]
   <Ni_b>Pubkey_r,
   <IDii_b>Ke_i            =>
                              HDR, SA, <Nr_b>PubKey_i,
                           <= <IDir_b>Ke_r
   HDR, <KE>Ke_i, HASH_I   =>
                           <= HDR, <KE>_Ke_r, HASH_R

CHANGE TO:

   Initiator                        Responder

   HDR, SA, [HASH(1),]
   <Ni_b>Pubkey_r,
   <IDii_b>Ke_i            =>
                              HDR, SA, <Nr_b>PubKey_i,
                              <IDir_b>Ke_r,
                           (*)<Ni_b>localkey_r,
                              <IDii_b>localkey_r,
                           <= <Nr_b>localkey_r,
   HDR, <KE>Ke_i, HASH_I,
(*)SA, [HASH(1),]
   <Ni_b>localkey_r,
   <Nr_b>localkey_r,
   <IDii_b>localkey_r      =>
                           <= HDR, <KE>_Ke_r, HASH_R

As in authentication with encryption...

--
Ari Huttunen                   GSM: +358 40 5524634
Senior Software Engineer       fax : +358 9 8599 xxxx

Data Fellows Corporation       http://www.DataFellows.com

F-Secure products: Integrated Solutions for Enterprise Security
  --------------543F1AC65AE5FB90F422594B-- From owner-ipsec@lists.tislabs.com Mon Aug 30 08:10:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA05183; Mon, 30 Aug 1999 08:10:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04300 Mon, 30 Aug 1999 09:23:54 -0400 (EDT) Date: Mon, 30 Aug 1999 09:25:04 -0400 Message-Id: <199908301325.JAA01867@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mcr@sandelman.ottawa.on.ca Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue References: <199908272127.RAA27698@tonga.xedia.com> <199908272305.TAA04266@istari.sandelman.ottawa.on.ca> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael C Richardson writes: >>>>> "Paul" == Paul Koning writes: Paul> Keep in mind that many applications have no need for multiple Paul> tunnels between the same pair of security gateways. Given high Paul> speed crypto, Michael> Uh, this doesn't work if you want to provide different flows Michael> with different qualities of service. Well, it does if you Michael> can do the appropriate marking on the VPN box, but at Michael> present, this is not likely to be widely available until all Michael> the VPN and QOS suppliers catch up. It isn't necessary for everyone to catch up. All that you need is VPN boxes that are also QOS suppliers with the ability to to TOS marking, and indeed those are available -- we've been shipping that for a while now. paul From owner-ipsec@lists.tislabs.com Mon Aug 30 08:30:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA05359; Mon, 30 Aug 1999 08:30:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04478 Mon, 30 Aug 1999 10:16:23 -0400 (EDT) Message-Id: <199908301242.IAA25254@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue In-Reply-To: Your message of "Mon, 30 Aug 1999 09:25:04 EDT." <199908301325.JAA01867@tonga.xedia.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 30 Aug 1999 08:42:05 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Koning writes: Paul> Keep in mind that many applications have no need for multiple Paul> tunnels between the same pair of security gateways. Given high Paul> speed crypto, Michael> Uh, this doesn't work if you want to provide different flows Michael> with different qualities of service. Well, it does if you can do Michael> the appropriate marking on the VPN box, but at present, this is Michael> not likely to be widely available until all the VPN and QOS Michael> suppliers catch up. Paul> It isn't necessary for everyone to catch up. All that you need is Paul> VPN boxes that are also QOS suppliers with the ability to to TOS Paul> marking, and indeed those are available -- we've been shipping that Paul> for a while now. I never said that they weren't shipping. I said that it wasn't widely available. If your box talks to a different vendor's box, then you have a problem. This is what interopability is about. So, unless you have such a box at BOTH ends, the end that can do both still needs to support multiple SAs between end points so that it can support having QOS and VPN done in different boxes. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Mon Aug 30 17:37:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA12764; Mon, 30 Aug 1999 17:37:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06010 Mon, 30 Aug 1999 19:08:59 -0400 (EDT) Message-ID: <37CB02A8.5BFB5A51@redcreek.com> Date: Mon, 30 Aug 1999 22:16:08 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue References: <29752A74B6C5D211A4920090273CA3DCCDE236@new-exc1.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Waters, Stephen" wrote: > There are three models that can be used here (using the example of an > IP-inIP tunnel): > > 1) IP tunnel device tunnels packets, IPSEC then applies transport-mode > protection to the IP-in-IP packets as they leave. > > 2) IPSEC tunnel is modeled as an interface, and just negotiates tunnel mode > and exposes the resulting tunnel as an interface. This is akin to marrying > an SDP policy with an Interface. > > 3) IP tunnel device tunnels packets, IPSEC then applies tunnel mode > protection. > > > Option 3) seems wasteful since in most cases two identical header have been > added. > Option 1) is in the mould of L2TP tunnel protection and is a generalised way > to protect pre-tunneled data > Option 2) is mean and lean. > Howdy () Correct me where I'm wrong, I'm going to give some of my impressions of these options. Option 3): Let this one die. Option 1): Good thing = routing works. Bad thing = security is impaired. It seems like we have automatically limited and forced all traffic traveling through a particular peer SGW to utilize the same SA and this SA is incapable of distinguishing and discriminating against any traffic. I suppose, Steven, that your implementation relies on packet filtering to guard against what enters the IPIP interface? Is packet filtering then to be seen as a mandatory prerequisite to this impelmentation strategy? Option 2): Good thing = security works. Bad thing = routing fails. If we have multiple SAs between the same peers, then which of these SAs is the routing interface? So here is a new suggestion: Its a modified Option 2) Allow a user configurable switch on a Policy Entry to tell this entry to become a routable interface. Now we introduce some extra limitations which would have to be drafted up: Symetric configuration of both peers is required. Once such a 'routable interface SA' switch is toggled on, no port or protocol selectors are allowed in this policy. We draft up a keep-alive mechanism (or take one from somewhere else) and start that state machine on the new SA-interface. Routing information between the two peers travles down this SA-interface. Link down and link up notifications cause normal routing responses. 'Interface-SAs' to different 'tightnesses' of subnet mask are allowed to be confiured. (repeating my self here) 'Interface-SAs' to ports or protocols are not allowed to be configured. Multiple 'interface-SAs' to the same far end SGW are permissable if and only if they 'attach' to different interfaces on the far end system (these would be like load balanced multiple paths). A non-interface SA (the ones we are all used to so far) with selectors pointing to particular ports and protocols within the same subnet as an Interfaces SA is permitted and the non-interface SA SHOULD be listed above the interrface-SA in the Policy Database. This option allows routing to work (I hope, no implementation experience speaking here) but still forces security policy down to some unified theme. The Interface-SA would have to be configured to match all traffic you anticipated... But the difference would be that your Interface-SA could also be configured to match _only_ the traffic you wished to allow. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Tue Aug 31 01:03:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA19657; Tue, 31 Aug 1999 01:03:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA06937 Tue, 31 Aug 1999 02:32:08 -0400 (EDT) Message-Id: <9908310643.AA02265@Ichiko.imailab.iis.u-tokyo.ac.jp> From: Kanta Matsuura Date: Tue, 31 Aug 1999 15:43:29 +0900 To: Ari Huttunen Cc: ipsec-list Subject: Re: More DoS resistant Base Mode In-Reply-To: <37CA886F.178A654C@DataFellows.com> MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How to make IKE more resistant against DoS is also discussed in http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-00.txt The idea is quite similar: the draft uses intermediate random fresh value (which is reconstructed if the initiator really pays cost to verify the responder's signature) as an additional input to the HASH payload in the ack message from the client; if the client (maybe a DoS attacker) does not follow the protocol (i.e. skip the verification of the responder's signature), he/she cannot produce the correct HASH, which is efficiently (<-- hashing is inexpensive computation) detected by the responder. This mechanism discourages DoS attackers by ``falling-together'' nightmare; if the attacker and the responder have the same level of computational power, the attacker must exhaust his/her own resource in order to exhaust that of the target since a bogus acknowledgment material is detected by the light verification procedure before computationally-expensive verification. Althogh this is currently focused on Signature authentication, I recommend the change of the HASH payload format in a way that the payload can use DoS-resistant mechanism based on an additional input as above. Then we might find a similar trick in other authentication mode. Why don't we discuss this matter together and go on further to make IKE more resistant against DoS. ---- Kanta MATSUURA ---- Ari Huttunen wrote: >>I read the base mode draft last week, and I was impressed in >>how much better it is against DoS attacks than either base >>mode or aggressive mode. (I'm not a cryptoanalyst(TM), though.) >>However, I think you could make it even more resistant to DoS >>attacks. >> >>The attack I am thinking about is what Simpson calls >>the Cookie Crumb Attack in his draft. Basically, I believe >>you can change base mode so that the responder creates no >>state after receiving the first message. Instead, the responder >>hashes all relevant information to the R-cookie. The initiator >>will then resend everything in the second message, and the responder >>will check everything by comparing the hash with the R-cookie. >>The initiator can't cheat because the responder hashes also some >>locally known secret in there. >> >>The modified exchanges are below. My intention is not to claim >>that what I've written is actually secure or works, but to show >>that this change is feasible to implement. The downside is that >>some of the messages become considerably larger than they were, >>and the ISAKMP base exchange will need to be modified more than >>the IKE base mode has done. Also, there are most likely better >>ways of achieving this than what I found. (One such way would >>be do define a Responder State Payload that responder could send >>to the initiator, to be subsequently sent back to the responder, >>and which could contain anything the responder wishes. This way >>you wouldn't have to modify the cookie generation at all.) >> >>I could do more work on this before sending this to the list, >>but I'd rather not in case the idea is totally rejected. >>Anyway, please feel free to punch holes in this. >> >>(I also can't claim the credit for this method of making >>a protocol stateless. I read it somewhere else in some >>other context...) >> >>Base Mode Authenticated with Signatures >>======================================= >> >> Initiator Responder >> >> HDR, SA, Idii, Ni_b => >> <= HDR, SA, Idir, Nr_b >> HDR, KE, [CERT,] SIG_I => >> <= HDR, KE, [CERT,] SIG_R >> >> >>CHANGE TO: >> >> Initiator Responder >> >> HDR, SA, Idii, Ni_b => (1) >> <= HDR, SA, Idir, Nr_b >> (No state retained at Responder yet.) >> HDR, KE, [CERT,] SIG_I, >>(*)IDii, Ni_b, SA, NR_b => (2) >> <= HDR, KE, [CERT,] SIG_R >> >>(*) IDii, Ni_b, NR_b are copies of what was exchanged in >> the first messages. SA is what responder sent in the first reply. >> >>(1) The responder puts in the R-cookie a hash of all the information that would need >> to be retained as state in the responder in the ordinary protocol. This includes >> a private secret, SA, IDii, Ni_b, Nr_b, I-cookie. The current time and date ARE NOT >> included. The ISAKMP RFC mentions that they are to be hashed because the R-cookie >> needs to be unique. I think the R-cookie is similarly unique if the I-cookie is >> unique. >> >>(2) The responder now has all the information it had at point (1), since the information >> is retransmitted by the initiator. If the initiator tries to send incorrect values, >> this is caught by checking the hash of all information (including the secret value) >> and if this does not produce the R-cookie, the exchange is terminated. >> >>Base Mode Authenticated with Pre Shared Keys >>============================================ >> >> Initiator Responder >> >> HDR, SA, Idii, Ni_b => >> <= HDR, SA, Idir, Nr_b >> HDR, KE, HASH_I => >> <= HDR, KE, HASH_R >> >> >>CHANGE TO: >> >> Initiator Responder >> >> HDR, SA, Idii, Ni_b => >> <= HDR, SA, Idir, Nr_b >> HDR, KE, HASH_I, >>(*)SA, IDii, Ni_b, Nr_b => >> <= HDR, KE, HASH_R >> >>As in signature mode.. >> >>Base Mode Authenticated with Public Key Encryption >>================================================== >> >> Initiator Responder >> >> HDR, SA, [HASH(1),] >> Pubkey_r, >> Pubkey_r => >> HDR, SA, PubKey_i, >> <= PubKey_i >> HDR, KE, HASH_I => >> <= HDR, KE, HASH_R >> >>CHANGE TO: >> >> Initiator Responder >> >> HDR, SA, [HASH(1),] >> Pubkey_r, >> Pubkey_r => (1) >> HDR, SA, PubKey_i, >> PubKey_i, >> (*)localkey_r, >> localkey_r, >> localkey_r >> HDR, KE, HASH_I, >>(*)SA, [HASH(1),] >> localkey_r, >> localkey_r, >> localkey_r => (2) >> <= HDR, KE, HASH_R >> >>(*) Resent stuff follows this marker.. >> >>(1) Responder creates a locally known encryption key localkey_r. This can be the >> same for several initiators, so no initiator specific state is retained. >> >>(2) The localkey_r is used to decrypt the resent stuff. This is much faster >> than if the initiator would have resent Pubkey_r, etc, which would >> have required PK operations. >> >>Base Mode Authenticated with Revised Public Key Encryption >>========================================================== >> >> Initiator Responder >> >> HDR, SA, [HASH(1),] >> Pubkey_r, >> Ke_i => >> HDR, SA, PubKey_i, >> <= Ke_r >> HDR, Ke_i, HASH_I => >> <= HDR, _Ke_r, HASH_R >> >>CHANGE TO: >> >> Initiator Responder >> >> HDR, SA, [HASH(1),] >> Pubkey_r, >> Ke_i => >> HDR, SA, PubKey_i, >> Ke_r, >> (*)localkey_r, >> localkey_r, >> <= localkey_r, >> HDR, Ke_i, HASH_I, >>(*)SA, [HASH(1),] >> localkey_r, >> localkey_r, >> localkey_r => >> <= HDR, _Ke_r, HASH_R >> >>As in authentication with encryption... >> >>-- >>Ari Huttunen GSM: +358 40 5524634 >>Senior Software Engineer fax : +358 9 8599 xxxx >> >>Data Fellows Corporation http://www.DataFellows.com ---- **** ---- Kanta MATSUURA, Ph.D. Lecturer 3rd Department, Institute of Industrial Science, University of Tokyo, Roppongi 7-22-1, Minato-ku, Tokyo 106-8558, JAPAN Tel: +81-3-3402-6231 (ext. 2325) Fax: +81-3-3479-1736 E-Mail: kanta@iis.u-tokyo.ac.jp From owner-ipsec@lists.tislabs.com Tue Aug 31 13:29:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA07726; Tue, 31 Aug 1999 13:29:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09069 Tue, 31 Aug 1999 14:34:22 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <29752A74B6C5D211A4920090273CA3DCCDE252@new-exc1.ctron.com> Date: Tue, 31 Aug 1999 11:22:29 -0400 To: "Waters, Stephen" From: Stephen Kent Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen, >I think I disagree with the statement that "Anything else will violate RFC >2401". A security gateway is perfectly entitled to protected 'originating >traffic' with transport-mode, and if the traffic source is a tunnel device >(IPIP, L2TP, GRE...), then IPSEC can quite fairly protect this with >transport mode to a remote peer/security gateway: > >" Note that for the case where traffic is destined for a > security gateway, e.g., SNMP commands, the security gateway is acting > as a host and transport mode is allowed." > >It is convenient, I think, to model generic traffic between two security >gateways as transport-mode, regardless of the protocol. One can do this if the goal is to eviscerate the access controls provided by IPsec, and there is a desire to add unnecessary protocol layers (e.g., L2TP and GRE) when carrying IP traffic :-). Steve From owner-ipsec@lists.tislabs.com Tue Aug 31 16:38:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA10876; Tue, 31 Aug 1999 16:38:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09700 Tue, 31 Aug 1999 18:15:53 -0400 (EDT) Message-Id: <199908312211.PAA00604@Potassium.Network-Alchemy.COM> To: Stephen Kent cc: "Waters, Stephen" , ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue In-reply-to: Your message of "Tue, 31 Aug 1999 11:22:29 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <601.936137499.1@network-alchemy.com> Date: Tue, 31 Aug 1999 15:11:40 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It seems to me that the whole problem described in this thread exists because routing protocols that assume their peers are 1 hop away are being used-- e.g. the multicast addresses used for OSPF and RIP are from the "local segment usage only" range. So the problem becomes how to tunnel these packets to hide this from the protocol, which would go away if the protocol did not have this requirement. So let me ask again, what is the problem with BGP? There would be no need for any bizarre tunneling scheme and the BGP session can be protected with transport mode IPSec if you're concerned about that (no need for the ambiguity of "is transport-mode protected IPIP actually tunnel mode?"). BGP sounds like the right tool for the right job here. No need to short circuit the IPSec access control mechanisms nor add unnecessary headers (as Steve K noted) to the packets. And, most importantly, it achieves the goal. Dan. On Tue, 31 Aug 1999 11:22:29 EDT you wrote > Stephen, > > >I think I disagree with the statement that "Anything else will violate RFC > >2401". A security gateway is perfectly entitled to protected 'originating > >traffic' with transport-mode, and if the traffic source is a tunnel device > >(IPIP, L2TP, GRE...), then IPSEC can quite fairly protect this with > >transport mode to a remote peer/security gateway: > > > >" Note that for the case where traffic is destined for a > > security gateway, e.g., SNMP commands, the security gateway is acting > > as a host and transport mode is allowed." > > > >It is convenient, I think, to model generic traffic between two security > >gateways as transport-mode, regardless of the protocol. > > One can do this if the goal is to eviscerate the access controls provided > by IPsec, and there is a desire to add unnecessary protocol layers (e.g., > L2TP and GRE) when carrying IP traffic :-). > > Steve From owner-ipsec@lists.tislabs.com Tue Aug 31 17:16:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA11298; Tue, 31 Aug 1999 17:16:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09751 Tue, 31 Aug 1999 18:59:34 -0400 (EDT) From: Dan McDonald Message-Id: <199908312259.PAA12978@kebe.Eng.Sun.COM> Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue To: dharkins@network-alchemy.com (Dan Harkins) Date: Tue, 31 Aug 1999 15:59:31 -0700 (PDT) Cc: kent@po1.bbn.com, Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com In-Reply-To: <199908312211.PAA00604@Potassium.Network-Alchemy.COM> from "Dan Harkins" at Aug 31, 99 03:11:40 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@lists.tislabs.com Precedence: bulk I don't know if I made myself clearer on this subject earlier. If you _insist_ on using OSPF and/or RIP, you _can_ do the right thing with a tunneling interface. There is a price. That price is that your tunneling interface will have to play an active role in enforcing IPsec policy. Let's first consider a transport-mode IPsec implementation that enforces policy on a combination of "socket state" and systemwide policy. An inbound IP processing path would look like: * Get packet. * Process IPsec headers, remove IPsec headers, annotate packet with IPsec protection applied to this packet. * When ready to deliver to destination upper-layer (e.g. TCP), inspect annoatated packet against upper-layer's socket state and/or systemwide policy. Drop packet if it fails, or allow packet to pass if it succeeds. An outbound IP processing path would look like: * Get packet from upper-layer. * Annotate packet with what socket state and systemwide policy require for this packet. * Select route, etc. * Based on annotations, apply IPsec. * Fragment packet. * Transmit packet. Now a tunnel that doesn't apply full tunnel mode selectors (which has been called Transport Mode IP-in-IP in this thread) can use the above infrastructure with out any change. What isn't obvious in the above is that TCP may not have full "socket state" for detached or closing connections. In that situation, the inbound processing path now looks like (WITH CHANGES IN CAPS): * Get packet. * Process IPsec headers, remove IPsec headers, annotate packet with IPsec protection applied to this packet. * When ready to deliver to destination upper-layer (e.g. TCP), inspect annoatated packet against upper-layer's socket state and/or systemwide policy. Drop packet if it fails, or allow packet to pass if it succeeds OR IF THE UPPER LAYER NEEDS TO FURTHER CHECK THE ANNOTATIONS. The outbound processing path now looks like (WITH CHANGES IN ALL CAPS): * Get packet from upper-layer. THE PACKET MAY ALREADY BE ANNOTATED. * IF NOT ALREADY ANNOTATED, annotate packet with what socket state and systemwide policy require for this packet. * Select route, etc. * Based on annotations, apply IPsec. * Fragment packet. * Transmit packet. So with those required-for-TCP changes in place, why not allow the IP-in-IP upper-layer to pre-annotate outbound packets based on inside packet information, and why not also allow the IP-in-IP upper-layer to enforce inbound policy based on further information. TCP already has to do it for detached connections, so why not your tunnel "driver"? It's not rocket science, folks. It's labor-intensive (how much so depends on your implementation), and your SPD gets distributed, but it's not tough. Hope this helps, Dan From owner-ipsec@lists.tislabs.com Tue Aug 31 18:38:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA16134; Tue, 31 Aug 1999 18:38:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09898 Tue, 31 Aug 1999 20:17:28 -0400 (EDT) From: "Evan Caves" To: "Dan Harkins" , "Stephen Kent" Cc: "Waters, Stephen" , Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Date: Tue, 31 Aug 1999 17:16:13 -0700 Message-ID: <00bf01bef40f$33156700$7c69c081@evan.acc.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 In-reply-to: <199908312211.PAA00604@Potassium.Network-Alchemy.COM> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have been partially tuned to this thread and I do _not_ see BGP as the 'right tool' here. From what I understand an IGP is all that is needed (for example I need to connect two private networks using a secure tunnel through the Internet). evan - > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > Sent: Tuesday, August 31, 1999 3:12 PM > To: Stephen Kent > Cc: Waters, Stephen; ipsec@lists.tislabs.com > Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue > > > It seems to me that the whole problem described in this thread exists > because routing protocols that assume their peers are 1 hop away are > being used-- e.g. the multicast addresses used for OSPF and RIP are > from the "local segment usage only" range. So the problem becomes how > to tunnel these packets to hide this from the protocol, which would go > away if the protocol did not have this requirement. > > So let me ask again, what is the problem with BGP? There would be no > need for any bizarre tunneling scheme and the BGP session can be protected > with transport mode IPSec if you're concerned about that (no need for > the ambiguity of "is transport-mode protected IPIP actually > tunnel mode?"). > > BGP sounds like the right tool for the right job here. No need to short > circuit the IPSec access control mechanisms nor add unnecessary > headers (as > Steve K noted) to the packets. And, most importantly, it achieves > the goal. > > Dan. > > On Tue, 31 Aug 1999 11:22:29 EDT you wrote > > Stephen, > > > > >I think I disagree with the statement that "Anything else will > violate RFC > > >2401". A security gateway is perfectly entitled to protected > 'originating > > >traffic' with transport-mode, and if the traffic source is a > tunnel device > > >(IPIP, L2TP, GRE...), then IPSEC can quite fairly protect this with > > >transport mode to a remote peer/security gateway: > > > > > >" Note that for the case where traffic is destined for a > > > security gateway, e.g., SNMP commands, the security gateway > is acting > > > as a host and transport mode is allowed." > > > > > >It is convenient, I think, to model generic traffic between > two security > > >gateways as transport-mode, regardless of the protocol. > > > > One can do this if the goal is to eviscerate the access > controls provided > > by IPsec, and there is a desire to add unnecessary protocol > layers (e.g., > > L2TP and GRE) when carrying IP traffic :-). > > > > Steve > From owner-ipsec@lists.tislabs.com Tue Aug 31 18:39:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA16266; Tue, 31 Aug 1999 18:39:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09928 Tue, 31 Aug 1999 20:24:18 -0400 (EDT) Message-ID: <37CC65C5.1802D7AC@redcreek.com> Date: Tue, 31 Aug 1999 23:31:17 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: Dan Harkins Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue References: <199908312211.PAA00604@Potassium.Network-Alchemy.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > > It seems to me that the whole problem described in this thread exists > because routing protocols that assume their peers are 1 hop away are > being used-- e.g. the multicast addresses used for OSPF and RIP are > from the "local segment usage only" range. So the problem becomes how > to tunnel these packets to hide this from the protocol, which would go > away if the protocol did not have this requirement. > > So let me ask again, what is the problem with BGP? There would be no > need for any bizarre tunneling scheme and the BGP session can be protected > with transport mode IPSec if you're concerned about that (no need for > the ambiguity of "is transport-mode protected IPIP actually tunnel mode?"). > > BGP sounds like the right tool for the right job here. No need to short > circuit the IPSec access control mechanisms nor add unnecessary headers (as > Steve K noted) to the packets. And, most importantly, it achieves the goal. > > Dan. Howdy () If BGP routes to a next hop which is more than one hop away, then BGP requires that the IGP be able to resolve the intermetiate next hops and you are back where you started. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Tue Aug 31 18:56:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA17727; Tue, 31 Aug 1999 18:56:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09991 Tue, 31 Aug 1999 20:38:53 -0400 (EDT) Message-Id: <199909010036.RAA01713@Potassium.Network-Alchemy.COM> To: "Evan Caves" cc: "Stephen Kent" , "Waters, Stephen" , ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue In-reply-to: Your message of "Tue, 31 Aug 1999 17:16:13 PDT." <00bf01bef40f$33156700$7c69c081@evan.acc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1710.936146188.1@network-alchemy.com> Date: Tue, 31 Aug 1999 17:36:29 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I-BGP!!! Dan. On Tue, 31 Aug 1999 17:16:13 PDT you wrote > I have been partially tuned to this thread and I do _not_ see BGP as > the 'right tool' here. From what I understand an IGP is all that is > needed (for example I need to connect two private networks using a > secure tunnel through the Internet). > > evan > - > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > > Sent: Tuesday, August 31, 1999 3:12 PM > > To: Stephen Kent > > Cc: Waters, Stephen; ipsec@lists.tislabs.com > > Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue > > > > > > It seems to me that the whole problem described in this thread exists > > because routing protocols that assume their peers are 1 hop away are > > being used-- e.g. the multicast addresses used for OSPF and RIP are > > from the "local segment usage only" range. So the problem becomes how > > to tunnel these packets to hide this from the protocol, which would go > > away if the protocol did not have this requirement. > > > > So let me ask again, what is the problem with BGP? There would be no > > need for any bizarre tunneling scheme and the BGP session can be protected > > with transport mode IPSec if you're concerned about that (no need for > > the ambiguity of "is transport-mode protected IPIP actually > > tunnel mode?"). > > > > BGP sounds like the right tool for the right job here. No need to short > > circuit the IPSec access control mechanisms nor add unnecessary > > headers (as > > Steve K noted) to the packets. And, most importantly, it achieves > > the goal. > > > > Dan. > > > > On Tue, 31 Aug 1999 11:22:29 EDT you wrote > > > Stephen, > > > > > > >I think I disagree with the statement that "Anything else will > > violate RFC > > > >2401". A security gateway is perfectly entitled to protected > > 'originating > > > >traffic' with transport-mode, and if the traffic source is a > > tunnel device > > > >(IPIP, L2TP, GRE...), then IPSEC can quite fairly protect this with > > > >transport mode to a remote peer/security gateway: > > > > > > > >" Note that for the case where traffic is destined for a > > > > security gateway, e.g., SNMP commands, the security gateway > > is acting > > > > as a host and transport mode is allowed." > > > > > > > >It is convenient, I think, to model generic traffic between > > two security > > > >gateways as transport-mode, regardless of the protocol. > > > > > > One can do this if the goal is to eviscerate the access > > controls provided > > > by IPsec, and there is a desire to add unnecessary protocol > > layers (e.g., > > > L2TP and GRE) when carrying IP traffic :-). > > > > > > Steve > > > From owner-ipsec@lists.tislabs.com Tue Aug 31 19:00:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA18104; Tue, 31 Aug 1999 19:00:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10024 Tue, 31 Aug 1999 20:47:10 -0400 (EDT) Message-Id: <199909010047.RAA01815@Potassium.Network-Alchemy.COM> To: Ricky Charlet cc: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue In-reply-to: Your message of "Tue, 31 Aug 1999 23:31:17 -0000." <37CC65C5.1802D7AC@redcreek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1812.936146833.1@network-alchemy.com> Date: Tue, 31 Aug 1999 17:47:13 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 31 Aug 1999 23:31:17 -0000 you wrote > > If BGP routes to a next hop which is more than one hop away, then BGP > requires that the IGP be able to resolve the intermetiate next hops and > you are back where you started. You have this problem anyway because you need your GRE tunnel needs to be established. You have to have some route from SGW1 to SGW2 regardless. Given that requirement, is the simplest way to "discover what is out there" (which is the desire that started this thread-- quote from Steve Waters) to tunnel RIP and/or OSPF-- and all the cruft that goes along with that-- between them or to just use BGP? BGP is a _much_ simpler protocol that OSPF and either is _much_ better than RIP. Dan.