From owner-ipsec Wed Jul 1 02:41:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA04661 for ipsec-outgoing; Wed, 1 Jul 1998 02:40:49 -0400 (EDT) Message-Id: <3.0.5.32.19980701095705.009ae5f0@127.0.0.1> X-Sender: ilkka@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 01 Jul 1998 09:57:05 +0300 To: ipsec@tis.com From: Ilkka Ranta Subject: IPSec client for OS/2 ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, do you know of any _commercial_ software based IPSec implementations for OS/2 ? I'm looking for an IPSec client for this platform. All information is appreciated. Thanks a bunch, --Ilkka From owner-ipsec Wed Jul 1 13:46:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA06661 for ipsec-outgoing; Wed, 1 Jul 1998 13:43:26 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807011759.KAA11279@kc.livingston.com> Subject: Re: More questions on ID types To: dharkins@cisco.com (Daniel Harkins) Date: Wed, 1 Jul 1998 10:59:38 -0700 (PDT) Cc: lmccarth@cs.umass.edu, ipsec@tis.com, BGleeson@shastanets.com In-Reply-To: <199806302047.NAA22141@greatdane.cisco.com> from "Daniel Harkins" at Jun 30, 98 01:47:57 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > On: Tue, 30 Jun 1998 16:19:32 EDT you wrote > > Bryan Gleeson writes: > [snip] > > > Thus perhaps it would be better for the Pre-Shared key case > > > to include the ID payload in the 3rd and 4th messages > > > of the exchange (the ones that transfer the D-H public info > > > and the nonces), rather than in the 5th and 6th. This removes > > > the need to look at source IP address at all, and would be > > > similar to the Authentication with Encryption exchange. > > > > Unfortunately Pre-Shared-Key-Auth Main Mode would no longer be > > an Identity Protect exchange if this change were made. > > Protecting the identities of the parties is a notable feature > > of Main Mode -- in contrast to Aggressive Mode -- for the > > pre-shared key case. So I don't think Main Mode should be > > altered to send ID payloads in the clear. > > > > I suppose there is some argument to be made for a compromise > > mode in the pre-shared key case that would be more "aggressive" > > than Main Mode, but more "reserved" than Aggressive Mode. > > For example (illustrative purposes only): > > > > Initiator Responder > > ---------- ----------- > > HDR, SA --> > > <-- HDR, SA, KE, Nr > > HDR, KE, Ni, IDii, HASH_I --> > > <-- HDR, IDir, HASH_R > > > > This doesn't offer identity protection. But it allows > > negotiation of the DH group (unlike Aggressive Mode) and > > saves a full round-trip versus Main Mode. > > (Other variations are possible. I haven't really considered > > which ones might be better.) > > It also might open the responder to a denial-of-service attack since > he does an exponentiation before he's got any belief the he's talking > to a genuine, honest-to-goodness IKE peer and not a program that forges > thousands of "HDR, SA" messages per second from bogus source addresses. > Main Mode is not immune from such attacks but before the responder does > any real work he's got a strong belief that he's talking to a real entity. > > One of the nice things about Oakley (and also one of the things that made > it so hard to implement) is that it didn't have this problem. Each side > could send what it wanted when it wanted. The initiator could send an SA, > KE, nonce and the responder could only send a cookie, or a cookie and an > SA and a KE, or a cookie and an SA, or.... > > A "reserved mode" (I like that) can be written up in a draft but Main > Mode is not changing at this point in time. Sorry Bryan but this point was > discussed about a year ago and the resolution is what you see today. If > you want to allow remote access with pre-shared keys use Aggressive Mode. > If you don't want to expose a meaningful identity use ID_KEY_ID as the > identity to which the pre-shared key is bound. > > Dan. > It is good to note that the issue came up earlier and was discussed, even though I dont like the alternative you suggest. In order to not expose the actual identities, the vendors would have to agree on an out-of-band encryption by which to encrypt the ID in the vendor specific ID_KEY_ID. This is yet another encryption, and yet another out-of-band requirement in addition to the pre-shared key. Also, as Bryan pointed out, it is a layer violation in that a pre-shared key has to be assusmed based on the src address (in IP header) rather than ID payload. As an aside, can someone explain to me why SKEYID is evaluated differently based on different authentication schemes used? Why couldnt they all be evaluated the same independent of the authentication scheme, as a function of Ni_b, Nr_b and g^xy. ex: SKEYID = prf (hash(Ni_b | Nr_b), g^xy) Distinctions between authentication schemes could be restricted simply to thw way HASH_I and HASH_R are evaluated. For example, HASH_I and HASH_R for the pre-shared key authentication could have been evaluated differently from other authentications by concatenating the pre-shared key to the message argument (i.e., arg2) of the prf function. This approach would cover the case Bryan pointed out, without requiring any changes to the main mode protocol. cheers, suresh From owner-ipsec Wed Jul 1 14:56:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06971 for ipsec-outgoing; Wed, 1 Jul 1998 14:51:38 -0400 (EDT) Message-Id: <199807011907.MAA00743@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins owned process doing -bs X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins@localhost didn't use HELO protocol To: suresh@livingston.com (Pyda Srisuresh) cc: lmccarth@cs.umass.edu, ipsec@tis.com, BGleeson@shastanets.com Subject: Re: More questions on ID types In-reply-to: Your message of "Wed, 01 Jul 1998 10:59:38 PDT." <199807011759.KAA11279@kc.livingston.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <741.899320033.1@cisco.com> Date: Wed, 01 Jul 1998 12:07:14 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On: Wed, 01 Jul 1998 10:59:38 PDT you wrote [snip] > > A "reserved mode" (I like that) can be written up in a draft but Main > > Mode is not changing at this point in time. Sorry Bryan but this point was > > discussed about a year ago and the resolution is what you see today. If > > you want to allow remote access with pre-shared keys use Aggressive Mode. > > If you don't want to expose a meaningful identity use ID_KEY_ID as the > > identity to which the pre-shared key is bound. > > > > Dan. > > > > It is good to note that the issue came up earlier and was discussed, > even though I dont like the alternative you suggest. In order to not expose > the actual identities, the vendors would have to agree on an out-of-band > encryption by which to encrypt the ID in the vendor specific ID_KEY_ID. > This is yet another encryption, and yet another out-of-band requirement > in addition to the pre-shared key. Also, as Bryan pointed out, it > is a layer violation in that a pre-shared key has to be assusmed based > on the src address (in IP header) rather than ID payload. What encryption? An ID is not encrypted "in the vendor specific ID_KEY_ID". The vendors have to agree on the pre-shared key out-of-band so in the same out-of-band channel they agree to bind the key to an opaque blob. e.g. the pre-shared key is "mekmitasdigoat" and the blob is "geukghisohfewh". That blob is not encrypted it is just meaningless outside the two peers. When someone presents and ID (whose type is ID_KEY_ID) of "geukghisohfewh" and provides proof of knowledge of the pre-shared-key associated with that then you've authenticated that party. The pre-shared key is based on the contents of the ID payload _not_ on address. If you don't like the solution then write up yet another authentication method for IKE and let us all throw darts at it. What is there now is not changing. Period. Full stop. End of discussion. Dan. From owner-ipsec Wed Jul 1 15:14:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA07117 for ipsec-outgoing; Wed, 1 Jul 1998 15:13:33 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807011929.MAA22644@kc.livingston.com> Subject: Re: More questions on ID types To: dharkins@cisco.com (Daniel Harkins) Date: Wed, 1 Jul 1998 12:29:50 -0700 (PDT) Cc: suresh@livingston.com, lmccarth@cs.umass.edu, ipsec@tis.com, BGleeson@shastanets.com In-Reply-To: <199807011907.MAA00743@dharkins-ss20.cisco.com> from "Daniel Harkins" at Jul 1, 98 12:07:14 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > On: Wed, 01 Jul 1998 10:59:38 PDT you wrote > [snip] > > > A "reserved mode" (I like that) can be written up in a draft but Main > > > Mode is not changing at this point in time. Sorry Bryan but this point was > > > discussed about a year ago and the resolution is what you see today. If > > > you want to allow remote access with pre-shared keys use Aggressive Mode. > > > If you don't want to expose a meaningful identity use ID_KEY_ID as the > > > identity to which the pre-shared key is bound. > > > > > > Dan. > > > > > > > It is good to note that the issue came up earlier and was discussed, > > even though I dont like the alternative you suggest. In order to not expose > > the actual identities, the vendors would have to agree on an out-of-band > > encryption by which to encrypt the ID in the vendor specific ID_KEY_ID. > > This is yet another encryption, and yet another out-of-band requirement > > in addition to the pre-shared key. Also, as Bryan pointed out, it > > is a layer violation in that a pre-shared key has to be assusmed based > > on the src address (in IP header) rather than ID payload. > > What encryption? An ID is not encrypted "in the vendor specific ID_KEY_ID". > > The vendors have to agree on the pre-shared key out-of-band so in the same > out-of-band channel they agree to bind the key to an opaque blob. e.g. the > pre-shared key is "mekmitasdigoat" and the blob is "geukghisohfewh". That > blob is not encrypted it is just meaningless outside the two peers. When What could have been a meaningful ID (such as foobar@foo.bar.com) is now having to be turned into a blob like "geukghisohfewh" by the vendors. This is what I meant by having to encrypt the ID. > someone presents and ID (whose type is ID_KEY_ID) of "geukghisohfewh" and > provides proof of knowledge of the pre-shared-key associated with that then > you've authenticated that party. The pre-shared key is based on the contents > of the ID payload _not_ on address. OK. > > If you don't like the solution then write up yet another authentication > method for IKE and let us all throw darts at it. What is there now is not > changing. Period. Full stop. End of discussion. > You misunderstood what I said. I wasnt saying I did not like the solution you proposed in the draft. Rather, I was asking for a rationale, because I was not present at the earlier IPsec meetings and am not privy to discussions on the subject otherwise. Hope you understand. > Dan. > > cheers, suresh From owner-ipsec Wed Jul 1 22:35:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA08213 for ipsec-outgoing; Wed, 1 Jul 1998 22:33:45 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807020250.TAA23999@kc.livingston.com> Subject: Re: More questions on ID types To: suresh@livingston.com (Pyda Srisuresh) Date: Wed, 1 Jul 1998 19:50:01 -0700 (PDT) Cc: dharkins@cisco.com, suresh@livingston.com, lmccarth@cs.umass.edu, ipsec@tis.com, BGleeson@shastanets.com In-Reply-To: <199807011929.MAA22644@kc.livingston.com> from "Pyda Srisuresh" at Jul 1, 98 12:29:50 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Ooops... Clarification to my last e-mail > > > > > On: Wed, 01 Jul 1998 10:59:38 PDT you wrote > > [snip] > > > > A "reserved mode" (I like that) can be written up in a draft but Main > > > > Mode is not changing at this point in time. Sorry Bryan but this point was > > > > discussed about a year ago and the resolution is what you see today. If > > > > you want to allow remote access with pre-shared keys use Aggressive Mode. > > > > If you don't want to expose a meaningful identity use ID_KEY_ID as the > > > > identity to which the pre-shared key is bound. > > > > > > > > Dan. > > > > > > > > > > It is good to note that the issue came up earlier and was discussed, > > > even though I dont like the alternative you suggest. In order to not expose > > > the actual identities, the vendors would have to agree on an out-of-band > > > encryption by which to encrypt the ID in the vendor specific ID_KEY_ID. > > > This is yet another encryption, and yet another out-of-band requirement > > > in addition to the pre-shared key. Also, as Bryan pointed out, it > > > is a layer violation in that a pre-shared key has to be assusmed based > > > on the src address (in IP header) rather than ID payload. > > > > What encryption? An ID is not encrypted "in the vendor specific ID_KEY_ID". > > > > The vendors have to agree on the pre-shared key out-of-band so in the same > > out-of-band channel they agree to bind the key to an opaque blob. e.g. the > > pre-shared key is "mekmitasdigoat" and the blob is "geukghisohfewh". That > > blob is not encrypted it is just meaningless outside the two peers. When > > What could have been a meaningful ID (such as foobar@foo.bar.com) is now > having to be turned into a blob like "geukghisohfewh" by the vendors. This > is what I meant by having to encrypt the ID. > > > someone presents and ID (whose type is ID_KEY_ID) of "geukghisohfewh" and > > provides proof of knowledge of the pre-shared-key associated with that then > > you've authenticated that party. The pre-shared key is based on the contents > > of the ID payload _not_ on address. > > OK. If main mode of exchange is permitted with pre-shared keys, the draft does state (section 5.4) that the pre-shared key can only be identified by initiator based on the IP address of the responder and not his ID payload. And, pre-shared keys MUST be permitted in Main mode because: Main mode is a MUST; Aggressive mode is a SHOULD. Authentication via pre-shared keys is a MUST. Pre-shared keys could be used in aggressive mode, as you say. But the ID type is in the clear. Vendors may need to transform the actual IDs (like foo@foo.com) into some undecipherable blobs and use ID_KEY_ID type IDs if they need to conceal real identity. > > > > > If you don't like the solution then write up yet another authentication > > method for IKE and let us all throw darts at it. What is there now is not > > changing. Period. Full stop. End of discussion. > > > > You misunderstood what I said. I wasnt saying I did not like the solution > you proposed in the draft. Rather, I was asking for a rationale, because I > was not present at the earlier IPsec meetings and am not privy to discussions > on the subject otherwise. Hope you understand. > > > Dan. > > > > > > cheers, > suresh > cheers, suresh From owner-ipsec Thu Jul 2 17:11:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA00519 for ipsec-outgoing; Thu, 2 Jul 1998 17:02:46 -0400 (EDT) Message-Id: <199807022114.RAA18455@relay.hq.tis.com> Date: Thu, 2 Jul 98 17:08:28 EDT From: Karen Seo To: ipsec@tis.com cc: rgm-sec@htt-consult.com, tytso@MIT.EDU, skent@bbn.com, clynn@bbn.com, kseo@bbn.com Subject: Revised drafts -- Arch, AH, ESP Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, In follow-up to Thomas Narten's (IESG) feedback (see Ted Ts'o's email of 5/22/98) and subsequent email, we have submitted to the IETF secretariat revised versions of the following drafts: o AH -- draft-ietf-ipsec-auth-header-06.txt o ESP -- draft-ietf-ipsec-esp-v2-05.txt o Architecture -- draft-ietf-ipsec-arch-sec-05.txt A summary of the changes that were made is attached below. Karen Architecture ------------ 1. Section 3.1 "What IPsec Does" and Section on "References" -- updated to reflect the progress of the IETF working group IP Payload Compression Protocol (ippcp) and make it easier for the RFC editor to insert the RFC number for ippcp. Changed Section 3.1, last paragraph, from: The IPsec DOI supports negotiation of IP compression, motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers. The IETF working group, "IP Payload Compression Protocol (ippcp)" has the charter to "develop protocol specifications that make it possible to perform lossless compression on individual payloads before the payload is processed by a protocol that encrypts it. These specifications will allow for compression operations to be performed prior to the encryption of a payload by such protocols as IPsec." To: The IPsec DOI also supports negotiation of IP compression [SMPT98], motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers. Added to References section: [SMPT98] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload Compression Protocol (IPComp)", Internet Draft, May 1998. 2. Section 4.4.3 Security Association Database (SAD) -- clarified issues relating to handling/calculating SA lifetime if a byte count is used. Changed from: o Lifetime of this Security Association: .... (a) If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec algorithm is applied. To: o Lifetime of this Security Association: .... (a) If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec algorithm is applied. For ESP, this is the encryption algorithm (including Null encryption) and for AH, this is the authentication algorithm. This includes pad bytes, etc. Note that implementations SHOULD be able to handle having the counters at the ends of an SA get out of synch, e.g., because of packet loss or because the implementations at each end of the SA aren't doing things the same way. 3. Section 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode -- added note to clarify decrementing of TTL. After the following paragraph: 2. The TTL in the inner header is decremented by the encapsulator prior to forwarding and by the decapsulator if it forwards the packet. (The checksum changes when the TTL changes.) we added: Note: The decrementing of the TTL is one of the usual actions that takes place when forwarding a packet. Packets originating from the same node as the encapsulator do not have their TTL's decremented, as the sending node is originating the packet rather than forwarding it. 4. Section 6.1.2.1 Propagation of PMTU, second bullet in paragraph 1; and Section B.3.1 "Identifying the Originating Host(s)" -- removed reference to IPv6/ICMP 576 byte minimum. Changed Section 6.1.2.1 from: o PMTU message with >64 bits of IPsec header -- If the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough non-opaque information to immediately determine to which host to propagate the ICMP/PMTU message.... To: o PMTU message with >64 bits of IPsec header -- If the ICMP message contains more information from the original packet then there MAY be enough non-opaque information to immediately determine to which host to propagate the ICMP/PMTU message.... Changed Section B.3.1, 2nd paragraph, from: In brief... An ICMP message must contain the following information from the "offending" packet: - IPv4 (RFC 792) -- IP header plus a minimum of 64 bits - IPv6 (RFC 1885) -- IP header plus a minimum of 576 bytes To: In brief... An ICMP message must contain the following information from the "offending" packet: - IPv4 (RFC 792) -- IP header plus a minimum of 64 bits Changed Section B.3.1, last paragraph, from: Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, if the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough information to....NOTE: The Next Protocol field MAY not be contained in the 576 bytes and the use of ESP encryption MAY hide the selector fields that have been encrypted. To: Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, if the ICMP message contains more information from the original packet, then there MAY be enough information to... NOTE: The Next Protocol field MAY not be contained in the ICMP message and the use of ESP encryption MAY hide the selector fields that have been encrypted. AH only ------- 1. Section 3.3.3.1 Handling Mutable Fields, 2nd paragraph -- clarified issue of which IP headers have a flag indicating mutability. This was related to confusion over the term "options". The "fixed" paragraph below was in the version distributed/posted by the secretariat on May 12/13. Changed from: As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV. If the IPsec implementation encounters an extension header that it does not recognize, it MUST zero the whole header except for the Next Header and Hdr Ext Len fields. The length of the extension header MUST be computed by 8 * Hdr Ext Len value + 8. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. (IPv6 options contain a flag indicating mutability, which determines appropriate processing for such options.) To: As a new extension header or IPv4 option is created, it will be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV. If the IP (v4 or v6) implementation encounters an extension header that it does not recognize, it will discard the packet and send an ICMP message. IPsec will never see the packet. If the IPsec implementation encounters an IPv4 option that it does not recognize, it should zero the whole option, using the second byte of the option as the length. IPv6 options (in Destination extension headers or Hop by Hop extension header) contain a flag indicating mutability, which determines appropriate processing for such options. AH and ESP ---------- 1. AH section 3.3.2 Sequence Number Generation, last paragraph; ESP section 3.3.3 Sequence Number Generation, last paragraph -- clarified the handling of the sequence number by the sender when anti-replay has been disabled. Changed from: If anti-replay has been disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management. To: If anti-replay is disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. From owner-ipsec Thu Jul 2 17:57:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA00835 for ipsec-outgoing; Thu, 2 Jul 1998 17:56:46 -0400 (EDT) Date: Thu, 2 Jul 1998 18:11:57 -0400 From: Ran Canetti Message-Id: <9807022211.AA29770@ornavella.watson.ibm.com> To: ipsec@tis.com Subject: DH-less encryption mode for IKE Sender: owner-ipsec@ex.tis.com Precedence: bulk Currently all the modes of (phase I of) IKE involve performing a Diffie-Hellman (DH) exponentiation on either end. While DH helps maintain long term secrecy (via its Perfect-Forward-Secrecy properties) the computational cost is high: DH exponentiations takes a large fraction of the processing time, even when elliptic curves are used. Yet, on the majority of internet traffic long term secrecy may not be be a concern at all. (In fact, many connections may be interested only in integrity.) Thus, a "lightweight" mode that does not involve DH exponentiations seems warranted. Hugo, Pau and I have submitted a draft describing how the (revised) encryption mode of IKE can be performed without the Diffie-Hellman exponentiations. This mode involves only a very minor modification of the current revised mode. (Basically, the DH payloads are omitted and the DH values needed for the derivation of SKEYID_a,d,e are zeroed out.) We would like to propose this mode to the list as a work item for ipsecond. I enclose the abstract; the draft should be available in couple days. In conjunction to this, and in order to avoid inflating the number of modes in IKE, we would like to propose to move the original (non-revised) encryption mode of IKE to "historic". Ran BTW, I'd like to draw attention to the "security considerations" section of the draft. It contains a warning that is relevant also to the current (DH-full) encryption modes of IKE. It reads: 4. Security Considerations The public key encryption modes of authentication in IKE require strong public key encryption. In particular, resistance to strong attacks generally known as "chosen ciphertext attacks" (CCA) is necessary. This is a practical need as well as the basis for a sound analysis of these protocols [BeCaKr]. Recently, an explicit chosen ciphertext attack on the PKCS #1 encryption standard was demonstrated [Ble]. RSA Labs., the authors of PKCS#1, are preparing a new release of PKCS #1 that will include the OAEP format of RSA encryption [RSAlabs]. It is strongly recommended that IKE specifications and implementations move to that format which was designed to resist CCA and other attacks. ------------------------------------------------------------------------------ IPSEC Working Group R. Canetti, P. Cheng, H. Krawczyk INTERNET-DRAFT IBM Research and the Technion draft-ietf-ipsec-dhless-enc-mode-00.txt July 1998 Expire in six months A DH-less encryption mode for IKE Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 1. Abstract The IKE document [HC98] describes a key exchange protocol for obtaining authenticated and secret keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. All the current modes for carrying out Phase 1 of the key exchange in [HC98] incorporate a Diffie- Hellman exponentiation. While the DH exponentiation enhances the security of the exchange (and in particular provides perfect forward secrecy (PFS)), this enhanced secrecy comes at a computational cost. In cases where PFS is not a requirement, most notably in authentication only scenarios, less expensive solutions are possible. This draft describes a ``DH-less'' version of the (revised) public- key encryption mode of [HC98]. This saves the DH exponentiation, which may be significant (especially on low-end machines and busy servers). The proposed mode is VERY similar to the existing modes and requires only minimal modifications. In particular, it is straightforward to implement as an addition to the existing modes. From owner-ipsec Fri Jul 3 01:12:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA01799 for ipsec-outgoing; Fri, 3 Jul 1998 01:09:47 -0400 (EDT) Message-Id: <199807030522.OAA06935@isl.rdc.toshiba.co.jp> To: Karen Seo cc: ipsec@tis.com Subject: Re: Revised drafts -- Arch, AH, ESP In-reply-to: kseo's message of "Thu, 02 Jul 1998 17:08:28 EDT." <199807022114.RAA18455@relay.hq.tis.com> Date: Fri, 03 Jul 1998 14:21:52 +0900 From: FUKUMOTO Atsushi Sender: owner-ipsec@ex.tis.com Precedence: bulk Regarding IPSEC architecture draft, I have a question: > Changed Section 6.1.2.1 from: : > To: > o PMTU message with >64 bits of IPsec header -- If the ICMP > message contains more information from the original packet > then there MAY be enough non-opaque information to I couldn't understand why "MAY" is used here instead of lowercase "may". Is it really "MAY" in RFC2119 way of definition? (There are some other similar capitalization I couldn't understand in the draft.) FUKUMOTO Atsushi fukumoto@imasy.or.jp From owner-ipsec Mon Jul 6 09:50:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA08628 for ipsec-outgoing; Mon, 6 Jul 1998 09:42:50 -0400 (EDT) From: Karen Heron To: Subject: IPsec and Fragmentation Message-ID: <5040300017909679000002L092*@MHS> Date: Mon, 6 Jul 1998 09:56:05 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk In draft-ietf-ipsec-arch-sec-05, AppendixB, section B.2, Fragmentation, it states that "Fragmentation MUST be done after outbound IPsec processing." I am seeing a problem when doing this. I have the following setup: +--------------------------------------------------------+ H1---|----MTU=2000-----RTR------MTU=1280------|------SG1-----MTU=1500-----H2 +--------------------------------------------------------+ SA, tunnel mode H1, H2 - hosts RTR - intermediate router in the secure tunnel SG1 - security gateway What I've tried to show is a tunnel mode SA between H1 and SG1 that will secure packets from H1 to H2. The MTU in the tunnel will be 1280. Here's what I see happening: 1. H1 sends 1800 bytes to H2. It is secured (it has an outer header) and sent into the tunnel. 2. A packet too big is sent back from RTR with an MTU of 1280. 3. H1 sends 1800 bytes to H2. It is secured and has an outer header from H1 to SG1. It is fragmented and sent into the tunnel. 4. SG1 receives the fragments and reassembles. 5. SG1 de-capsulates the packet and attempts to forward to H2. 6. This fails since the packet is 1800 bytes and the MTU on the output net for SG1 is 1500 bytes. Have I implemented something incorrectly? It appears that I am following the architecture for H1 (i.e., securing and then fragmenting), but I don't see how I can get these large packets to H2 unless I fragment and then secure in H1. Any help would be appreciated. By the way, my example is for IPv6 (no fragmentation allowed by intermediate routers) although the same problem exists for IPv4 with the DF bit set in the inner and outer headers. Karen Heron Router Development IBM, RTP, NC From owner-ipsec Mon Jul 6 11:38:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09044 for ipsec-outgoing; Mon, 6 Jul 1998 11:36:57 -0400 (EDT) From: Karen Heron To: , Subject: Re: IPsec and Fragmentation Message-ID: <5040300017915625000002L052*@MHS> Date: Mon, 6 Jul 1998 11:49:58 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > Path MTU discovery is a required feature of any compliant IPsec > implementation. While PMTU discovery doesn't "fix the problem", it > permits originating hosts (be they secured or not) to deflate their MTUs > according to the actually observed MTU in the pathway. > We calculate an MTU by subtracting IPsec header/trailer expansion octets > from the known MTU of the path. (It was a "bug" in our implementation > until I was charged with implementing PMTU discovery in our IPsec...) > In your example, the failure in step 6 should cause backpropagation > (sorry!), by ICMP CANT_FRAG packets, of the MTU to the originator of the > excessively-large packet. A good question to ask at this point is > how ICMP CANT_FRAG packets are needed to propagate the real path MTU to > the originating host. The problem with SG1 returning a Packet Too Big message with MTU=1500 to H1 is that H1 already sees the Path MTU as 1280 (which is the MTU for the tunnel). H1 won't increase its PMTU in response to receiving a Packet Too Big message, but even if H1 did, it would then not be able to send the packets through the tunnel. Karen Heron writes: >> In draft-ietf-ipsec-arch-sec-05, AppendixB, section B.2, Fragmentation, it >> states that "Fragmentation MUST be done after outbound IPsec processing." I am >> seeing a problem when doing this. I have the following setup: >> >> +--------------------------------------------------------+ >> H1---|----MTU=2000-----RTR------MTU=1280------|------SG1-----MTU=1500-----H2 >> +--------------------------------------------------------+ >> SA, tunnel mode >> >> >> H1, H2 - hosts >> RTR - intermediate router in the secure tunnel >> SG1 - security gateway >> >> What I've tried to show is a tunnel mode SA between H1 and SG1 that will secure >> packets from H1 to H2. The >> MTU in the tunnel will be 1280. Here's what I see happening: >> >> 1. H1 sends 1800 bytes to H2. It is secured (it has an outer header) and sent >> into the tunnel. >> 2. A packet too big is sent back from RTR with an MTU of 1280. >> 3. H1 sends 1800 bytes to H2. It is secured and has an outer header from H1 >> to SG1. It is fragmented and >> sent into the tunnel. >> 4. SG1 receives the fragments and reassembles. >> 5. SG1 de-capsulates the packet and attempts to forward to H2. >> 6. This fails since the packet is 1800 bytes and the MTU on the output net for >> SG1 is 1500 bytes. >> >> Have I implemented something incorrectly? It appears that I am following the >> architecture for H1 (i.e., securing >> and then fragmenting), but I don't see how I can get these large packets to H2 >> unless I fragment and then secure >> in H1. Any help would be appreciated. By the way, my example is for IPv6 (no >> fragmentation allowed by >> intermediate routers) although the same problem exists for IPv4 with the DF bit >> set in the inner and outer headers. >> >> Karen Heron >> Router Development >> IBM, RTP, NC From owner-ipsec Mon Jul 6 11:44:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09087 for ipsec-outgoing; Mon, 6 Jul 1998 11:43:56 -0400 (EDT) From: Dan McDonald Message-Id: <199807061559.IAA11031@kebe.eng.sun.com> Subject: Re: IPsec and Fragmentation To: heron@us.ibm.com (Karen Heron) Date: Mon, 6 Jul 1998 08:59:16 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <5040300017909679000002L092*@MHS> from "Karen Heron" at Jul 6, 98 09:56:05 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > I have the following setup: > > +--------------------------------------------------------+ > H1---|----MTU=2000-----RTR------MTU=1280------|------SG1-----MTU=1500-----H2 > +--------------------------------------------------------+ > SA, tunnel mode > > > H1, H2 - hosts > RTR - intermediate router in the secure tunnel > SG1 - security gateway > > What I've tried to show is a tunnel mode SA between H1 and SG1 that will > secure packets from H1 to H2. The MTU in the tunnel will be 1280. Here's > what I see happening: Wait. Let's look at this from the network-only perspective first. Since the tunnel is between H1 and SG1, then I have reachability from H1 to SG1. How would your implementation on H1 normally handle such MTU discovery? Is there an entry of some kind on H1 that says "1280 bytes from me to SG1"? > 1. H1 sends 1800 bytes to H2. It is secured (it has an outer header) and > sent into the tunnel. So far so good. > 2. A packet too big is sent back from RTR with an MTU of 1280. Okay, after this, you'd BETTER have an entry on H1 that says "1280 bytes from me to SG1". > 3. H1 sends 1800 bytes to H2. It is secured and has an outer header from H1 > to SG1. It is fragmented and sent into the tunnel. So 1800 + ESP will get split. Cool. BTW, if you were using TCP, your TCP should know to send smaller fragments. Just a point. UDP can't do this, neither can ICMP (e.g. ping). > 4. SG1 receives the fragments and reassembles. Okay. > 5. SG1 de-capsulates the packet and attempts to forward to H2. Over an ethernet of 1500. > 6. This fails since the packet is 1800 bytes and the MTU on the output net > for SG1 is 1500 bytes. Yes, and what should then happen is SG1 should send back a "too big" to H1 for the 1500 bit. In addition to "1280 bytes from me to SG1", perhaps H1 should also have a "1500 bytes from H1 to H2" which will have the initial IP do the right thing. Since H1 is the originator of both the INNER and the OUTER packet, fragmenting twice is perfectly within the rules, even for IPv6. > Have I implemented something incorrectly? Which part? Judging from your .signature, I'd guess you're concerned about SG1 or the RTR. I'd just make sure that your SG1 issues a "packet too big" for destination H2 back to H1. It is up to (IMHO) H1 to do the right thing with that. > It appears that I am following the architecture for H1 (i.e., securing and > then fragmenting), but I don't see how I can get these large packets to H2 > unless I fragment and then secure in H1. Any help would be appreciated. A lot will depend on how H1 and SG1 implements things. Like I said, H1 should be able to deal with ICMP too big messages for both the outer-packet path, and the inner-packet path, because it is the originator of both. Likewise, SG1 should know the difference between a too big sent on behalf of the outer packet vs. one sent on behalf of the inner packet. Solving this is not painless. Dan From owner-ipsec Mon Jul 6 12:40:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA09296 for ipsec-outgoing; Mon, 6 Jul 1998 12:39:06 -0400 (EDT) From: Karen Heron To: , Subject: Re: IPsec and Fragmentation Message-ID: <5040300017918088000002L082*@MHS> Date: Mon, 6 Jul 1998 12:52:07 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > Yes, and what should then happen is SG1 should send back a "too big" to H1 > for the 1500 bit. > > In addition to "1280 bytes from me to SG1", perhaps H1 should also have a > "1500 bytes from H1 to H2" which will have the initial IP do the right > thing. > > Since H1 is the originator of both the INNER and the OUTER packet, > fragmenting twice is perfectly within the rules, even for IPv6. I agree, except I missed my opportunity to fragment the inner packet because according to the architecture, I need to secure the packet first and then fragment it. By the time I've secure it, I "lose track" of the inner header, so I just fragment it according to the outer header which is causing my problem! Any other suggestions to help me get out of my predicament? I must be missing something obvious - I still think the only way to get out of this is fragment first and then secure. Karen Heron Router Development IBM, RTP, NC From owner-ipsec Mon Jul 6 12:46:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA09354 for ipsec-outgoing; Mon, 6 Jul 1998 12:46:07 -0400 (EDT) From: Dan McDonald Message-Id: <199807061701.KAA11334@kebe.eng.sun.com> Subject: Re: IPsec and Fragmentation To: heron@us.ibm.com (Karen Heron) Date: Mon, 6 Jul 1998 10:01:51 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <5040300017918088000002L082*@MHS> from "Karen Heron" at Jul 6, 98 12:52:07 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > I agree, except I missed my opportunity to fragment the inner packet > because according to the architecture, I need to secure the packet first > and then fragment it. And that should be your first course of action. It shouldn't be the subsequent course of action. > By the time I've secure it, I "lose track" of the inner header, so I just > fragment it according to the outer header which is causing my problem! Is that true? Like I said, H1 > Any other suggestions to help me get out of my predicament? I must be > missing something obvious - I still think the only way to get out of this > is fragment first and then secure. After receiving appropriate ICMP too big information, I guess you should "fragment before you secure". From the inner packet's point of view (i.e. the inner packet sees a network, and nothing about tunnels), it's just a node somewhere out on the network saying that the packet is too big. That sort of "fragmenting before you secure" is not so much a "violation" of the architecture document. That phrase is in there to prevent doing additional stuff beyond normal IP processing. (Steve, I do have this right, don't I?) It's just normal IP processing. Keeping the inner and outer packets as distinct IP entities helps keep a lot of this easier to manage. Dan From owner-ipsec Mon Jul 6 13:14:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA09449 for ipsec-outgoing; Mon, 6 Jul 1998 13:13:13 -0400 (EDT) Date: Mon, 6 Jul 1998 13:29:28 -0400 (EDT) From: "M.C.Nelson" To: ipsec@tis.com cc: heron@us.ibm.com Subject: Re: IPsec and Fragmentation In-Reply-To: <5040300017915625000002L052*@MHS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk IPSEC WG, I just want to add a parenthetic note, that PMTU seems to really be at odds with the definition and philosophy of IP, i.e. IP in general, is supposed to be able to fragment packets in route, and routes are in general subject to change. I have some difficulty understanding why an appropriate IP encryption standard that is supposed to become general usage, would require such dissonances with the general case use of its host architecture. Mitch Nelson On Mon, 6 Jul 1998, Karen Heron wrote: > > Path MTU discovery is a required feature of any compliant IPsec > > implementation. While PMTU discovery doesn't "fix the problem", it > > permits originating hosts (be they secured or not) to deflate their MTUs > > according to the actually observed MTU in the pathway. > > > We calculate an MTU by subtracting IPsec header/trailer expansion octets > > from the known MTU of the path. (It was a "bug" in our implementation > > until I was charged with implementing PMTU discovery in our IPsec...) > > > In your example, the failure in step 6 should cause backpropagation > > (sorry!), by ICMP CANT_FRAG packets, of the MTU to the originator of the > > excessively-large packet. A good question to ask at this point is > > how ICMP CANT_FRAG packets are needed to propagate the real path MTU to > > the originating host. > > The problem with SG1 returning a Packet Too Big message with MTU=1500 to H1 > is that H1 already sees the Path MTU as 1280 (which is the MTU for the > tunnel). H1 won't increase its PMTU in response to receiving a Packet Too > Big message, but even if H1 did, it would then not be able to send the > packets through the tunnel. > > Karen Heron writes: > >> In draft-ietf-ipsec-arch-sec-05, AppendixB, section B.2, Fragmentation, it > >> states that "Fragmentation MUST be done after outbound IPsec processing." I > am > >> seeing a problem when doing this. I have the following setup: > >> > >> +--------------------------------------------------------+ > >> > H1---|----MTU=2000-----RTR------MTU=1280------|------SG1-----MTU=1500-----H2 > >> +--------------------------------------------------------+ > >> SA, tunnel mode > >> > >> > >> H1, H2 - hosts > >> RTR - intermediate router in the secure tunnel > >> SG1 - security gateway > >> > >> What I've tried to show is a tunnel mode SA between H1 and SG1 that will > secure > >> packets from H1 to H2. The > >> MTU in the tunnel will be 1280. Here's what I see happening: > >> > >> 1. H1 sends 1800 bytes to H2. It is secured (it has an outer header) and > sent > >> into the tunnel. > >> 2. A packet too big is sent back from RTR with an MTU of 1280. > >> 3. H1 sends 1800 bytes to H2. It is secured and has an outer header from H1 > >> to SG1. It is fragmented and > >> sent into the tunnel. > >> 4. SG1 receives the fragments and reassembles. > >> 5. SG1 de-capsulates the packet and attempts to forward to H2. > >> 6. This fails since the packet is 1800 bytes and the MTU on the output net > for > >> SG1 is 1500 bytes. > >> > >> Have I implemented something incorrectly? It appears that I am following the > >> architecture for H1 (i.e., securing > >> and then fragmenting), but I don't see how I can get these large packets to > H2 > >> unless I fragment and then secure > >> in H1. Any help would be appreciated. By the way, my example is for IPv6 > (no > >> fragmentation allowed by > >> intermediate routers) although the same problem exists for IPv4 with the DF > bit > >> set in the inner and outer headers. > >> > >> Karen Heron > >> Router Development > >> IBM, RTP, NC > > > > > From owner-ipsec Mon Jul 6 13:44:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA09635 for ipsec-outgoing; Mon, 6 Jul 1998 13:40:19 -0400 (EDT) Message-Id: <98Jul6.135747edt.11651@janus.tor.securecomputing.com> To: "M.C.Nelson" cc: ipsec@tis.com, heron@us.ibm.com Subject: Re: IPsec and Fragmentation References: In-reply-to: netsec's message of "Mon, 06 Jul 1998 13:29:28 -0400". From: "C. Harald Koch" Date: Mon, 6 Jul 1998 13:55:56 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , "M.C.Nelson" writes: > IPSEC WG, > > I just want to add a parenthetic note, that PMTU seems to really be at > odds with the definition and philosophy of IP, i.e. IP in general, is > supposed to be able to fragment packets in route, and routes are in > general subject to change. I have some difficulty understanding why an > appropriate IP encryption standard that is supposed to become general > usage, would require such dissonances with the general case use of its > host architecture. PMTU is an optimisation technique, and is not required for IP to work. It is, however, strongly recommended, especially for TCP over congested networks. As a result, many vendors now implemented it in their operating systems. This leads to the IPsec MUST requirement. Like many other parts of IPsec, the MUST is "You MUST support this", not "You MUST *use* this". Fragmentation is exceedingly evil for performance in the face of packet loss (either due to errors or congestion); See "Fragmentation Considered Harmful" for details... -- Harald Koch From owner-ipsec Mon Jul 6 14:37:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA09868 for ipsec-outgoing; Mon, 6 Jul 1998 14:31:21 -0400 (EDT) Message-Id: <199807061846.OAA00896@istari.sandelman.ottawa.on.ca> To: "M.C.Nelson" CC: ipsec@tis.com Subject: Re: IPsec and Fragmentation In-reply-to: Your message of "Mon, 06 Jul 1998 13:29:28 EDT." Date: Mon, 06 Jul 1998 14:46:53 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "M" == M C Nelson writes: M> IPSEC WG, M> I just want to add a parenthetic note, that PMTU seems to really be at M> odds with the definition and philosophy of IP, i.e. IP in general, is M> supposed to be able to fragment packets in route, and routes are in M> general subject to change. I have some difficulty understanding why an M> appropriate IP encryption standard that is supposed to become general M> usage, would require such dissonances with the general case use of its M> host architecture. a) go read the PMTU spec. b) routes changes, and the PMTU changes as a result. c) IPv6 does not fragment packets. Deal with it, don't try and change the way things have gone ahead. I see that draft-richardson-ipsec-pmtu-discov-01.txt has expired. Please read it. I have some revisions that I didn't change, and I will resubmit ASAP. In the meantime, please see: 1. http://www.sandelman.ottawa.on.ca/SSW/ietf/draft-richardson-ipsec-pmtu-discovery-00.txt 2. grep'ing my archives To: Cc: Subject: Re: IPsec and Fragmentation Message-ID: <5040300017924730000002L002*@MHS> Date: Mon, 6 Jul 1998 15:15:10 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Phuong - It would be fragmented at the host - at an upper layer such as TCP or, depending on the implementation, it could also occur at the IP layer. Either way, before the datagrams leave the host, they need to "fit" the Path MTU! > I don't think it wouldn't be the case for IPV4, if you said > although the same problem exists for IPv4 with the DF bit set in the > inner and outer headers." then how the packet get fragmented in > the first place in step 3? > > Phuong Karen Heron Router Development IBM, RTP, NC From owner-ipsec Mon Jul 6 16:53:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA10308 for ipsec-outgoing; Mon, 6 Jul 1998 16:52:23 -0400 (EDT) Message-ID: <35A1678C.3CA7@phase2net.com> Date: Mon, 06 Jul 1998 17:10:52 -0700 From: Jeff Pickering Reply-To: jpickering@phase2net.com Organization: phase2 networks X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: isakmp sig payload encoding Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I need a spec interpretation for encoding of a DSS signature in oakley phase1. Section 5.1 of the IKE document says that "DSS signatures MUST be encoded as r followed by s". Does this mean: a) a BER constructed sequence consisting of 2 integers, or b) 2 BER encoded integers, or c) 2 raw unencoded integers because the key will specify the length of the integers? All comments appreciated. jeff From owner-ipsec Mon Jul 6 16:55:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA10349 for ipsec-outgoing; Mon, 6 Jul 1998 16:54:25 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199807061701.KAA11334@kebe.eng.sun.com> References: <5040300017918088000002L082*@MHS> from "Karen Heron" at Jul 6, 98 12:52:07 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 6 Jul 1998 17:05:23 -0400 To: Dan McDonald From: Stephen Kent Subject: Re: IPsec and Fragmentation Cc: heron@us.ibm.com (Karen Heron), ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan and Karen, Section 3.2.5 of the architecture document states that transport mode is always applied to whole IP datagrams, but that tunnel mode may be applied to packet fragments. This was motivated by the need to accommodate security gateways, and BITS, BITW implementations, but you can legitimately apply tunnel mode processing in this fashion in your host to make matching of MTU info to the headers easier. The IPsec receiver at H2 does not know whether you have a BITS or BITW implementation vs. a native implementation, so it must be prepared to accept encapsulated fragments in tunnel mode. Steve From owner-ipsec Mon Jul 6 17:17:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10447 for ipsec-outgoing; Mon, 6 Jul 1998 17:17:23 -0400 (EDT) Message-Id: <2.2.32.19980706213242.008df0fc@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 Jul 1998 17:32:42 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Serous system failure Sender: owner-ipsec@ex.tis.com Precedence: bulk My notebook is out of service (since thursday) for maybe a week. My mail is on it until maybe tomorrow (should have been today :( ). I am running a little of my mail here on my server. I have rgm@icsa.net kind of working temporarily. So anyone needing to 'talk' to me use it. Ted, give me a call (my phone book is on that system). I will be at my desk most of the day. Robert Moskowitz HTT Consulting rgm@htt-consult.com From owner-ipsec Mon Jul 6 18:14:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA10646 for ipsec-outgoing; Mon, 6 Jul 1998 18:13:25 -0400 (EDT) Message-Id: <199807062225.SAA11180@relay.hq.tis.com> Date: Mon, 6 Jul 98 18:25:58 EDT From: Karen Seo To: FUKUMOTO Atsushi cc: ipsec@tis.com, kseo@bbn.com Subject: Re: Revised drafts -- Arch, AH, ESP Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, >>I couldn't understand why "MAY" is used here instead of lowercase >>"may". Is it really "MAY" in RFC2119 way of definition? You're right. Thank you for pointing this out. >>(There are some other similar capitalization I couldn't understand in >>the draft.) Could you let me know about any other cases of this and I'll try to take care of them before the I-D goes to the RFC editor? Thanks again, Karen From owner-ipsec Tue Jul 7 07:17:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12790 for ipsec-outgoing; Tue, 7 Jul 1998 07:15:23 -0400 (EDT) From: Karen Heron To: Cc: , Subject: Re: IPsec and Fragmentation Message-ID: <5040300017945831000002L012*@MHS> Date: Tue, 7 Jul 1998 07:28:44 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > Dan and Karen, > > Section 3.2.5 of the architecture document states that transport mode is > always applied to whole IP datagrams, but that tunnel mode may be applied > to packet fragments. This was motivated by the need to accommodate > security gateways, and BITS, BITW implementations, but you can legitimately > apply tunnel mode processing in this fashion in your host to make matching > of MTU info to the headers easier. The IPsec receiver at H2 does not know > whether you have a BITS or BITW implementation vs. a native implementation, > so it must be prepared to accept encapsulated fragments in tunnel mode. > > Steve Thanks for the clarification. (However, I'm having trouble finding section 3.2.5 in my copy of the architecture doc (draft-ietf-ipsec-arch-sec-05)). But I believe that the statement in Appendix B, section B.2, "Fragmentation MUST be done after outbound IPsec processing." is incorrect. In fact, for a tunnel mode SA on a host, fragmentation must be done before IPsec processing to make PMTU discovery work, correct? Karen Heron Router Development IBM, RTP, NC From owner-ipsec Tue Jul 7 08:52:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA13185 for ipsec-outgoing; Tue, 7 Jul 1998 08:50:24 -0400 (EDT) Message-Id: <199807071303.WAA26402@isl.rdc.toshiba.co.jp> To: Karen Seo cc: ipsec@tis.com Subject: Re: Revised drafts -- Arch, AH, ESP In-reply-to: kseo's message of "Mon, 06 Jul 1998 18:25:58 EDT." Date: Tue, 07 Jul 1998 22:03:03 +0900 From: FUKUMOTO Atsushi Sender: owner-ipsec@ex.tis.com Precedence: bulk Regarding the capital words, I browsed through the draft and found the following. In section 5.2.1 "Selecting and Using an SA or SA Bundle" In general, a packet's source address MUST match the SA selector value. However, an ICMP packet received on a tunnel mode SA MAY have a source address other than that bound to the SA and thus such packets should be permitted as exceptions to this check. For an ICMP packet, the selectors "MAY" should be "may". Also, in my opinion, "MUST" should be "must". Besides, the construct of this paragraph "In general... MUST... However... should..." seems not very good. I think it should be something like: "Implementation MUST support exact match. Implementation SHOULD be able to pass non-matching ICMP." In Appendix B.3.1 "Identifying the Originating Host(s)" Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, if the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with the 5 fields (source address, destination address, source port, destination port, and transport protocol) needed to determine where to store/update the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. NOTE: The Next Protocol field MAY not be contained in the 576 bytes and the use of ESP encryption MAY hide the selector fields that have been encrypted. All "MAY"s should be "may". (I wish the second "MUST" be replaced with "SHOULD"...) That's all for now. I think we need some discussion whether some of "MUST" really need to be "MUST", but I think this point was raised in the mailing list already and the opions were "publish RFC, fix later," if I remember correctly. Regards, FUKUMOTO Atsushi fukumoto@isl.rdc.toshiba.co.jp From owner-ipsec Tue Jul 7 14:12:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14612 for ipsec-outgoing; Tue, 7 Jul 1998 14:07:53 -0400 (EDT) Message-ID: <35A26792.7321396A@redcreek.com> Date: Tue, 07 Jul 1998 11:23:15 -0700 From: "Scott G. Kelly" X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: simultaneous lifetime type support required? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I recall a discussion regarding the case where lifetimes of both types are specified, i.e. 8 hours or 10MB, whichever occurs first. However, I don't recall the wg's disposition on this matter. Specifically, is this required for phase 1, 2, or both? I found text referring to this in DOI in section 4.5.2 (attribute parsing requirements for lifetime), but haven't found anything in ARCH. Anyone? From owner-ipsec Tue Jul 7 14:45:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14827 for ipsec-outgoing; Tue, 7 Jul 1998 14:44:53 -0400 (EDT) Date: Tue, 7 Jul 1998 22:00:08 +0300 (EET DST) Message-Id: <199807071900.WAA18319@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: jpickering@phase2net.com Cc: ipsec@tis.com Subject: isakmp sig payload encoding In-Reply-To: <35A1678C.3CA7@phase2net.com> References: <35A1678C.3CA7@phase2net.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 2 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Jeff Pickering writes: > I need a spec interpretation for encoding of a DSS signature > in oakley phase1. > Section 5.1 of the IKE document says that "DSS signatures MUST be > encoded as r followed by s". Does this mean: > c) 2 raw unencoded integers because the key will specify the > length of the integers? C. -- 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 Tue Jul 7 17:14:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15421 for ipsec-outgoing; Tue, 7 Jul 1998 17:13:07 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF207106@exchange.timestep.com> From: Roy Pereira To: "Scott G. Kelly" , ipsec@tis.com Subject: RE: simultaneous lifetime type support required? Date: Tue, 7 Jul 1998 17:28:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BDA9EE.2D539900" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BDA9EE.2D539900 Content-Type: text/plain You should be able to support both expiry types for both phase 1 and phase 2 SAs. Multiple occurrences of each expiry type is forbidden though. > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: Tuesday, July 07, 1998 2:23 PM > To: ipsec@tis.com > Subject: simultaneous lifetime type support required? > > > I recall a discussion regarding the case where lifetimes of both types > are specified, i.e. 8 hours or 10MB, whichever occurs first. > However, I > don't recall the wg's disposition on this matter. > Specifically, is this > required for phase 1, 2, or both? > > I found text referring to this in DOI in section 4.5.2 (attribute > parsing requirements for lifetime), but haven't found > anything in ARCH. > Anyone? > > > ------ =_NextPart_001_01BDA9EE.2D539900 Content-Type: text/html RE: simultaneous lifetime type support required?

You should be able to support both expiry types for both phase 1 and phase 2 SAs.

Multiple occurrences of each expiry type is forbidden though.


> -----Original Message-----
> From: Scott G. Kelly [mailto:skelly@redcreek.com]
> Sent: Tuesday, July 07, 1998 2:23 PM
> To: ipsec@tis.com
> Subject: simultaneous lifetime type support required?
>
>
> I recall a discussion regarding the case where lifetimes of both types
> are specified, i.e. 8 hours or 10MB, whichever occurs first.
> However, I
> don't recall the wg's disposition on this matter.
> Specifically, is this
> required for phase 1, 2, or both?
>
> I found text referring to this in DOI in section 4.5.2 (attribute
> parsing requirements for lifetime), but haven't found
> anything in ARCH.
> Anyone?
>
>
>

------ =_NextPart_001_01BDA9EE.2D539900-- From owner-ipsec Tue Jul 7 17:18:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15447 for ipsec-outgoing; Tue, 7 Jul 1998 17:18:06 -0400 (EDT) Message-ID: <35A29433.301412E3@redcreek.com> Date: Tue, 07 Jul 1998 14:33:39 -0700 From: "Scott G. Kelly" X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Roy Pereira , ipsec@tis.com Subject: Re: simultaneous lifetime type support required? References: <319A1C5F94C8D11192DE00805FBBADDF207106@exchange.timestep.com> Content-Type: multipart/alternative; boundary="------------EAB2AA416CD27D9511E6D58E" Sender: owner-ipsec@ex.tis.com Precedence: bulk --------------EAB2AA416CD27D9511E6D58E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Roy Pereira wrote: > > > You should be able to support both expiry types for both phase 1 and > phase 2 SAs. > > Multiple occurrences of each expiry type is forbidden though. > I recognize the need to support both types, but the question is, am I required to support both types simultaneously? That is, if you send me 2 lifetime payloads together, one in kbytes and one in seconds, does this mean you want both values used, with the actual expiration based upon whichever occurs first? --------------EAB2AA416CD27D9511E6D58E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Roy Pereira wrote:

 

You should be able to support both expiry types for both phase 1 and phase 2 SAs.

Multiple occurrences of each expiry type is forbidden though.
 

I recognize the need to support both types, but the question is, am I required to support both types simultaneously? That is, if you send me 2 lifetime payloads together, one in kbytes and one in seconds, does this mean you want both values used, with the actual expiration based upon whichever occurs first?
  --------------EAB2AA416CD27D9511E6D58E-- From owner-ipsec Tue Jul 7 17:47:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15660 for ipsec-outgoing; Tue, 7 Jul 1998 17:47:20 -0400 (EDT) Message-Id: <199807072203.SAA04204@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: simultaneous lifetime type support required? In-reply-to: Your message of "Tue, 07 Jul 1998 14:33:39 PDT." <35A29433.301412E3@redcreek.com> Date: Tue, 07 Jul 1998 18:03:19 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Scott" == Scott G Kelly writes: Scott> I recognize the need to support both types, but the question is, Scott> am I required to support both types simultaneously? That is, if That is my understanding. Scott> you send me 2 lifetime payloads together, one in kbytes and one in Scott> seconds, does this mean you want both values used, with the actual Scott> expiration based upon whichever occurs first? The two types represent quantization of two weaknesses of cryptographic functions: 1. given a certain amount of time/money, you can brute force them. e.g. DES may be safe if you rekey every 10 minutes, assuming that your adversary can't afford to break the key faster than that. 2. some cryptographic functions have a limited lifetime. That is, you should not send more than Xk bytes through them. My understanding is that this has nothing to do with how much time it takes. A very high performance network may indeed send more than #2's bytes in much less than the brute force attack time, and so wants to rekey more often. I was just leafing through Schneier looking for some explanation of this. Pg. 184 (2nd edition) "It is generally easier to do cryptanalysis with more ciphertext encrypted under the same key" :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson | SSH IPsec: http://www.ssh.fi/. Secure, strong, international Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Tue Jul 7 18:13:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15759 for ipsec-outgoing; Tue, 7 Jul 1998 18:12:29 -0400 (EDT) Message-ID: <39ADCF833E74D111A2D700805F1951EF053FA073@red-msg-06.dns.microsoft.com> From: Brian Swander To: "'ipsec@tis.com'" Subject: Signature format and smart cards Date: Tue, 7 Jul 1998 15:28:09 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk The IKE signature format demands that the algo OID not be present in the signature. Smart card vendors are not supporting this format, but instead doing the standard pkcs1 with the OID. It is unlikely that all the vendors will ship using our format, and at the same time, IKE needs to be able to use certs from smart cards. I propose: Set the reserved field of the sig_payload header to 1 to signal standard pkcs1 with the OID, 0 otherwise. bs From owner-ipsec Tue Jul 7 18:35:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15870 for ipsec-outgoing; Tue, 7 Jul 1998 18:35:28 -0400 (EDT) Message-Id: <199807072251.SAA04275@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Signature format and smart cards In-reply-to: Your message of "Tue, 07 Jul 1998 15:28:09 PDT." <39ADCF833E74D111A2D700805F1951EF053FA073@red-msg-06.dns.microsoft.com> Date: Tue, 07 Jul 1998 18:51:14 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Brian" == Brian Swander writes: Brian> It is unlikely that all the vendors will ship using our format, Brian> and at the same time, IKE needs to be able to use certs from smart Brian> cards. Brian> I propose: Brian> Set the reserved field of the sig_payload header to 1 to signal Brian> standard pkcs1 with the OID, 0 otherwise. That is a silly thing to do. It doesn't nothing to help interopability, nor signals to people who haven't implemented this "hack" why the signatures fail. Instead, you need to define a new signature format, as if it were a totally different format. From isakmp-oakley-08: - Authentication Method pre-shared key 1 DSS signatures 2 RSA signatures 3 Encryption with RSA 4 Revised encryption with RSA 5 RSA signatures with OID 6 <--add values 6-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson | SSH IPsec: http://www.ssh.fi/. Secure, strong, international Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNaKmWtiXVu0RiA21AQG7nwL/TIclOU31I3CVIZG8nonN01TzGj7D6LJz BE9roolxmgZMsh1YGm4QyQhZP9ft7xXGmqe2N7jsH9DvodGWCiKdIH/+dT8R1L4g k377FEmqvdJ9ndvnBW3c2wFXQ94kNpbw =9sxX -----END PGP SIGNATURE----- From owner-ipsec Tue Jul 7 18:53:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15931 for ipsec-outgoing; Tue, 7 Jul 1998 18:53:27 -0400 (EDT) Message-Id: <199807072308.QAA07308@gallium.network-alchemy.com> To: "Scott G. Kelly" cc: Roy Pereira , ipsec@tis.com Subject: Re: simultaneous lifetime type support required? In-reply-to: Your message of "Tue, 07 Jul 1998 14:33:39 PDT." <35A29433.301412E3@redcreek.com> Date: Tue, 07 Jul 1998 16:08:42 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk >I recognize the need to support both types, but the question is, am I >required to support both types simultaneously? That is, if you send me 2 >lifetime payloads together, one in kbytes and one in seconds, does this >mean you want both values used, with the actual expiration based upon >whichever occurs first? Yes. Derrell From owner-ipsec Tue Jul 7 18:57:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15952 for ipsec-outgoing; Tue, 7 Jul 1998 18:57:27 -0400 (EDT) Message-ID: <35A2AB91.762FC189@redcreek.com> Date: Tue, 07 Jul 1998 16:13:21 -0700 From: "Scott G. Kelly" X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "Derrell D. Piper" CC: Roy Pereira , ipsec@tis.com Subject: Re: simultaneous lifetime type support required? References: <199807072308.QAA07308@gallium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell D. Piper wrote: > >I recognize the need to support both types, but the question is, am I > >required to support both types simultaneously? That is, if you send me 2 > >lifetime payloads together, one in kbytes and one in seconds, does this > >mean you want both values used, with the actual expiration based upon > >whichever occurs first? > > Yes. > > Derrell Next question: where is the language which says I MUST implement this? As previously posted, all I've seen is the stuff in DOI, which only relates to phase 2, and doesn't (appear) to say MUST. From owner-ipsec Tue Jul 7 20:14:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA16154 for ipsec-outgoing; Tue, 7 Jul 1998 20:13:31 -0400 (EDT) Date: Wed, 8 Jul 1998 03:29:02 +0300 (EET DST) Message-Id: <199807080029.DAA18080@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Brian Swander Cc: "'ipsec@tis.com'" Subject: Signature format and smart cards In-Reply-To: <39ADCF833E74D111A2D700805F1951EF053FA073@red-msg-06.dns.microsoft.com> References: <39ADCF833E74D111A2D700805F1951EF053FA073@red-msg-06.dns.microsoft.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 7 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Brian Swander writes: > The IKE signature format demands that the algo OID not be present in the > signature. Smart card vendors are not supporting this format, but instead > doing the standard pkcs1 with the OID. At least Bull's TB98S family supports raw RSA encryption and decryption with just raw data given to card. The another card we have here (from another vendor) does the rsa encryption / decryption similarly. Neither one of those doesn't allow doing the hashing or padding in the smart card. They must be done before the block is given to smart card. Those operations might be done in the pc/sc driver library. > It is unlikely that all the vendors will ship using our format, and at the > same time, IKE needs to be able to use certs from smart cards. The current IKE protocol can be used with smart cards. If the smart card you are using doesn't support raw rsa encryption / decryption, it might be better to change using some card that supports them. > I propose: > Set the reserved field of the sig_payload header to 1 to signal standard > pkcs1 with the OID, 0 otherwise. I see no need for that. -- 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 Wed Jul 8 09:32:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA18275 for ipsec-outgoing; Wed, 8 Jul 1998 09:29:53 -0400 (EDT) Message-ID: From: Greg Carter To: "'Brian Swander'" Cc: "'ipsec@tis.com'" Subject: RE: Signature format and smart cards Date: Wed, 8 Jul 1998 09:41:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Brian, I have successfully tested with two smart cards and have had no problems, a DataKey SignatureSure and a Chrysalis-ITS Luna Token, both use a PKCS-11 type interface. As well Tero mentioned others. I remember discussing this a while ago, but can't remember whether it was on the list or in person. Either way since there was enough smart cards that did support OIDless encryption it wasn't a problem. Personally I would rather see a smart card vendor do a driver update than change the spec at this point. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > ---------- > From: Brian Swander[SMTP:briansw@microsoft.com] > Sent: Tuesday, July 07, 1998 6:28 PM > To: 'ipsec@tis.com' > Subject: Signature format and smart cards > > The IKE signature format demands that the algo OID not be present in the > signature. Smart card vendors are not supporting this format, but instead > doing the standard pkcs1 with the OID. > > It is unlikely that all the vendors will ship using our format, and at the > same time, IKE needs to be able to use certs from smart cards. > > I propose: > > Set the reserved field of the sig_payload header to 1 to signal standard > pkcs1 with the OID, 0 otherwise. > > bs > From owner-ipsec Wed Jul 8 12:11:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19015 for ipsec-outgoing; Wed, 8 Jul 1998 12:10:02 -0400 (EDT) Message-ID: From: skeung To: ipsec@tis.com Subject: RE: simultaneous lifetime type support required? Date: Wed, 8 Jul 1998 09:27:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Are there any recommended lifetimes (both in time and bytes encrypted) for various ciphers for both phases? ---------------- Stephen Keung (skeung@rainbow.com) Rainbow Technologies, Inc. Internet Security Group > -----Original Message----- > From: Roy Pereira [SMTP:rpereira@TimeStep.com] > Sent: Tuesday, July 07, 1998 2:28 PM > To: Scott G. Kelly; ipsec@tis.com > Subject: RE: simultaneous lifetime type support required? > > You should be able to support both expiry types for both phase 1 and phase > 2 SAs. > > Multiple occurrences of each expiry type is forbidden though. > > > > -----Original Message----- > > From: Scott G. Kelly [ ] > > Sent: Tuesday, July 07, 1998 2:23 PM > > To: ipsec@tis.com > > Subject: simultaneous lifetime type support required? > > > > > > I recall a discussion regarding the case where lifetimes of both types > > are specified, i.e. 8 hours or 10MB, whichever occurs first. > > However, I > > don't recall the wg's disposition on this matter. > > Specifically, is this > > required for phase 1, 2, or both? > > > > I found text referring to this in DOI in section 4.5.2 (attribute > > parsing requirements for lifetime), but haven't found > > anything in ARCH. > > Anyone? > > > > > > > From owner-ipsec Wed Jul 8 12:44:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19176 for ipsec-outgoing; Wed, 8 Jul 1998 12:44:05 -0400 (EDT) Message-ID: <39ADCF833E74D111A2D700805F1951EF053FA07A@red-msg-06.dns.microsoft.com> From: Brian Swander To: "'Michael C. Richardson'" , ipsec@tis.com Subject: RE: Signature format and smart cards Date: Wed, 8 Jul 1998 09:59:27 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk This is not a new auth method, but an existing auth method with a different signature format. The analogous example is the cert payload. There are different encoding types for certs and we determine which we are using by a field in the certificate payload header. The obvious choice is to do the similar thing for the signature payload instead of unnecessarily expanding the authentication methods available. I agree that we should change the signature header to include this field instead of using the reserved section, but that will be an ipsecond issue. Implementations that choose not to recognize this flag will fail because the signature is in the wrong format. It is obviously up to those implementations to signal whatever they like to whomever they like. They have all the necessary information whether they choose to recognize the flag or not. bs > -----Original Message----- > From: Michael C. Richardson [SMTP:mcr@sandelman.ottawa.on.ca] > Sent: Tuesday, July 07, 1998 3:51 PM > To: ipsec@tis.com > Subject: Re: Signature format and smart cards > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Brian" == Brian Swander writes: > Brian> It is unlikely that all the vendors will ship using our format, > Brian> and at the same time, IKE needs to be able to use certs from > smart > Brian> cards. > > Brian> I propose: > > Brian> Set the reserved field of the sig_payload header to 1 to signal > Brian> standard pkcs1 with the OID, 0 otherwise. > > That is a silly thing to do. > It doesn't nothing to help interopability, nor signals to people who > haven't implemented this "hack" why the signatures fail. > > Instead, you need to define a new signature format, as if it were > a totally different format. From isakmp-oakley-08: > > - Authentication Method > pre-shared key 1 > DSS signatures 2 > RSA signatures 3 > Encryption with RSA 4 > Revised encryption with RSA 5 > RSA signatures with OID 6 <--add > > values 6-65000 are reserved to IANA. Values 65001-65535 are for > private use among mutually consenting parties. > > :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON > > Michael Richardson | SSH IPsec: http://www.ssh.fi/. Secure, > strong, international > Personal: HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html > ">mcr@sandelman.ottawa.on.ca. PGP key available. > Corporate: HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca > . > > > > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3ia > Charset: latin1 > Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface > > iQB1AwUBNaKmWtiXVu0RiA21AQG7nwL/TIclOU31I3CVIZG8nonN01TzGj7D6LJz > BE9roolxmgZMsh1YGm4QyQhZP9ft7xXGmqe2N7jsH9DvodGWCiKdIH/+dT8R1L4g > k377FEmqvdJ9ndvnBW3c2wFXQ94kNpbw > =9sxX > -----END PGP SIGNATURE----- From owner-ipsec Wed Jul 8 12:55:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19236 for ipsec-outgoing; Wed, 8 Jul 1998 12:55:05 -0400 (EDT) Message-Id: <199807081711.NAA07029@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Signature format and smart cards In-reply-to: Your message of "Wed, 08 Jul 1998 09:59:27 PDT." <39ADCF833E74D111A2D700805F1951EF053FA07A@red-msg-06.dns.microsoft.com> Date: Wed, 08 Jul 1998 13:11:15 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Brian" == Brian Swander writes: Brian> This is not a new auth method, but an existing auth method with a Brian> different signature format. The analogous example is the cert Brian> payload. There are different encoding types for certs and we Brian> determine which we are using by a field in the certificate payload Brian> header. The obvious choice is to do the similar thing for the Brian> signature payload instead of unnecessarily expanding the Brian> authentication methods available. No, it isn't obvious to me. The signatures are not compatible. If my smart card/software refuses to sign using the OID, and yours can not sign without the OID, we can not communicate. To the user, this is exactly the same as if you had DSS and I had RSA. Certificates are *requested* by format, and if you don't get something you understand, the failure mode is clear. Further, you may not even need that certificate, and the ability to send multiple certificates allows one to send certificates in multiple formats. Brian> I agree that we should change the signature header to include this Brian> field instead of using the reserved section, but that will be an Brian> ipsecond issue. No. If you want to use the reserved field, it is an IPsecond issue as well. Brian> Implementations that choose not to recognize this flag will fail Brian> because the signature is in the wrong format. It is obviously up Which causes the user/administator to spend hours trying to determine why the public keys/certificates are not configured right. What you suggest leads to non-interoperable systems. Maybe that doesn't bother you. The protocol has a clear place for vendor specific codes (65001-65535 for signature algorithms). Use it. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson | SSH IPsec: http://www.ssh.fi/. Secure, strong, international Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNaOoMdiXVu0RiA21AQGTkAMApweMPF8lczmqKkZXZ9E3SuTTEI+FA9JY 7z0vPbbpDRaFDI6LSlc1tigtFawYBYG/IjWUWH4PbcXDJIaMZnico7Kl+C0xMNMS 75ArT7oX9UG+IyKTIgBO2P7qQlKDJHpB =WqJE -----END PGP SIGNATURE----- From owner-ipsec Wed Jul 8 13:49:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19473 for ipsec-outgoing; Wed, 8 Jul 1998 13:47:09 -0400 (EDT) Message-ID: <39ADCF833E74D111A2D700805F1951EF053FA07F@red-msg-06.dns.microsoft.com> From: Brian Swander To: "'Michael C. Richardson'" , ipsec@tis.com Subject: RE: Signature format and smart cards Date: Wed, 8 Jul 1998 11:01:47 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk Then the solution is to negotiate signature encoding type as well. Clearly, the best solution is to add signature encoding type to the cert and cert request payload headers. We cannot do this. So I again propose to flag the oid-ful format with a 1 in the reserved field of these headers until ipsecond can fix this. bs > -----Original Message----- > From: Michael C. Richardson [SMTP:mcr@sandelman.ottawa.on.ca] > Sent: Wednesday, July 08, 1998 10:11 AM > To: ipsec@tis.com > Subject: Re: Signature format and smart cards > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Brian" == Brian Swander writes: > > Brian> This is not a new auth method, but an existing auth method with > a > Brian> different signature format. The analogous example is the cert > Brian> payload. There are different encoding types for certs and we > Brian> determine which we are using by a field in the certificate > payload > Brian> header. The obvious choice is to do the similar thing for the > Brian> signature payload instead of unnecessarily expanding the > Brian> authentication methods available. > > No, it isn't obvious to me. > The signatures are not compatible. If my smart card/software refuses to > sign > using the OID, and yours can not sign without the OID, we can not > communicate. > To the user, this is exactly the same as if you had DSS and I had RSA. > > Certificates are *requested* by format, and if you don't get something > you understand, the failure mode is clear. Further, you may not even > need that certificate, and the ability to send multiple certificates > allows > one to send certificates in multiple formats. > > Brian> I agree that we should change the signature header to include > this > Brian> field instead of using the reserved section, but that will be > an > Brian> ipsecond issue. > > No. If you want to use the reserved field, it is an IPsecond issue as > well. > > Brian> Implementations that choose not to recognize this flag will > fail > Brian> because the signature is in the wrong format. It is obviously > up > > Which causes the user/administator to spend hours trying to determine > why the public keys/certificates are not configured right. > What you suggest leads to non-interoperable systems. Maybe that > doesn't bother you. > > The protocol has a clear place for vendor specific codes (65001-65535 > for signature algorithms). Use it. > > :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON > > Michael Richardson | SSH IPsec: http://www.ssh.fi/. Secure, > strong, international > Personal: HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html > ">mcr@sandelman.ottawa.on.ca. PGP key available. > Corporate: HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca > . > > > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3ia > Charset: latin1 > Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface > > iQB1AwUBNaOoMdiXVu0RiA21AQGTkAMApweMPF8lczmqKkZXZ9E3SuTTEI+FA9JY > 7z0vPbbpDRaFDI6LSlc1tigtFawYBYG/IjWUWH4PbcXDJIaMZnico7Kl+C0xMNMS > 75ArT7oX9UG+IyKTIgBO2P7qQlKDJHpB > =WqJE > -----END PGP SIGNATURE----- From owner-ipsec Wed Jul 8 15:24:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19766 for ipsec-outgoing; Wed, 8 Jul 1998 15:19:04 -0400 (EDT) Date: Wed, 8 Jul 1998 15:34:59 -0400 Message-Id: <199807081934.PAA11323@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: briansw@microsoft.com Cc: mcr@sandelman.ottawa.on.ca, ipsec@tis.com Subject: RE: Signature format and smart cards References: <39ADCF833E74D111A2D700805F1951EF053FA07F@red-msg-06.dns.microsoft.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Brian" == Brian Swander writes: Brian> Then the solution is to negotiate signature encoding type as Brian> well. Clearly, the best solution is to add signature encoding Brian> type to the cert and cert request payload headers. We cannot Brian> do this. So I again propose to flag the oid-ful format with a Brian> 1 in the reserved field of these headers until ipsecond can Brian> fix this. Why can't this wait? I tend to agree with Micheal that hacking up the protocol at this late stage is not desirable. Given that there are devices that work with the spec as it stands, why the rush? paul From owner-ipsec Wed Jul 8 16:09:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA19912 for ipsec-outgoing; Wed, 8 Jul 1998 16:08:04 -0400 (EDT) Message-Id: <199807082024.QAA07178@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Signature format and smart cards In-reply-to: Your message of "Wed, 08 Jul 1998 15:34:59 EDT." <199807081934.PAA11323@tonga.xedia.com> Date: Wed, 08 Jul 1998 16:24:04 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Paul" == Paul Koning writes: Paul> Why can't this wait? Paul> I tend to agree with Micheal that hacking up the protocol at this Paul> late stage is not desirable. Given that there are devices that Paul> work with the spec as it stands, why the rush? I want to point out that even if there were a rush, the protocol provides for extending the number of signature types by using signature ids 65001 to 65535. This can be without need of a vendor id, since a compliant implementation will simply not accept that proposal. If there are alternate proposals, then a different will be chosen. If there aren't alternate proposals, then it will clear that the algorithms just don't match. (Kivinen, Darren, please confirm for me this interpretation) I would suggest that you still include a vendor id so that another implementation can determine which private address space is in use. RSA signatures (sans OID) are not a MUST in the spec, so if you can't support them, no big deal. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson | SSH IPsec: http://www.ssh.fi/. Secure, strong, international Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Wed Jul 8 18:48:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA20306 for ipsec-outgoing; Wed, 8 Jul 1998 18:46:20 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5040300017945831000002L012*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jul 1998 18:57:53 -0400 To: Karen Heron From: Stephen Kent Subject: Re: IPsec and Fragmentation Cc: Sender: owner-ipsec@ex.tis.com Precedence: bulk Karen, >Thanks for the clarification. (However, I'm having trouble finding section >3.2.5 in my copy of the architecture doc (draft-ietf-ipsec-arch-sec-05)). But >I believe that the statement in Appendix B, section B.2, "Fragmentation MUST >be done after outbound IPsec processing." is incorrect. In fact, for a tunnel >mode SA on a host, fragmentation must be done before IPsec processing to make >PMTU discovery work, correct? The section I cited is from the most recent version of the spec, arch-sec-06, distributed to the list last week (7/2). However, B.2 still makes the same statement in this version! I could point out that the appendices are not normative, but I guess it would be better to just fix it :-). Steve From owner-ipsec Thu Jul 9 13:21:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23151 for ipsec-outgoing; Thu, 9 Jul 1998 13:19:10 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF2322C2@exchange.timestep.com> From: Roy Pereira To: "Scott G. Kelly" , ipsec@tis.com Subject: RE: simultaneous lifetime type support required? Date: Thu, 9 Jul 1998 13:33:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BDAB5F.B8C15150" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BDAB5F.B8C15150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes.=A0 Both expiry types should be supported at the same time.=A0 = Expiry would happen when either of the expiry values et triggered.=20 =A0 -----Original Message----- From: Scott G. Kelly [mailto:skelly@redcreek.com] Sent: Tuesday, July 07, 1998 5:34 PM To: Roy Pereira; ipsec@tis.com Subject: Re: simultaneous lifetime type support required? Roy Pereira wrote:=20 =A0=20 You should be able to support both expiry types for both phase 1 and phase 2 SAs.=20 Multiple occurrences of each expiry type is forbidden though.=20 I recognize the need to support both types, but the question is, am I required to support both types simultaneously? That is, if you send me = 2 lifetime payloads together, one in kbytes and one in seconds, does this mean you want both values used, with the actual expiration based upon whichever occurs first?=20 =A0=20 ------ =_NextPart_001_01BDAB5F.B8C15150 Content-Type: text/html; charset="iso-8859-1"
Yes.  Both expiry types should be supported at the same time.  Expiry would happen when either of the expiry values et triggered.
 
-----Original Message-----
From: Scott G. Kelly [mailto:skelly@redcreek.com]
Sent: Tuesday, July 07, 1998 5:34 PM
To: Roy Pereira; ipsec@tis.com
Subject: Re: simultaneous lifetime type support required?

Roy Pereira wrote:

 

You should be able to support both expiry types for both phase 1 and phase 2 SAs.

Multiple occurrences of each expiry type is forbidden though.

I recognize the need to support both types, but the question is, am I required to support both types simultaneously? That is, if you send me 2 lifetime payloads together, one in kbytes and one in seconds, does this mean you want both values used, with the actual expiration based upon whichever occurs first?
 
------ =_NextPart_001_01BDAB5F.B8C15150-- From owner-ipsec Thu Jul 9 13:29:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23255 for ipsec-outgoing; Thu, 9 Jul 1998 13:29:18 -0400 (EDT) Message-ID: <35A501E9.77B96C7C@redcreek.com> Date: Thu, 09 Jul 1998 10:46:17 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Roy Pereira CC: ipsec@tis.com Subject: Re: simultaneous lifetime type support required? References: <319A1C5F94C8D11192DE00805FBBADDF2322C2@exchange.timestep.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Roy Pereira wrote: > > Yes. Both expiry types should be supported at the same time. Expiry > would happen when either of the expiry values et triggered. > > Scott wrote: > I recognize the need to support both types, but the question > is, am I required to support both types simultaneously? That > is, if you send me 2 lifetime payloads together, one in > kbytes and one in seconds, does this mean you want both > values used, with the actual expiration based upon whichever > occurs first? The question has not been answered satisfactorily by any of the responses to date. Let me rephrase: where in the document set does it state that a system MUST/should/may support simultaneous specification of seconds/kbytes for SA lifetimes, terminating the SA depending upon which limit is reached first? I see a reference to multiple lifetimes in DOI (section 4.5.2), but this is just parsing info, and does not contain any language indicating the implementation status (must/may/should). I see no other references. From owner-ipsec Thu Jul 9 13:37:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23314 for ipsec-outgoing; Thu, 9 Jul 1998 13:37:14 -0400 (EDT) Message-Id: <199807091750.NAA15381@adk.gr> To: "Scott G. Kelly" Cc: Roy Pereira , ipsec@tis.com Subject: Re: simultaneous lifetime type support required? In-reply-to: Your message of "Thu, 09 Jul 1998 10:46:17 PDT." <35A501E9.77B96C7C@redcreek.com> Date: Thu, 09 Jul 1998 13:50:12 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- To: "Scott G. Kelly" Subject: Re: simultaneous lifetime type support required? Cc: Roy Pereira , ipsec@tis.com Date: 07/09/98, 13:50:08 In message <35A501E9.77B96C7C@redcreek.com>, "Scott G. Kelly" writes: > >The question has not been answered satisfactorily by any of the >responses to date. Let me rephrase: where in the document set does it >state that a system MUST/should/may support simultaneous specification >of seconds/kbytes for SA lifetimes, terminating the SA depending upon >which limit is reached first? I see a reference to multiple lifetimes in >DOI (section 4.5.2), but this is just parsing info, and does not contain >any language indicating the implementation status (must/may/should). I >see no other references. This is implied by the fact both lifetimes appeared in the same proposal. Otherwise, one could ask "am I supposed to support 3DES encryption and MD5 MAC simultaneously ?" which is what your question sounds like. As the draft mentions (somewhere), the proposal is accepted as a block. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNaUC0r0pBjh2h1kFAQHSEAP/S/1ORB7NMjH2fxtFsQ7N9oPajMMNI3sX GAgPzwkNTOCwzU03IT0YhbikdDCnjMeEJ4pfeLGI0CR1YtthsQRUxTYhcPcMIZA3 frqswkScXLnulWfTbeXR3KVTqsRAhAwT31YqsIpzuQi5PibPvlAxiIK8glFGHL4q /iLx1fG9jqY= =uNRj -----END PGP SIGNATURE----- From owner-ipsec Thu Jul 9 14:06:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23453 for ipsec-outgoing; Thu, 9 Jul 1998 14:06:13 -0400 (EDT) Message-Id: <199807091822.OAA09997@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: simultaneous lifetime type support required? In-reply-to: Your message of "Thu, 09 Jul 1998 10:46:17 PDT." <35A501E9.77B96C7C@redcreek.com> Date: Thu, 09 Jul 1998 14:22:21 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Scott" == Scott G Kelly writes: Scott> responses to date. Let me rephrase: where in the document set does it Scott> state that a system MUST/should/may support simultaneous specification Scott> of seconds/kbytes for SA lifetimes, terminating the SA depending upon I understand what you are asking now. Sorry. "lifetime" occurs on page 23 of the architecture document. (arch-sec-06.txt) "lifetime" occurs on page 5 of RFC1825. section 4.2 of ciph-des-expiv-02.txt discussed lifetimes in general. The doi and isakmp use the word "lifetime" several times, but don't say anything about what is supported. Therefore, I agree with you. It doesn't say that you must support simultaneous limits. Perhaps Ran or Paul can let us know if there were specific thoughts about this in the first round of RFCs. :!mcr!: | "Elegant and extremely rapid for calculation are the Michael Richardson | techniques of Young tableaux. They also have the merit | of being fun to play with." - p.47 Intro to Quarks&Partons Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Thu Jul 9 14:08:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23477 for ipsec-outgoing; Thu, 9 Jul 1998 14:08:16 -0400 (EDT) Message-Id: <199807091823.OAA10005@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: simultaneous lifetime type support required? In-reply-to: Your message of "Thu, 09 Jul 1998 13:50:12 EDT." <199807091750.NAA15381@adk.gr> Date: Thu, 09 Jul 1998 14:23:46 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Angelos" == Angelos D Keromytis writes: Angelos> In message <35A501E9.77B96C7C@redcreek.com>, "Scott G. Kelly" writes: >> >> The question has not been answered satisfactorily by any of the >> responses to date. Let me rephrase: where in the document set does it >> state that a system MUST/should/may support simultaneous specification >> of seconds/kbytes for SA lifetimes, terminating the SA depending upon >> which limit is reached first? I see a reference to multiple lifetimes in >> DOI (section 4.5.2), but this is just parsing info, and does not contain >> any language indicating the implementation status (must/may/should). I >> see no other references. Angelos> This is implied by the fact both lifetimes appeared in the same Angelos> proposal. Otherwise, one could ask "am I supposed to support 3DES Angelos> encryption and MD5 MAC simultaneously ?" which is what your question Angelos> sounds like. As the draft mentions (somewhere), the proposal is Angelos> accepted as a block. The question is, MUST a compliant implementation accept such a proposal? :!mcr!: | "Elegant and extremely rapid for calculation are the Michael Richardson | techniques of Young tableaux. They also have the merit | of being fun to play with." - p.47 Intro to Quarks&Partons Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Thu Jul 9 14:42:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23645 for ipsec-outgoing; Thu, 9 Jul 1998 14:41:17 -0400 (EDT) Message-ID: <35A51286.88C633B1@redcreek.com> Date: Thu, 09 Jul 1998 11:57:10 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "Angelos D. Keromytis" CC: ipsec@tis.com Subject: Re: simultaneous lifetime type support required? References: <199807091750.NAA15381@adk.gr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos D. Keromytis wrote: > This is implied by the fact both lifetimes appeared in the same > proposal. Otherwise, one could ask "am I supposed to support 3DES > encryption and MD5 MAC simultaneously ?" which is what your question > sounds like. As the draft mentions (somewhere), the proposal is > accepted as a block. > - -Angelos Not trying to be difficult here, just looking for a clarification. Someone asked me if we're *required* to implement this and I said yes, recalling prior discussion on this list. That person said the documents don't support my assertion, and a quick re-read confirms that other than the reference in DOI, this appears to be true. I'm asking if people here agree that the documents don't explicitly require this, and what I hear is that everyone thinks this is a requirement, but nobody can say where the language is. In general, when something is *required*, documents say 'MUST'. For the sake of argument, I concede that the requirement is at least implied by the reference in DOI, and that if one wishes to interoperate with others, it is appropriate to support it. But DOI only refers to phase 2, so what about phase 1? Is there language anywhere defining this? If not, and if we want apply this same interoperability caveat to phase 1, shouldn't there be language to that affect in either ISAKMP or ARCH? From owner-ipsec Thu Jul 9 14:54:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23724 for ipsec-outgoing; Thu, 9 Jul 1998 14:54:18 -0400 (EDT) Message-Id: <199807091910.MAA24384@gallium.network-alchemy.com> To: "Scott G. Kelly" cc: Roy Pereira , ipsec@tis.com Subject: Re: simultaneous lifetime type support required? In-reply-to: Your message of "Thu, 09 Jul 1998 10:46:17 PDT." <35A501E9.77B96C7C@redcreek.com> Date: Thu, 09 Jul 1998 12:10:33 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott, The text in Section 4.5.2 of the DOI was meant to require simultaneous support for both types of lifetime, but I see how one could interpret that as just a parsing requirement, given the title of that section. However, it has always been the intent to require implementations to support both simultaneously for the obvious reason that negotiated key lifetimes is one of the more important attributes of any key management protocol. I'll make this more explicit in the next version of the document. Derrell From owner-ipsec Thu Jul 9 15:00:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA23740 for ipsec-outgoing; Thu, 9 Jul 1998 15:00:19 -0400 (EDT) Message-Id: <199807091916.PAA10061@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: simultaneous lifetime type support required? In-reply-to: Your message of "Thu, 09 Jul 1998 11:57:10 PDT." <35A51286.88C633B1@redcreek.com> Date: Thu, 09 Jul 1998 15:16:07 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Scott" == Scott G Kelly writes: Scott> others, it is appropriate to support it. But DOI only refers to phase 2, Scott> so what about phase 1? Is there language anywhere defining this? Frankly, I don't think that the ISAKMP SA will pass enough bytes to ever justify expiring it by byte count. Time will always be the critical factor for expiring keys for ISAKMP. [If I'm wrong, and that the ISAKMP will pass megabytes of data in under a hour or two, then there is probably something very wrong..] Scott> and if we want apply this same interoperability caveat to phase 1, Scott> shouldn't there be language to that affect in either ISAKMP or ARCH? page 23 or arch-sec-06.txt: o Lifetime of this Security Association: a time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should | occur. This may be expressed as a time or byte count, or a | combination of both, the first lifetime to expire taking | precedence. A compliant implementation MUST support both | types of lifetimes, and must support their combination. If time is employed, and if IKE employs X.509 certificates for SA establishment, the SA lifetime must be constrained by the validity intervals of the certificates, and the NextIssueDate of the CRLs used in the IKE exchange for the SA. Both initiator and responder are responsible for constraining SA lifetime in this fashion. (I'm almost sure that there is a better term than "combination". Something more precise that expresses the fact that this is an inclusive or, but I can't think of the right word while taking a break from hex dumps) :!mcr!: | "Elegant and extremely rapid for calculation are the Michael Richardson | techniques of Young tableaux. They also have the merit | of being fun to play with." - p.47 Intro to Quarks&Partons Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Thu Jul 9 15:05:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA23773 for ipsec-outgoing; Thu, 9 Jul 1998 15:05:19 -0400 (EDT) Date: Thu, 9 Jul 1998 15:21:20 -0400 Message-Id: <199807091921.PAA20219@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: skelly@redcreek.com Cc: ipsec@tis.com Subject: Re: simultaneous lifetime type support required? References: <319A1C5F94C8D11192DE00805FBBADDF2322C2@exchange.timestep.com> <35A501E9.77B96C7C@redcreek.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Scott" == Scott G Kelly writes: >> Roy Pereira wrote: >> >> Yes. Both expiry types should be supported at the same time. >> Expiry would happen when either of the expiry values et triggered. >> >> Scott wrote: I recognize the need to support both types, but the >> question is, am I required to support both types simultaneously? >> That is, if you send me 2 lifetime payloads together, one in >> kbytes and one in seconds, does this mean you want both values >> used, with the actual expiration based upon whichever occurs >> first? Scott> The question has not been answered satisfactorily by any of Scott> the responses to date. Let me rephrase: where in the document Scott> set does it state that a system MUST/should/may support Scott> simultaneous specification of seconds/kbytes for SA lifetimes, Scott> terminating the SA depending upon which limit is reached Scott> first? I see a reference to multiple lifetimes in DOI (section Scott> 4.5.2), but this is just parsing info, and does not contain Scott> any language indicating the implementation status Scott> (must/may/should). I see no other references. Ipsec-arch discusses lifetime but doesn't explicitly discuss the case of both limits being active at the same time either. Then again, I must admit being somewhat puzzled why this is such an issue. If you implement each feature, it's hard to see how it could cost you ANYTHING to have them both active for the same SA. paul From owner-ipsec Thu Jul 9 15:35:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA23852 for ipsec-outgoing; Thu, 9 Jul 1998 15:33:26 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5040300017945831000002L012*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Jul 1998 15:45:05 -0400 To: Karen Heron From: Stephen Kent Subject: Re: IPsec and Fragmentation Cc: Sender: owner-ipsec@ex.tis.com Precedence: bulk Karen, I went back and checked the IPsec arch-doc and I must clearly have been on drugs at the time! The text in question really appears in AH and in ESP, in 3.3.4 and 3.3.5, respectively. In any case, we'll update the appendix in the arch-doc to be consistent with the text in AH and ESP. Steve From owner-ipsec Thu Jul 9 15:59:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA24002 for ipsec-outgoing; Thu, 9 Jul 1998 15:57:36 -0400 (EDT) Message-ID: <35A52464.CB562BF5@redcreek.com> Date: Thu, 09 Jul 1998 13:13:24 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@tis.com Subject: Re: simultaneous lifetime type support required? References: <199807091916.PAA10061@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael C. Richardson wrote: > > >>>>> "Scott" == Scott G Kelly writes: > Scott> others, it is appropriate to support it. But DOI only refers to phase 2, > Scott> so what about phase 1? Is there language anywhere defining this? > > Frankly, I don't think that the ISAKMP SA will pass enough bytes to > ever justify expiring it by byte count. Time will always be the critical > factor for expiring keys for ISAKMP. > [If I'm wrong, and that the ISAKMP will pass megabytes of data in > under a hour or two, then there is probably something very wrong..] Agreed. > page 23 or arch-sec-06.txt: > > o Lifetime of this Security Association: a time interval after > which an SA must be replaced with a new SA (and new SPI) or > terminated, plus an indication of which of these actions should > | occur. This may be expressed as a time or byte count, or a > | combination of both, the first lifetime to expire taking > | precedence. A compliant implementation MUST support both > | types of lifetimes, and must support their combination. Excellent - this is what I was looking for. Thanks! From owner-ipsec Thu Jul 9 16:20:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24108 for ipsec-outgoing; Thu, 9 Jul 1998 16:20:35 -0400 (EDT) Message-Id: <199807092036.QAA10137@istari.sandelman.ottawa.on.ca> To: "Scott G. Kelly" cc: ipsec@tis.com Subject: Re: simultaneous lifetime type support required? In-reply-to: Your message of "Thu, 09 Jul 1998 13:13:24 PDT." <35A52464.CB562BF5@redcreek.com> Date: Thu, 09 Jul 1998 16:36:13 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Scott" == Scott G Kelly writes: >> page 23 or arch-sec-06.txt: >> >> o Lifetime of this Security Association: a time interval after >> which an SA must be replaced with a new SA (and new SPI) or >> terminated, plus an indication of which of these actions should >> | occur. This may be expressed as a time or byte count, or a >> | combination of both, the first lifetime to expire taking >> | precedence. A compliant implementation MUST support both >> | types of lifetimes, and must support their combination. Scott> Excellent - this is what I was looking for. Thanks! Wait, that was my *PROPOSED TEXT*!!! Thus the change bars. :!mcr!: | "Elegant and extremely rapid for calculation are the Michael Richardson | techniques of Young tableaux. They also have the merit | of being fun to play with." - p.47 Intro to Quarks&Partons Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. From owner-ipsec Thu Jul 9 16:26:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24139 for ipsec-outgoing; Thu, 9 Jul 1998 16:26:35 -0400 (EDT) Message-ID: <35A52B1B.23AAF8B7@redcreek.com> Date: Thu, 09 Jul 1998 13:42:03 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@tis.com Subject: Re: simultaneous lifetime type support required? References: <199807092036.QAA10137@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael C. Richardson wrote: > > Scott> Excellent - this is what I was looking for. Thanks! > > Wait, that was my *PROPOSED TEXT*!!! Thus the change bars. Er, right. I got your earlier messages out of order, and was just looking at the ARCH doc when I got this one, scratching my head. I think a number of valid points have been made, and that this should certainly be supported. Upon reflection, I'm a little shy about saying that more MUST language should be added to the docs, but this really is a matter of security: permitting either too much time or too much ciphertext to a determined attacker is a bad thing (tm), so maybe it should be made explicit. From owner-ipsec Fri Jul 10 10:25:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27037 for ipsec-outgoing; Fri, 10 Jul 1998 10:21:48 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01B142BE@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Subject: Transport Mode Q Date: Fri, 10 Jul 1998 15:37:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Just had a scan of the likely documents for the definition on what to deal with the outer header for Transport Mode - I suppose this is obvious, but is it documented in the ipsec drafts? I'm assuming, as a BITW sort of thing, I need to move the IP protocol field into one of the extra headers I apply, and adjust the packet length: [IP][Upper] [IP][AH][ESP][IPCOMP][Upper] In this example, IPCOMP next-head needs to copy the value from [IP], and [IP] needs it's next prot set to AH, and so on. Once compression/encryption is complete, I write the final length into [IP] and then Authenticate. Am I close? Steve. From owner-ipsec Fri Jul 10 17:46:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA28507 for ipsec-outgoing; Fri, 10 Jul 1998 17:40:49 -0400 (EDT) Message-Id: X-Sender: ellesson@rtp-pop3.raleigh.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 26 Jun 1998 16:47:33 -0400 To: Scott Bradner , Vern Paxson From: Ed Ellesson Subject: Request for Policy BOF Cc: agenda@ietf.org, policy@raleigh.ibm.com, rap@iphighway.com, rsvp@isi.edu, diff-serv@BayNetworks.COM, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk [Note: Please excuse multiple notes if you are on more than one of these lists. See bottom of this note for a mailing list specifically for discussion of policy frameworks.] Scott and Vern, Please consider this to be a formal request for a BOF at the August IETF on the topic of "Policy Framework". (This request was compiled from the results of an informal policy meeting in Cambridge, June 12, 1998, which took place immediately following the diffserv interim meeting, held there June 11-12. In fairness to those participants, I am copying the diffserv mailing list, and I therefore felt it to be only fair to copy other working group mailing lists who may have an interest....please see policy mailing list at end of this note for discussion on this BOF request.) Number of Attendees (to informal pre-BOF policy meeting): 41 (Signup list available on request) At this stage, the agenda is preliminary, and not all presenters have confirmed. I have also left room for other presenters. Should the BOF be approved, and others want time on the agenda, please contact me at: ellesson@raleigh.ibm.com BOF Description ---------------- Objectives of BOF: 1. To consider the creation of a new IETF working group called "Policy Framework". The proposed scope for this working group includes a common, interoperable, and scalable framework and namespace for administering QOS and VPN security policy in a single network domain which uses some or all of the following protocols: LDAP, SNMP, COPS, RADIUS, RSVP, Intserv, Diffserv, ISSLL, DSSLL, IPSEC 2. To develop a charter for this new working group 3. To discuss the proposed architectural framework and functional description of the architectural elements, for policy administration and distribution, documented in draft-ellesson-sla-schema-02.txt (see diffserv archive) 4. To discuss the functional requirements of a schema or schemas which could act as a central repository for policy rules for administering QOS and security policy in a single network domain. (QOS includes rsvp, intserv, diffserv, issll and dssll. Security includes vpn and ipsec.) (The reason that both QOS and VPN security are considered here, is that it may be more efficient to include them both in the same schema, from an implementation and management perspective.) 5. To discuss whether a specific schema should be a deliverable of the working group. Preliminary BOF Agenda (2 1/2 hours) ------------------------------------- -Review of BOF agenda and objectives: (Ed Ellesson) - 10 minutes -Proposed Architectural Framework (Ed Ellesson) - 15 minutes -Proposed positioning of this framework and namespace relative to other IETF and non-IETF work: * LDAP, DEN and DMTF: (TBD: John Strassner?) - 15 minutes * RSVP, Intserv, and RAP: (Raj Yavatkar) - 15 minutes * Diffserv: (TBD: Jean Christophe Martin or Raju Rajan?) - 15 minutes * VPN/IPSEC: (TBD: Charlie Kunzinger?) - 15 minutes * DHCP/RADIUS/Routing Policy (TBD: Rajiv Chaudhuri?) - 15 minutes * other proposals - 20 minutes -Proposed Charter Discussion (Ed Ellesson) - 30 minutes * Scope/track * Framework definition * Schema * Workgroup documents and Timeframe *************** Please direct discussion related to this proposed BOF to the following mailing list: policy@raleigh.ibm.com To subscribe: send a note to policy-request@raleigh.ibm.com, with subscribe on the first line of the note. Archives at: http://www.raleigh.ibm.com/m aillists/policy] ****************** Regards, Regards, Ed Ellesson Sr. Engineer, TCP/IP Technology Management IBM Networking Software Products Research Triangle Park, NC ellesson@raleigh.ibm.com 919-254-4115 From owner-ipsec Fri Jul 10 18:13:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA28703 for ipsec-outgoing; Fri, 10 Jul 1998 18:12:51 -0400 (EDT) Date: Mon, 6 Jul 1998 14:48:13 -0400 (EDT) Message-Id: <199807061848.OAA14386@pong.morningstar.com> From: leonard_samuelson@ascend.com (Len Samuelson) To: Karen Heron , ipsec@tis.com Subject: Re: IPsec and Fragmentation In-Reply-To: <5040300017915625000002L052*@MHS> References: <5040300017915625000002L052*@MHS> Reply-To: leonard_samuelson@ascend.com (Len Samuelson) Sender: owner-ipsec@ex.tis.com Precedence: bulk Karen Heron writes: > > Path MTU discovery is a required feature of any compliant IPsec > > implementation. While PMTU discovery doesn't "fix the problem", it > > permits originating hosts (be they secured or not) to deflate their MTUs > > according to the actually observed MTU in the pathway. > > > We calculate an MTU by subtracting IPsec header/trailer expansion octets > > from the known MTU of the path. (It was a "bug" in our implementation > > until I was charged with implementing PMTU discovery in our IPsec...) > > > In your example, the failure in step 6 should cause backpropagation > > (sorry!), by ICMP CANT_FRAG packets, of the MTU to the originator of the > > excessively-large packet. A good question to ask at this point is > > how ICMP CANT_FRAG packets are needed to propagate the real path MTU to > > the originating host. > > The problem with SG1 returning a Packet Too Big message with MTU=1500 to H1 > is that H1 already sees the Path MTU as 1280 (which is the MTU for the > tunnel). H1 won't increase its PMTU in response to receiving a Packet Too > Big message, but even if H1 did, it would then not be able to send the > packets through the tunnel. A good point, sorry I didn't catch it before. I think there's an ambiguity in the situation that is not addressed in either standard IP PMTU discovery or the IPsec variant: I (perhaps alone) interpret the behavior of H1 as being two distinct objects. I see the existence of a packet originator within H1, constructing and "sending" plaintext packets. I see H1's IPsec subsystem as being almost a logically separate colocated security gateway. Using such a model, the secured inner packet generator needs to be informed of the final MTU (in your example, the 1500-byte MTU between SG1 and H2). I think your example points out that ambiguity. Note that the only I can think of solving it would be to perform some sort of addressing hack to distinguish the "internal elements" of H1. -- Leonard Samuelson, Ascend Communications, Inc. 614-760-4024 From owner-ipsec Sat Jul 11 11:20:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00130 for ipsec-outgoing; Sat, 11 Jul 1998 11:15:58 -0400 (EDT) Date: Sat, 11 Jul 1998 18:32:08 +0300 (EET DST) Message-Id: <199807111532.SAA23782@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Michael C. Richardson" Cc: ipsec@tis.com Subject: Re: simultaneous lifetime type support required? In-Reply-To: <199807091916.PAA10061@istari.sandelman.ottawa.on.ca> References: <35A51286.88C633B1@redcreek.com> <199807091916.PAA10061@istari.sandelman.ottawa.on.ca> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 11 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael C. Richardson writes: > >>>>> "Scott" == Scott G Kelly writes: > Scott> others, it is appropriate to support it. But DOI only refers to phase 2, > Scott> so what about phase 1? Is there language anywhere defining this? > Frankly, I don't think that the ISAKMP SA will pass enough bytes to > ever justify expiring it by byte count. Time will always be the critical > factor for expiring keys for ISAKMP. > [If I'm wrong, and that the ISAKMP will pass megabytes of data in > under a hour or two, then there is probably something very wrong..] I agree, that you propably don't transfer that much data that it would make it easier to break the encryption of phase 1 sa, but you can also use the kilobyte lifetime to limit how many phase 2 negotiations can be negotiated using that phase 1 sa. If you are using pre shared keys and normal ip identities and simple proposal then one phase 2 negotiation will take about 250 bytes in each directions if you use PFS, and 150 bytes if you don't use pfs, so if you set the kilobyte limit to 10 kilobytes that means about 40 phase 2 negotiations using PFS or 70 phase 2 negotiations without PFS, inside that phase 1 negotiation. I would also like to have phase 1 lifetime that could be used to limit number of negotiations done under that phase 1 sa (now the draft says it is local policy issue, but I would also like to tell/negotiate that to the the remote end also). But it already too late for that, but perhaps in the ipsecond. -- 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 Sun Jul 12 12:11:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA03026 for ipsec-outgoing; Sun, 12 Jul 1998 12:07:12 -0400 (EDT) Message-Id: <199807121622.MAA29901@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: simultaneous lifetime type support required? In-reply-to: Your message of "Sat, 11 Jul 1998 18:32:08 +0300." <199807111532.SAA23782@torni.ssh.fi> Date: Sun, 12 Jul 1998 12:22:54 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Tero" == Tero Kivinen writes: Tero> I agree, that you propably don't transfer that much data that it would Tero> make it easier to break the encryption of phase 1 sa, but you can also Tero> use the kilobyte lifetime to limit how many phase 2 negotiations can Tero> be negotiated using that phase 1 sa. Yes, that is a good point. It would be approximate, but that would still be useful. :!mcr!: | Network and security consulting/contract programming Michael Richardson | I do IPsec policy code for SSH Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Sun Jul 12 13:20:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA03134 for ipsec-outgoing; Sun, 12 Jul 1998 13:20:17 -0400 (EDT) Message-Id: <4.0.1.19980712131758.00f092d0@enterprise.unitran.com> X-Sender: rodney@enterprise.unitran.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Sun, 12 Jul 1998 13:18:11 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: test, please ignore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk From owner-ipsec Sun Jul 12 20:07:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA03692 for ipsec-outgoing; Sun, 12 Jul 1998 20:03:12 -0400 (EDT) Message-Id: <199807130019.UAA00805@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: searchable IPsec mailing list archive Date: Sun, 12 Jul 1998 20:19:20 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- For some months I've been grabbing the list archives from ftp.tis.com and putting them through MHonArc (an mbox->html converter that does pretty things with threads). I have just added the archive to a glimpse index so it can be searched. The archive is at http://www.sandelman.ottawa.on.ca/ipsec/ Please be gentle, this is only on a 64kps ISDN. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNalSfNiXVu0RiA21AQGhOgL/fSKTb5SB1M2sy3OBjDqRx9+INjiuGT/4 XaN1fKU9ese9iPrXDbropk3ASpcuoVqt1v5+Du8jpOvjQKEgzJfv7o2y7JiF9VtT QLDEEoSWOWS/OeB5SLoIB5Y296kpcERY =iJIL -----END PGP SIGNATURE----- From owner-ipsec Mon Jul 13 06:57:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA05156 for ipsec-outgoing; Mon, 13 Jul 1998 06:54:12 -0400 (EDT) Message-Id: <199807131109.HAA24418@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-10.txt,.ps Date: Mon, 13 Jul 1998 07:09:54 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, M. Schertler, M. Schneider, J. Turner Filename : draft-ietf-ipsec-isakmp-10.txt,.ps Pages : 86 Date : 10-Jul-98 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and crypto-graphic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment. Internet-Drafts are 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-10.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-10.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-10.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: <19980710104431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980710104431.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Jul 13 11:27:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06069 for ipsec-outgoing; Mon, 13 Jul 1998 11:23:16 -0400 (EDT) Date: Mon, 13 Jul 1998 00:45:52 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199807130445.AAA29703@earth.hpc.org> To: ipsec@tis.com Subject: New entry in privacy/wiretap debate Sender: owner-ipsec@ex.tis.com Precedence: bulk I read a newspaper article today that said Cisco, Sun, Network Associates, and others had a proposed agreement that would allow those with warrants to catch plaintext email from network devices at the edge devices. The implication was that email encryption would be entrusted to edge entities, not to users. The article implied that the diversion of data would be done based on IP headers. Is this idea based in any way on IPSEC or planned IPSEC products? It sounded as though it might be IPSEC with key recovery. Hilarie From owner-ipsec Mon Jul 13 11:54:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06175 for ipsec-outgoing; Mon, 13 Jul 1998 11:54:16 -0400 (EDT) Message-Id: <3.0.32.19980713110739.009589a0@localhost> X-Sender: clonvick@localhost X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 13 Jul 1998 11:07:47 -0500 To: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com From: "Chris M. Lonvick" Subject: Re: New entry in privacy/wiretap debate Cc: ekaufman@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello Hilarie, There is no key recovery in the "operator action" model. Basically, we and others are arguing that most (probably all) IPsec devices already provide a customer with the ability to comply with a legal warrant without any modification at all. Responding to a lawful warrant is, for many classes of product, a management issue not a cryptographic one. Please see the following white paper for an explanation of our approach. Contact Elizabeth Kaufman (mailto:ekaufman@cisco.com) if you have any questions. There is no key recovery here! http://www.cisco.com/warp/public/146/july98/2.html - Elizabeth (using Chris Lonvick's PC in a meeting....) At 12:45 AM 7/13/98 -0400, Hilarie Orman wrote: >I read a newspaper article today that said Cisco, Sun, Network >Associates, and others had a proposed agreement that would allow those >with warrants to catch plaintext email from network devices at the >edge devices. The implication was that email encryption would be >entrusted to edge entities, not to users. The article implied that >the diversion of data would be done based on IP headers. Is this >idea based in any way on IPSEC or planned IPSEC products? It sounded >as though it might be IPSEC with key recovery. > >Hilarie > > > > From owner-ipsec Mon Jul 13 12:07:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06255 for ipsec-outgoing; Mon, 13 Jul 1998 12:06:17 -0400 (EDT) Date: Mon, 13 Jul 1998 09:21:47 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: New entry in privacy/wiretap debate To: Hilarie Orman Cc: ipsec@tis.com In-Reply-To: "Your message with ID" <199807130445.AAA29703@earth.hpc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk See http://www.washingtonpost.com/wp-srv/WPlate/1998-07/12/194l-071298-idx.html for more information about the story. PatC > I read a newspaper article today that said Cisco, Sun, Network > Associates, and others had a proposed agreement that would allow those > with warrants to catch plaintext email from network devices at the > edge devices. The implication was that email encryption would be > entrusted to edge entities, not to users. The article implied that > the diversion of data would be done based on IP headers. Is this > idea based in any way on IPSEC or planned IPSEC products? It sounded > as though it might be IPSEC with key recovery. > > Hilarie > > From owner-ipsec Mon Jul 13 12:19:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06295 for ipsec-outgoing; Mon, 13 Jul 1998 12:16:16 -0400 (EDT) Message-ID: <70C20C1647EBD11183F800805FA67B43151CB2@vpnet.com> From: Sumit Vakil To: ipsec@tis.com Subject: ISAKMP Draft 10 Date: Mon, 13 Jul 1998 09:30:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk The General Message Processing section of draft 10 (section 5.1) has the following regarding how an implementation is supposed to set the retransmission timer: NOTE: Implementations MUST NOT use a fixed timer. Instead, transmission timer values should be adjusted dynamically based on measured round trip times. In addition, successive retransmissions of the same packet should be separated by increasingly longer time intervals (e.g., exponential backoff). How and why has this been added to the draft? I don't recollect it being discussed on the mailing list. This is an implementation detail. The draft should only suggest a scheme, not make one a requirement. Thanks, Sumit A. Vakil VPNet Technologies, Inc. From owner-ipsec Mon Jul 13 12:30:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA06331 for ipsec-outgoing; Mon, 13 Jul 1998 12:28:17 -0400 (EDT) Message-Id: <199807131644.MAA01974@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-dhless-enc-mode-00.txt Date: Mon, 13 Jul 1998 12:44:23 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart It was reported that this announcement never made it to the IPSEC list. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A DH-less encryption mode for IKE Author(s) : R. Canetti, P. Cheng, H. Krawczyk Filename : draft-ietf-ipsec-dhless-enc-mode-00.txt Pages : 5 Date : 06-Jul-98 This draft describes a ``DH-less'' version of the (revised) public-key encryption mode of [HC98]. This saves the DH exponentiation, which may be significant (especially on low-end machines and busy servers). The proposed mode is VERY similar to the existing modes and requires only minimal modifications. In particular, it is straightforward to implement as an addition to the existing modes. Internet-Drafts are 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-dhless-enc-mode-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-dhless-enc-mode-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dhless-enc-mode-00.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: <19980713123226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhless-enc-mode-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhless-enc-mode-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980713123226.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Jul 13 13:26:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA06510 for ipsec-outgoing; Mon, 13 Jul 1998 13:25:20 -0400 (EDT) Date: Mon, 13 Jul 98 17:11:59 GMT From: "William Allen Simpson" Message-ID: <7380.bsimpson@morningstar.com> To: iesg@ietf.org CC: ipsec@tis.com Subject: Re: Revised drafts -- Arch, AH, ESP Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't read IPSec often anymore, but in working on my own found a new error just introduced in the latest drafts: > From: Karen Seo > In follow-up to Thomas Narten's (IESG) feedback (see Ted Ts'o's email of > 3. Section 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode -- added > note to clarify decrementing of TTL. > > After the following paragraph: > 2. The TTL in the inner header is decremented by the > encapsulator prior to forwarding and by the decapsulator if > it forwards the packet. (The checksum changes when the TTL > changes.) > > we added: > Note: The decrementing of the TTL is one of the usual actions > that takes place when forwarding a packet. Packets > originating from the same node as the encapsulator do not > have their TTL's decremented, as the sending node is > originating the packet rather than forwarding it. > The note is in error. The TTL is required to be decremented when encapsulating into a tunnel in exactly the same way as when forwarding into any other interface, even when the sending node originated the packet, in order to prevent loops where the packet is decapsulated and encapsulated and forwarded again. On many systems, there is no distinction -- a tunnel is an interface. An originating node that makes the mistake described in the note could be involved in such a loop. This is a fundamental principle, and already proscribed in the various tunnelling RFCs. Since I don't want the publication of these documents to be delayed in any way (see my response to the Last Call April 11), and it is already July, and there are already many known failure modes inherent in these documents, you could just leave the error. I just thought I ought to tell you, since this error affects the work of so many other IETF WGs. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ipsec Mon Jul 13 15:43:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA07346 for ipsec-outgoing; Mon, 13 Jul 1998 15:41:23 -0400 (EDT) Message-Id: <199807131957.PAA03670@penelope.ve3tla.ampr.org> To: "Chris M. Lonvick" cc: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com, ekaufman@cisco.com Subject: Re: New entry in privacy/wiretap debate References: <3.0.32.19980713110739.009589a0@localhost> In-reply-to: clonvick's message of "Mon, 13 Jul 1998 12:07:47 -0400". <3.0.32.19980713110739.009589a0@localhost> From: "C. Harald Koch" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3663.900359831.1@penelope.ve3tla.ampr.org> Date: Mon, 13 Jul 1998 15:57:12 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <3.0.32.19980713110739.009589a0@localhost>, "Chris M. Lonvick" writes: > Hello Hilarie, > > There is no key recovery in the "operator action" model. Basically, we and > others are arguing that most (probably all) IPsec devices already provide a > customer with the ability to comply with a legal warrant without any > modification at all. Responding to a lawful warrant is, for many classes of > product, a management issue not a cryptographic one. Specifically, plaintext recovery at *one* end of the connection is all that is required (last time I tried :-) for some exports of strong cryptography. -- Harald Koch From owner-ipsec Mon Jul 13 21:40:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA08903 for ipsec-outgoing; Mon, 13 Jul 1998 21:38:29 -0400 (EDT) Message-Id: <199807140120.VAA04185@penelope.ve3tla.ampr.org> To: "William Allen Simpson" cc: iesg@ietf.org, ipsec@tis.com Subject: Re: Revised drafts -- Arch, AH, ESP References: <7380.bsimpson@morningstar.com> In-reply-to: bsimpson's message of "Mon, 13 Jul 1998 13:11:59 -0400". <7380.bsimpson@morningstar.com> From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4177.900379213.1@penelope.ve3tla.ampr.org> Date: Mon, 13 Jul 1998 21:20:14 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <7380.bsimpson@morningstar.com>, "William Allen Simpson" writes: > > Note: The decrementing of the TTL is one of the usual actions > > that takes place when forwarding a packet. Packets > > originating from the same node as the encapsulator do not > > have their TTL's decremented, as the sending node is > > originating the packet rather than forwarding it. > > > The note is in error. The TTL is required to be decremented when > encapsulating into a tunnel in exactly the same way as when forwarding > into any other interface, even when the sending node originated the > packet, in order to prevent loops where the packet is decapsulated and > encapsulated and forwarded again. The note is correct. TTL decrement is done when a packet arrives on an interface *and* leaves via an interface (possibly the same one). This includes a packet that arrives on an interface and then enters a tunnel, and a packet that is decapsulated and then re-encapsulated. It does *not* include a packet locally originated or, for that matter, a packet that arrives destined to the local host. RFC 1853 is incorrect in this regard. OTOH, RFC 2002 says: When encapsulating a datagram, the TTL in the inner IP header is decremented by one if the tunneling is being done as part of forwarding the datagram; otherwise, the inner header TTL is not changed during encapsulation. If the resulting TTL in the inner IP header is 0, the datagram is discarded and an ICMP Time Exceeded message SHOULD be returned to the sender. An encapsulator MUST NOT encapsulate a datagram with TTL = 0. The TTL in the inner IP header is not changed when decapsulating. If, after decapsulation, the inner datagram has TTL = 0, the decapsulator MUST discard the datagram. If, after decapsulation, the decapsulator forwards the datagram to one of its network interfaces, it will decrement the TTL as a result of doing normal IP forwarding. See also Section 4.4. The Architecture document is merely restating this passage in a slightly less clear fashion. -- Harald Koch From owner-ipsec Tue Jul 14 02:30:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA09517 for ipsec-outgoing; Tue, 14 Jul 1998 02:28:31 -0400 (EDT) Message-Id: <199807140640.CAA14883@relay.hq.tis.com> Date: Tue, 14 Jul 98 2:41:48 EDT From: Karen Seo To: bsimpson@morningstar.com cc: iesg@ietf.org, ipsec@tis.com, kseo@bbn.com Subject: Re: Revised drafts -- Arch, AH, ESP Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello Bill, >>.... I just thought I ought to tell you, since this error affects the >>work of so many other IETF WGs. Since your email is addressed to the IESG (and cc'd to ipsec), presumably your comments are intended for the IESG. However, just in case your feedback is intended primarily for the IPsec community and/or document editors, I've attached the rationale for this change below.... In short, the note was intended to address Thomas Narten's question/recommendation. Charlie Lynn didn't hear back from any routing experts or other IETF folks so we went ahead with Thomas Narten's proposal (per Ted's direction on 5/22). Thank you, Karen [From email to ipsec community from Ted Ts'o on 5/22/98] >From: Thomas Narten >To: iesg@ietf.org >Date: Fri, 24 Apr 1998 17:55:25 -0400 >Subject: Re: Ballot: Security Architecture for the Internet Protocol to Proposed Standard >...... >Text relating to decrementing TTL of inner header of encapsulated >packet needs clarification. Text should be clarified to say TTL >decremented only if packet was forwarded (i.e., the forwarding >operation is what decrements the TTL, not the fact that a complete IP >packet is being encapsulated again upon entry to an IPSec tunnel). If >packet originates from node, TTL is left unchanged. This is consistent >with the current general practice of when to decrement TTLs, and some >aspects of IPv6 protocols (i.e, ND) depend on it. My understanding is that everyone is implementing this anyway. Thomas in a later message suggested the following clarification, to be added after the text which described when the TTL in the inner header should be decremented: Note: The decrementing of the TTL is one of the usual actions that takes place when forwarding a packet. Packets originating from the same node as the encapsulator do not have their TTLs decremented, as the sending node is originating the packet rather than forwarding it. Charile Lynn has sent mail dissenting, claiming that it would be a bad thing to do this since it would imply that this would imply that IPSEC tunnels change the Internet Routing Topology, and if so, they might have to conform to all requirements for Internet Routers. (I don't think that's the case today for normal IP-IP tunnels, is it?) Not clear what's the best way to resolve it. If Charlie is right that this has some bad architectural implications, can we please get some Internet Routing experts to explain to us exactly what the problem is please? (and quickly). If my sense that everyone is implementing it the way Thomas and what apparently what most of the IPV6 working group wants, then we might as well document that in the spec. My instincts are to document what people are actually implementing and shipping as products, and if it's a problem we can fix it later. This is *only* a proposed standard folks ---- we don't have to wait until it is perfect (and the technology obsolete) before we ship it. ....... From owner-ipsec Tue Jul 14 11:23:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA11750 for ipsec-outgoing; Tue, 14 Jul 1998 11:21:34 -0400 (EDT) Date: Tue, 14 Jul 98 14:06:41 GMT From: "William Allen Simpson" Message-ID: <7386.wsimpson@greendragon.com> To: iesg@ietf.org Cc: ipsec@tis.com Subject: Re: Revised drafts -- Arch, AH, ESP Sender: owner-ipsec@ex.tis.com Precedence: bulk I am replying to Harold, as he is otherwise an intelligent and thoughtful person who actually writes code, instead of merely speculating about it. Unfortunately, he has been confused by errors in recent RFCs. > From: "C. Harald Koch" > TTL decrement is done when a packet arrives on an interface *and* leaves via > an interface (possibly the same one). This includes a packet that arrives on > an interface and then enters a tunnel, and a packet that is decapsulated and > then re-encapsulated. It does *not* include a packet locally originated or, > for that matter, a packet that arrives destined to the local host. > > RFC 1853 is incorrect in this regard. I firmly disagree with the last two sentences. The issue is that any node that performs "tunnelling" is a router, and must conform to routing requirements. When a locally originated packet is forwarded directly to the final destination over a single interface, we consider that a "host" operation, and do not expect the node to follow routing requirements. When a locally originated packet is forwarded indirectly to the final destination over a tunnel interface that is then re-forwarded (via another interface) over intermediate nodes, that is an act of routing. Thus, the node is acting as a "router". This fact was ignored by the Mobile-IP revisionists, and also by the IPv6 Neighbor Discovery revisionists. It's just too bad that we get proposed standards that do not conform to full standards, but that's what happens when volunteers come along that have not considered nor understood what has gone before. As many of you know, I was involved in the original design and implementation of IPv6 Neighbor Discovery, IP Mobility, and IP Security. Most of the RFC text in all three fields was written by me, but recent editors have mangled them. In Mobile-IP, they went to great lengths to say that a Home Agent that intercepted packets by proxy arp and then forwarded them down a tunnel was not acting as a router, and that a Mobile Node that had a "co-located" Foreign Agent was not acting as a router. This is simply egregious doublespeak. Every node is either acting as a host or a router, and there are no "other" kinds of nodes. There were two principles of Neighbor Discovery that I stated in an interim meeting would be removed over my dead body: integrated mobility and security. Both were removed without any public WG discussion by secret fiat of the chairs, by secretly assigning the documents to revisionists without telling me for over 2 months. I have not read the final version(s) of Neighbor Discovery. At the outset, the revisionist had so little understanding of the basic design principles that as many as 6 messages were being bounced around (where ARP sufficed with only 2), there was no provision for security on the local link during discovery, and all the router self-configuration techniques had been stripped. Anyway, one of the important integral design considerations of both Neighbor Discovery and Mobility was that discovery packets that traverse a tunnel should not exit onto a remote LAN. However, in a conservative design, a packet destined for the Home Agent through a Foreign Agent tunnel should behave in exactly the same fashion as packet that was locally generated and inserted into a local tunnel. During Neighbor Discovery, the host sends a TTL of 1. The Foreign Agent will receive the datagram, and decrement the TTL as it inserts into the tunnel (the outer TTL is set to the configurable IANA value of 64). Likewise, a locally generated tunnel must decrement TTL to 0 when inserting into the tunnel. When it arrives at the Home Agent, the Home Agent does not examine the TTL and does not drop the datagram when it is destined for itself, but is prevented from forwarding. To accomplish this symmetric behaviour, the inner TTL is decremented before encapsulation. This principle depended upon the requirement in RFC-1122: 3.2.1.7 Time-to-Live: RFC-791 Section 3.2 A host MUST NOT send a datagram with a Time-to-Live (TTL) value of zero. A host MUST NOT discard a datagram just because it was received with TTL less than 2. This is also described in RFC-1812: 4.2.2.9 Time to Live: RFC 791 Section 3.2 ... Note in particular that a router MUST NOT check the TTL of a packet except when forwarding it. A router MUST NOT originate or forward a datagram with a Time-to-Live (TTL) value of zero. A router MUST NOT discard a datagram just because it was received with TTL equal to zero or one; if it is to the router and otherwise valid, the router MUST attempt to receive it. Note that RFC-2002 does not conform to either host or router requirements: > If, after decapsulation, the inner datagram has TTL = 0, the > decapsulator MUST discard the datagram. Furthermore, there is a happy by-product to my design that came out during implementation. Routing loops were more quickly eliminated. Many systems cannot differentiate between a datagram that is locally generated and one that has arrived and been decapsulated. Early implementations tried to check this by looking at the IP source to decide whether it is local. When the node is involved in a tunnel loop, that node would keep inserting the datagram into the tunnel without decrementing TTL. This has an obvious flaw -- just think about it. It all comes down to the old "be conservative in its sending behavior, and liberal in its receiving behavior." Sending a more conservative TTL prevents currently known and future potential problems. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ipsec Tue Jul 14 11:23:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA11737 for ipsec-outgoing; Tue, 14 Jul 1998 11:20:32 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01B142BE@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Jul 1998 11:25:11 -0400 To: Stephen Waters From: Stephen Kent Subject: Re: Transport Mode Q Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen, > Just had a scan of the likely documents for the definition on what >to deal with the outer header for > Transport Mode - I suppose this is obvious, but is it documented in >the ipsec drafts? > > I'm assuming, as a BITW sort of thing, I need to move the IP >protocol field into one of the extra > headers I apply, and adjust the packet length: > > [IP][Upper] > > [IP][AH][ESP][IPCOMP][Upper] > > In this example, IPCOMP next-head needs to copy the value from >[IP], and [IP] needs it's > next prot set to AH, and so on. Once compression/encryption is >complete, I write the > final length into [IP] and then Authenticate. > > Am I close? Yes, this is an accurate characterization of the processing. I guess we did not include an explicit description because, as you said, it seemed fairly obvious. However, it would be preferable to include a discussion of this in the arch doc. I'll defer to the judgement of the WG chairs to determine if we need to make this change at this stage in the process. Steve From owner-ipsec Tue Jul 14 11:58:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA11931 for ipsec-outgoing; Tue, 14 Jul 1998 11:58:31 -0400 (EDT) Message-ID: <35AB8617.70F95E1D@tiac.net> Date: Tue, 14 Jul 1998 12:23:51 -0400 From: Michael Giniger X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: X.509 certificate format X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi I am trying to determine the working format for the X.509 certificate as applied to IKE testing. In particular, is the subject identifier using the altsubjectname and if so what is the format for encoding the IPv4 address? an RFC822 name? a full domain name? Are there any special characteristics for the X.509 certificate as used by IKE that are different form the stnadard X.509 format? Thank you very much for your help sincerely Michael Giniger From owner-ipsec Tue Jul 14 14:53:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12597 for ipsec-outgoing; Tue, 14 Jul 1998 14:49:41 -0400 (EDT) Message-ID: From: Greg Carter To: ipsec@tis.com, "'Michael Giniger'" Subject: RE: X.509 certificate format Date: Tue, 14 Jul 1998 14:59:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk The DOI suggests that the ID payload is used to do policy lookup. To make sure the presented ID is OK, during IKE exchanges authenticated via signatures/certificates you should validate the ID in the ID payload is in the certificate. The place to look for these types of names (rfc822, dns, ip address) is the subjectAltName extension. Read http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-08.txt section 4.2.1.7 for formatting of various subjectAltNames. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > ---------- > From: Michael Giniger[SMTP:mginiger@tiac.net] > Sent: Tuesday, July 14, 1998 12:23 PM > To: ipsec@tis.com > Subject: X.509 certificate format > > Hi > > I am trying to determine the working format for the X.509 certificate as > applied to IKE testing. In particular, is the subject identifier using > the altsubjectname and if so what is the format for encoding the IPv4 > address? > an RFC822 name? > a full domain name? > > Are there any special characteristics for the X.509 certificate as used > by IKE that are different form the stnadard X.509 format? > > Thank you very much for your help > > sincerely > Michael Giniger > > From owner-ipsec Tue Jul 14 16:29:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12936 for ipsec-outgoing; Tue, 14 Jul 1998 16:27:16 -0400 (EDT) From: Harald Koch Message-Id: <98Jul14.164356edt.11681@janus.tor.securecomputing.com> Subject: Re: Revised drafts -- Arch, AH, ESP To: wsimpson@greendragon.com (William Allen Simpson) Date: Tue, 14 Jul 1998 16:42:20 -0400 Cc: iesg@ietf.org, ipsec@tis.com In-Reply-To: <7386.wsimpson@greendragon.com> from "William Allen Simpson" at Jul 14, 98 10:06:41 am X-uri: z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > I am replying to Harald, as he is otherwise an intelligent and > thoughtful person who actually writes code, instead of merely > speculating about it. Unfortunately, he has been confused by errors in > recent RFCs. Actually, I think I understand the confusion now. Mobile-IP and VPNs have completely different ideas about the definition and use of IP-in-IP tunnels. I think of VPN-style tunnels as the logical equivalent of a Layer 2 Link between two systems, and it should be treated as such. The TTL processing requirements for feeding IP packets into Layer 2 interfaces are clearly defined as in my previous message. I have never seen an IP stack that couldn't tell the difference between a locally-sourced packet and a packet that arrived on another interface; specifically, all IP stacks that I've worked with have a BSD-style ipforward() function that is the connection between input() and output(), and is the only code that can spell "ttl". Actually, implementations of IP-in-IP tunnelling that I've seen can't tell the difference between a physical interface and a tunnelling interface, and so wouldn't be able to change their TTL behaviour based on that difference! Now, Mobile-IP is a strange beast, one that I have not studied. Of course, I've also never *needed* Mobile-IP, despite using machines that regularly change their IP address and/or move around in space-time. However, I bow to wiser experts than I with regards to this issue, which was previously argued (and settled) as a result of forwarding the IPsec documents to the IESG. -- Harald Koch From owner-ipsec Tue Jul 14 23:10:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA13860 for ipsec-outgoing; Tue, 14 Jul 1998 23:08:22 -0400 (EDT) Date: Wed, 15 Jul 98 02:55:16 GMT From: "William Allen Simpson" Message-ID: <7392.wsimpson@greendragon.com> To: iesg@ietf.org Cc: ipsec@tis.com Subject: Re: Revised drafts -- Arch, AH, ESP Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Harald Koch > Actually, I think I understand the confusion now. Mobile-IP and VPNs have > completely different ideas about the definition and use of IP-in-IP tunnels. > > I think of VPN-style tunnels as the logical equivalent of a Layer 2 Link > between two systems, and it should be treated as such. The TTL processing > requirements for feeding IP packets into Layer 2 interfaces are clearly > defined as in my previous message. > Whereas, I have been coming from the tunnels designed by Phil Karn and others to tie together the AMPRnet over the Internet, which I attempted to generalize combined with JI's doctoral work on mobility and Fred Goldstein's RSPF (and Moy's OSPF, ISIS, etc, etc, etc). Standing on the shoulders of giants, it was my generalization that tunnels for for VPNs and mobility _both_ have the _same_ definition and use, emulating a layer 3 hop, rather than a layer 2 non-hop. It seems pretty clear (to me) that a hop is involved. That is, tunnels are internet routing constructs, not link-layer constructs. But then, I've no stomach for L2TP either, and have turned down a couple contract offers.... Unfortunately, with the lack of any consistent architechural vision, we (the IETF) now have many inconsistent ways of doing the same things. While many have implemented RFC-1853 (which explicitly mentions its use for security), others have implemented RFC-2003 (which only claims to be for mobile-ip). So, given our track record, there is no particular reason to make changes to the Arch draft before publication. It's only another proposed standard that does not comply with full standards. We have plenty of those.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ipsec Wed Jul 15 09:10:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA15785 for ipsec-outgoing; Wed, 15 Jul 1998 09:08:23 -0400 (EDT) Message-Id: <199807151324.IAA04593@stan.lcc.net> X-Sender: bkovar@lcc.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 15 Jul 1998 08:23:57 -0500 To: ipsec@tis.com From: Brent Kovar Subject: demo 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 portal.ex.tis.com id JAA15782 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi! I'm kind of new to IPsec and was wanting to set up a demo in our lab at work. We have two Cisco 1600s and a Linux box. Are there any suggestions out there as to how a test may be perfomed. We also an HP Internet Advisor. Thanks Brent Kovar                      Phone: 409-788-7852 Assistant Network Engineer       Fax:     409-788-7545 Multimedia Services                   E-mail:  bkovar@lcc.net From owner-ipsec Wed Jul 15 13:57:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA17120 for ipsec-outgoing; Wed, 15 Jul 1998 13:54:17 -0400 (EDT) Message-Id: <199807151742.KAA04421@dali.ca.mew.com> X-Mailer: Macintosh Eudora Pro Version 2.1.4-J Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Date: Wed, 15 Jul 1998 10:45:05 -0700 To: ipsec@tis.com From: mat@ca.mew.com (Nobuo Matsuo) Subject: Patent & licence for IPSec ? Sender: owner-ipsec@ex.tis.com Precedence: bulk Dear Mam/Sir, Additionally, are there any patents, licence, trade securet issues exist for ISAKMP ? > When to develop IPSec technology/products where and/or whom to > contact with regarding its patents and licence issues ? > (Who owns patents or not?) > > For example, how about the following cases ? > 1. Products with using IPSec and DES > 2. Products with using IPSec and SHA1 and MD5 Best Regards, Nobuo ------------------------------------------------------- Nobuo Matsuo Email : mat@ca.mew.com Matsushita Electric Works R&D Lab, Inc. 1975 West El Camino Real, Suite #102 Mountain View, CA 94040 Phone: (650) 938-6639, (Ext. 203), Fax : (650) 938-6629 From owner-ipsec Wed Jul 15 17:13:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA18236 for ipsec-outgoing; Wed, 15 Jul 1998 17:09:34 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199807151742.KAA04421@dali.ca.mew.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Jul 1998 17:23:34 -0400 To: mat@ca.mew.com (Nobuo Matsuo) From: Stephen Kent Subject: Re: Patent & licence for IPSec ? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At this time are not aware of any intellectual property issues with the base IPsec protocols and algorithms, or with IKE use of D-H. Use of RSA for certificate signatures, or use of ECC for key exchange does involve patent issues. Steve From owner-ipsec Thu Jul 16 11:13:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21724 for ipsec-outgoing; Thu, 16 Jul 1998 11:09:51 -0400 (EDT) Message-ID: From: "Linn, John" To: ipsec@tis.com, "'Ran Canetti'" Subject: Revised PKCS#1 draft available for comment [Was: RE: DH-less encr yption mode for IKE] Date: Thu, 16 Jul 1998 11:26:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Canetti wrote earlier this month, excerpting: > BTW, I'd like to draw attention to the "security considerations" section > of the draft. It contains a warning that is relevant also to the > current (DH-full) encryption modes of IKE. It reads: > > 4. Security Considerations > > The public key encryption modes of authentication in IKE require > strong public key encryption. In particular, resistance to strong > attacks generally known as "chosen ciphertext attacks" (CCA) is > necessary. This is a practical need as well as the basis for a sound > analysis of these protocols [BeCaKr]. Recently, an explicit chosen > ciphertext attack on the PKCS #1 encryption standard was demonstrated > [Ble]. RSA Labs., the authors of PKCS#1, are preparing a new release > of PKCS #1 that will include the OAEP format of RSA encryption > [RSAlabs]. > It is strongly recommended that IKE specifications and implementations > move to that format which was designed to resist CCA and other attacks. > > To update the status here, the draft version of PKCS #1 V2.0 is now available for review on http://www.rsa.com/rsalabs/pubs/PKCS/. Comments are solicited to pkcs-editor@rsa.com, and those received by Friday, 14 August will be considered in the final version. The draft is available now in MS-Word .doc and Adobe Acrobat .pdf format; preparation of an ASCII version is currently in progress. --John Linn, RSA Laboratories From owner-ipsec Thu Jul 16 14:02:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA23038 for ipsec-outgoing; Thu, 16 Jul 1998 14:00:55 -0400 (EDT) Date: Thu, 16 Jul 1998 11:08:43 -0700 (PDT) From: Gene Tsudik Message-Id: <199807161808.LAA22710@pollux.usc.edu> To: ipsec@tis.com Subject: ACM CCCS'98: Preliminary Program and Call for Participation Sender: owner-ipsec@ex.tis.com Precedence: bulk Preliminary Program Fifth ACM Conference on Computer and Communications Security San Francisco, California November 2-5, 1998 Sponsored by ACM SIGSAC For more information visit http://www.research.att.com/~reiter/ccs5 Launched in 1993, ACM CCCS is the ACM's flagship security conference. CCCS covers a wide range of topics in computer/information security and offers a technical as well as a tutorial program. Presentation topics are diverse, addressing state-of-the-art results of both practical and theoretical nature (and everything in between). ================================= DAY 0 =================================== Monday, November 2, 1998: Tutorials Core Topics Emerging Topics 9:00-12:30 Cryptography: Theory and Programming Languages and Security Applications Martin Abadi (DEC Systems Research Dan Boneh (Stanford Center, USA) and George Necula University, USA) (Carnegie Mellon University, USA) 12:30-13:30 Lunch 13:30-17:00 To Be Determined Authentication Protocol Verification and Analysis Jon Millen (SRI International, USA) ================================= DAY 1 =================================== Tuesday, November 3, 1998: Technical sessions 9:00-10:00 Keynote address Risks and challenges in computer-communication infrastructures Peter G. Neumann (SRI International, USA) 10:00-10:30 Break 10:30-12:00 Group key management Communication complexity of group key distribution Klaus Becker (R^3 Security Engineering, Switzerland) and Uta Wille (IBM Zurich Research Laboratory, Switzerland) Key management for encrypted broadcast Avishai Wool (Bell Labs, USA) Authenticated group key agreement and related protocols Giuseppe Ateniese (USC Information Sciences Institute, USA), Michael Steiner (IBM Zurich Research Laboratory, Switzerland), and Gene Tsudik (USC Information Sciences Institute, USA) 12:00-13:30 Lunch 13:30-15:30 Anonymity The design, implementation and operation of an email pseudonym server David Mazie`res and M. Frans Kaashoek (Massachusetts Institute of Technology, USA) Panel: Anonymity on the Internet Moderator: Paul Syverson (Naval Research Lab, USA) 15:30-16:00 Break 16:00-17:00 Mobile code security History-based access-control for mobile code Guy Edjlali, Anurag Acharya, and Vipin Chaudhary (University of California, Santa Barbara, USA) A specification of Java loading and bytecode verification Allen Goldberg (Kestrel Institute, USA) ================================= DAY 2 =================================== Wednesday, November 4, 1998: Technical sessions 9:00-10:30 Cryptography A new public key cryptosystem based on higher residues David Naccache (Gemplus, France) and Jacques Stern (Ecole Normale Superieure, France) An efficient non-interactive statistical zero-knowledge proof system for quasi-safe prime products Rosario Gennaro (IBM T.J. Watson Research Center, USA), Daniele Micciancio (Massachusetts Institute of Technology, USA), and Tal Rabin (IBM T.J. Watson Research Center, USA) Communication-efficient anonymous group identification Alfredo De Santis (Universita' di Salerno, Italy) and Giovanni Di Crescenzo (University of California, San Diego, USA) 10:30-11:00 Break 11:00-12:00 Invited talk The development of public key cryptography Martin Hellman 12:00-13:30 Lunch 13:30-15:00 Systems A security architecture for computational grids Ian Foster (Argonne National Laboratory, USA), Carl Kesselman, Gene Tsudik (USC Information Sciences Institute, USA), and Steven Tuecke (Argonne National Laboratory, USA) Design of a high-performance ATM firewall Jun Xu and Mukesh Singhal (Ohio State University, USA) A practical secure physical random bit generator Markus Jakobsson, Elisabeth Shriver, Bruce Hillyer (Bell Labs, USA) and Ari Juels (RSA Labs, USA) 15:00-15:30 Break 15:30-16:30 Invited talk Trust in cyberspace? A research roadmap Fred Schneider (Cornell University, USA) ================================= DAY 3 =================================== Thursday, November 5, 1998: Technical sessions 9:00-10:30 Protocol design and analysis A probabilistic poly-time framework for protocol analysis Pat Lincoln (SRI International, USA), John Mitchell, Mark Mitchell (Stanford University, USA), and Andre Scedrov (University of Pennsylvania, USA) On using public-key cryptography in password protocols Shai Halevi (IBM T.J. Watson Research Center, USA) and Hugo Krawczyk (Technion, Israel) Cryptanalysis of Microsoft's point-to-point tunneling protocol Bruce Schneier (Counterpane Systems, USA) 10:30-11:00 Break 11:00-12:00 System monitoring How to prove where you are Eran Gabber and Avishai Wool (Bell Labs, USA) Temporal sequence learning and data reduction for anomaly detection Terran Lane and Carla E. Brodley (Purdue University, USA) ================== Worst paper award and author lampooning =================== Steering committee chair: Ravi Sandhu, George Mason University General chair: Li Gong, JavaSoft Program chair: Mike Reiter AT&T Labs, Room A269, 180 Park Avenue Florham Park, NJ 07932-0971 USA phone: +973-360-8349 Awards chair: Jacques Stern, ENS/DMI Publication chair: Stuart Stubblebine, AT&T Labs Publicity chair: Gene Tsudik, USC ISI Program committee: Martin Abadi, DEC SRC David Naccache, Gemplus Bill Cheswick, Lucent/Bell Labs Hilarie Orman, DARPA/ITO Carl Ellison, Cybercash Avi Rubin, AT&T Labs--Research Ed Felten, Princeton University Pierangela Samarati, Universita di Milano Paul Karger, IBM T.J. Watson Gene Tsudik, USC ISI Steve Kent, BBN Corporation Paul Van Oorschot, Entrust Technologies Ueli Maurer, ETH Zurich Bennet Yee, UCSD Cathy Meadows, Naval Res. Lab Moti Yung, CertCo For more information, visit http://www.research.att.com/~reiter/ccs5 From owner-ipsec Thu Jul 16 15:42:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA23527 for ipsec-outgoing; Thu, 16 Jul 1998 15:38:54 -0400 (EDT) Date: Thu, 16 Jul 1998 12:48:28 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Hybrid Authentication and Remote Access To: ipsec@tis.com Cc: vgupta@nobel.Eng.Sun.COM, moshe@checkpoint.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: PdIU3nByL4YHUPbJlpl6hg== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk Since others on this list may have an interest in using IPSec for remote access scenarios, I'd like to share the following e-mail exchange with Moshe Litvin. It is posted here with his permission. vipul ----------------------------------------------------------- Date: Mon, 13 Jul 1998 20:42:06 +0300 From: Moshe Litvin MIME-Version: 1.0 To: Vipul Gupta CC: moshe@CheckPoint.COM, roy@CheckPoint.COM Subject: Re: Your draft on Hybrid Authentication Content-Transfer-Encoding: 7bit Vipul Gupta wrote: > Hello, > > I read your draft titled "A Hybrid Authentication Mode > for IKE" with great interest. I am very interested in the > use of IPSec fro remote access scenarios myself and see > your draft as supplying a crucial missing piece (if you > could review draft-gupta-ipsec-remote-access-00.txt and > send me feedback, I'd appreciate it). > > What is your opinion regarding draft-ietf-ipsec-isakmp > -xauth-02.txt which also describes the use of token cards > and one-time passwords for authentication with ISAKMP? > That draft assumes that the OTP/token card interaction > occurs *after* a phase one ISAKMP SA has already been > established (i.e. the ISAKMP negotiators have already > authenticated themselves mutually). With these assumptions, > it isn't clear to me that there are many scenarios where > the xauth draft will be applicable. > > Your draft proposed the use of existing authentication > mechanisms like token cards etc for Phase I SA establishment > and seems to have wider applicability. Any comments/feedback > appreciated. > > Thanks, > > vipul > > -- > Vipul Gupta, Ph.D. > Mailstop UMPK15-214 > Sun Microsystems Inc. Email: vipul.gupta@Eng.Sun.COM > 901 San Antonio Road Tel: +1 (650) 786 3614 > Palo Alto CA 94303-4900 Fax: +1 (650) 786 6445 I think that the hybrid mode has several advantages over ISAKMP/XAUTH. There is reason that you stated that ISAKMP/XAUTH can be done only after phase 1, so we have the problem of established ISAKMP SA which is yet completely secure because the ISAKMP/XAUTH hadn't started. It also has security advantage that are gained through the use of public keys, without the need for a full blown PKI as in the case of the full public keys modes. The most natural way to apply ISAKMP/XAUTH is to have a PHASE 1 authenticated by pre-shared secrets (because if you can do something more powerful in phase 1 you probably don't want ISAKMP/XAUTH) and then authenticate only the user with the ISAKMP/XAUTH. But since a user must remember the pre-shared secret is is vulnerable to dictionary attacks, and without the pre-shared secret there is no server authentication and you are vulnerable to man in the middle attack. I also read your draft, and found that when we designed our remote access solution (SecuRemote) we encountered the same problems and we implemented/will implement most of the solutions that you suggested. As for the configuration problem we don't think that a manual configuration of which gateway protects which hosts is feasible, the configuration is to complicated for the normal end user, especially where there are a lot of networks and gateways. I believe that standard way of fetching that configuration information is a must for an inter operable remote access solution. BTW If you like to continue this discussion I would appreciate it, if you will do it on the ipsec list, It may encourage others to join the discussion. regards Moshe Litvin -- ----------------------------------------------------------------------- Moshe Litvin Check Point Software Technologies Ltd. moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555) Fax: +972-3-575-9256 ----------------------------------------------------------------------- From owner-ipsec Thu Jul 16 17:04:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA24022 for ipsec-outgoing; Thu, 16 Jul 1998 17:02:55 -0400 (EDT) Message-ID: <35AE6E72.58638F86@redcreek.com> Date: Thu, 16 Jul 1998 14:19:50 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Vipul Gupta CC: ipsec@tis.com, moshe@checkpoint.com Subject: Re: Hybrid Authentication and Remote Access References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I wasn't planning on commenting on this until I'd had a bit more time to review it, but so long as you're bringing it up, I will voice one criticism of the hybrid-auth draft: ISAKMP Notify messages are ONE-WAY. You are using them for a 2-way exchange. This is a hack. Read the other drafts. Hacking your enhancements into the protocol is ridiculous and unjustified, given that the working group is entering another round in which such modifications may be properly implemented if appropriate. Aside from that criticism, I agree that there is a need for such a mechanism, and that this proposal meets that need in one way, and Roy's isakmp-xauth proposal meets it in others. It's certainly worthy of continued discussion. From owner-ipsec Thu Jul 16 20:49:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA24733 for ipsec-outgoing; Thu, 16 Jul 1998 20:47:58 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807170104.SAA27069@kc.livingston.com> Subject: Re: Revised drafts -- Arch, AH, ESP To: kseo@bbn.com (Karen Seo) Date: Thu, 16 Jul 1998 18:04:18 -0700 (PDT) Cc: ipsec@tis.com, rgm-sec@htt-consult.com, tytso@MIT.EDU, skent@bbn.com, clynn@bbn.com, kseo@bbn.com In-Reply-To: <199807022114.RAA18455@relay.hq.tis.com> from "Karen Seo" at Jul 2, 98 05:08:28 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > From owner-ipsec@portal.ex.tis.com Thu Jul 2 15:51:50 1998 > Message-Id: <199807022114.RAA18455@relay.hq.tis.com> > Date: Thu, 2 Jul 98 17:08:28 EDT > From: Karen Seo > To: ipsec@tis.com > cc: rgm-sec@htt-consult.com, tytso@MIT.EDU, skent@bbn.com, clynn@bbn.com, > kseo@bbn.com > Subject: Revised drafts -- Arch, AH, ESP > Sender: owner-ipsec@ex.tis.com > Precedence: bulk > > Folks, > > In follow-up to Thomas Narten's (IESG) feedback (see Ted Ts'o's email of > 5/22/98) and subsequent email, we have submitted to the IETF secretariat > revised versions of the following drafts: > o AH -- draft-ietf-ipsec-auth-header-06.txt > o ESP -- draft-ietf-ipsec-esp-v2-05.txt > o Architecture -- draft-ietf-ipsec-arch-sec-05.txt > > A summary of the changes that were made is attached below. > > Karen <... snip> Karen, I posted a list of queries a while back to this list. Some of these were responded to and others were not. I would appreciate if you could respond to the following and update the "Security Architecture" draft as necessary with the responses. 1. Sections 4.4.1 and 4.4.2 - Secure Policy data base and selectors The policy selectors such as source Address, Destination Address, Transport Layer Protocol, Transport port no. etc. are allowed to be either discrete numbers or a wildcard; Nothing in between. Yet, there is no mention of multiple SPD entries using the same SA. (For example, how do I create a policy that uses a single SA to encrypt TCP and UDP packets?) I believe, the following posting from Stephen Kent answers this. But, this needs to be documented, considering that the restriction stated will likely be reviewed for removal in IPsecond. X-Sender: kent@po1.bbn.com Date: Mon, 29 Jun 1998 18:12:48 -0400 To: avs@winner.lc.lucent.com Subject: Re: A question about SPD selectors Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Some time ago we agreed to simplify the selector types and removed some options, to make the SPD selectors align with the IKE payload ID types. That's why we limit the address choices, in part. In IPSecond it may be possible to remove some of these restrictions, if corresponding changes to IKE are made. 2. Section 4.4.2 - Name Selectors The User ID based name selector does not seem appropriate for an IPsec SA selection. For example, a VPN router, trying to select an SA for forwarding the packet cannot know if the packet is originating from a certain user. It can only make a decision based on the contents within IP and transport layer headrs. In other wirds, the selection criteria has to boil down to fields you could match against in IP and transport headers. Does this make sense? Can you comment on this? 3. Section 4.6.2: Automated SA and Key management: IKE is specified as the default key management protocol, while protocols such as kerberos and SKIP are mentioned (elsewhere in the document) as other possible key managment protocols. What does "default key management protocol" mean here? Is IKE a manadatory key management protocol? 4. Section 5.0 - Last sentence of the first paragraph: The draft states that a packet MUST be discarded, if no policy in SPD matches the packet, inbound or outbound. Why is this a MUST? This should be left to local administrator to determine the local default policy. For example, the local site could choose to send pakcets in clear, by default, if there is no matching policy in SPD. (May be, all you need to do is lower the case of "MUST" to "must"). Thanks. cheers, suresh From owner-ipsec Thu Jul 16 22:22:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA24994 for ipsec-outgoing; Thu, 16 Jul 1998 22:22:00 -0400 (EDT) Message-Id: <3.0.5.32.19980716223603.007c7100@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 16 Jul 1998 22:36:03 -0400 To: Vipul Gupta , ipsec@tis.com From: David Jablon Subject: Re: Hybrid Authentication and Remote Access Cc: vgupta@nobel.Eng.Sun.COM, moshe@checkpoint.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm curious about the design goals of ipsec-isakmp-xauth ... At 12:48 PM 7/16/98 -0700, Vipul Gupta wrote: > Since others on this list may have an interest in using > IPSec for remote access scenarios, I'd like to share the > following e-mail exchange with Moshe Litvin. >From: Moshe Litvin >To: Vipul Gupta >CC: moshe@CheckPoint.COM, roy@CheckPoint.COM >Subject: Re: Your draft on Hybrid Authentication > >Vipul Gupta wrote: >> [...] What is your opinion regarding draft-ietf-ipsec-isakmp >> -xauth-02.txt which also describes the use of token cards >> and one-time passwords for authentication with ISAKMP? >> That draft assumes that the OTP/token card interaction >> occurs *after* a phase one ISAKMP SA has already been >> established (i.e. the ISAKMP negotiators have already >> authenticated themselves mutually). With these assumptions, >> it isn't clear to me that there are many scenarios where >> the xauth draft will be applicable. >> >> Your draft proposed the use of existing authentication >> mechanisms like token cards etc for Phase I SA establishment >> and seems to have wider applicability. Any comments/feedback >> appreciated. Moshe Litvin wrote: >I think that the hybrid mode has several advantages over ISAKMP/XAUTH. >There is reason that you stated that ISAKMP/XAUTH can be done only after >phase 1, so we have the problem of established ISAKMP SA which is yet >completely secure because the ISAKMP/XAUTH hadn't started. > >It also has security advantage that are gained through the use of public >keys, without the need for a full blown PKI as in the case of the full >public keys modes. > >The most natural way to apply ISAKMP/XAUTH is to have a PHASE 1 >authenticated by pre-shared secrets (because if you can do something >more powerful in phase 1 you probably don't want ISAKMP/XAUTH) and then >authenticate only the user with the ISAKMP/XAUTH. Are you concerned that the "more powerful" techniques are precluded by cost of computation, or by inconvenience? >But since a user must remember the pre-shared secret is is vulnerable to >dictionary attacks, and without the pre-shared secret there is no server >authentication and you are vulnerable to man in the middle attack. If computational cost is not the overriding concern, have you (Vipal or Moshe) considered using an EKE-class shared-secret authentication method, which is immune to these attacks? These were specifically designed to handle memorized secrets. -- dpj From owner-ipsec Thu Jul 16 23:18:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA25092 for ipsec-outgoing; Thu, 16 Jul 1998 23:16:59 -0400 (EDT) Message-ID: From: Bryan Gleeson To: "Scott G. Kelly" , Vipul Gupta Cc: ipsec@tis.com, moshe@checkpoint.com Subject: RE: Hybrid Authentication and Remote Access Date: Thu, 16 Jul 1998 20:33:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott et al. > I wasn't planning on commenting on this until I'd had a bit > more time to > review it, but so long as you're bringing it up, I will voice one > criticism of the hybrid-auth draft: ISAKMP Notify messages > are ONE-WAY. > You are using them for a 2-way exchange. This is a hack. Read > the other > drafts. Hacking your enhancements into the protocol is ridiculous and > unjustified, given that the working group is entering another round in > which such modifications may be properly implemented if appropriate. > > Aside from that criticism, I agree that there is a need for such a > mechanism, and that this proposal meets that need in one way, > and Roy's > isakmp-xauth proposal meets it in others. It's certainly worthy of > continued discussion. I agree with your comments on the encoding. ISAKMP has a rich set of hooks for future extensions and so they should be used rather than redefining or mis-using existing payloads or message exchanges. Specifically if there is a new message exchange that has an unlimited number of messages in it, then that is probably a good time to define a new exchange type, rather than defining it as a variant of main mode, which always has 6 messages. Also if there is a new grouping of attributes that are needed for challenge/response type scenarios, then a new payload type with an associated set of attributes is also the way to go, rather than using the notification payload. The "minor version" field of the ISAKMP header field can be bumped up as extensions like this are agreed and accepted. Before that the "Vendor ID" payload can be used to indicate that private payloads are in use. Bryan Gleeson Shasta Networks. From owner-ipsec Fri Jul 17 01:06:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA25363 for ipsec-outgoing; Fri, 17 Jul 1998 01:04:59 -0400 (EDT) Message-Id: <199807170518.BAA17341@postal.research.att.com> To: ipsec@tis.com Subject: DES-cracker built Date: Fri, 17 Jul 1998 01:18:08 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk According to http://www.nytimes.com/library/tech/98/07/biztech/articles/17encrypt.html John Gilmore and Paul Kocher have designed and built a DES-cracking machine. It works; the whole project cost just $250,000. When is the right time to discuss making a stronger cipher than DES mandatory? From owner-ipsec Fri Jul 17 03:40:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA25709 for ipsec-outgoing; Fri, 17 Jul 1998 03:38:59 -0400 (EDT) Date: Fri, 17 Jul 98 00:54:14 PDT From: jim@mentat.com (Jim Gillogly) Message-Id: <9807170754.AA14587@mentat.com> To: ipsec@tis.com Subject: Re: DES-cracker built Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve Bellovin says: > According to http://www.nytimes.com/library/tech/98/07/biztech/articles/17encrypt.html > John Gilmore and Paul Kocher have designed and built a DES-cracking > machine. It works; the whole project cost just $250,000. > > When is the right time to discuss making a stronger cipher than > DES mandatory? I think that would be now. A couple of times ago when we discussed it I defended DES for the short term, suggesting that it be re-opened when and if somebody admitted having built a hardware cracker. Seems to me the easiest quick fix would be to make 3DES a MUST also: everybody's implementing it anyway, so it won't be any extra effort. Jim Gillogly From owner-ipsec Fri Jul 17 05:08:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA25862 for ipsec-outgoing; Fri, 17 Jul 1998 05:06:59 -0400 (EDT) Message-Id: <199807170923.JAA04063@orchard.arlington.ma.us> To: Steve Bellovin cc: ipsec@tis.com Subject: Re: DES-cracker built In-Reply-To: Message from Steve Bellovin of "Fri, 17 Jul 1998 01:18:08 EDT." <199807170518.BAA17341@postal.research.att.com> Date: Fri, 17 Jul 1998 05:22:59 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > When is the right time to discuss making a stronger cipher than > DES mandatory? Last year. :-) - Bill From owner-ipsec Fri Jul 17 10:09:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA26522 for ipsec-outgoing; Fri, 17 Jul 1998 10:07:10 -0400 (EDT) From: moshe@checkpoint.com (Moshe Litvin) To: Bryan Gleeson Cc: "Scott G. Kelly" , Vipul Gupta , ipsec@tis.com Subject: Re: Hybrid Authentication and Remote Access Date: Fri, 17 Jul 1998 14:19:12 GMT Message-ID: <35b159cf.65607551@cale.checkpoint.com> References: In-Reply-To: X-Mailer: Forte Agent 1.0/32.390 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id KAA26519 Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 16 Jul 1998 20:33:32 -0700, Bryan Gleeson wrote: >Scott et al. > >> I wasn't planning on commenting on this until I'd had a bit >> more time to >> review it, but so long as you're bringing it up, I will voice one >> criticism of the hybrid-auth draft: ISAKMP Notify messages >> are ONE-WAY. >> You are using them for a 2-way exchange. This is a hack. Read >> the other >> drafts. Hacking your enhancements into the protocol is ridiculous and >> unjustified, given that the working group is entering another round in >> which such modifications may be properly implemented if appropriate. >> >> Aside from that criticism, I agree that there is a need for such a >> mechanism, and that this proposal meets that need in one way, >> and Roy's >> isakmp-xauth proposal meets it in others. It's certainly worthy of >> continued discussion. > >I agree with your comments on the encoding. ISAKMP has a rich set of >hooks for future extensions and so they should be used rather than >redefining or mis-using existing payloads or message exchanges. As for the use of the notify payloads, I can't say that I disagree with you, but see my comments in the reply to Scott G. Kelly. >Specifically if there is a new message exchange that has an unlimited >number of messages in it, then that is probably a good time to define >a new exchange type, rather than defining it as a variant of main mode, >which always has 6 messages. The hybrid authentication mode has exactly the same purpose as the main mode, and a very similar structure. In fact the first two messages are identical thus providing the ability to negotiate the use of the hybrid mode or other authentication mode, using a different exchange number will prevent this useful property. I don't think that the 6 messages of main mode are curved in rock and I don't see why it should be. Also note that normally the hybrid mode takes also exactly 6 messages. More fundamental to IKE is the idea that the authentication mode is negotiable. > Also if there is a new grouping of >attributes that are needed for challenge/response type scenarios, then >a new payload type with an associated set of attributes is also the way >to go, rather than using the notification payload. The "minor version" >field of the ISAKMP header field can be bumped up as extensions like >this are agreed and accepted. Before that the "Vendor ID" payload can >be used to indicate that private payloads are in use. > >Bryan Gleeson >Shasta Networks. > Moshe Litvin From owner-ipsec Fri Jul 17 10:09:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA26512 for ipsec-outgoing; Fri, 17 Jul 1998 10:06:10 -0400 (EDT) From: moshe@checkpoint.com (Moshe Litvin) To: "Scott G. Kelly" Cc: Vipul Gupta , ipsec@tis.com Subject: Re: Hybrid Authentication and Remote Access Date: Fri, 17 Jul 1998 14:19:03 GMT Message-ID: <35b35d0e.66438486@cale.checkpoint.com> References: <35AE6E72.58638F86@redcreek.com> In-Reply-To: <35AE6E72.58638F86@redcreek.com> X-Mailer: Forte Agent 1.0/32.390 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id KAA26509 Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 16 Jul 1998 14:19:50 -0700, Scott G. Kelly wrote: >I wasn't planning on commenting on this until I'd had a bit more time to >review it, but so long as you're bringing it up, I will voice one >criticism of the hybrid-auth draft: ISAKMP Notify messages are ONE-WAY. >You are using them for a 2-way exchange. This is a hack. I agree that it is a hack, not because of the one-way nature of the notify message, but because the hybrid mode uses them to transfer specific information with specific format, and in a perfect protocol it should deserve a payload type of it's own. > Read the other drafts. I read them. From where do you think that I got the idea of using the notify payload for challenge response? (read for example ISAKMP/XAUTH). > Hacking your enhancements into the protocol is ridiculous and >unjustified, given that the working group is entering another round in >which such modifications may be properly implemented if appropriate. In general I agree with you. The problem is that while the future of ISAKMP is the full public key modes, in the present there are large installation bases of challenge/response tokens. Thus waiting for the next phase of the ipsec to add more notification types to is missing the point of providing a solution in the near future. > >Aside from that criticism, I agree that there is a need for such a >mechanism, and that this proposal meets that need in one way, and Roy's >isakmp-xauth proposal meets it in others. It's certainly worthy of >continued discussion. > Regards, Moshe Litvin From owner-ipsec Fri Jul 17 10:20:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA26573 for ipsec-outgoing; Fri, 17 Jul 1998 10:20:09 -0400 (EDT) Message-Id: <199807171436.HAA27347@gallium.network-alchemy.com> To: Bill Sommerfeld cc: Steve Bellovin , ipsec@tis.com Subject: Re: DES-cracker built In-reply-to: Your message of "Fri, 17 Jul 1998 05:22:59 EDT." <199807170923.JAA04063@orchard.arlington.ma.us> Date: Fri, 17 Jul 1998 07:36:22 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk RE: hardware DES cracker Cool! I can update the IPSEC DOI in, say, one minute... We will want to update IKE as well and mandate the second Oakley MODP group. I believe that Hillary has some additional concerns even about the strength of that group for generating full 3DES keys... Derrell From owner-ipsec Fri Jul 17 11:02:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA26763 for ipsec-outgoing; Fri, 17 Jul 1998 11:02:10 -0400 (EDT) Message-Id: <199807171518.LAA02444@jekyll.piermont.com> To: Steve Bellovin cc: ipsec@tis.com Subject: Re: DES-cracker built In-reply-to: Your message of "Fri, 17 Jul 1998 01:18:08 EDT." <199807170518.BAA17341@postal.research.att.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 17 Jul 1998 11:18:24 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve Bellovin writes: > According to http://www.nytimes.com/library/tech/98/07/biztech/articles/17encrypt.html > John Gilmore and Paul Kocher have designed and built a DES-cracking > machine. It works; the whole project cost just $250,000. > > When is the right time to discuss making a stronger cipher than > DES mandatory? Given how long such a debate takes us, starting now is probably a good idea. This means that, sadly, the only algorithm we strongly enough suspect to be secure is 3DES. More importantly, I suspect the only algorithm that we could get consensus on would be 3DES. My suggestion, therefore, would be for us to switch "mandatory" to 3DES, with a commitment to replacing 3DES with AES eventually. I would suggest using AES now, but for the fact that it doesn't yet exist. I'm pretty confident that AES will eventually be a good replacement, though. Several of the candidates look like exceptionally good ciphers. My one question is whether, for interoperability with older devices, we should retain "must implement" for DES (or any cipher that we may mandate for a while and then drop, like 3DES) into the future. I would claim, unfortunately, that "yes" must be an answer to this. Perry PS Unfortunately, the recent near attacks on Skipjack by Eli Biham make me suspect that it is not a reasonable alternative. From owner-ipsec Fri Jul 17 11:06:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA26804 for ipsec-outgoing; Fri, 17 Jul 1998 11:06:10 -0400 (EDT) X-Authentication-Warning: keeks.ioc.ee: helger owned process doing -bs Date: Fri, 17 Jul 1998 18:31:47 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: "Derrell D. Piper" cc: ipsec@tis.com Subject: Re: DES-cracker built In-Reply-To: <199807171436.HAA27347@gallium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 17 Jul 1998, Derrell D. Piper wrote: > I can update the IPSEC DOI in, say, one minute... Being sarcastic: did you really have to way until today? A product I'm involved with supports DES only to be compatible with IPSEC drafts. The product manuals have stating that from the very beginning, warning the customers _never_ to use DES. Helger http://home.cyber.ee/helger From owner-ipsec Fri Jul 17 12:15:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA27276 for ipsec-outgoing; Fri, 17 Jul 1998 12:11:35 -0400 (EDT) Message-ID: <35AF7BA1.FEF41C70@redcreek.com> Date: Fri, 17 Jul 1998 09:28:17 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Moshe Litvin CC: Vipul Gupta , ipsec@tis.com Subject: Re: Hybrid Authentication and Remote Access References: <35AE6E72.58638F86@redcreek.com> <35b35d0e.66438486@cale.checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Moshe, Moshe Litvin wrote: > > On Thu, 16 Jul 1998 14:19:50 -0700, Scott G. Kelly wrote: > I agree that it is a hack, not because of the one-way nature of the > notify message, but because the hybrid mode uses them to transfer > specific information with specific format, and in a perfect protocol > it should deserve a payload type of it's own. > It is a hack when you use one-way messages for an exchange. > > Read the other drafts. Sorry, I shouldn't have said this - you obviously have read them. > > I read them. From where do you think that I got the idea of using the > notify payload for challenge response? (read for example > ISAKMP/XAUTH). Read, for example, isakmp-xauth-02, in which this flaw was corrected. > In general I agree with you. The problem is that while the future of > ISAKMP is the full public key modes, in the present there are large > installation bases of challenge/response tokens. Thus waiting for the > next phase of the ipsec to add more notification types to is missing > the point of providing a solution in the near future. No. In the interim you can use the vendor ID and a propietary (extension) exchange/payload. When and if you convince others of its utility, these can be added to the protocol. Scott From owner-ipsec Fri Jul 17 12:15:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA27291 for ipsec-outgoing; Fri, 17 Jul 1998 12:15:39 -0400 (EDT) Message-ID: <35AF7CA0.AC9113D2@redcreek.com> Date: Fri, 17 Jul 1998 09:32:32 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "Derrell D. Piper" CC: Bill Sommerfeld , Steve Bellovin , ipsec@tis.com Subject: Re: DES-cracker built References: <199807171436.HAA27347@gallium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell D. Piper wrote: > > RE: hardware DES cracker > I believe that Hillary has some additional concerns even about the strength of > that group for generating full 3DES keys... It seems to be the consensus that the second group will give around 80 or so bits of strength. I've been curious for some time as to how we get 112 bits of key strength when we begin with 85. Anyone? From owner-ipsec Fri Jul 17 13:18:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27649 for ipsec-outgoing; Fri, 17 Jul 1998 13:16:42 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199807170104.SAA27069@kc.livingston.com> References: <199807022114.RAA18455@relay.hq.tis.com> from "Karen Seo" at Jul 2, 98 05:08:28 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Jul 1998 13:24:48 -0400 To: suresh@livingston.com (Pyda Srisuresh) From: Stephen Kent Subject: Re: Revised drafts -- Arch, AH, ESP Cc: kseo@bbn.com (Karen Seo), ipsec@tis.com, rgm-sec@htt-consult.com, tytso@MIT.EDU, skent@bbn.com, clynn@bbn.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda, >1. Sections 4.4.1 and 4.4.2 - Secure Policy data base and selectors > > The policy selectors such as source Address, Destination Address, > Transport Layer Protocol, Transport port no. etc. are allowed to > be either discrete numbers or a wildcard; Nothing in between. > Yet, there is no mention of multiple SPD entries using the same SA. > (For example, how do I create a policy that uses a single SA to > encrypt TCP and UDP packets?) > > I believe, the following posting from Stephen Kent answers this. > But, this needs to be documented, considering that the restriction > stated will likely be reviewed for removal in IPsecond. > > X-Sender: kent@po1.bbn.com > Date: Mon, 29 Jun 1998 18:12:48 -0400 > To: avs@winner.lc.lucent.com > Subject: Re: A question about SPD selectors > Cc: ipsec@tis.com > Sender: owner-ipsec@ex.tis.com > Precedence: bulk > > Some time ago we agreed to simplify the selector types and removed some > options, to make the SPD selectors align with the IKE payload ID types. > That's why we limit the address choices, in part. In IPSecond it may be > possible to remove some of these restrictions, if corresponding changes to > IKE are made. So the answer here is that, for now, you can support both TCP and UDP in the same SA only by accepting ANY transport protocol in that SPD entry. To do otherwise would require support for an enumerated list, a feature we once had and then deleted due to concerns expressed by implementors, as noted in my earlier message. >2. Section 4.4.2 - Name Selectors > > The User ID based name selector does not seem appropriate for an > IPsec SA selection. For example, a VPN router, trying to select > an SA for forwarding the packet cannot know if the packet is > originating from a certain user. It can only make a decision > based on the contents within IP and transport layer headrs. > In other wirds, the selection criteria has to boil down to > fields you could match against in IP and transport headers. > Does this make sense? Can you comment on this? Section 4.4.2 requires security gateway support for the User ID name form only for INBOUND SA processing. This is used to support mobile users with dynamically assigned addresses. After SA creation, a temporary SPD entry is created with the address of the mobile user (instead of the name), so that subsequent traffic in both directions can be keyed off of the IPaddress (and any other applicable selectors). >3. Section 4.6.2: Automated SA and Key management: > > IKE is specified as the default key management protocol, while > protocols such as kerberos and SKIP are mentioned (elsewhere in > the document) as other possible key managment protocols. What > does "default key management protocol" mean here? Is IKE a > manadatory key management protocol? If one uses an automated key management protocol, the only one endorsed by the IPsec WG is IKE. Thus it is the default. However, support for IKE is not required for IPsec compliance. >4. Section 5.0 - Last sentence of the first paragraph: > > The draft states that a packet MUST be discarded, if no policy in SPD > matches the packet, inbound or outbound. Why is this a MUST? > This should be left to local administrator to determine the > local default policy. For example, the local site could choose > to send pakcets in clear, by default, if there is no matching > policy in SPD. > (May be, all you need to do is lower the case of "MUST" to "must"). Customary security policy is to reject any access that is not explicitly authorized. The specified SPD processing is consistent with this policy. A site can override this default by creating a final SPD entry that allows for BYPASS of any packet, which then becomes the default action for a packet that does not match any previous SPD entry. Steve From owner-ipsec Fri Jul 17 13:31:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27709 for ipsec-outgoing; Fri, 17 Jul 1998 13:30:42 -0400 (EDT) Date: Fri, 17 Jul 1998 10:46:05 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Hybrid Authentication and Remote Access To: Moshe Litvin Cc: "Scott G. Kelly" , Vipul Gupta , ipsec@tis.com In-Reply-To: "Your message with ID" <35b35d0e.66438486@cale.checkpoint.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > On Thu, 16 Jul 1998 14:19:50 -0700, Scott G. Kelly wrote: > > >I wasn't planning on commenting on this until I'd had a bit more time to > >review it, but so long as you're bringing it up, I will voice one > >criticism of the hybrid-auth draft: ISAKMP Notify messages are ONE-WAY. > >You are using them for a 2-way exchange. This is a hack. > > I agree that it is a hack, not because of the one-way nature of the > notify message, but because the hybrid mode uses them to transfer > specific information with specific format, and in a perfect protocol > it should deserve a payload type of it's own. > > > Read the other drafts. > > I read them. From where do you think that I got the idea of using the > notify payload for challenge response? (read for example > ISAKMP/XAUTH). > > > Hacking your enhancements into the protocol is ridiculous and > >unjustified, given that the working group is entering another round in > >which such modifications may be properly implemented if appropriate. > > In general I agree with you. The problem is that while the future of > ISAKMP is the full public key modes, in the present there are large > installation bases of challenge/response tokens. Thus waiting for the > next phase of the ipsec to add more notification types to is missing > the point of providing a solution in the near future. Just want to add my 2 cents here. I want to make sure that whatever the solution is adopted, it is not restricted to challenge/response algorithms only and can support more sophisticated schemes like biometrics. PatC > > > > >Aside from that criticism, I agree that there is a need for such a > >mechanism, and that this proposal meets that need in one way, and Roy's > >isakmp-xauth proposal meets it in others. It's certainly worthy of > >continued discussion. > > > > Regards, > > Moshe Litvin From owner-ipsec Fri Jul 17 13:37:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27729 for ipsec-outgoing; Fri, 17 Jul 1998 13:37:42 -0400 (EDT) Message-Id: <199807171752.NAA03128@jekyll.piermont.com> To: Helger Lipmaa cc: "Derrell D. Piper" , ipsec@tis.com Subject: Re: DES-cracker built In-reply-to: Your message of "Fri, 17 Jul 1998 18:31:47 +0300." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 17 Jul 1998 13:52:29 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk Helger Lipmaa writes: > On Fri, 17 Jul 1998, Derrell D. Piper wrote: > > > I can update the IPSEC DOI in, say, one minute... > > Being sarcastic: did you really have to way until today? A product I'm > involved with supports DES only to be compatible with IPSEC drafts. The > product manuals have stating that from the very beginning, warning the > customers _never_ to use DES. Lets just get on with it rather than fighting. I think we all now agree that better than DES (I'm assuming 3DES) is mandatory, especially since the O'Reilly book on the crack will contain complete plans for the DES cracker. Perry From owner-ipsec Fri Jul 17 13:57:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27801 for ipsec-outgoing; Fri, 17 Jul 1998 13:56:45 -0400 (EDT) Message-Id: <199807171812.LAA27637@gallium.network-alchemy.com> To: perry@piermont.com cc: Helger Lipmaa , ipsec@tis.com Subject: Re: DES-cracker built In-reply-to: Your message of "Fri, 17 Jul 1998 13:52:29 EDT." <199807171752.NAA03128@jekyll.piermont.com> Date: Fri, 17 Jul 1998 11:12:48 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk > especially since the O'Reilly book on the crack will > contain complete plans for the DES cracker. Is there also going to be a "DES Cracking for Dummys" book forthcoming? Derrell From owner-ipsec Fri Jul 17 13:59:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27815 for ipsec-outgoing; Fri, 17 Jul 1998 13:59:45 -0400 (EDT) Date: Fri, 17 Jul 1998 21:15:10 +0300 (EET DST) Message-Id: <199807171815.VAA12705@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: moshe@checkpoint.com (Moshe Litvin) Cc: "Scott G. Kelly" , Vipul Gupta , ipsec@tis.com Subject: Re: Hybrid Authentication and Remote Access In-Reply-To: <35b35d0e.66438486@cale.checkpoint.com> References: <35AE6E72.58638F86@redcreek.com> <35b35d0e.66438486@cale.checkpoint.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 64 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Moshe Litvin writes: > > Read the other drafts. > I read them. From where do you think that I got the idea of using the > notify payload for challenge response? (read for example > ISAKMP/XAUTH). The draft-ietf-ipsec-isakmp-xauth-02 draft uses configuration mode instead of notify payloads. The configuration mode draft-ietf-ipsec-isakmp-mode-cfg-04 draft defines new exchange method called transaction exchanges, and uses special attribute payload inside them. It doesn't use notify payloads anymore. One thing that xauth draft does incorrectly is that it again extends the transaction exchange defined by the configuration mode from 2 packets to 3 or more packets. The configuration mode clearly defines that transaction mode is always 2 packets, and I think that if xauth mode is supposed to work over that it must not modify the exchange, only the values inside the payloads. This could be fixed in the xauth draft so that it uses one or more transaction exchanges like this: IPSec Host Edge Device -------------- ----------------- 1. <-- REQUEST(SECURID NAME PASSWORD PASSCODE) REPLY(SECURID NAME PASSWORD PASSCODE) --> 2. <-- REQUEST(SECURID NAME PASSWORD PASSCODE) REPLY(SECURID NAME PASSWORD PASSCODE) --> Where 1 and 2 are separate transaction exchanges requesting two passcodes. The only thing that is missing is the AUTH-OK or AUTH-FAILED information, but I think that can be expressed as notification (it really is notification). So if the authentication fails the server MAY send a notify message to the other end specifying that the AUTHENTICATION-FAILED error (or probably better have own EXTENDED-AUTHENTICATION-FAILED error code). The IPSec host can know that the authentication has succeeded if the Edge Device lets it continue the process that triggered this extended authentication. If we think about the whole picture it will probably be something like this: IPSec Host Edge Device ---------------- ------------------- Starts Main mode HDR, SA -> <- HDR, SA HDR, KE, Ni -> <- HDR, KE, Nr HDR*, IDii, SIG_I -> <- HDR*, IDir, SIG_R Starts quick mode HDR*, HASH, SA, Ni, KE, IDci, IDcr -> Edge device realizes that it needs extended authentication before quick mode can be allowed, it starts extended authentication <- REQ(NAME, PASSWORD) Asks password from user (note that quick mode negotiation may expire during this, because it may take quite long time from the user to answer the password query) REPLY(NAME, PASSWORD) -> If client notices that is quick mode has already expired (timed out) it should start new one here. Verifies the password. If correct, replies to the quick mode. <- HDR*, HASH, SA, Nr, KE, IDci, IDcr HDR*, HASH -> And then we have authenticated connection. If the password verification fails the negotiation might continue like this: IPSec Host Edge Device ---------------- ------------------- Verifies the password. Notices that password is bad, sends notify back <- HDR*, HASH, N If the client receives notification it can show it to user. In any way it is going to resent its quick mode packet later, because server hasn't yet answered that HDR*, HASH, SA, Ni, KE, IDci, IDcr -> Edge device realizes that it needs extended authentication before quick mode can be allowed, and it doesn't have extended authentication in progress, so it starts a new extended authentication <- REQ(NAME, PASSWORD) Asks password from user REPLY(NAME, PASSWORD) -> Lets assume here that the previous packet to the quick mode was the final retransmit and now the negotiation is expired, so the client must start new quick mode negotiation here. HDR*, HASH, SA, Ni, KE, IDci, IDcr -> Verifies the password if correct replies to the quick mode. <- HDR*, HASH, SA, Nr, KE, IDci, IDcr HDR*, HASH -> > In general I agree with you. The problem is that while the future of > ISAKMP is the full public key modes, in the present there are large > installation bases of challenge/response tokens. Thus waiting for the > next phase of the ipsec to add more notification types to is missing > the point of providing a solution in the near future. It is ok to add new ERROR notification types, but I don't think it is good to add new semantics to notify payload. I really really don't like that we modify existing exchanges and extend the number of packets used in them. If you need more packets than in the main mode, then define new exchange method. Also note, that there is no need to be concerned about breaking existing implementations. If the other end does support this new authentication method (it selects that authentication method), then it will also support all new payloads etc you might invent for this. If you use new exchange method and the other end doesn't support it, then you have to revert back to main mode if you can, but if you cannot, then there is nothing you can do. Also extending the main mode after the 6 packet (+ possible commit bit notifications) is explicitly forbidden in the isakmp-oakley-08 draft when doing certificate request payload processing, so I think most of the implementations take that so that it will always take 6 packets, no more, no less (+ plus the (two) final connected notifications if commit bit was on). If you are going to extend it, that might require quite a large modifications to the existing code. So I suggest following. Use ATTR payload (from configuration mode) to store authentication information. You can also use the same numbers etc than the extended authentication mode is already using. If the server selects the hybrid authentication mode from the SA then it also supports those new payloads, if it doesn't select it then it selects something else (if another choice is provided) and the other end does not send ATTR payloads. You might also want to think about creating completely new exchange method that would allow this, gss api authentication, and possible other authentication methods that require multiple packets back and fort. Also I really don't like the idea that the server cannot start re-keying, because IT MAKES things really hard. If you think about the situation where we have 10 MB byte life time for the SA and the server is sending some large file to the client. Now the client must count incoming bytes in addition to its own outgoing bytes, so it can know when the server is going to expire the SA because of the byte limit, and it must start re-keying before that (provided that the ISAKMP SA is already expired too). That is really BAD. Also note, that the client might not know that the server has already deleted the ISAKMP SA when it is going to start re-keying of the ipsec SA. The server might have deleted the ISAKMP SA because it run out of memory or so and the delete notify might have been lost (if the server even ever sent one). In that case the server has no other choice than just start dropping all packets going to the client. It cannot restart main mode, because it needs client to do that. It might not even have enough information about the previous ISAKMP SA, so it could resent its delete notification to client. The only thing it can do is to send completely UNPROTECTED notification to the client asking him to start ISAKMP SA (denial of service attackers really like that, they just send one faked isakmp notify to client and that will consume lots of processing power from the server (Diffie-Hellman, Private key decrypt etc). I think that draft is going to need more thinking about. I now think that you really need new exchange method for this. -- 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 Fri Jul 17 14:03:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27836 for ipsec-outgoing; Fri, 17 Jul 1998 14:02:50 -0400 (EDT) Message-Id: <199807171818.OAA03259@jekyll.piermont.com> To: "Derrell D. Piper" cc: ipsec@tis.com Subject: Re: DES-cracker built In-reply-to: Your message of "Fri, 17 Jul 1998 11:12:48 PDT." <199807171812.LAA27637@gallium.network-alchemy.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 17 Jul 1998 14:18:50 -0400 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk "Derrell D. Piper" writes: > > especially since the O'Reilly book on the crack will > > contain complete plans for the DES cracker. > > Is there also going to be a "DES Cracking for Dummys" book forthcoming? I hear word that a commercial organization will be renting time on a machine like the EFF DES cracker, so I suspect that dummies would be best off buying time. Perry From owner-ipsec Fri Jul 17 14:09:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27862 for ipsec-outgoing; Fri, 17 Jul 1998 14:08:50 -0400 (EDT) Date: Fri, 17 Jul 1998 21:24:27 +0300 (EET DST) Message-Id: <199807171824.VAA12688@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: moshe@checkpoint.com (Moshe Litvin) Cc: Bryan Gleeson , "Scott G. Kelly" , Vipul Gupta , ipsec@tis.com Subject: Re: Hybrid Authentication and Remote Access In-Reply-To: <35b159cf.65607551@cale.checkpoint.com> References: <35b159cf.65607551@cale.checkpoint.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 6 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Moshe Litvin writes: > I don't think that the 6 messages of main mode are curved in rock and > I don't see why it should be. Also note that normally the hybrid mode > takes also exactly 6 messages. It doesn't matter if it takes 6 packets normally, if it can take more. I still have to write code for that special case, and test it, and it doesn't help me a bit that it quite often takes only 6 packets. > More fundamental to IKE is the idea that the authentication mode is > negotiable. Yes, but if you are only offering the hybrid mode, then only think you can really negotiate is, if the other ends supports this method or not. You can get same feedback by trying to use new exchange method (==notification back). If you can suggest several authentication methods, why select this one with so many problems (the re-keying problem)? -- 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 Fri Jul 17 14:48:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA28011 for ipsec-outgoing; Fri, 17 Jul 1998 14:46:55 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807171903.MAA14273@kc.livingston.com> Subject: Re: Revised drafts -- Arch, AH, ESP To: kent@bbn.com (Stephen Kent) Date: Fri, 17 Jul 1998 12:03:32 -0700 (PDT) Cc: suresh@livingston.com, kseo@bbn.com, ipsec@tis.com, rgm-sec@htt-consult.com, tytso@MIT.EDU, skent@bbn.com, clynn@bbn.com In-Reply-To: from "Stephen Kent" at Jul 17, 98 01:24:48 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Thanks, Steve, for your responses. Additional comments below. cheers, suresh > > Pyda, > > >1. Sections 4.4.1 and 4.4.2 - Secure Policy data base and selectors > > > > The policy selectors such as source Address, Destination Address, > > Transport Layer Protocol, Transport port no. etc. are allowed to > > be either discrete numbers or a wildcard; Nothing in between. > > Yet, there is no mention of multiple SPD entries using the same SA. > > (For example, how do I create a policy that uses a single SA to > > encrypt TCP and UDP packets?) > > > > I believe, the following posting from Stephen Kent answers this. > > But, this needs to be documented, considering that the restriction > > stated will likely be reviewed for removal in IPsecond. > > > > X-Sender: kent@po1.bbn.com > > Date: Mon, 29 Jun 1998 18:12:48 -0400 > > To: avs@winner.lc.lucent.com > > Subject: Re: A question about SPD selectors > > Cc: ipsec@tis.com > > Sender: owner-ipsec@ex.tis.com > > Precedence: bulk > > > > Some time ago we agreed to simplify the selector types and removed some > > options, to make the SPD selectors align with the IKE payload ID types. > > That's why we limit the address choices, in part. In IPSecond it may be > > possible to remove some of these restrictions, if corresponding changes to > > IKE are made. > > So the answer here is that, for now, you can support both TCP and UDP in > the same SA only by accepting ANY transport protocol in that SPD entry. To > do otherwise would require support for an enumerated list, a feature we > once had and then deleted due to concerns expressed by implementors, as > noted in my earlier message. > Got it. All I was asking was to state in the draft that there was a consideration to include a discrete list of individual entries, ranges and blocks of entries, but has been dropped for the time being for ease of implementation and to be in line with IKE and IP DOI drafts. If you dont add the clarification, you will continue to be asked the same types of questions on the subject over and over even after the draft is progressed into an RFC. > >2. Section 4.4.2 - Name Selectors > > > > The User ID based name selector does not seem appropriate for an > > IPsec SA selection. For example, a VPN router, trying to select > > an SA for forwarding the packet cannot know if the packet is > > originating from a certain user. It can only make a decision > > based on the contents within IP and transport layer headrs. > > In other wirds, the selection criteria has to boil down to > > fields you could match against in IP and transport headers. > > Does this make sense? Can you comment on this? > > Section 4.4.2 requires security gateway support for the User ID name form > only for INBOUND SA processing. This is used to support mobile users with > dynamically assigned addresses. After SA creation, a temporary SPD entry > is created with the address of the mobile user (instead of the name), so > that subsequent traffic in both directions can be keyed off of the > IPaddress (and any other applicable selectors). > OK, I get it now. Thanks. Once again, I think, it would be useful to add the clarification to the draft. > >3. Section 4.6.2: Automated SA and Key management: > > > > IKE is specified as the default key management protocol, while > > protocols such as kerberos and SKIP are mentioned (elsewhere in > > the document) as other possible key managment protocols. What > > does "default key management protocol" mean here? Is IKE a > > manadatory key management protocol? > > If one uses an automated key management protocol, the only one endorsed by > the IPsec WG is IKE. Thus it is the default. However, support for IKE is > not required for IPsec compliance. > OK. That clears it up. I asked the question because even the basic ICSA certification 1.0 requires support for IKE. IPsec compliant, policy based, manually configured SAs are not certifiable from ICSA. Yes, I do realize, ICSA is different from IETF. > >4. Section 5.0 - Last sentence of the first paragraph: > > > > The draft states that a packet MUST be discarded, if no policy in SPD > > matches the packet, inbound or outbound. Why is this a MUST? > > This should be left to local administrator to determine the > > local default policy. For example, the local site could choose > > to send pakcets in clear, by default, if there is no matching > > policy in SPD. > > (May be, all you need to do is lower the case of "MUST" to "must"). > > Customary security policy is to reject any access that is not explicitly > authorized. The specified SPD processing is consistent with this policy. A > site can override this default by creating a final SPD entry that allows > for BYPASS of any packet, which then becomes the default action for a > packet that does not match any previous SPD entry. > OK, I understand what you say. I was only objecting to the use of MUST (as in RFC 2119). > Steve > > > cheers, suresh From owner-ipsec Fri Jul 17 15:02:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28061 for ipsec-outgoing; Fri, 17 Jul 1998 15:01:56 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199807171903.MAA14273@kc.livingston.com> References: from "Stephen Kent" at Jul 17, 98 01:24:48 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Jul 1998 15:14:29 -0400 To: suresh@livingston.com (Pyda Srisuresh) From: Stephen Kent Subject: Re: Revised drafts -- Arch, AH, ESP Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Suresh, At this point in the document editing process, it probably is not possible top make these changes, although I agree that the document would be better if 1-3 were made. Steve From owner-ipsec Fri Jul 17 15:19:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28104 for ipsec-outgoing; Fri, 17 Jul 1998 15:19:06 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807171935.MAA18542@kc.livingston.com> Subject: Re: Revised drafts -- Arch, AH, ESP To: kent@bbn.com (Stephen Kent) Date: Fri, 17 Jul 1998 12:35:42 -0700 (PDT) Cc: suresh@livingston.com, ipsec@tis.com In-Reply-To: from "Stephen Kent" at Jul 17, 98 03:14:29 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Suresh, > > At this point in the document editing process, it probably is not possible > top make these changes, although I agree that the document would be better > if 1-3 were made. > > Steve > When I sent these comments in May (i.e. more than six weeks ago), it was deemed too late to make changes. Yet, I see updated drafts submitted by Karen just a couple of weeks back. I understand, if you are reluctant to make a new submission just with these updates. But, if you are making another submission independent of these changes, I suggest folding in these updates. Hope this would be OK by you. Thanks. cheers, suresh From owner-ipsec Fri Jul 17 15:58:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28174 for ipsec-outgoing; Fri, 17 Jul 1998 15:56:24 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199807171935.MAA18542@kc.livingston.com> References: from "Stephen Kent" at Jul 17, 98 03:14:29 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Jul 1998 16:05:41 -0400 To: suresh@livingston.com (Pyda Srisuresh) From: Stephen Kent Subject: Re: Revised drafts -- Arch, AH, ESP Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Suresh, We made changes in response to some of your comments, when they were received several weeks ago. We deemed the other comments not significant enough to warrant changes, because we were requested to complete the edits as soon as possible. For other reasons the process has dragged on and the documents are not yet out, but that does not change the relative importance of the edits we chose to make vs. defer. >When I sent these comments in May (i.e. more than six weeks ago), it >was deemed too late to make changes. Yet, I see updated drafts submitted >by Karen just a couple of weeks back. I understand, if you are reluctant >to make a new submission just with these updates. But, if you are making >another submission independent of these changes, I suggest folding >in these updates. Hope this would be OK by you. Thanks. Steve From owner-ipsec Sat Jul 18 20:01:07 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA00245 for ipsec-outgoing; Sat, 18 Jul 1998 19:54:45 -0400 (EDT) Date: Sat, 18 Jul 98 20:03:53 EDT From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9807190003.AA06900@dolphin.ncsc.mil> To: ipsec@tis.com, SVakil@vpnet.com Subject: Re: ISAKMP Draft 10 Content-Type: X-sun-attachment Sender: owner-ipsec@ex.tis.com Precedence: bulk ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 30 Sumit, > The General Message Processing section of draft 10 (section 5.1) has the > following regarding how an implementation is supposed to set the > retransmission timer: > NOTE: Implementations MUST NOT use a fixed timer. Instead, > transmission timer values should be adjusted dynamically based on > measured round trip times. In addition, successive retransmissions > of the same packet should be separated by increasingly longer time > intervals (e.g., exponential backoff). > > How and why has this been added to the draft? I don't recollect it being > discussed on the mailing list. This is an implementation detail. The draft > should only suggest a scheme, not make one a requirement. This was added to the ISAKMP-10 I-D because of Thomas Narten's IESG vote. Basically, it was added so we can get the documents accepted to RFC. The wording was exactly as he proposed it. As I see it, the text as presented gives a suggested approach, i.e. dynamically adjusted using exponential backoff. That is not part of the requirement. The requirement is "MUST NOT use a fixed timer". On another note, I asked Ted to send the list of ISAKMP-10 changes to the IPSEC list after the I-D was announced. I'm just returning from vacation and I haven't seen it, so attached is a list of all changes made to the ISAKMP-10 Internet Draft. Regards, Doug Maughan ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: v10changes.txt X-Sun-Content-Lines: 51 Chapter 2 --------- 2.4 Line 5 of Table Description - Changed SHOULD to MUST for consistency with section 3.1 (Tom McMillan e-mail - 29 Apr 98) Chapter 3 --------- 3 Removed sentence about message alignment (Agreed upon by implementors via IPSEC list) 3.1 Added Private Use Exchange Types 240-255 (requested by Dan Harkins, et. al.) 3.1 Clarification of Commit Bit and Information Exchange (Derrell Piper e-mail - 13 Jun 98) 3.14.1 Added UNSUPPORTED-EXCHANGE-TYPE notify message (requested by Derrell Piper) Rationale: Let communicating peer know what exchanges can be used in establishing secure communications 3.14.1 Added UNEQUAL-PAYLOAD-LENGTHS notify message (based on discussion with several implementors) Chapter 4 --------- 4.8 Added clarifying text similar to 3.1 above for dealing with Commit Bit and Informational Exchange (Derrell Piper e-mail - 13 Jun 98) Chapter 5 --------- 5.1 Added clarifying text associated with timer values (Used text suggested by Thomas Narten) 5.2 Added reference to section 3.1 for Major and Minor Version check 5.14 & Corrected ESP and AH SPI size from 8 octets to 4 octets 5.15 (Tom McMillan e-mail - 29 Apr 98) Bibliography ------------ Changed [IAB] reference from I-D to RFC 2316 Changed [RFC-1825] reference from RFC to new Sec-Arch I-D * as directed by Narten's vote Updated IKE and IPSEC DOI references From owner-ipsec Sun Jul 19 13:45:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01444 for ipsec-outgoing; Sun, 19 Jul 1998 13:41:46 -0400 (EDT) Message-ID: <35B232C7.DDF0D26E@cale.checkpoint.com> Date: Sun, 19 Jul 1998 20:54:15 +0300 From: Moshe Litvin X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Tero Kivinen CC: Moshe Litvin , "Scott G. Kelly" , Vipul Gupta , ipsec@tis.com Subject: Re: Hybrid Authentication and Remote Access References: <35AE6E72.58638F86@redcreek.com> <35b35d0e.66438486@cale.checkpoint.com> <199807171815.VAA12705@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Tero Kivinen wrote: > > Moshe Litvin writes: > > > Read the other drafts. > > I read them. From where do you think that I got the idea of using the > > notify payload for challenge response? (read for example > > ISAKMP/XAUTH). > > The draft-ietf-ipsec-isakmp-xauth-02 draft uses configuration mode > instead of notify payloads. The configuration mode > draft-ietf-ipsec-isakmp-mode-cfg-04 draft defines new exchange method > called transaction exchanges, and uses special attribute payload > inside them. It doesn't use notify payloads anymore. You are right, I wasn't aware of the changes in that draft, the ATTR payload is more appropriate. [critisim of XAUTH deleted] > > IPSec Host Edge Device > ---------------- ------------------- > Starts Main mode > HDR, SA -> > <- HDR, SA > HDR, KE, Ni -> > <- HDR, KE, Nr > HDR*, IDii, SIG_I -> > <- HDR*, IDir, SIG_R > Starts quick mode > HDR*, HASH, SA, Ni, KE, IDci, IDcr -> > Edge device realizes > that it needs extended > authentication before > quick mode can be > allowed, it starts > extended authentication > > <- REQ(NAME, PASSWORD) > Asks password from user (note that > quick mode negotiation may expire > during this, because it may take quite > long time from the user to answer the > password query) > REPLY(NAME, PASSWORD) -> > If client notices that is quick mode > has already expired (timed out) > it should start new one here. > Verifies the password. > If correct, replies to > the quick mode. > <- HDR*, HASH, SA, Nr, > KE, IDci, IDcr > HDR*, HASH -> > > And then we have authenticated connection. If the password > verification fails the negotiation might continue like this: > > IPSec Host Edge Device > ---------------- ------------------- > Verifies the password. > Notices that password > is bad, sends notify > back > <- HDR*, HASH, N > If the client receives notification > it can show it to user. > In any way it is going to resent > its quick mode packet later, because > server hasn't yet answered that > HDR*, HASH, SA, Ni, KE, IDci, IDcr -> > Edge device realizes > that it needs extended > authentication before > quick mode can be > allowed, and it doesn't > have extended > authentication in > progress, so it starts > a new extended > authentication > <- REQ(NAME, PASSWORD) > Asks password from user > REPLY(NAME, PASSWORD) -> > Lets assume here that the previous > packet to the quick mode was the final > retransmit and now the negotiation is > expired, so the client must start new > quick mode negotiation here. > HDR*, HASH, SA, Ni, KE, IDci, IDcr -> > Verifies the password > if correct replies to > the quick mode. > <- HDR*, HASH, SA, Nr, > KE, IDci, IDcr > HDR*, HASH -> 1. If you already did ISAKMP with signatures why do you need XAUTH? signatures seems to be a stronger method. 2. How does the edge device knows the client support XAUTH? is it negotiated or just assumed? 3. I thought that the main purpose of main mode is to provide authentication for the following negotiations, in your example it didn't (otherwise you wouldn't need XAUTH). You created an ISAKMP SA, what security does it hold? [deleted argument that I already agreed to] > Also extending the main mode after the 6 packet (+ possible commit bit > notifications) is explicitly forbidden in the isakmp-oakley-08 draft > when doing certificate request payload processing, so I think most of > the implementations take that so that it will always take 6 packets, > no more, no less (+ plus the (two) final connected notifications if > commit bit was on). > > If you are going to extend it, that might require quite a large > modifications to the existing code. None of the implementation support hybrid mode, I think that most of them don't even support the revised encryption mode, so I am sure that it will require quite a large modifications to the existing code. I don't see why the larger number of packet is so much harder than other changes. > > So I suggest following. Use ATTR payload (from configuration mode) to > store authentication information. You can also use the same numbers > etc than the extended authentication mode is already using. If the > server selects the hybrid authentication mode from the SA then it also > supports those new payloads, if it doesn't select it then it selects > something else (if another choice is provided) and the other end does > not send ATTR payloads. I agree. > > You might also want to think about creating completely new exchange > method that would allow this, gss api authentication, and possible > other authentication methods that require multiple packets back and > fort. There are three options: 1. Create a new exchange type which means that the hybrid mode cannot be negotiated. 2. Criple the mode to allow only a single "challenge/response" (like in the GSS-API draft). 3. Allow more than 6 packets in main mode. Two of those option heart the usability of the authentication mode, one of them breaks a detail wich is not even specified as a rule. I really don't see why there is a question which is the best option. > Also I really don't like the idea that the server cannot start > re-keying, because IT MAKES things really hard. If you think about the > situation where we have 10 MB byte life time for the SA and the server > is sending some large file to the client. Now the client must count > incoming bytes in addition to its own outgoing bytes, so it can know > when the server is going to expire the SA because of the byte limit, > and it must start re-keying before that (provided that the ISAKMP SA > is already expired too). That is really BAD. It less bad in reality than it is in theory. All the client has to do is to keep the ISAKMP SA alive. (BTW the client has to count the incoming bytes anyway, to make sure that complies with the security policy) > Also note, that the client might not know that the server has already > deleted the ISAKMP SA when it is going to start re-keying of the ipsec > SA. The server might have deleted the ISAKMP SA because it run out of > memory or so and the delete notify might have been lost (if the server > even ever sent one). In that case the server has no other choice than > just start dropping all packets going to the client. It cannot restart > main mode, because it needs client to do that. It might not even have > enough information about the previous ISAKMP SA, so it could resent > its delete notification to client. The only thing it can do is to send > completely UNPROTECTED notification to the client asking him to start > ISAKMP SA (denial of service attackers really like that, they just > send one faked isakmp notify to client and that will consume lots of > processing power from the server (Diffie-Hellman, Private key decrypt > etc). When dealing with remote users (with no fixed IP) the server has to remember some dynamic data to be able to do isakmp (it at least has to know that there is a remote user at that IP, it will probably want to know who is the user (perhaps that user is not permited to work at those hours so there is no need to waste effort on negotiation). In some case it will do some sort of NAT, so it will have to remember also this. So, to be able to recover, the server may generate a protected delete payload when it delete the SA and remember it. Then if and when the server will won't to recover the tunnle he can retransmit that payload. > > I think that draft is going to need more thinking about. I now think > that you really need new exchange method for this. I really don't see what is so wrong with having more than 6 packets in main mode. For me the structure of main mode is: two packets for SA attributes negotiation, two packet for exchangin key material, and authentication packets. Until now the authentication mode required exactly two packets, so main mode needed exactily 6 packets. But if an authentication mode require a different number of packet main mode can be made to have a different number of packets. Regards, Moshe -- ----------------------------------------------------------------------- Moshe Litvin Check Point Software Technologies Ltd. moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555) Fax: +972-3-575-9256 ----------------------------------------------------------------------- From owner-ipsec Sun Jul 19 13:57:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01467 for ipsec-outgoing; Sun, 19 Jul 1998 13:54:46 -0400 (EDT) Message-ID: <35B235C5.1C491677@cale.checkpoint.com> Date: Sun, 19 Jul 1998 21:07:01 +0300 From: Moshe Litvin X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Tero Kivinen CC: Moshe Litvin , Bryan Gleeson , "Scott G. Kelly" , Vipul Gupta , ipsec@tis.com Subject: Re: Hybrid Authentication and Remote Access References: <35b159cf.65607551@cale.checkpoint.com> <199807171824.VAA12688@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Tero Kivinen wrote: > > Moshe Litvin writes: > > I don't think that the 6 messages of main mode are curved in rock and > > I don't see why it should be. Also note that normally the hybrid mode > > takes also exactly 6 messages. > > It doesn't matter if it takes 6 packets normally, if it can take more. > I still have to write code for that special case, and test it, and it > doesn't help me a bit that it quite often takes only 6 packets. If a server doesn't want to support more than 6 packets, he can easily do so (it will limit the ways of authentication that it can support but that's all). For client the situation is a bit more complex. The hybrid mode was designed to allow the client software to be unaware to the actual authentication method used (the server can transmit text that will be displayed directly to the user). But even so, if you only want to support authentication methods that have only one round of challenge/response you don't have to support more than 6 packets. > > > More fundamental to IKE is the idea that the authentication mode is > > negotiable. > > Yes, but if you are only offering the hybrid mode, then only think you > can really negotiate is, if the other ends supports this method or > not. You can get same feedback by trying to use new exchange method > (==notification back). > > If you can suggest several authentication methods, why select this one > with so many problems (the re-keying problem)? Because it also has advantages. Regards, Moshe > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ -- ----------------------------------------------------------------------- Moshe Litvin Check Point Software Technologies Ltd. moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555) Fax: +972-3-575-9256 ----------------------------------------------------------------------- From owner-ipsec Sun Jul 19 18:21:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA01688 for ipsec-outgoing; Sun, 19 Jul 1998 18:18:46 -0400 (EDT) Date: Mon, 20 Jul 1998 01:34:40 +0300 (EET DST) Message-Id: <199807192234.BAA19071@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Moshe Litvin Cc: "Scott G. Kelly" , Vipul Gupta , ipsec@tis.com Subject: Re: Hybrid Authentication and Remote Access In-Reply-To: <35B232C7.DDF0D26E@cale.checkpoint.com> References: <35AE6E72.58638F86@redcreek.com> <35b35d0e.66438486@cale.checkpoint.com> <199807171815.VAA12705@torni.ssh.fi> <35B232C7.DDF0D26E@cale.checkpoint.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 26 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Moshe Litvin writes: > 1. If you already did ISAKMP with signatures why do you need XAUTH? > signatures seems to be a stronger method. Because the signatures only authenticate the machine, not the user. For example we might have several general use machines around, with each one having separate private key, and when someone logs in from that, it only says that ok, this is this pc-55.xxx.com, but it doesn't say anything about who he is and does he have permission to create ipsec SA. > 2. How does the edge device knows the client support XAUTH? is it > negotiated or just assumed? If the server requires XAUTH, it assumes the clinet does it. If the client doesn't answer to XAUTH or answers with error notification then it doesn't support it, and then the edge device will propably just drop the connection, because the user could not be authenticated. > 3. I thought that the main purpose of main mode is to provide > authentication for the following negotiations, in your example it didn't > (otherwise you wouldn't need XAUTH). You created an ISAKMP SA, what > security does it hold? Main mode is used to authenticate the MACHINE in the other end. For example the machine might be the other networks security gateway. After that we do know that ok, the connection is coming from the other network, but we do not know who is in the other end. XAUTH will give us that information after that we might decide wheter we allow user to do something or not. > None of the implementation support hybrid mode, I think that most of > them don't even support the revised encryption mode, so I am sure that > it will require quite a large modifications to the existing code. I > don't see why the larger number of packet is so much harder than other > changes. Larger number of packets isn't harder if it is separate exchange. Combining everything together makes the protocol complicated and we have lots of different special cases. > 1. Create a new exchange type which means that the hybrid mode cannot be > negotiated. I think it has so much special cases and differences compared to main mode that it is no use to try to combine it to main mode. Quite often the client will know before hand whether to use hybrid mode or not, and in the server it doesn't matter. So if client does have key for other authentications (rsa/dsa private key or preshared key) then use normal main mode first and do XAUTH after that. If the client doesn't have any key to the server, the only choice it has is to use hybrid mode anyways. So I don't think that is a real problem. > 2. Criple the mode to allow only a single "challenge/response" (like in > the GSS-API draft). I don't think that is a good idea, because after that you create new complicated system and still you don't allow taking advantage of the benefits after the basic system. > 3. Allow more than 6 packets in main mode. I don't like that option, because it will make integrating lots of special code inside main mode code. If we use separate exchange the code can also easily be separated. In any way I really dont like about exchanges that can go forever... > Two of those option heart the usability of the authentication mode, one > of them breaks a detail wich is not even specified as a rule. I really > don't see why there is a question which is the best option. I want the isakmp to as simple as possible. I do not want to combine everything together as one huge negotiation having lots of different options that will change the negotiation slightly. Using modular structure makes implemantation quite a lot of easier. There are already some special cases in the isakmp protocol that makes its implementation unnecessaryly harder, and I don't want to get more of them in it. > > Also I really don't like the idea that the server cannot start > > re-keying, because IT MAKES things really hard. If you think about the > > situation where we have 10 MB byte life time for the SA and the server > > is sending some large file to the client. Now the client must count > > incoming bytes in addition to its own outgoing bytes, so it can know > > when the server is going to expire the SA because of the byte limit, > > and it must start re-keying before that (provided that the ISAKMP SA > > is already expired too). That is really BAD. > > It less bad in reality than it is in theory. All the client has to do is > to keep the ISAKMP SA alive. How? The server can always delete the ISAKMP SA, and if the one packet containing the delete notification is lost the client HAS no way to know if the ISAKMP SA is still valid or not. Also if server has a resource shortage, it might be that it doesn't have enough resources to send that notification at all. > > Also note, that the client might not know that the server has already > > deleted the ISAKMP SA when it is going to start re-keying of the ipsec > > SA. The server might have deleted the ISAKMP SA because it run out of > > memory or so and the delete notify might have been lost (if the server > > even ever sent one). In that case the server has no other choice than > > just start dropping all packets going to the client. It cannot restart > > main mode, because it needs client to do that. It might not even have > > enough information about the previous ISAKMP SA, so it could resent > > its delete notification to client. The only thing it can do is to send > > completely UNPROTECTED notification to the client asking him to start > > ISAKMP SA (denial of service attackers really like that, they just > > send one faked isakmp notify to client and that will consume lots of > > processing power from the server (Diffie-Hellman, Private key decrypt > > etc). > > When dealing with remote users (with no fixed IP) the server has to > remember some dynamic data to be able to do isakmp (it at least has to > know that there is a remote user at that IP, it will probably want to > know who is the user (perhaps that user is not permited to work at those > hours so there is no need to waste effort on negotiation). In some case > it will do some sort of NAT, so it will have to remember also this. That information is usually stored in the ipsec SA and the ISAKMP SA doesn't need to store that information. If the ISAKMP SA is deleted when the ipsec SA is about to expire we just create new ISAKMP SA with that IP address that is the other end of the ipsec SA. There is no need to store anything about the other end in the ISAKMP, only in the ipsec. > So, to be able to recover, the server may generate a protected delete > payload when it delete the SA and remember it. Then if and when the > server will won't to recover the tunnle he can retransmit that payload. And what happens if it runs out of memory to store those protected delete payloads? It has no way to know if the client has received it or not, and in your example it cannot delete it. > I really don't see what is so wrong with having more than 6 packets in > main mode. For me the structure of main mode is: two packets for SA > attributes negotiation, two packet for exchangin key material, and > authentication packets. Until now the authentication mode required > exactly two packets, so main mode needed exactily 6 packets. But if an > authentication mode require a different number of packet main mode can > be made to have a different number of packets. I think the rekeying stuff is much more serious than having 6 packets in the main mode. Having more than 6 packets in the main mode will just make it harder to implement and proably generate some more bugs there, but it can be don. I just dont like it. Makeing the rekeying stuff only work for one direction is much worse, and can create very nasty situations where the server has no way to fix the broken connection with client (for example after server reboot the client cannot detect this before it sends first packet after that (or not even then, if the server just throws unknown ipsec packet away without any notification)). -- 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 Sun Jul 19 18:23:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA01704 for ipsec-outgoing; Sun, 19 Jul 1998 18:21:45 -0400 (EDT) Date: Mon, 20 Jul 1998 01:38:02 +0300 (EET DST) Message-Id: <199807192238.BAA18850@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Moshe Litvin Cc: Bryan Gleeson , "Scott G. Kelly" , Vipul Gupta , ipsec@tis.com Subject: Re: Hybrid Authentication and Remote Access In-Reply-To: <35B235C5.1C491677@cale.checkpoint.com> References: <35b159cf.65607551@cale.checkpoint.com> <199807171824.VAA12688@torni.ssh.fi> <35B235C5.1C491677@cale.checkpoint.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Moshe Litvin writes: > > If you can suggest several authentication methods, why select this one > > with so many problems (the re-keying problem)? > Because it also has advantages. What advantages it has if you do have private key or preshared key in the client (== you can propose several different authentication methods) compared doing normal main mode and then XAUTH. It does save 2 packets but because they can be interleaved with the 3 packets in the quick mode, it doesn even add one round trip of properly done. -- 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 Sun Jul 19 19:29:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA01787 for ipsec-outgoing; Sun, 19 Jul 1998 19:28:45 -0400 (EDT) Message-Id: <199807192342.TAA15658@postal.research.att.com> To: "Scott G. Kelly" cc: "Derrell D. Piper" , Bill Sommerfeld , ipsec@tis.com Subject: Re: DES-cracker built Date: Sun, 19 Jul 1998 19:42:30 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <35AF7CA0.AC9113D2@redcreek.com>, "Scott G. Kelly" writes: > Derrell D. Piper wrote: > > > > RE: hardware DES cracker > > I believe that Hillary has some additional concerns even about the strength > of > > that group for generating full 3DES keys... > > It seems to be the consensus that the second group will give around 80 > or so bits of strength. I've been curious for some time as to how we get > 112 bits of key strength when we begin with 85. Anyone? In general, you can't; the more interesting question is whether or not there is a feasible attack that has work proportional to 2^80. From owner-ipsec Sun Jul 19 21:33:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA01999 for ipsec-outgoing; Sun, 19 Jul 1998 21:30:44 -0400 (EDT) Message-Id: <3.0.5.32.19980719214547.00a036f0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 19 Jul 1998 21:45:47 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Re: Serous system failure In-Reply-To: <2.2.32.19980706213242.008df0fc@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:32 PM 7/6/98 -0400, Robert Moskowitz wrote: >My notebook is out of service (since thursday) for maybe a week. My mail is >on it until maybe tomorrow (should have been today :( ). > I am still down, running on my server and an old notebook.... Thus I am quite behind in reading. Perhaps by mid-week, things will improve :( Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Mon Jul 20 03:28:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA02622 for ipsec-outgoing; Mon, 20 Jul 1998 03:26:45 -0400 (EDT) Message-ID: <35B2F412.D093475@cale.checkpoint.com> Date: Mon, 20 Jul 1998 10:38:58 +0300 From: Moshe Litvin X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Tero Kivinen CC: Moshe Litvin , "Scott G. Kelly" , Vipul Gupta , ipsec@tis.com Subject: Re: Hybrid Authentication and Remote Access References: <35AE6E72.58638F86@redcreek.com> <35b35d0e.66438486@cale.checkpoint.com> <199807171815.VAA12705@torni.ssh.fi> <35B232C7.DDF0D26E@cale.checkpoint.com> <199807192234.BAA19071@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Tero Kivinen wrote: > > Moshe Litvin writes: > > 1. If you already did ISAKMP with signatures why do you need XAUTH? > > signatures seems to be a stronger method. > > Because the signatures only authenticate the machine, not the user. > For example we might have several general use machines around, with > each one having separate private key, and when someone logs in from > that, it only says that ok, this is this pc-55.xxx.com, but it doesn't > say anything about who he is and does he have permission to create > ipsec SA. > > > 2. How does the edge device knows the client support XAUTH? is it > > negotiated or just assumed? > > If the server requires XAUTH, it assumes the clinet does it. If the > client doesn't answer to XAUTH or answers with error notification then > it doesn't support it, and then the edge device will propably just > drop the connection, because the user could not be authenticated. > > > 3. I thought that the main purpose of main mode is to provide > > authentication for the following negotiations, in your example it didn't > > (otherwise you wouldn't need XAUTH). You created an ISAKMP SA, what > > security does it hold? If I understand you correctly XAUTH is used when you want to separately authenticate the machine and then the user. Usually in remote access scenario you don't really care about the machine and you are only interested in the user. > > Main mode is used to authenticate the MACHINE in the other end. For > example the machine might be the other networks security gateway. > After that we do know that ok, the connection is coming from the other > network, but we do not know who is in the other end. XAUTH will give > us that information after that we might decide wheter we allow user to > do something or not. > > > None of the implementation support hybrid mode, I think that most of > > them don't even support the revised encryption mode, so I am sure that > > it will require quite a large modifications to the existing code. I > > don't see why the larger number of packet is so much harder than other > > changes. > > Larger number of packets isn't harder if it is separate exchange. > Combining everything together makes the protocol complicated and we > have lots of different special cases. > > > 1. Create a new exchange type which means that the hybrid mode cannot be > > negotiated. > > I think it has so much special cases and differences compared to main > mode that it is no use to try to combine it to main mode. Quite often > the client will know before hand whether to use hybrid mode or not, > and in the server it doesn't matter. So if client does have key for > other authentications (rsa/dsa private key or preshared key) then use > normal main mode first and do XAUTH after that. If the client doesn't > have any key to the server, the only choice it has is to use hybrid > mode anyways. So I don't think that is a real problem. Hybrid mode is not so different, in fact it is more similar to revised encryption than revised is to pre-shared secret. > > > 2. Criple the mode to allow only a single "challenge/response" (like in > > the GSS-API draft). > > I don't think that is a good idea, because after that you create new > complicated system and still you don't allow taking advantage of the > benefits after the basic system. > > > 3. Allow more than 6 packets in main mode. > > I don't like that option, because it will make integrating lots of > special code inside main mode code. If we use separate exchange the > code can also easily be separated. In any way I really dont like about > exchanges that can go forever... > > > Two of those option heart the usability of the authentication mode, one > > of them breaks a detail wich is not even specified as a rule. I really > > don't see why there is a question which is the best option. > > I want the isakmp to as simple as possible. I do not want to combine > everything together as one huge negotiation having lots of different > options that will change the negotiation slightly. Using modular > structure makes implemantation quite a lot of easier. There are > already some special cases in the isakmp protocol that makes its > implementation unnecessaryly harder, and I don't want to get more of > them in it. It is modular. All the difference are after both sides agreed about a certain path. If you like, after this point you can treat it as a separate exchange. > > > > Also I really don't like the idea that the server cannot start > > > re-keying, because IT MAKES things really hard. If you think about the > > > situation where we have 10 MB byte life time for the SA and the server > > > is sending some large file to the client. Now the client must count > > > incoming bytes in addition to its own outgoing bytes, so it can know > > > when the server is going to expire the SA because of the byte limit, > > > and it must start re-keying before that (provided that the ISAKMP SA > > > is already expired too). That is really BAD. > > > > It less bad in reality than it is in theory. All the client has to do is > > to keep the ISAKMP SA alive. > > How? The server can always delete the ISAKMP SA, and if the one packet > containing the delete notification is lost the client HAS no way to > know if the ISAKMP SA is still valid or not. Also if server has a > resource shortage, it might be that it doesn't have enough resources > to send that notification at all. > > > > Also note, that the client might not know that the server has already > > > deleted the ISAKMP SA when it is going to start re-keying of the ipsec > > > SA. The server might have deleted the ISAKMP SA because it run out of > > > memory or so and the delete notify might have been lost (if the server > > > even ever sent one). In that case the server has no other choice than > > > just start dropping all packets going to the client. It cannot restart > > > main mode, because it needs client to do that. It might not even have > > > enough information about the previous ISAKMP SA, so it could resent > > > its delete notification to client. The only thing it can do is to send > > > completely UNPROTECTED notification to the client asking him to start > > > ISAKMP SA (denial of service attackers really like that, they just > > > send one faked isakmp notify to client and that will consume lots of > > > processing power from the server (Diffie-Hellman, Private key decrypt > > > etc). > > > > When dealing with remote users (with no fixed IP) the server has to > > remember some dynamic data to be able to do isakmp (it at least has to > > know that there is a remote user at that IP, it will probably want to > > know who is the user (perhaps that user is not permited to work at those > > hours so there is no need to waste effort on negotiation). In some case > > it will do some sort of NAT, so it will have to remember also this. > > That information is usually stored in the ipsec SA and the ISAKMP SA > doesn't need to store that information. This a strange implementation choice, you may have a lot of IPSEC SA's Simultaneously, and they will change all the time. Why do you want to copy all that information to every separate IPSEC SA (especially since you are so concerned about resource shortage). > If the ISAKMP SA is deleted > when the ipsec SA is about to expire we just create new ISAKMP SA with > that IP address that is the other end of the ipsec SA. There is no > need to store anything about the other end in the ISAKMP, only in the > ipsec. > > > So, to be able to recover, the server may generate a protected delete > > payload when it delete the SA and remember it. Then if and when the > > server will won't to recover the tunnle he can retransmit that payload. > > And what happens if it runs out of memory to store those protected > delete payloads? It has no way to know if the client has received it > or not, and in your example it cannot delete it. > > > I really don't see what is so wrong with having more than 6 packets in > > main mode. For me the structure of main mode is: two packets for SA > > attributes negotiation, two packet for exchangin key material, and > > authentication packets. Until now the authentication mode required > > exactly two packets, so main mode needed exactily 6 packets. But if an > > authentication mode require a different number of packet main mode can > > be made to have a different number of packets. > > I think the rekeying stuff is much more serious than having 6 packets > in the main mode. Having more than 6 packets in the main mode will > just make it harder to implement and proably generate some more bugs > there, but it can be don. I just dont like it. > > Makeing the rekeying stuff only work for one direction is much worse, > and can create very nasty situations where the server has no way to > fix the broken connection with client (for example after server reboot > the client cannot detect this before it sends first packet after that > (or not even then, if the server just throws unknown ipsec packet away > without any notification)). The problem of rekeying is a direct consequences of the asymmetrical nature of the hybrid mode. The asymmetrical nature gives the ability to harness the powers of public key cryptography without using a full blown PKI, but there is such thing as free lunch. However implementations that are aware of that problem can solve it quite easily. Remembering the encrypted delete payload will require less than 1K per user, which means 1 MB per 1000 users, every machine that can handle 1000 concurent users can easily handle it (the same for higher or smaller number). Once you do this, all you need is for the client to keep the ISAKMP SA alive. If there is on going traffic on the line someone has to keep it alive and might as well be the client. If there is no traffic this can be used as a keep-alive signal, so that the server will not think that the client hanged-up (and in case of NAT will give the IP address to someone else). Regards, Moshe -- ----------------------------------------------------------------------- Moshe Litvin Check Point Software Technologies Ltd. moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555) Fax: +972-3-575-9256 ----------------------------------------------------------------------- From owner-ipsec Mon Jul 20 06:19:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA02984 for ipsec-outgoing; Mon, 20 Jul 1998 06:18:46 -0400 (EDT) Date: Mon, 20 Jul 1998 17:34:37 +0700 (JAVT) From: asep tea To: ipsec@tis.com Subject: header of the Subjects Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I have subscribed many mailing lists. So I need to see easily wether the mail which comes to my box is from IPSEC or not. Yes, I know some of mail client can group the mail automatically, but mine doesn't. I propose to process all the mail come to the mailing list so the subject can look like this Subject: [IPSEC]mySubject It comes easier to me to read and to group the mail manually. Thanks in advance asep asep@w3.to From owner-ipsec Mon Jul 20 07:54:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA03253 for ipsec-outgoing; Mon, 20 Jul 1998 07:52:48 -0400 (EDT) Date: Mon, 20 Jul 1998 15:08:35 +0300 (EET DST) Message-Id: <199807201208.PAA26086@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Moshe Litvin Cc: "Scott G. Kelly" , Vipul Gupta , ipsec@tis.com Subject: Re: Hybrid Authentication and Remote Access In-Reply-To: <35B2F412.D093475@cale.checkpoint.com> References: <35AE6E72.58638F86@redcreek.com> <35b35d0e.66438486@cale.checkpoint.com> <199807171815.VAA12705@torni.ssh.fi> <35B232C7.DDF0D26E@cale.checkpoint.com> <199807192234.BAA19071@torni.ssh.fi> <35B2F412.D093475@cale.checkpoint.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 22 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Moshe Litvin writes: > > > When dealing with remote users (with no fixed IP) the server has to > > > remember some dynamic data to be able to do isakmp (it at least has to > > > know that there is a remote user at that IP, it will probably want to > > > know who is the user (perhaps that user is not permited to work at those > > > hours so there is no need to waste effort on negotiation). In some case > > > it will do some sort of NAT, so it will have to remember also this. > > That information is usually stored in the ipsec SA and the ISAKMP SA > > doesn't need to store that information. > This a strange implementation choice, you may have a lot of IPSEC SA's > Simultaneously, and they will change all the time. Why do you want to > copy all that information to every separate IPSEC SA (especially since > you are so concerned about resource shortage). That information must be inside the IPsec SA. It must know ip address of the remote node, it is not interested in who the user, and it it doesn't need to store that information. On the other hand isakmp doesn't need to store anything about the IPsec SA after it has been initialized and it can throw away all information about ISAKMP SA and IPsec SA after it has installed IPsec SA to the IPsec engine. If the ISAKMP module runs out of the memory it can safely throw away everything that is not in the middle of the negotiation, and it doesn't cause any more trouble than that we might have to renegotiate the ISAKMP SA later. Note, that for example the ISAKMP SA information stored in the ISAKMP SA can be quite large, for example if you are using blowfish encryption the encryption context is 4 kB. The IPsec must store the protocol, spi, dst-addr, and algorithm context (esp, ah, replay). New normal isakmp negotiation can be started by the server by just one information the destionation-address, everything else will be received from the isakmp negotiation itself. So when the IPsec SA expires, it only needs to send message to isakmp module saying that it wants to have new IPsec SA with this destination host and the ISAKMP module will then check if it already has an ISAKMP SA with that host and if not it will start main mode. ISAKMP module doesn't have to store anything about the remote users. > The problem of rekeying is a direct consequences of the asymmetrical > nature of the hybrid mode. The asymmetrical nature gives the ability to > harness the powers of public key cryptography without using a full blown > PKI, but there is such thing as free lunch. However implementations that > are aware of that problem can solve it quite easily. If you create your own exchange for hybrid mode, you can also fix this. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Mon Jul 20 10:03:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA03625 for ipsec-outgoing; Mon, 20 Jul 1998 10:02:05 -0400 (EDT) Date: Sun, 19 Jul 1998 16:29:28 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199807192029.QAA01674@earth.hpc.org> To: kent@bbn.com Cc: mat@ca.mew.com, ipsec@tis.com In-reply-to: Yourmessage <199807152138.OAA16972@baskerville.CS.Arizona.EDU> Subject: Re: Patent & licence for IPSec ? Sender: owner-ipsec@ex.tis.com Precedence: bulk > At this time are not aware of any intellectual property issues with the > base IPsec protocols and algorithms, or with IKE use of D-H. Use of RSA > for certificate signatures, or use of ECC for key exchange does involve > patent issues. ECC over F[2^p] for DH key exchange does not infringe on intellectual property. Hilarie From owner-ipsec Mon Jul 20 19:16:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05341 for ipsec-outgoing; Mon, 20 Jul 1998 19:14:39 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Paul Lambert" To: ho@earth.hpc.org (Hilarie Orman) cc: kent@bbn.com, ipsec@tis.com Message-ID: <88256647.00805309.00@domino2.certicom.com> Date: Mon, 20 Jul 1998 16:25:34 -0700 Subject: Re: Patent & licence for IPSec ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, I assume that your note below indicates that you personally do not have any patents filed or patents issued related to IPsec. >> At this time are not aware of any intellectual property issues with the >> base IPsec protocols and algorithms, or with IKE use of D-H. Use of RSA >> for certificate signatures, or use of ECC for key exchange does involve >> patent issues. > >ECC over F[2^p] for DH key exchange does not infringe on intellectual >property. > >Hilarie Certicom has pending patents that cover secure and efficient implementations of Elliptic Curve Cryptography (ECC) over both F[2^m] and F[p]. Some of the pending patents for secure implementations of public key technologies may also cover implementations of the current mandatory portions of IKE in IPsec. A statement of our non-exclusive and nondiscriminatory patent licensing is available at: http://grouper.ieee.org/groups/1363/letters/Certicom.txt The pending patents include some mechanisms to provide more efficient processing of ECC based on F[2^m] with "m" being composite. Note that our cryptographic research group invested considerable effort in composite techniques some years ago. They are now only advocating the use of "m" prime based on security considerations. Note that Certicom has more patents pending on F[2^m] with m composite than for F[2^m] prime. As we have discussed on this list before, it is strongly recommended that the IPsec use of ECC not support composite 2^m, but rather use only prime 2^m curves. This would provide much better security and would incorporate less potential IPR from Certicom Regards, Paul A. Lambert VP. Product Management Certicom Corporation San Mateo California +1-650-312-7996 From owner-ipsec Mon Jul 20 21:16:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA05731 for ipsec-outgoing; Mon, 20 Jul 1998 21:14:39 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199807192234.BAA19071@torni.ssh.fi> References: <35B232C7.DDF0D26E@cale.checkpoint.com> <35AE6E72.58638F86@redcreek.com> <35b35d0e.66438486@cale.checkpoint.com> <199807171815.VAA12705@torni.ssh.fi> <35B232C7.DDF0D26E@cale.checkpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jul 1998 17:17:48 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: Hybrid Authentication and Remote Access Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Tero, >Because the signatures only authenticate the machine, not the user. >For example we might have several general use machines around, with >each one having separate private key, and when someone logs in from >that, it only says that ok, this is this pc-55.xxx.com, but it doesn't >say anything about who he is and does he have permission to create >ipsec SA. That's not necessarily true. IPsec supports individual authentication, e.g., a DN or an RFC 822 address, not just device authentication. For laptops or single-user hosts, this is just as valid a form of individual authentication as one might provide via Radius, and it is of higher quality that one would get from a password. When user auth is proxied by a security gateway one might augue for separate user auth from the end system, but since the SA terminates at the SG, it would not seem appropriate to make such authentication a funciton of IPsec or ISAKMP. Steve From owner-ipsec Mon Jul 20 21:16:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA05759 for ipsec-outgoing; Mon, 20 Jul 1998 21:16:39 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199807201208.PAA26086@torni.ssh.fi> References: <35B2F412.D093475@cale.checkpoint.com> <35AE6E72.58638F86@redcreek.com> <35b35d0e.66438486@cale.checkpoint.com> <199807171815.VAA12705@torni.ssh.fi> <35B232C7.DDF0D26E@cale.checkpoint.com> <199807192234.BAA19071@torni.ssh.fi> <35B2F412.D093475@cale.checkpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jul 1998 18:01:35 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: Hybrid Authentication and Remote Access Cc: Moshe Litvin , "Scott G. Kelly" , Vipul Gupta , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Tero, >Moshe Litvin writes: >> > > When dealing with remote users (with no fixed IP) the server has to >> > > remember some dynamic data to be able to do isakmp (it at least has to >> > > know that there is a remote user at that IP, it will probably want to >> > > know who is the user (perhaps that user is not permited to work at those >> > > hours so there is no need to waste effort on negotiation). In some case >> > > it will do some sort of NAT, so it will have to remember also this. >> > That information is usually stored in the ipsec SA and the ISAKMP SA >> > doesn't need to store that information. >> This a strange implementation choice, you may have a lot of IPSEC SA's >> Simultaneously, and they will change all the time. Why do you want to >> copy all that information to every separate IPSEC SA (especially since >> you are so concerned about resource shortage). > >That information must be inside the IPsec SA. It must know ip address >of the remote node, it is not interested in who the user, and it it >doesn't need to store that information. On the other hand isakmp >doesn't need to store anything about the IPsec SA after it has been >initialized and it can throw away all information about ISAKMP SA and >IPsec SA after it has installed IPsec SA to the IPsec engine. Well, not exactly. The reuqirement to check packets against the selectors for an SA do reuqire that the implementation maintain some data with each SA. >Note, that for example the ISAKMP SA information stored in the ISAKMP >SA can be quite large, for example if you are using blowfish >encryption the encryption context is 4 kB. Maybe a good reaosn not to use that algorithm :-). >The IPsec must store the protocol, spi, dst-addr, and algorithm >context (esp, ah, replay). New normal isakmp negotiation can be >started by the server by just one information the >destionation-address, everything else will be received from the isakmp >negotiation itself. So when the IPsec SA expires, it only needs to >send message to isakmp module saying that it wants to have new IPsec >SA with this destination host and the ISAKMP module will then check if >it already has an ISAKMP SA with that host and if not it will start main mode. See my comments above about the additional selector data that must be maintained in some fashion for each SA. Steve From owner-ipsec Tue Jul 21 04:29:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA06750 for ipsec-outgoing; Tue, 21 Jul 1998 04:25:40 -0400 (EDT) Message-ID: <35B4533D.447A6074@cale.checkpoint.com> Date: Tue, 21 Jul 1998 11:37:17 +0300 From: Moshe Litvin X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "W. Douglas Maughan" , ipsec@tis.com Subject: Re: ISAKMP Draft 10 References: <9807190003.AA06900@dolphin.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk W. Douglas Maughan wrote: > > Sumit, > > > The General Message Processing section of draft 10 (section 5.1) has the > > following regarding how an implementation is supposed to set the > > retransmission timer: > > NOTE: Implementations MUST NOT use a fixed timer. Instead, > > transmission timer values should be adjusted dynamically based on > > measured round trip times. In addition, successive retransmissions > > of the same packet should be separated by increasingly longer time > > intervals (e.g., exponential backoff). > > > > How and why has this been added to the draft? I don't recollect it being > > discussed on the mailing list. This is an implementation detail. The draft > > should only suggest a scheme, not make one a requirement. > > This was added to the ISAKMP-10 I-D because of Thomas Narten's IESG > vote. Basically, it was added so we can get the documents accepted to > RFC. The wording was exactly as he proposed it. As I see it, the text > as presented gives a suggested approach, i.e. dynamically adjusted > using exponential backoff. That is not part of the requirement. The > requirement is "MUST NOT use a fixed timer". > > On another note, I asked Ted to send the list of ISAKMP-10 changes to > the IPSEC list after the I-D was announced. I'm just returning from > vacation and I haven't seen it, so attached is a list of all changes > made to the ISAKMP-10 Internet Draft. > > Regards, > > Doug Maughan > Measuring round trip time has little meaning in ISAKMP. The time to process every ISAKMP packet can vary allot, for example in main mode with signatures, it can be very quick to answer the first message, two answer the third message may require to generate a DH key, which is a longer operation (but implementation may start to compute it after the answer to the 2nd message and have it ready). Then when it comes to answer the 5th message it must do RSA computation, it may need to look at LDAP servers for CRLs, maybe several levels of CRL, it can be quite a long operation. Implementation that will try to estimate the expected return from the measured round trip times in the same negotiation will be way off. I suggest to, at least, replace "measured round trip times" with "expected return time". Moshe -- ----------------------------------------------------------------------- Moshe Litvin Check Point Software Technologies Ltd. moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555) Fax: +972-3-575-9256 ----------------------------------------------------------------------- From owner-ipsec Tue Jul 21 11:44:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08043 for ipsec-outgoing; Tue, 21 Jul 1998 11:41:54 -0400 (EDT) Message-ID: <004a01bdb4bf$ec465f30$030b0ac0@cta1> From: "Todd S. Glassey" To: "Hilarie Orman" Cc: , Subject: Re: Patent & licence for IPSec ? Date: Tue, 21 Jul 1998 08:54:58 -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.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hillary, I have been listening/reading this thread for a bit now and this is really important material to deal with as far as basing any deliverables on these technologies and the legal impacts thereof - It seems to me that to date, this thread has been about the "lay understanding" of the IPSec process and while that may be accurate I personally would feel better if there was a corporate counsel from one of the players - maybe Cisco or IBM that agrees with these general responses. Maybe that would be willing to issue and opinion. Few companies, especially the smaller EC startups, could survive an all-out damages effort from one of the big players and so this is actually really important to their adoption of the IPSec standards. Just my two-cents - Todd -----Original Message----- From: Hilarie Orman To: kent@bbn.com Cc: mat@ca.mew.com ; ipsec@tis.com Date: Monday, July 20, 1998 7:36 AM Subject: Re: Patent & licence for IPSec ? >> At this time are not aware of any intellectual property issues with the >> base IPsec protocols and algorithms, or with IKE use of D-H. Use of RSA >> for certificate signatures, or use of ECC for key exchange does involve >> patent issues. > >ECC over F[2^p] for DH key exchange does not infringe on intellectual >property. > >Hilarie > From owner-ipsec Tue Jul 21 12:08:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA08199 for ipsec-outgoing; Tue, 21 Jul 1998 12:07:49 -0400 (EDT) Message-Id: <199807211623.JAA08235@greatdane.cisco.com> To: "Todd S. Glassey" cc: ipsec@tis.com Subject: Re: Patent & licence for IPSec ? In-reply-to: Your message of "Tue, 21 Jul 1998 08:54:58 PDT." <004a01bdb4bf$ec465f30$030b0ac0@cta1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Jul 1998 09:23:58 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk You're asking for cisco or IBM to give you free legal advice. I don't think that's gonna happen. If you want a professional legal opinion ask a legal professional and be prepared to pay (and it'll be more than the 2 cents you contributed already :-). Dan. On Tue, 21 Jul 1998 08:54:58 PDT you wrote > Hillary, > I have been listening/reading this thread for a bit now and this is really > important material to deal with as far as basing any deliverables on these > technologies and the legal impacts thereof - It seems to me that to date, > this thread has been about the "lay understanding" of the IPSec process and > while that may be accurate I personally would feel better if there was a > corporate counsel from one of the players - maybe Cisco or IBM that agrees > with these general responses. Maybe that would be willing to issue and > opinion. > > Few companies, especially the smaller EC startups, could survive an all-out > damages effort from one of the big players and so this is actually really > important to their adoption of the IPSec standards. > > > Just my two-cents - > Todd > > -----Original Message----- > From: Hilarie Orman > To: kent@bbn.com > Cc: mat@ca.mew.com ; ipsec@tis.com > Date: Monday, July 20, 1998 7:36 AM > Subject: Re: Patent & licence for IPSec ? > > > >> At this time are not aware of any intellectual property issues with the > >> base IPsec protocols and algorithms, or with IKE use of D-H. Use of > RSA > >> for certificate signatures, or use of ECC for key exchange does involve > >> patent issues. > > > >ECC over F[2^p] for DH key exchange does not infringe on intellectual > >property. > > > >Hilarie > > > From owner-ipsec Tue Jul 21 13:17:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08619 for ipsec-outgoing; Tue, 21 Jul 1998 13:15:56 -0400 (EDT) Message-ID: <014e01bdb4cc$fdd16ad0$030b0ac0@cta1> From: "Todd S. Glassey" To: "Daniel Harkins" Cc: Subject: Re: Patent & licence for IPSec ? Date: Tue, 21 Jul 1998 10:28:29 -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.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel, what did I miss here, what I am looking for is some way of knowing that some other patent holder won't sue my company for infringing on any existing IPSec patents. That involves two processes, the first: disclosure, and the second: patent licensing/use authorization. If the IETF cannot make the use of it's standards more than a crap shoot then it may be doomed. What's the point of banking on a set of standards where the entry fee can be years in court and millions of dollars. This is a serious issue, because it gets at the standards process and the root of who pays for all our playpens and sandboxes. Whether we as engineers like it or not, Business and Business Process are driving the NII and all it stands fo'. Sorry to disagree with you but ... If the IETF cannot make its standards more secure from a commercial sense then its long term form and fashion are likely to change or to be changed. The first time somebody sues the IETF/IESG/ISOC for creating a standard and allowing the standard-process to complete when it has either "direct knowledge" or "enforced ignorance" as to the patent status of any given effort - The standards effort will change forever. After all if the IETF knowingly ignores the charter and in particular the IP issues inside of RFC2026 and its follow successors, IMHO - the IETF could wind up liable for damages by not enforcing its publicly stated operational processes and policies. This is pretty serious stuff since most of us are betting our companies livelihood on these technologies or derivatives thereof. Here's another two cents for the pile and that making my contribution 4 all told - Can I buy any legal time for this? Todd -----Original Message----- From: Daniel Harkins To: Todd S. Glassey Cc: ipsec@tis.com Date: Tuesday, July 21, 1998 9:23 AM Subject: Re: Patent & licence for IPSec ? > You're asking for cisco or IBM to give you free legal advice. I don't >think that's gonna happen. If you want a professional legal opinion ask >a legal professional and be prepared to pay (and it'll be more than the >2 cents you contributed already :-). > > Dan. > >On Tue, 21 Jul 1998 08:54:58 PDT you wrote >> Hillary, >> I have been listening/reading this thread for a bit now and this is really >> important material to deal with as far as basing any deliverables on these >> technologies and the legal impacts thereof - It seems to me that to date, >> this thread has been about the "lay understanding" of the IPSec process and >> while that may be accurate I personally would feel better if there was a >> corporate counsel from one of the players - maybe Cisco or IBM that agrees >> with these general responses. Maybe that would be willing to issue and >> opinion. >> >> Few companies, especially the smaller EC startups, could survive an all-out >> damages effort from one of the big players and so this is actually really >> important to their adoption of the IPSec standards. >> >> >> Just my two-cents - >> Todd >> >> -----Original Message----- >> From: Hilarie Orman >> To: kent@bbn.com >> Cc: mat@ca.mew.com ; ipsec@tis.com >> Date: Monday, July 20, 1998 7:36 AM >> Subject: Re: Patent & licence for IPSec ? >> >> >> >> At this time are not aware of any intellectual property issues with the >> >> base IPsec protocols and algorithms, or with IKE use of D-H. Use of >> RSA >> >> for certificate signatures, or use of ECC for key exchange does involve >> >> patent issues. >> > >> >ECC over F[2^p] for DH key exchange does not infringe on intellectual >> >property. >> > >> >Hilarie >> > >> > From owner-ipsec Tue Jul 21 13:33:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08715 for ipsec-outgoing; Tue, 21 Jul 1998 13:33:00 -0400 (EDT) Message-Id: <199807211746.NAA18777@postal.research.att.com> To: "Todd S. Glassey" cc: "Daniel Harkins" , ipsec@tis.com Subject: Re: Patent & licence for IPSec ? Date: Tue, 21 Jul 1998 13:46:10 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <014e01bdb4cc$fdd16ad0$030b0ac0@cta1>, "Todd S. Glassey" writes: > > If the IETF cannot make the use of it's standards more than a crap shoot > then it may be doomed. What's the point of banking on a set of standards > where the entry fee can be years in court and millions of dollars. > > This is a serious issue, because it gets at the standards process and the > root of who pays for all our playpens and sandboxes. Whether we as engineers > like it or not, Business and Business Process are driving the NII and all it > stands fo'. > > Sorry to disagree with you but ... If the IETF cannot make its standards > more secure from a commercial sense then its long term form and fashion are > likely to change or to be changed. > > The first time somebody sues the IETF/IESG/ISOC for creating a standard and > allowing the standard-process to complete when it has either "direct > knowledge" or "enforced ignorance" as to the patent status of any given > effort - The standards effort will change forever. After all if the IETF > knowingly ignores the charter and in particular the IP issues inside of > RFC2026 and its follow successors, IMHO - the IETF could wind up liable for > damages by not enforcing its publicly stated operational processes and > policies. Have you read RFC 2026, the current description of the IETF standards process? While it's certainly true that anyone can be sued for more or less anything, the relevant provisions were indeed drawn up in consultation with a lawyer. Briefly -- the IETF *can't* have complete knowledge of intellectual property claims on its work. (Nor, I might add, can other standards bodies.) What is done is to require that anyone who submits anything to the IETF agrees to disclose any intellectual property rights in the submitted material. We also encourage people to make the IETF aware of any possible conflicts. This is precisely what Paul Lambert has just done. Btw -- not complying with the IETF process has reprecussions for folks who lie about patents. See http://www.ftc.gov/opa/9511/dell.htm for one example. From owner-ipsec Tue Jul 21 15:56:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09375 for ipsec-outgoing; Tue, 21 Jul 1998 15:55:21 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807212012.NAA07586@kc.livingston.com> Subject: Comments on "Hybrid Auth. mode for IKE" To: moshe@checkpoint.com Date: Tue, 21 Jul 1998 13:12:17 -0700 (PDT) Cc: ipsec@tis.com, suresh@livingston.com (Pyda Srisuresh) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Moshe, Thanks for initiating the discussion on the subject. Your draft is timely and goes right to the point of addressing remote user requirements. I have also been following the thread of comments from Tero, Bryan, Scott and others on the draft. Below is a summary of my thoughts on the draft. 1. The ID payload is not good enough for remote access user authentication. What we need is new type(s) of ISAKMP payload(s) - something like ID_EXCHANGE_INITIATE, ID_EXCHANGE_IN_PROGRESS and ID_EXCHANGE_COMPLETE. (There may be variations to the ID_EXCHANGE types, like challenge/response, token card, OTP etc..) This new exchange type of authentication begins when the user sends in the ID_EXCHANGE_INITIATE with his/her username. The exchange ends when the edge device grants authentication or denies authentication with ID_EXCHANGE_COMPLETE payload. 2. The authentication mechanism outlined in your draft is simpler and does away with the 2-level authentication approach (once with IKE negotiator device and once with the actual remote user) in the XAUTH draft. However, I do think that NOTIFY is not the right type of payload to do that, because NOTIFY is a one-way error notification type payload. 3. The authentication mechanisms suggested are asymmetrical between edge device and remote user. Edge device is authenticated with a public key, whereas remote user is authenticated with token card and CHAP(Challeng/Response) mechasims. However, it doesnt have to be that way. If desired, the remote user could run the same token card/CHAP mechanisms to authenticate the edge device. 4. SA lifetime: The current metrics of "time-bound" and "Data-bound" for an SA lifetime do not seem adequate for remote access users. I would like to see a new metric like "network-connected-time" for SA lifetime. This new metric may be used in conjunction with other metrics (if the crypto algorithms mandate such a limiting criteria) or by itself. Keeping an SA valid for the lifetime of network connection, makes the administratve overhead on remote user and edge device simpler. I can see this new metric being valuable even in GW-GW type VPN connections. (SA rekeying is a lot of overhead and has lots of scope for confusion and inconsistencies between vendors). 5. Rekeying of ISAKMP SA: ISAKMP SAs (on client and server ends) neednt be kept forever while the session SAs are alive. ISAKMP SAs can be short lived, unless either end wants to use the ISAKMP SA for periodic authentication or session SA rekeying. In the case where an adge device or remote user has to use the ISAKMP SA to talk to the other end, and finds that the ISAKMP SA is missing (or lost in bit bucket), I think, it is reasonable for the device to simply retire all the session SAs(created using the lost ISAKMP SA), send an ICMP error message to the other end and drop the network connection. At such a time, the remote user could reinitate the conection to edge device. Thats all for now. Have a nice day. cheers, suresh From owner-ipsec Tue Jul 21 22:35:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA10546 for ipsec-outgoing; Tue, 21 Jul 1998 22:29:43 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199807212012.NAA07586@kc.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Jul 1998 22:25:31 -0400 To: suresh@livingston.com (Pyda Srisuresh) From: Stephen Kent Subject: Re: Comments on "Hybrid Auth. mode for IKE" Cc: moshe@checkpoint.com, ipsec@tis.com, suresh@livingston.com (Pyda Srisuresh) Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda, > 1. The ID payload is not good enough for remote access user > authentication. What we need is new type(s) of ISAKMP > payload(s) - something like ID_EXCHANGE_INITIATE, > ID_EXCHANGE_IN_PROGRESS and ID_EXCHANGE_COMPLETE. > (There may be variations to the ID_EXCHANGE types, > like challenge/response, token card, OTP etc..) This assertion needs to be justified. Perhaps the argument is support of legacy auth systems, but it certainly is not security. We can do a better job of user auth with certs than any of these other approaches. The certs (and associated crypto processing) could be in a personal token, not just in software, thus providing very high quality user auth. Also, one might argue that IPsec provides an impetus to switch away from transient user auth, to continuous user auth, from passwords to keys, etc. That's why I think this first premise needs to be much better justified than what I've seen so far. > 3. The authentication mechanisms suggested are asymmetrical between > edge device and remote user. Edge device is authenticated with > a public key, whereas remote user is authenticated with token card > and CHAP(Challeng/Response) mechasims. Why? I'd much rather use a cert for user auth, as provided in SSL with client certs, than these other mechanisms. Again, you need to justify this assertion. > However, it doesnt have to be that way. If desired, the remote > user could run the same token card/CHAP mechanisms to authenticate > the edge device. That's definately a step down in security! Why even suggest this? > 4. SA lifetime: > > The current metrics of "time-bound" and "Data-bound" for an > SA lifetime do not seem adequate for remote access users. > I would like to see a new metric like "network-connected-time" > for SA lifetime. This new metric may be used in conjunction with > other metrics (if the crypto algorithms mandate such a limiting > criteria) or by itself. Why is not SA lifetime close enough to net sonnect time? Why is the latter metric preferable? > Keeping an SA valid for the lifetime of network connection, > makes the administratve overhead on remote user and edge device > simpler. I can see this new metric being valuable even in > GW-GW type VPN connections. (SA rekeying is a lot of overhead > and has lots of scope for confusion and inconsistencies between > vendors). See questions above. Steve From owner-ipsec Wed Jul 22 14:08:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13041 for ipsec-outgoing; Wed, 22 Jul 1998 14:01:43 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF2937DB@exchange.timestep.com> From: Roy Pereira To: Stephen Kent , suresh@livingston.com Cc: moshe@checkpoint.com, ipsec@tis.com, suresh@livingston.com, "Pat Calhoun (E-mail)" Subject: RE: Comments on "Hybrid Auth. mode for IKE" Date: Wed, 22 Jul 1998 14:16:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BDB59C.E7C67C00" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BDB59C.E7C67C00 Content-Type: text/plain FYI: A general common authentication protocol BOF is being planned for the Chicago IETF. The agenda is to discuss combining among others, the PPP EAP protocol and IPSec's XAUTH protocol, and producing an authentication mechanism that can be migrated to any environment. I would worry that we are trying to on-the-fly build a protocol thru email that would be better designed by teams dedicated to solving this problem. Besides most of these issues were already brought up on this mailing list previously when XAUTH was released and again when PPP EAP was introduced to the IPSec mailing list. > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Tuesday, July 21, 1998 10:26 PM > To: suresh@livingston.com > Cc: moshe@checkpoint.com; ipsec@tis.com; suresh@livingston.com > Subject: Re: Comments on "Hybrid Auth. mode for IKE" > > > Pyda, > > > 1. The ID payload is not good enough for remote access user > > authentication. What we need is new type(s) of ISAKMP > > payload(s) - something like ID_EXCHANGE_INITIATE, > > ID_EXCHANGE_IN_PROGRESS and ID_EXCHANGE_COMPLETE. > > (There may be variations to the ID_EXCHANGE types, > > like challenge/response, token card, OTP etc..) > > This assertion needs to be justified. Perhaps the argument > is support of > legacy auth systems, but it certainly is not security. We > can do a better > job of user auth with certs than any of these other > approaches. The certs > (and associated crypto processing) could be in a personal > token, not just > in software, thus providing very high quality user auth. > Also, one might > argue that IPsec provides an impetus to switch away from > transient user > auth, to continuous user auth, from passwords to keys, etc. > That's why I > think this first premise needs to be much better justified > than what I've > seen so far. > > > 3. The authentication mechanisms suggested are > asymmetrical between > > edge device and remote user. Edge device is authenticated with > > a public key, whereas remote user is authenticated > with token card > > and CHAP(Challeng/Response) mechasims. > > Why? I'd much rather use a cert for user auth, as provided > in SSL with > client certs, than these other mechanisms. Again, you need > to justify this > assertion. > > > However, it doesnt have to be that way. If desired, the remote > > user could run the same token card/CHAP mechanisms to > authenticate > > the edge device. > > That's definately a step down in security! Why even suggest this? > > > 4. SA lifetime: > > > > The current metrics of "time-bound" and "Data-bound" for an > > SA lifetime do not seem adequate for remote access users. > > I would like to see a new metric like "network-connected-time" > > for SA lifetime. This new metric may be used in > conjunction with > > other metrics (if the crypto algorithms mandate such > a limiting > > criteria) or by itself. > > Why is not SA lifetime close enough to net sonnect time? Why > is the latter > metric preferable? > > > Keeping an SA valid for the lifetime of network connection, > > makes the administratve overhead on remote user and > edge device > > simpler. I can see this new metric being valuable even in > > GW-GW type VPN connections. (SA rekeying is a lot of overhead > > and has lots of scope for confusion and > inconsistencies between > > vendors). > > See questions above. > > Steve > > > ------ =_NextPart_001_01BDB59C.E7C67C00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Comments on "Hybrid Auth. mode for IKE"

FYI: A general common authentication protocol BOF is = being planned for the Chicago IETF.  The agenda is to discuss = combining among others, the PPP EAP protocol and IPSec's XAUTH = protocol, and producing an authentication mechanism that can be = migrated to any environment. 

I would worry that we are trying to on-the-fly build = a protocol thru email that would be better designed by teams dedicated = to solving this problem.  Besides most of these issues were = already brought up on this mailing list previously when XAUTH was = released and again when PPP EAP was introduced to the IPSec mailing = list.

> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Tuesday, July 21, 1998 10:26 PM
> To: suresh@livingston.com
> Cc: moshe@checkpoint.com; ipsec@tis.com; = suresh@livingston.com
> Subject: Re: Comments on "Hybrid Auth. = mode for IKE"
>
>
> Pyda,
>
> >    1. The ID payload is not = good enough for remote access user
> >       = authentication. What we need is new type(s) of ISAKMP
> >       = payload(s) - something like ID_EXCHANGE_INITIATE,
> >       = ID_EXCHANGE_IN_PROGRESS and ID_EXCHANGE_COMPLETE.
> >       (There = may be variations to the ID_EXCHANGE types,
> >        = like challenge/response, token card, OTP etc..)
>
> This assertion needs to be justified.  = Perhaps the argument
> is support of
> legacy auth systems, but it certainly is not = security.  We
> can do a better
> job of user auth with certs than any of these = other
> approaches.  The certs
> (and associated crypto processing) could be in = a personal
> token, not just
> in software, thus providing very high quality = user auth. 
> Also, one might
> argue that IPsec provides an impetus to switch = away from
> transient user
> auth, to continuous user auth, from passwords = to keys, etc. 
> That's why I
> think this first premise needs to be much = better justified
> than what I've
> seen so far.
>
> >    3. The authentication = mechanisms suggested are
> asymmetrical between
> >       edge = device and remote user. Edge device is authenticated with
> >       a = public key, whereas remote user is authenticated
> with token card
> >       and = CHAP(Challeng/Response) mechasims.
>
> Why?  I'd much rather use a cert for user = auth, as provided
> in SSL with
> client certs, than these other = mechanisms.  Again, you need
> to justify this
> assertion.
>
> >       = However, it doesnt have to be that way. If desired, the remote
> >       user = could run the same token card/CHAP mechanisms to
> authenticate
> >       the = edge device.
>
> That's definately a step down in = security!  Why even suggest this?
>
> >    4. SA lifetime:
> >
> >       The = current  metrics of "time-bound" and = "Data-bound" for an
> >       SA = lifetime do not seem adequate for remote access users.
> >       I = would like to see a new metric like = "network-connected-time"
> >       for SA = lifetime. This new metric may be used in
> conjunction with
> >       other = metrics (if the crypto algorithms mandate such
> a limiting
> >       = criteria) or by itself.
>
> Why is not SA lifetime close enough to net = sonnect time?  Why
> is the latter
> metric preferable?
>
> >       = Keeping an SA valid for the lifetime of network connection,
> >       makes = the administratve overhead on remote user and
> edge device
> >       = simpler. I can see this new metric being valuable even in
> >       GW-GW = type VPN connections. (SA rekeying is a lot of overhead
> >       and = has lots of scope for confusion and
> inconsistencies between
> >       = vendors).
>
> See questions above.
>
> Steve
>
>
>

------ =_NextPart_001_01BDB59C.E7C67C00-- From owner-ipsec Wed Jul 22 15:02:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13223 for ipsec-outgoing; Wed, 22 Jul 1998 15:01:43 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807221918.MAA29865@kc.livingston.com> Subject: Re: Comments on "Hybrid Auth. mode for IKE" To: kent@bbn.com (Stephen Kent) Date: Wed, 22 Jul 1998 12:18:49 -0700 (PDT) Cc: suresh@livingston.com, moshe@checkpoint.com, ipsec@tis.com In-Reply-To: from "Stephen Kent" at Jul 21, 98 10:25:31 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Pyda, > > > 1. The ID payload is not good enough for remote access user > > authentication. What we need is new type(s) of ISAKMP > > payload(s) - something like ID_EXCHANGE_INITIATE, > > ID_EXCHANGE_IN_PROGRESS and ID_EXCHANGE_COMPLETE. > > (There may be variations to the ID_EXCHANGE types, > > like challenge/response, token card, OTP etc..) > > This assertion needs to be justified. Perhaps the argument is support of > legacy auth systems, but it certainly is not security. We can do a better > job of user auth with certs than any of these other approaches. The certs > (and associated crypto processing) could be in a personal token, not just > in software, thus providing very high quality user auth. Also, one might > argue that IPsec provides an impetus to switch away from transient user > auth, to continuous user auth, from passwords to keys, etc. That's why I > think this first premise needs to be much better justified than what I've > seen so far. > First, the authentication info in the main mode is encrypted. The actual authentication mechanism is not indicative of the type of security that would be allowed for session SAs or the ISAKMP SA encryption. Note, pre-shared key is a valid auth. mechanism. It is up to the negotiating peers to determine the level of authentication they like to enforce. The drafts cannot mandate this, only offer viable solution options. Secondly, I would think, exchange mode of authentication is generally speaking more robust than a one-time ID authentication. Exchange mode allows either party to probe beyond a single notification. For example, it allows multiple forms of authentication (i.e., increasingly strong levels of authentication, if you desire). Above all, exchange mode of authentication does meet the legacy auth. requirements. Lastly, certificate based authentication you suggests requires a vast deployment of CA infrastructure, which is not in place yet. Many of the ISP consortiums have to go with what is commonly available as opposed to what a single enterprise or a limited no. of ISPs have. Would you rather that remote access applications not utilize the benefits of IPsec until the certificate deployment is common place? I would think not. > > 3. The authentication mechanisms suggested are asymmetrical between > > edge device and remote user. Edge device is authenticated with > > a public key, whereas remote user is authenticated with token card > > and CHAP(Challeng/Response) mechasims. > > Why? I'd much rather use a cert for user auth, as provided in SSL with > client certs, than these other mechanisms. Again, you need to justify this > assertion. > Please see my comments above. > > However, it doesnt have to be that way. If desired, the remote > > user could run the same token card/CHAP mechanisms to authenticate > > the edge device. > > That's definately a step down in security! Why even suggest this? Well, not really. It is just an extension of the authentication mechanism to both parties. > > > 4. SA lifetime: > > > > The current metrics of "time-bound" and "Data-bound" for an > > SA lifetime do not seem adequate for remote access users. > > I would like to see a new metric like "network-connected-time" > > for SA lifetime. This new metric may be used in conjunction with > > other metrics (if the crypto algorithms mandate such a limiting > > criteria) or by itself. > > Why is not SA lifetime close enough to net sonnect time? Why is the latter > metric preferable? > How would you pick a close enough metric? Could be quite arbitrary. A user may have no way to know ahead of time, how long his/her sessions are going to have to be kept alive or how much data he/she is going to be exchanging. If these metrics are to be set infinitely large, then that defeats the purpose to start with. Most often than not, a user is likely to want to keep the negotiated security parameters unchanged throughout the connected time. > > Keeping an SA valid for the lifetime of network connection, > > makes the administratve overhead on remote user and edge device > > simpler. I can see this new metric being valuable even in > > GW-GW type VPN connections. (SA rekeying is a lot of overhead > > and has lots of scope for confusion and inconsistencies between > > vendors). > > See questions above. > > Steve > > cheers, suresh From owner-ipsec Wed Jul 22 15:20:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13287 for ipsec-outgoing; Wed, 22 Jul 1998 15:18:46 -0400 (EDT) Date: Wed, 22 Jul 1998 15:33:00 -0700 X-Priority: 3 From: "Goss, Chad" Subject: Examples? To: ipsec@tis.com Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8Bit Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk Can someone point me to a location where I can find samples(hex dumps) of a complete IKE Exchange, Phase I Agressive Mode? Would these be available, or is it easier just to run some of the reference code that exists. thanks in advance -chad ***************************************************************************** Chad Goss 978-287-6288 Senior Software Engineer chad.goss@tccmail.fabrik.com Technical Communications Corporation 100 Domino Drive, Concord Ma. 01742 ***************************************************************************** From owner-ipsec Wed Jul 22 18:46:17 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA13884 for ipsec-outgoing; Wed, 22 Jul 1998 18:42:50 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF2937DB@exchange.timestep.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Jul 1998 18:08:46 -0400 To: Roy Pereira From: Stephen Kent Subject: RE: Comments on "Hybrid Auth. mode for IKE" Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, I don't mean to suggest that we should engineer on the fly. However, I do object to statements justifying XAUTH design features based on purported shortcomings of IKE and thye general IPsec authentication model. If folks make such comments and they're not substantiated (or just wrong), I think it apprppriate to comment on that in the context of this mailing list. Do you disagree/ Steve From owner-ipsec Wed Jul 22 18:48:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA13898 for ipsec-outgoing; Wed, 22 Jul 1998 18:46:49 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199807221918.MAA29865@kc.livingston.com> References: from "Stephen Kent" at Jul 21, 98 10:25:31 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Jul 1998 18:57:36 -0400 To: suresh@livingston.com (Pyda Srisuresh) From: Stephen Kent Subject: Re: Comments on "Hybrid Auth. mode for IKE" Cc: suresh@livingston.com, moshe@checkpoint.com, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Suresh, >Secondly, I would think, exchange mode of authentication is generally >speaking more robust than a one-time ID authentication. Exchange mode >allows either party to probe beyond a single notification. For example, >it allows multiple forms of authentication (i.e., increasingly strong >levels of authentication, if you desire). Above all, exchange mode >of authentication does meet the legacy auth. requirements. I don't agree. Once an IKE exhange has been performed using certs, all subsequent client traffic is cryptographically protected using keying material that has been bound to the user in question (if we are providing user-granularity keying) and authenticated by the cert processing. The suggestion is often made that a protocol that allows for subsequent re-auth is "more secure," but that is true only under certain curstances. If the communication path were not continuousluy authenticated, this argument has some merit, but that's not the case for IPsec. If the re-auth requires additional user involvement, all of my marketing folks tell me it's unacceptable, and, as a user, I agree with them! This is the era of single sign on, not extra sign on. Finally, if the re-auth is automatic, then I'd argue that it is no better than the continuous auth being probvided by IPsec. We also must compare apples and organges. Using hardware for key management with IKE should be better than using a software-based OTP system, or even a token like SecurID. Arguments about using a hardware token for user auth but not for IKE are mushier. >Lastly, certificate based authentication you suggests requires a vast >deployment of CA infrastructure, which is not in place yet. Many of the >ISP consortiums have to go with what is commonly available as opposed to >what a single enterprise or a limited no. of ISPs have. Would you rather >that remote access applications not utilize the benefits of IPsec until >the certificate deployment is common place? I would think not. Not true. I have personal experience establ;ishing PKIs that were derrived from name/password baselines. It can be done easily, especially for intranets and for closed user communities. Since I'm in the PKI business I may me accused of being biased ;-), but I also have some ammount of experience proving assertions of this sort to be false. >> > However, it doesnt have to be that way. If desired, the remote >> > user could run the same token card/CHAP mechanisms to authenticate >> > the edge device. >> >> That's definately a step down in security! Why even suggest this? > >Well, not really. It is just an extension of the authentication >mechanism to both parties. If we have authenticated end points using good keys associayted with certs, it's not at all clear that use of additional, weaker mechanisms adds to the strength of the system, while it certainly adds to the complexity of design and management! My clients want fewer user auth databases to manage, not more, and moving these databases to certs is the best approach from a security perspective, in most cases. >> >> > 4. SA lifetime: >> > >> > The current metrics of "time-bound" and "Data-bound" for an >> > SA lifetime do not seem adequate for remote access users. >> > I would like to see a new metric like "network-connected-time" >> > for SA lifetime. This new metric may be used in conjunction with >> > other metrics (if the crypto algorithms mandate such a limiting >> > criteria) or by itself. >> >> Why is not SA lifetime close enough to net sonnect time? Why is the latter >> metric preferable? >> > >How would you pick a close enough metric? Could be quite arbitrary. >A user may have no way to know ahead of time, how long his/her sessions >are going to have to be kept alive or how much data he/she is going >to be exchanging. If these metrics are to be set infinitely large, >then that defeats the purpose to start with. > >Most often than not, a user is likely to want to keep the negotiated >security parameters unchanged throughout the connected time. i don't understand your response. You origjnally suggested that net connect time was preferable to SA lifetime. For an individual user SA, these seem to be almost the same to me, so I asked how they bwere significantly different. Your response does not address that question. Steve From owner-ipsec Thu Jul 23 09:33:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA15783 for ipsec-outgoing; Thu, 23 Jul 1998 09:30:00 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01B14301@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Subject: ESP and AH used in tunnel mode by a Security Gateway Date: Thu, 23 Jul 1998 14:45:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I seem to remember asking this question before, but.... Although not covered in the IPSEC architecture, is there any restriction on a Security Gateway applying both ESP and AH in tunnel mode? Thanks, Steve. From owner-ipsec Thu Jul 23 09:36:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA15818 for ipsec-outgoing; Thu, 23 Jul 1998 09:36:00 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF293A07@exchange.timestep.com> From: Roy Pereira To: Stephen Kent Cc: ipsec@tis.com Subject: RE: Comments on "Hybrid Auth. mode for IKE" Date: Thu, 23 Jul 1998 09:51:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BDB640.F6A684A0" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BDB640.F6A684A0 Content-Type: text/plain Steve, I didn't make the statement that XAUTH was designed because IKE had shortcomings. It was designed to extend IKE to support (mostly) legacy authentication mechanisms. Most of these mechanisms are less secure than the authentication mechanisms that IKE support (X.509 certs), but nonetheless, these mechanisms are in demand. > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Wednesday, July 22, 1998 6:09 PM > To: Roy Pereira > Cc: ipsec@tis.com > Subject: RE: Comments on "Hybrid Auth. mode for IKE" > > > Roy, > > I don't mean to suggest that we should engineer on the fly. > However, I do > object to statements justifying XAUTH design features based > on purported > shortcomings of IKE and thye general IPsec authentication > model. If folks > make such comments and they're not substantiated (or just > wrong), I think > it apprppriate to comment on that in the context of this > mailing list. Do > you disagree/ > > Steve > > ------ =_NextPart_001_01BDB640.F6A684A0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Comments on "Hybrid Auth. mode for IKE"

Steve, I didn't make the statement that XAUTH was = designed because IKE had shortcomings.  It was designed to extend = IKE to support (mostly) legacy authentication mechanisms.  Most of = these mechanisms are less secure than the authentication mechanisms = that IKE support (X.509 certs), but nonetheless, these mechanisms are = in demand.



> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Wednesday, July 22, 1998 6:09 PM
> To: Roy Pereira
> Cc: ipsec@tis.com
> Subject: RE: Comments on "Hybrid Auth. = mode for IKE"
>
>
> Roy,
>
> I don't mean to suggest that we should engineer = on the fly. 
> However, I do
> object to statements justifying XAUTH design = features based
> on purported
> shortcomings of IKE and thye general IPsec = authentication
> model. If folks
> make such comments and they're not = substantiated (or just
> wrong), I think
> it apprppriate to comment on that in the = context of this
> mailing list.  Do
> you disagree/
>
> Steve
>
>

------ =_NextPart_001_01BDB640.F6A684A0-- From owner-ipsec Thu Jul 23 09:56:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA15898 for ipsec-outgoing; Thu, 23 Jul 1998 09:56:03 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF293A07@exchange.timestep.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jul 1998 10:11:19 -0400 To: Roy Pereira From: Stephen Kent Subject: RE: Comments on "Hybrid Auth. mode for IKE" Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy, The message I responded to did assert that these less secure mechanisms were a response to shortcomings in IKE and IPsec, so my response seems appropriate. The bissue you raise is one that I don't think the WG has decided, but one that can wait for IPsecond, i.e., should the security of IPsec be degraded to satisfy an apparent demand for use of less secure auth mechanisms. I would find it inconsistent with the general thrust of the Wg to do this. Note that we are now planning on upping the default encryption algorithm to triple DES, while the XAUTH approach would generally diminish security in the authentication dimension. Frankly, since most attacks exploit poor auth and/or management procedures, rather than cryptanalysis of intercepted ciphertext, the path proposed by XAUTH seems completely at odds with the general thrust of IPsec. Steve From owner-ipsec Thu Jul 23 10:38:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA16109 for ipsec-outgoing; Thu, 23 Jul 1998 10:36:05 -0400 (EDT) Message-ID: From: Greg Carter To: Stephen Kent , suresh@livingston.com, "'Roy Pereira'" Cc: moshe@checkpoint.com, ipsec@tis.com, suresh@livingston.com, "Pat Calhoun (E-mail)" Subject: RE: Comments on "Hybrid Auth. mode for IKE" Date: Thu, 23 Jul 1998 10:42:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id KAA16104 Sender: owner-ipsec@ex.tis.com Precedence: bulk EAP Introduced to ipsec ? :), I don't want to be there when PKIX meets SPKI... Anyway... When I thought of EAP-ISAKMP it was to increase security which was lacking in most of the other EAP mechanisms. Now it seems we want to hack ISAKMP to work with the 'lacking' EAP mechanisms, mostly token cards. Which come in two varieties, those based on DES, and those based on proprietary protocols. Putting aside the wisdom of DES and proprietary algorithms... The DES cards usually have a "Guess next Challenge" mode where they know what the next challenge will be based on the last. The proprietary card uses a time based scheme, and so at any moment in time you know the response, there is no challenge. You can take the response as the IKE shared secret. No Challenge is needed. Benefits - No changes to IKE. May increase security of DES based challenge/response cards since known plain text/cipher text never flows over the network. DES cards when used with protocols like RADIUS or TACACS do all the challenge/response in the open. $250K and 56-224 hours later you have the key. In this mode DES is combined with key hashes and no known text is transmitted over the network. Supports DES cards, Time based cards (OK they'll have to write some code on their server to give up the expected response based on ID, rather than a simple yes/no response, but nothing is for free), PAP/CHAP (no reason to do CHAP, just use the password as the secret... Drawbacks Aggressive mode is the only practical choice. Initialization and resync. Initialization is easily handled, resync is doable. Backend server will be needed to track card state. Not really a drawback, every card manufacture I know offers a backend management server of some sort which already does this. Since the backend server is now essentially a key server you should probably run IPSEC over the link from the Gateway to the server. Anyway my point is that it is doable with the current spec, no changes to token hardware, maybe a little coding on the server side. Sure there are some drawbacks but you want to use 1980's technology... Later. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > ---------- > From: Roy Pereira[SMTP:rpereira@TimeStep.com] > Sent: Wednesday, July 22, 1998 2:16 PM > To: Stephen Kent; suresh@livingston.com > Cc: moshe@checkpoint.com; ipsec@tis.com; suresh@livingston.com; Pat > Calhoun (E-mail) > Subject: RE: Comments on "Hybrid Auth. mode for IKE" > > FYI: A general common authentication protocol BOF is being planned for the > Chicago IETF.  The agenda is to discuss combining among others, the PPP > EAP protocol and IPSec's XAUTH protocol, and producing an authentication > mechanism that can be migrated to any environment.  > > I would worry that we are trying to on-the-fly build a protocol thru email > that would be better designed by teams dedicated to solving this problem.  > Besides most of these issues were already brought up on this mailing list > previously when XAUTH was released and again when PPP EAP was introduced > to the IPSec mailing list. > > > -----Original Message----- > > From: Stephen Kent [ mailto:kent@bbn.com] > > Sent: Tuesday, July 21, 1998 10:26 PM > > To: suresh@livingston.com > > Cc: moshe@checkpoint.com; ipsec@tis.com; suresh@livingston.com > > Subject: Re: Comments on "Hybrid Auth. mode for IKE" > > > > > > Pyda, > > > > >    1. The ID payload is not good enough for remote access user > > >       authentication. What we need is new type(s) of ISAKMP > > >       payload(s) - something like ID_EXCHANGE_INITIATE, > > >       ID_EXCHANGE_IN_PROGRESS and ID_EXCHANGE_COMPLETE. > > >       (There may be variations to the ID_EXCHANGE types, > > >        like challenge/response, token card, OTP etc..) > > > > This assertion needs to be justified.  Perhaps the argument > > is support of > > legacy auth systems, but it certainly is not security.  We > > can do a better > > job of user auth with certs than any of these other > > approaches.  The certs > > (and associated crypto processing) could be in a personal > > token, not just > > in software, thus providing very high quality user auth.  > > Also, one might > > argue that IPsec provides an impetus to switch away from > > transient user > > auth, to continuous user auth, from passwords to keys, etc.  > > That's why I > > think this first premise needs to be much better justified > > than what I've > > seen so far. > > > > >    3. The authentication mechanisms suggested are > > asymmetrical between > > >       edge device and remote user. Edge device is authenticated with > > >       a public key, whereas remote user is authenticated > > with token card > > >       and CHAP(Challeng/Response) mechasims. > > > > Why?  I'd much rather use a cert for user auth, as provided > > in SSL with > > client certs, than these other mechanisms.  Again, you need > > to justify this > > assertion. > > > > >       However, it doesnt have to be that way. If desired, the remote > > >       user could run the same token card/CHAP mechanisms to > > authenticate > > >       the edge device. > > > > That's definately a step down in security!  Why even suggest this? > > > > >    4. SA lifetime: > > > > > >       The current  metrics of "time-bound" and "Data-bound" for an > > >       SA lifetime do not seem adequate for remote access users. > > >       I would like to see a new metric like "network-connected-time" > > >       for SA lifetime. This new metric may be used in > > conjunction with > > >       other metrics (if the crypto algorithms mandate such > > a limiting > > >       criteria) or by itself. > > > > Why is not SA lifetime close enough to net sonnect time?  Why > > is the latter > > metric preferable? > > > > >       Keeping an SA valid for the lifetime of network connection, > > >       makes the administratve overhead on remote user and > > edge device > > >       simpler. I can see this new metric being valuable even in > > >       GW-GW type VPN connections. (SA rekeying is a lot of overhead > > >       and has lots of scope for confusion and > > inconsistencies between > > >       vendors). > > > > See questions above. > > > > Steve > > > > > > > > From owner-ipsec Thu Jul 23 10:54:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA16202 for ipsec-outgoing; Thu, 23 Jul 1998 10:53:03 -0400 (EDT) Date: Thu, 23 Jul 1998 08:05:03 -0700 From: Pat.Calhoun@Eng.Sun.Com (Patrice Calhoun) Message-Id: <199807231505.IAA01112@hsmpka.eng.sun.com> To: "Greg Carter" , "Stephen Kent" , suresh@livingston.com, "'Roy Pereira'" Cc: moshe@checkpoint.com, ipsec@tis.com, suresh@livingston.com, "Pat Calhoun (E-mail)" Reply-To: Pat.Calhoun@Eng.Sun.Com X-Mailer: Sun NetMail 2.1.6 Subject: RE: Comments on "Hybrid Auth. mode for IKE" Sender: owner-ipsec@ex.tis.com Precedence: bulk >EAP Introduced to ipsec ? :), I don't want to be there when PKIX meets >SPKI... You make it sounds like a bad movie :) > >Anyway... >When I thought of EAP-ISAKMP it was to increase security which was lacking >in most of the other EAP mechanisms. Now it seems we want to hack ISAKMP to >work with the 'lacking' EAP mechanisms, mostly token cards. Which come in >two varieties, those based on DES, and those based on proprietary protocols. >Putting aside the wisdom of DES and proprietary algorithms... > >The DES cards usually have a "Guess next Challenge" mode where they know >what the next challenge will be based on the last. The proprietary card >uses a time based scheme, and so at any moment in time you know the >response, there is no challenge. You can take the response as the IKE >shared secret. No Challenge is needed. EAP can support any authentication mechanism. It can be viewed as a way to tunnel an authentication protocol between two endpoints that may not have direct connectivity (which is normally true when a client is trying to gain access to the network). It seems that it would be desirable to have the same (or a similar) model for PPP, IKE, SOCKS and possibly other services such as IP Telephony. But I agree that the exchange must be secure. > >Benefits - >No changes to IKE. >May increase security of DES based challenge/response cards since known >plain text/cipher text never flows over the network. DES cards when used >with protocols like RADIUS or TACACS do all the challenge/response in the >open. $250K and 56-224 hours later you have the key. In this mode DES is >combined with key hashes and no known text is transmitted over the network. >Supports DES cards, Time based cards (OK they'll have to write some code on >their server to give up the expected response based on ID, rather than a >simple yes/no response, but nothing is for free), PAP/CHAP (no reason to do >CHAP, just use the password as the secret... Again, it just happens that *some* of the EAP proposal are based on DES. EAP could also support biometrics, TLS and a whole slew of other more secure schemes. EAP is not tied to DES in any way. And there is no reason that one cannot protect the RADIUS or TACACS session with IPSEC using strong crypto. > >Drawbacks >Aggressive mode is the only practical choice. >Initialization and resync. Initialization is easily handled, resync is >doable. >Backend server will be needed to track card state. Not really a drawback, >every card manufacture I know offers a backend management server of some >sort which already does this. Since the backend server is now essentially a >key server you should probably run IPSEC over the link from the Gateway to >the server. > >Anyway my point is that it is doable with the current spec, no changes to >token hardware, maybe a little coding on the server side. Sure there are >some drawbacks but you want to use 1980's technology... >Later. >---- >Greg Carter, Entrust Technologies >greg.carter@entrust.com > > >> ---------- >> From: Roy Pereira[SMTP:rpereira@TimeStep.com] >> Sent: Wednesday, July 22, 1998 2:16 PM >> To: Stephen Kent; suresh@livingston.com >> Cc: moshe@checkpoint.com; ipsec@tis.com; suresh@livingston.com; Pat >> Calhoun (E-mail) >> Subject: RE: Comments on "Hybrid Auth. mode for IKE" >> >> FYI: A general common authentication protocol BOF is being planned for the >> Chicago IETF.  The agenda is to discuss combining among others, the PPP >> EAP protocol and IPSec's XAUTH protocol, and producing an authentication >> mechanism that can be migrated to any environment.  >> >> I would worry that we are trying to on-the-fly build a protocol thru email >> that would be better designed by teams dedicated to solving this problem.  >> Besides most of these issues were already brought up on this mailing list >> previously when XAUTH was released and again when PPP EAP was introduced >> to the IPSec mailing list. >> >> > -----Original Message----- >> > From: Stephen Kent [ mailto:kent@bbn.com] >> > Sent: Tuesday, July 21, 1998 10:26 PM >> > To: suresh@livingston.com >> > Cc: moshe@checkpoint.com; ipsec@tis.com; suresh@livingston.com >> > Subject: Re: Comments on "Hybrid Auth. mode for IKE" >> > >> > >> > Pyda, >> > >> > >    1. The ID payload is not good enough for remote access user >> > >       authentication. What we need is new type(s) of ISAKMP >> > >       payload(s) - something like ID_EXCHANGE_INITIATE, >> > >       ID_EXCHANGE_IN_PROGRESS and ID_EXCHANGE_COMPLETE. >> > >       (There may be variations to the ID_EXCHANGE types, >> > >        like challenge/response, token card, OTP etc..) >> > >> > This assertion needs to be justified.  Perhaps the argument >> > is support of >> > legacy auth systems, but it certainly is not security.  We >> > can do a better >> > job of user auth with certs than any of these other >> > approaches.  The certs >> > (and associated crypto processing) could be in a personal >> > token, not just >> > in software, thus providing very high quality user auth.  >> > Also, one might >> > argue that IPsec provides an impetus to switch away from >> > transient user >> > auth, to continuous user auth, from passwords to keys, etc.  >> > That's why I >> > think this first premise needs to be much better justified >> > than what I've >> > seen so far. >> > >> > >    3. The authentication mechanisms suggested are >> > asymmetrical between >> > >       edge device and remote user. Edge device is authenticated with >> > >       a public key, whereas remote user is authenticated >> > with token card >> > >       and CHAP(Challeng/Response) mechasims. >> > >> > Why?  I'd much rather use a cert for user auth, as provided >> > in SSL with >> > client certs, than these other mechanisms.  Again, you need >> > to justify this >> > assertion. >> > >> > >       However, it doesnt have to be that way. If desired, the remote >> > >       user could run the same token card/CHAP mechanisms to >> > authenticate >> > >       the edge device. >> > >> > That's definately a step down in security!  Why even suggest this? >> > >> > >    4. SA lifetime: >> > > >> > >       The current  metrics of "time-bound" and "Data-bound" for an >> > >       SA lifetime do not seem adequate for remote access users. >> > >       I would like to see a new metric like "network-connected-time" >> > >       for SA lifetime. This new metric may be used in >> > conjunction with >> > >       other metrics (if the crypto algorithms mandate such >> > a limiting >> > >       criteria) or by itself. >> > >> > Why is not SA lifetime close enough to net sonnect time?  Why >> > is the latter >> > metric preferable? >> > >> > >       Keeping an SA valid for the lifetime of network connection, >> > >       makes the administratve overhead on remote user and >> > edge device >> > >       simpler. I can see this new metric being valuable even in >> > >       GW-GW type VPN connections. (SA rekeying is a lot of overhead >> > >       and has lots of scope for confusion and >> > inconsistencies between >> > >       vendors). >> > >> > See questions above. >> > >> > Steve >> > >> > >> > >> >> From owner-ipsec Thu Jul 23 11:06:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA16301 for ipsec-outgoing; Thu, 23 Jul 1998 11:05:04 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807231521.IAA27088@kc.livingston.com> Subject: Re: Comments on "Hybrid Auth. mode for IKE" To: kent@bbn.com (Stephen Kent) Date: Thu, 23 Jul 1998 08:21:40 -0700 (PDT) Cc: suresh@livingston.com, moshe@checkpoint.com, ipsec@tis.com In-Reply-To: from "Stephen Kent" at Jul 22, 98 06:57:36 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Suresh, > > >Secondly, I would think, exchange mode of authentication is generally > >speaking more robust than a one-time ID authentication. Exchange mode > >allows either party to probe beyond a single notification. For example, > >it allows multiple forms of authentication (i.e., increasingly strong > >levels of authentication, if you desire). Above all, exchange mode > >of authentication does meet the legacy auth. requirements. > > I don't agree. Once an IKE exhange has been performed using certs, all > subsequent client traffic is cryptographically protected using keying > material that has been bound to the user in question (if we are providing > user-granularity keying) and authenticated by the cert processing. The > suggestion is often made that a protocol that allows for subsequent re-auth > is "more secure," but that is true only under certain curstances. If the > communication path were not continuousluy authenticated, this argument has > some merit, but that's not the case for IPsec. If the re-auth requires > additional user involvement, all of my marketing folks tell me it's > unacceptable, and, as a user, I agree with them! This is the era of single > sign on, not extra sign on. Finally, if the re-auth is automatic, then I'd > argue that it is no better than the continuous auth being probvided by > IPsec. We also must compare apples and organges. Using hardware for key > management with IKE should be better than using a software-based OTP > system, or even a token like SecurID. Arguments about using a hardware > token for user auth but not for IKE are mushier. > There may be a mis-understanding here. What I was saying was not what you were alluding to. Re-authentication may be done any number of times, if so desired, independent of what the authetication type is. CHAP allows re-authentication. But, Re-authentication arguments you allude to apply to existing authentication schemes as well as the exchange-type authentication scheme being proposed. I am drawing a distinction between an authentication mechanism that is exchange oriented (starting with a ID_EXCH_START type payload, and ending with a ID_EXCH_DONE payload) as opposed to a single-payload-type authentication (ex: signature authentication). Within an exchange-type authentication, you could authenticate a client in more than one-way. For example: Challenge/response authentication, followed by smart token card authentication. In general, the exchange type authentication could combine multiple authentications and hence is a stronger mechanism for auth than a single-payload-type authentcation. Why do you call the current auth. mechanism continuous auth? They authenticate each side just once using a single ID payload from either side. I dont quite parse you last sentence right. I am arguing for using smart token cards for IKE authentication. > >Lastly, certificate based authentication you suggests requires a vast > >deployment of CA infrastructure, which is not in place yet. Many of the > >ISP consortiums have to go with what is commonly available as opposed to > >what a single enterprise or a limited no. of ISPs have. Would you rather > >that remote access applications not utilize the benefits of IPsec until > >the certificate deployment is common place? I would think not. > > Not true. I have personal experience establ;ishing PKIs that were derrived > from name/password baselines. It can be done easily, especially for > intranets and for closed user communities. Since I'm in the PKI business I > may me accused of being biased ;-), but I also have some ammount of > experience proving assertions of this sort to be false. > You may be right in that there are CA deployments, based on name/password baselines. But, CA deployment is still very small compared to RADIUS based deployments for CHAP and token card authentications. > >> > However, it doesnt have to be that way. If desired, the remote > >> > user could run the same token card/CHAP mechanisms to authenticate > >> > the edge device. > >> > >> That's definately a step down in security! Why even suggest this? > > > >Well, not really. It is just an extension of the authentication > >mechanism to both parties. > > If we have authenticated end points using good keys associayted with certs, > it's not at all clear that use of additional, weaker mechanisms adds to the > strength of the system, while it certainly adds to the complexity of design > and management! My clients want fewer user auth databases to manage, not > more, and moving these databases to certs is the best approach from a > security perspective, in most cases. > Hmm... Seems to me, you have the logic the other way around. Certificate based authentication is lot more complex to design, implement and manage than CHAP type authentication. Certificate based CAs are yet another infrastructure and auth database to deloy and manage. So are secure-DNS, Kerberos and so forth. Customers want fewer databases. But, only time will tell which database they would want to keep. In the mean time, it is important to support the existing databases while trying to leap frog into other databases. > >> > >> > 4. SA lifetime: > >> > > >> > The current metrics of "time-bound" and "Data-bound" for an > >> > SA lifetime do not seem adequate for remote access users. > >> > I would like to see a new metric like "network-connected-time" > >> > for SA lifetime. This new metric may be used in conjunction with > >> > other metrics (if the crypto algorithms mandate such a limiting > >> > criteria) or by itself. > >> > >> Why is not SA lifetime close enough to net sonnect time? Why is the latter > >> metric preferable? > >> > > > >How would you pick a close enough metric? Could be quite arbitrary. > >A user may have no way to know ahead of time, how long his/her sessions > >are going to have to be kept alive or how much data he/she is going > >to be exchanging. If these metrics are to be set infinitely large, > >then that defeats the purpose to start with. > > > >Most often than not, a user is likely to want to keep the negotiated > >security parameters unchanged throughout the connected time. > > i don't understand your response. You origjnally suggested that net > connect time was preferable to SA lifetime. For an individual user SA, > these seem to be almost the same to me, so I asked how they bwere > significantly different. Your response does not address that question. > Let us say, there is a way to determine the connect time of a remote user into enterprise network. I am refering to such a network-connected-time as the metric. I was suggesting to keep the negotiated SAs alive for the whole of network-connected-time, as opposed to an arbitrary time-bound or data-bounbd lifetime. Of course, Network-connected-time could in itself be combined with time-bound and/or data-bound lifetimes. > Steve > cheers, suresh From owner-ipsec Thu Jul 23 11:08:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA16322 for ipsec-outgoing; Thu, 23 Jul 1998 11:07:09 -0400 (EDT) Message-ID: From: Greg Carter To: Greg Carter , Stephen Kent , suresh@livingston.com, "'Roy Pereira'" , "'Pat.Calhoun@Eng.Sun.COM'" Cc: moshe@checkpoint.com, ipsec@tis.com, suresh@livingston.com, "Pat Calhoun (E-mail)" Subject: RE: Comments on "Hybrid Auth. mode for IKE" Date: Thu, 23 Jul 1998 11:14:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Pat, Perhaps I wasn't clear, I know EAP is not tied to DES. I authored EAP-ISAKMP. My point was that the XAUTH stuff stems from a desire to support token cards. That would be the biggest consumer of the protocol if it were implemented. So I was suggesting a way of supporting token cards without a new auth method. On an aside, how do biometric devices increase network authentication security? Of the ones I have worked with all they do is output a large password based on some bio input. They don't solve the problem of securely transferring that password to be verified on the other end. But I haven't used biometric devices to do network authentication, only to secure private keys which are then used in the network authentication. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > Again, it just happens that *some* of the EAP proposal are based on DES. > EAP > could also support biometrics, TLS and a whole slew of other more secure > schemes. EAP is not tied to DES in any way. > > From owner-ipsec Thu Jul 23 12:31:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16917 for ipsec-outgoing; Thu, 23 Jul 1998 12:28:09 -0400 (EDT) Message-ID: <35B768B0.EAA079B2@redcreek.com> Date: Thu, 23 Jul 1998 09:45:36 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Pyda Srisuresh CC: ipsec@tis.com Subject: Re: Comments on "Hybrid Auth. mode for IKE" References: <199807231521.IAA27088@kc.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk [cc: list trimmed...] Pyda Srisuresh wrote: > > >> > 4. SA lifetime: > > >> > > > >> > The current metrics of "time-bound" and "Data-bound" for an > > >> > SA lifetime do not seem adequate for remote access users. > > >> > I would like to see a new metric like "network-connected-time" > > >> > for SA lifetime. This new metric may be used in conjunction with > > >> > other metrics (if the crypto algorithms mandate such a limiting > > >> > criteria) or by itself. > > >> > > >> Why is not SA lifetime close enough to net sonnect time? Why is the latter > > >> metric preferable? > > >> > > > > > >How would you pick a close enough metric? Could be quite arbitrary. > > >A user may have no way to know ahead of time, how long his/her sessions > > >are going to have to be kept alive or how much data he/she is going > > >to be exchanging. If these metrics are to be set infinitely large, > > >then that defeats the purpose to start with. > > > > > >Most often than not, a user is likely to want to keep the negotiated > > >security parameters unchanged throughout the connected time. Then the user is risking compromise due to the dearth of ciphertext and time the attacker is being given to attack the key with. Rekeying is a minor expense which provides greatly increased security. The cost associated with it is negligible, compared to the benefits. If you insist on life-of-connection SAs, then configure your gateway so that SAs have infinite lifetimes, and make it your policy that SAs are dropped when connections are. I wouldn't do it, but you can... From owner-ipsec Thu Jul 23 12:34:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16943 for ipsec-outgoing; Thu, 23 Jul 1998 12:33:08 -0400 (EDT) Message-ID: <35B769A8.E681209F@redcreek.com> Date: Thu, 23 Jul 1998 09:49:44 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Pyda Srisuresh CC: ipsec@tis.com Subject: Re: Comments on "Hybrid Auth. mode for IKE" References: <199807212012.NAA07586@kc.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda Srisuresh wrote: > 5. Rekeying of ISAKMP SA: > > ISAKMP SAs (on client and server ends) neednt be kept forever > while the session SAs are alive. ISAKMP SAs can be short lived, > unless either end wants to use the ISAKMP SA for periodic > authentication or session SA rekeying. > > In the case where an adge device or remote user has to use the > ISAKMP SA to talk to the other end, and finds that the ISAKMP SA > is missing (or lost in bit bucket), I think, it is reasonable > for the device to simply retire all the session SAs(created using > the lost ISAKMP SA), send an ICMP error message to the other end > and drop the network connection. > > At such a time, the remote user could reinitate the conection to > edge device. > Why would you even suggest such a thing? Protocol SAs, once established, have no dependence upon ISAKMP SAs. Retire all sessions? Send an ICMP error message to the other end and drop the network connection? You're joking, right? From owner-ipsec Thu Jul 23 12:57:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17032 for ipsec-outgoing; Thu, 23 Jul 1998 12:56:08 -0400 (EDT) Message-ID: <35B76F2A.3B1FC43B@redcreek.com> Date: Thu, 23 Jul 1998 10:13:14 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Pyda Srisuresh CC: ipsec@tis.com Subject: Re: Comments on "Hybrid Auth. mode for IKE" References: <199807212012.NAA07586@kc.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk A bit more on my previous response to this: Pyda Srisuresh wrote: > 5. Rekeying of ISAKMP SA: > > ISAKMP SAs (on client and server ends) neednt be kept forever > while the session SAs are alive. ISAKMP SAs can be short lived, > unless either end wants to use the ISAKMP SA for periodic > authentication or session SA rekeying. > > In the case where an adge device or remote user has to use the > ISAKMP SA to talk to the other end, and finds that the ISAKMP SA > is missing (or lost in bit bucket), I think, it is reasonable > for the device to simply retire all the session SAs(created using > the lost ISAKMP SA), send an ICMP error message to the other end > and drop the network connection. > > At such a time, the remote user could reinitate the conection to > edge device. > I said that the Protocol SA (P-SA) and ISAKMP SAs (I-SAs) are unrelated after the P-SA is established; that's not strictly correct since you need an I-SA to rekey, but the point is, you don't need a *particular* I-SA, and you *certainly* don't need the same one which was used to establish the original P-SA, in order to rekey. Again, this is one of the reasons for prior suggestions that you may cache additional I-SA's to a given host/gw for later use. If you lose the current I-SA, you can either use a cached one, or build a new one. In either case, there is no need to drop connections, and if you build a product that does this, our marketing guy can whip your marketing guy for sure :-) From owner-ipsec Thu Jul 23 13:06:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA17080 for ipsec-outgoing; Thu, 23 Jul 1998 13:05:08 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807231717.KAA29041@kc.livingston.com> Subject: Re: Comments on "Hybrid Auth. mode for IKE" To: skelly@redcreek.com (Scott G. Kelly) Date: Thu, 23 Jul 1998 10:17:59 -0700 (PDT) Cc: suresh@livingston.com, ipsec@tis.com In-Reply-To: <35B768B0.EAA079B2@redcreek.com> from "Scott G. Kelly" at Jul 23, 98 09:45:36 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > [cc: list trimmed...] > > Pyda Srisuresh wrote: > > > > > > >> > 4. SA lifetime: > > > >> > > > > >> > The current metrics of "time-bound" and "Data-bound" for an > > > >> > SA lifetime do not seem adequate for remote access users. > > > >> > I would like to see a new metric like "network-connected-time" > > > >> > for SA lifetime. This new metric may be used in conjunction with > > > >> > other metrics (if the crypto algorithms mandate such a limiting > > > >> > criteria) or by itself. > > > >> > > > >> Why is not SA lifetime close enough to net sonnect time? Why is the latter > > > >> metric preferable? > > > >> > > > > > > > >How would you pick a close enough metric? Could be quite arbitrary. > > > >A user may have no way to know ahead of time, how long his/her sessions > > > >are going to have to be kept alive or how much data he/she is going > > > >to be exchanging. If these metrics are to be set infinitely large, > > > >then that defeats the purpose to start with. > > > > > > > >Most often than not, a user is likely to want to keep the negotiated > > > >security parameters unchanged throughout the connected time. > > Then the user is risking compromise due to the dearth of ciphertext and > time the attacker is being given to attack the key with. Rekeying is a > minor expense which provides greatly increased security. The cost > associated with it is negligible, compared to the benefits. > I did suggest to use this metric only when it doesnt compromise the crypto strength (for example, 3DES encryption with 168-bit key). Reduction of management overhead is a significant benifit. cheers, suresh From owner-ipsec Thu Jul 23 13:33:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA17223 for ipsec-outgoing; Thu, 23 Jul 1998 13:32:10 -0400 (EDT) Message-ID: <35B776D2.C352A4D9@cale.checkpoint.com> Date: Thu, 23 Jul 1998 20:45:54 +0300 From: Moshe Litvin X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Greg Carter CC: moshe@checkpoint.com, ipsec@tis.com, "Pat Calhoun (E-mail)" Subject: Re: Comments on "Hybrid Auth. mode for IKE" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, You proposal require perfect state synchronization between the client and the server (either what is the last challenge "sent" or the exact time). It is impossible in practice especially since there are no means to synchronize them. Also notice that in the hybrid mode no challenge and no reply are passing in the clear. Regards, Moshe Greg Carter wrote: > > EAP Introduced to ipsec ? :), I don't want to be there when PKIX meets > SPKI... > > Anyway... > When I thought of EAP-ISAKMP it was to increase security which was lacking > in most of the other EAP mechanisms. Now it seems we want to hack ISAKMP to > work with the 'lacking' EAP mechanisms, mostly token cards. Which come in > two varieties, those based on DES, and those based on proprietary protocols. > Putting aside the wisdom of DES and proprietary algorithms... > > The DES cards usually have a "Guess next Challenge" mode where they know > what the next challenge will be based on the last. The proprietary card > uses a time based scheme, and so at any moment in time you know the > response, there is no challenge. You can take the response as the IKE > shared secret. No Challenge is needed. > > Benefits - > No changes to IKE. > May increase security of DES based challenge/response cards since known > plain text/cipher text never flows over the network. DES cards when used > with protocols like RADIUS or TACACS do all the challenge/response in the > open. $250K and 56-224 hours later you have the key. In this mode DES is > combined with key hashes and no known text is transmitted over the network. > Supports DES cards, Time based cards (OK they'll have to write some code on > their server to give up the expected response based on ID, rather than a > simple yes/no response, but nothing is for free), PAP/CHAP (no reason to do > CHAP, just use the password as the secret... > > Drawbacks > Aggressive mode is the only practical choice. > Initialization and resync. Initialization is easily handled, resync is > doable. > Backend server will be needed to track card state. Not really a drawback, > every card manufacture I know offers a backend management server of some > sort which already does this. Since the backend server is now essentially a > key server you should probably run IPSEC over the link from the Gateway to > the server. > > Anyway my point is that it is doable with the current spec, no changes to > token hardware, maybe a little coding on the server side. Sure there are > some drawbacks but you want to use 1980's technology... > Later. > ---- > Greg Carter, Entrust Technologies > greg.carter@entrust.com > -- ----------------------------------------------------------------------- Moshe Litvin Check Point Software Technologies Ltd. moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555) Fax: +972-3-575-9256 ----------------------------------------------------------------------- From owner-ipsec Thu Jul 23 13:42:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA17307 for ipsec-outgoing; Thu, 23 Jul 1998 13:42:10 -0400 (EDT) To: Stephen Waters Cc: ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway References: <250F9C8DEB9ED011A14D08002BE4F64C01B14301@wade.reo.dec.com> From: Ben Rogers Date: 23 Jul 1998 13:58:28 -0400 In-Reply-To: Stephen Waters's message of Thu, 23 Jul 1998 14:45:29 +0100 Message-ID: Lines: 28 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Waters writes: > I seem to remember asking this question before, but.... > > Although not covered in the IPSEC architecture, is there any > restriction on a Security Gateway > applying both ESP and AH in tunnel mode? You could do this. However, you'll want to be a little more precise with your terminology. ESP and AH in tunnel mode: IP AH IP ESP IP DATA You probably intended to apply ESP in tunnel mode and AH in transport mode on top of that: IP AH ESP IP DATA Note that in an ISAKMP negotiation, you would negotiate a single proposal containing an ESP transform with the tunnel mode attribute and an AH transform with the transport mode attribute. (This is something we agreed to some time ago but which might not have made it into the docs yet.) ben From owner-ipsec Thu Jul 23 14:14:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA17462 for ipsec-outgoing; Thu, 23 Jul 1998 14:14:15 -0400 (EDT) Message-ID: <35B78197.9C3F510E@redcreek.com> Date: Thu, 23 Jul 1998 11:31:51 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Pyda Srisuresh CC: ipsec@tis.com Subject: Re: Comments on "Hybrid Auth. mode for IKE" References: <199807231829.LAA02288@kc.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda Srisuresh wrote: > > > product that does this, our marketing guy can whip your marketing guy > > for sure :-) > > > This macho comment is uncalled for. I would appreciate if you dont make > such comments in the future. Macho? The smiley emoticon clearly demarks the joke. Lighten up. Scott From owner-ipsec Thu Jul 23 14:14:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA17437 for ipsec-outgoing; Thu, 23 Jul 1998 14:12:16 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807231829.LAA02288@kc.livingston.com> Subject: Re: Comments on "Hybrid Auth. mode for IKE" To: skelly@redcreek.com (Scott G. Kelly) Date: Thu, 23 Jul 1998 11:29:11 -0700 (PDT) Cc: suresh@livingston.com, ipsec@tis.com In-Reply-To: <35B76F2A.3B1FC43B@redcreek.com> from "Scott G. Kelly" at Jul 23, 98 10:13:14 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > A bit more on my previous response to this: > > Pyda Srisuresh wrote: > > 5. Rekeying of ISAKMP SA: > > > > ISAKMP SAs (on client and server ends) neednt be kept forever > > while the session SAs are alive. ISAKMP SAs can be short lived, > > unless either end wants to use the ISAKMP SA for periodic > > authentication or session SA rekeying. > > > > In the case where an adge device or remote user has to use the > > ISAKMP SA to talk to the other end, and finds that the ISAKMP SA > > is missing (or lost in bit bucket), I think, it is reasonable > > for the device to simply retire all the session SAs(created using > > the lost ISAKMP SA), send an ICMP error message to the other end > > and drop the network connection. > > > > At such a time, the remote user could reinitate the conection to > > edge device. > > > > I said that the Protocol SA (P-SA) and ISAKMP SAs (I-SAs) are unrelated > after the P-SA is established; that's not strictly correct since you > need an I-SA to rekey, but the point is, you don't need a *particular* > I-SA, and you *certainly* don't need the same one which was used to > establish the original P-SA, in order to rekey. > > Again, this is one of the reasons for prior suggestions that you may > cache additional I-SA's to a given host/gw for later use. If you lose > the current I-SA, you can either use a cached one, or build a new one. You miss the point. Read Tero's and Moshe's comments on rekeying. Once an ISAKMP-SA is lost on the edge device, the edge device cannot initiate a new IKE negotiation for re-keying. Only the remote user can start the main mode. > In either case, there is no need to drop connections, and if you build a Dropping connections would ensure that the edge device would not have to initiate a new IKE negotiation. The remote user would initiate IKE to get the connection. > product that does this, our marketing guy can whip your marketing guy > for sure :-) > This macho comment is uncalled for. I would appreciate if you dont make such comments in the future. cheers, suresh From owner-ipsec Thu Jul 23 14:23:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA17553 for ipsec-outgoing; Thu, 23 Jul 1998 14:23:16 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01B14308@wade.reo.dec.com> From: Stephen Waters To: Ben Rogers Cc: ipsec@tis.com Subject: RE: ESP and AH used in tunnel mode by a Security Gateway Date: Thu, 23 Jul 1998 19:39:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Yes, I suppose once I have applied ESP-Tunnel, using AH as well become transport mode - unless I really want to incur the overhead of yet another IP header. Thanks. Steve. > ---------- > From: Ben Rogers[SMTP:ben@ascend.com] > Sent: Thursday, July 23, 1998 6:58 PM > To: Stephen Waters > Cc: ipsec@tis.com > Subject: Re: ESP and AH used in tunnel mode by a Security Gateway > > Stephen Waters writes: > > > I seem to remember asking this question before, but.... > > > > Although not covered in the IPSEC architecture, is there any > > restriction on a Security Gateway > > applying both ESP and AH in tunnel mode? > > You could do this. However, you'll want to be a little more precise > with your terminology. > > ESP and AH in tunnel mode: > > IP AH IP ESP IP DATA > > You probably intended to apply ESP in tunnel mode and AH in transport > mode on top of that: > > IP AH ESP IP DATA > > Note that in an ISAKMP negotiation, you would negotiate a single > proposal containing an ESP transform with the tunnel mode attribute > and an AH transform with the transport mode attribute. (This is > something we agreed to some time ago but which might not have made it > into the docs yet.) > > > ben > From owner-ipsec Thu Jul 23 14:51:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA17688 for ipsec-outgoing; Thu, 23 Jul 1998 14:49:16 -0400 (EDT) Message-Id: <35B7896B.355D7F79@raleigh.ibm.com> Date: Thu, 23 Jul 1998 15:05:15 -0400 From: Phuong Nguyen Organization: IBM Research Triangle Park X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Ben Rogers Cc: ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway References: <250F9C8DEB9ED011A14D08002BE4F64C01B14301@wade.reo.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben Rogers wrote: > > Stephen Waters writes: > > > I seem to remember asking this question before, but.... > > > > Although not covered in the IPSEC architecture, is there any > > restriction on a Security Gateway > > applying both ESP and AH in tunnel mode? > > You could do this. However, you'll want to be a little more precise > with your terminology. > > ESP and AH in tunnel mode: > > IP AH IP ESP IP DATA > > You probably intended to apply ESP in tunnel mode and AH in transport > mode on top of that: > > IP AH ESP IP DATA > > Note that in an ISAKMP negotiation, you would negotiate a single > proposal containing an ESP transform with the tunnel mode attribute > and an AH transform with the transport mode attribute. (This is > something we agreed to some time ago but which might not have made it > into the docs yet.) > > ben I know it's a little weird but is there any spec againsts this: IP ESP AH IP DATA IP ESP AH DATA Thanks, Phuong From owner-ipsec Thu Jul 23 15:40:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17870 for ipsec-outgoing; Thu, 23 Jul 1998 15:40:18 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01B14301@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jul 1998 11:15:18 -0400 To: Stephen Waters From: Stephen Kent Subject: Re: ESP and AH used in tunnel mode by a Security Gateway Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, There is no requirement for an implementation to support application of both an AH and an ESP tunnel between the same two endpoints. However, an SG might be the terminus of two tunnels, in the same or different modes, with different endpoints. For example, there might be a tunnel between SG1 and SG2 and H1, behind SG1, might open another tunnel to SG2. So that would cause traffic to flow over two tunnels that terminate at SG2. However, an SG should not create two nested tunnels to the same endpoint. We removed that requirement a while ago because implementors did not feel that it was worth the added complexity. So, if an SG created such nested tunnels, there is no reason to believe that a compliant IPsec implementation at the other end would support such nesting, as the spec warns. Steve From owner-ipsec Thu Jul 23 15:56:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17898 for ipsec-outgoing; Thu, 23 Jul 1998 15:55:22 -0400 (EDT) Message-Id: <199807231806.LAA04862@yupa.ca.mew.com> X-Mailer: Macintosh Eudora Pro Version 2.1.4-J Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Date: Thu, 23 Jul 1998 11:12:07 -0700 To: ipsec@tis.com From: mat@ca.mew.com (Nobuo Matsuo) Subject: Target date and implementation ? Cc: mat@ca.mew.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello everyone, Are there any target date and/or schedule to fix IPSEC 2,ISAKMP drafts as RFCs ? Are there any reference information regarding which version of each spec. to implement as the latest implementation ? Nobuo ------------------------------------------------------- Nobuo Matsuo Email : mat@ca.mew.com Matsushita Electric Works R&D Lab, Inc. 1975 West El Camino Real, Suite #102 Mountain View, CA 94040 Phone: (650) 938-6639, (Ext. 203), Fax : (650) 938-6629 >From owner-fwmib@tis.com Thu Jul 23 12:54 EDT 1998 X-UIDL: 02f341ed9a0f96d424ac2cacc2a9cb78 Received: from relay.hq.tis.com (relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with ESMTP id MAA25949 for ; Thu, 23 Jul 1998 12:53:28 -0400 (EDT) Received: by relay.hq.tis.com; id MAA23910; Thu, 23 Jul 1998 12:56:08 -0400 (EDT) Received: from portal.ex.tis.com(192.94.214.101) by relay.hq.tis.com via smap (4.0a) id xma023841; Thu, 23 Jul 98 12:55:11 -0400 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA16981; Thu, 23 Jul 1998 12:42:07 -0400 (EDT) Date: Thu, 23 Jul 1998 12:42:07 -0400 (EDT) From: owner-fwmib@ex.tis.com Message-Id: <199807231642.MAA16981@portal.ex.tis.com> To: owner-fwmib@tis.com Subject: BOUNCE fwmib@portal.ex.tis.com: Non-member submission from ["Grall, Cynthia" ] Content-Type: text Content-Length: 4156 Status: RO X-Status: >From majordomo-owner Thu Jul 23 12:42:05 1998 Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by portal.ex.tis.com (8.8.2/8.8.2) with ESMTP id MAA16977 for ; Thu, 23 Jul 1998 12:42:05 -0400 (EDT) Received: by relay.hq.tis.com; id MAA23835; Thu, 23 Jul 1998 12:55:08 -0400 (EDT) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma023802; Thu, 23 Jul 98 12:54:11 -0400 Received: from relay.hq.tis.com (relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with ESMTP id MAA25810; Thu, 23 Jul 1998 12:51:28 -0400 (EDT) Received: by relay.hq.tis.com; id MAA23790; Thu, 23 Jul 1998 12:54:08 -0400 (EDT) Received: from na-ex-bridge2.nai.com(208.228.228.65) by relay.hq.tis.com via smap (4.0a) id xma023739; Thu, 23 Jul 98 12:53:11 -0400 Received: by na-ex-bridge2.nai.com with Internet Mail Service (5.5.1960.3) id ; Thu, 23 Jul 1998 09:55:24 -0700 Message-ID: From: "Grall, Cynthia" To: "'Herbert Lin'" , jimf@cisco.com, struong@cisco.com, sfan@cisco.com, jokrent@cisco.com, grall@tis.com, eff@checkpoint.com, mwittig@mail.cybg.com, dlancaster@raptor.com, cliff_wang@vnet.ibm.com, sfan@cisco.com, Jack Danahy , fwmib@tis.com Subject: RE: We like to form a formal IETF FirewallMIB Working Group Date: Thu, 23 Jul 1998 10:04:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain If you look back to my latest summary of things to do, you will notice that I mentioned we must provide a Charter statement to our Area Director if we want to form a Working Group. According to RFC 1603, section 2.2: "The formation of a working group requires a charter which is primarily negotiated between a prospective working group Chair and the relevant Area Director,..." The current Charter is somewhat out of date and needs to be updated. This must be done before we all start sending seperate messages to IETF/IAB folks who are probably very very busy. Cindy ------------- Cindy Grall Network Associates, Inc. cgrall@nai.com 3415 s. Sepulvida Blvd. suite 700 phone: (310) 737-1744, x129 Los Angeles, CA 90034 fax: (310) 737-1755 > -----Original Message----- > From: Herbert Lin [SMTP:hlin@bbnplanet.com] > Sent: Thursday, July 23, 1998 7:58 AM > To: jimf@cisco.com; struong@cisco.com; sfan@cisco.com; > jokrent@cisco.com; grall@tis.com; eff@checkpoint.com; > mwittig@mail.cybg.com; dlancaster@raptor.com; cliff_wang@vnet.ibm.com; > sfan@cisco.com; Jack Danahy; fwmib@tis.com > Subject: Re: We like to form a formal IETF FirewallMIB Working > Group > > All- > > Can I ask you who are interested to form a formal IETF FirewallMIB > working > Group to send a short email to the following four people in IETF to > voice > your/our needs? > > Jeffrey Schiller , > Marcus Leech , > Fred Baker , > scoya@ietf.org > > And cc: to fwmib@tis.com > > I think we need a team effort to make this work. > > Herbert > -------- > >X-Sender: fred@stilton.cisco.com (Unverified) > >X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) > >Date: Thu, 23 Jul 1998 09:17:46 +0200 > >To: Herbert Lin > >From: Fred Baker > >Subject: Re: We like to form a formal IETF FirewallMIB Working Group > >Cc: Jeffrey Schiller , Marcus Leech , > > scoya@ietf.org > > > >At 11:34 AM 7/22/98 -0400, Herbert Lin wrote: > >>Can you help us schedule a work group session? > > > >I will leave that to Jeff and Marcus. Understand that the fact that > you > >have been working on it doesn't imply a *right* to a working group > meeting, > >per the IETF's rules. However, I fully believe that this can be > worked out. > > > Herbert Lin > Manager, Software Development > Mail Stop: 20/6D > GTE Internetworking, Powered by BBN > 150 CambridgePark Drive > Cambridge, MA 02138 > > E-mail: hlin@bbnplanet.com > Tel: 617-873-5920 > Fax: 617-873-6846 From owner-ipsec Thu Jul 23 15:59:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17921 for ipsec-outgoing; Thu, 23 Jul 1998 15:59:26 -0400 (EDT) Message-Id: <199807232015.NAA09697@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins owned process doing -bs X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins@localhost didn't use HELO protocol To: Ben Rogers cc: Stephen Waters , ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway In-reply-to: Your message of "23 Jul 1998 13:58:28 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9695.901224946.1@cisco.com> Date: Thu, 23 Jul 1998 13:15:46 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk I really don't want to open this can-of-worms but it has some interoperability implications. On 23 Jul 1998 13:58:28 EDT you wrote > Stephen Waters writes: > > > I seem to remember asking this question before, but.... > > > > Although not covered in the IPSEC architecture, is there any > > restriction on a Security Gateway > > applying both ESP and AH in tunnel mode? > > You could do this. However, you'll want to be a little more precise > with your terminology. > > ESP and AH in tunnel mode: > > IP AH IP ESP IP DATA > > You probably intended to apply ESP in tunnel mode and AH in transport > mode on top of that: > > IP AH ESP IP DATA > > Note that in an ISAKMP negotiation, you would negotiate a single > proposal containing an ESP transform with the tunnel mode attribute > and an AH transform with the transport mode attribute. (This is > something we agreed to some time ago but which might not have made it > into the docs yet.) I don't remember agreeing to that. In fact, the only mention of this I remember came up during the IPCOMP and IPSEC thread. On May 28, in <199805282040.NAA01397@orna.mentat.com> Marc Hasson wrote: > > I guess you could say that ESP is in transport mode, but what about the > case where both AH and ESP are applied to the same packet: > > [IP2][AH][ESP][IP1][data] > > Is AH in transport mode? Good point. I can hear people arguing it both ways and am sorry I raised that side tidbit. Whats more important is that we all understand how to process the above, which I think is pretty clear in the specs. Yes, I feel we can all process this but it's now apparent that we can't all negotiate it. The next header in AH is not IPinIP so I understand the point being made. But these two SAs are the result of a single rule. If PFS is also part of the rule it applies to both and the ID payloads passed in the QM exchange also apply to both. They are a single unit. If we have: H1 ------ SG1 ---------- SG2 ------- H2 |<-- secured -->| | |__ H3 the rules I've applied to SG1 (vice versa for SG2) is: For traffic from H1 to H2, apply AH and ESP and peer with SG2 If AH is in transport mode the rule becomes: For traffic from H1 to H2, apply ESP and peer with SG2 For ESP traffic from SG1 to SG2 apply AH and peer with SG2 But if I want my packets from H1 to H2 to look like: IP[SG1-SG2] AH ESP IP[H1-H2] and from H1 to H3 to look like: IP[SG1-SG2] ESP [H1-H2] That'll break down because my packets ESP packets will match the rule being applied for H1-H2 traffic and it'll have AH applied. There'd be some ugly code to prevent this from happening. SG2 would also have some ugly spagetti code to make sure that, at decaps, AH is only applied to an ESP packet that was applied to H1-H2 traffic. That would be necessary since the AH+ESP negotiation specified H1-H2 and to use AH on an ESP packet that was H1-H3 would be in violation of that. Transport mode can't be applied by a SG to a packet in transit-- in the example a packet from H1 to H2. But if AH was treated as being in transport mode in IP AH ESP IP DATA then that's exactly what you'd be saying in your Quick Mode message. So you'd have to do two separate negotiations, one for ESP on IP between H1 and H2 and another for AH on ESP packets between SG1 and SG2, and that would have problems too because you would be unable to specify that traffic from H1 to H3 *not* have AH applied. I think it's better to treat AH as being in tunnel mode in this case. It precludes lots of ugly, hard-to-maintain code, it makes UI much simpler, and it allows for a wider array of rules to be applied to various sorts of traffic. I'm not suggesting doing IP AH IP ESP IP DATA. I'm just suggesting that when we want to do IP AH ESP IP DATA that we negotiate it using the same encapsulation attribute-- tunnel mode-- in both the AH and ESP proposals. This would also apply to IP ESP PCP IP DATA or IP AH ESP PCP IP DATA too. Dan. From owner-ipsec Thu Jul 23 16:03:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17953 for ipsec-outgoing; Thu, 23 Jul 1998 16:03:28 -0400 (EDT) Message-Id: <199807232019.QAA14633@istari.sandelman.ottawa.on.ca> To: Stephen Waters CC: ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway In-reply-to: Your message of "Thu, 23 Jul 1998 14:45:29 BST." <250F9C8DEB9ED011A14D08002BE4F64C01B14301@wade.reo.dec.com> Date: Thu, 23 Jul 1998 16:19:36 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Stephen" == Stephen Waters writes: Stephen> I seem to remember asking this question before, but.... Stephen> Although not covered in the IPSEC architecture, is there any Stephen> restriction on a Security Gateway Stephen> applying both ESP and AH in tunnel mode? Stephen> Thanks, Steve. No, you may do so. The combined transform was designed to reduce the overhead of doing this, but you can explicitely do this. A likely case where this happens is something like: H--------SG1===========SG2-----G <----- AH ----> <-----------ESP---------> SG2 has negotiated an AH tunnel with SG1, and an ESP tunnel with H. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Thu Jul 23 16:06:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17978 for ipsec-outgoing; Thu, 23 Jul 1998 16:06:27 -0400 (EDT) Message-Id: <199807232022.NAA29623@greatdane.cisco.com> To: ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway In-reply-to: Your message of "Thu, 23 Jul 1998 13:15:46 PDT." <199807232015.NAA09697@dharkins-ss20.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jul 1998 13:22:19 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On: Thu, 23 Jul 1998 13:15:46 PDT I fatfingered: [snip] > But if I want my packets from H1 to H2 to look like: > > IP[SG1-SG2] AH ESP IP[H1-H2] > > and from H1 to H3 to look like: > > IP[SG1-SG2] ESP [H1-H2] Make that: IP[SG1-SG2] ESP [H1-H3] Dan. From owner-ipsec Thu Jul 23 16:25:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA18116 for ipsec-outgoing; Thu, 23 Jul 1998 16:25:27 -0400 (EDT) To: Daniel Harkins Cc: Stephen Waters , ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway References: <199807232015.NAA09697@dharkins-ss20.cisco.com> From: Ben Rogers Date: 23 Jul 1998 16:37:53 -0400 In-Reply-To: Daniel Harkins's message of Thu, 23 Jul 1998 13:15:46 -0700 Message-ID: Lines: 55 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > I don't remember agreeing to that. In fact, the only mention of this > I remember came up during the IPCOMP and IPSEC thread. On May 28, in > <199805282040.NAA01397@orna.mentat.com> Marc Hasson wrote: > > > > > I guess you could say that ESP is in transport mode, but what about the > > case where both AH and ESP are applied to the same packet: > > > > [IP2][AH][ESP][IP1][data] > > > > Is AH in transport mode? > > Good point. I can hear people arguing it both ways and am sorry I > raised that side tidbit. Whats more important is that we all understand > how to process the above, which I think is pretty clear in the specs. > > Yes, I feel we can all process this but it's now apparent that we can't all > negotiate it. > I think it's better to treat AH as being in tunnel mode in this case. > It precludes lots of ugly, hard-to-maintain code, it makes UI much simpler, > and it allows for a wider array of rules to be applied to various sorts of > traffic. I agree wholeheartedly, and was aparently mistaken as to the extent the agreement. I think that it came out of a semi-private conversation between Steve Kent and myself (probably during the document reading party at the DC IETF). Steve -- are you okay with the rationale that Dan presents? If so, I'd like to make sure that arch-sec and ipsec-doi are updated appropriately once we get to play with them again. If I understand correctly, the suggestion is to treat: IP AH ESP IP data IP AH ESP IPPCP IP data IP ESP IPPCP IP data as AH(tunnel) + ESP(tunnel) AH(tunnel) + ESP(tunnel) + IPPCP(tunnel) ESP(tunnel) + IPPCP(tunnel) respectively, at least so far as ISAKMP negotiations are concerned. I've run into similar configuration issues to those Dan describes while trying to represent these with both tunnel and transport mode transforms (which is, in theory, the correct representation), and would be happy to see the change. ben From owner-ipsec Thu Jul 23 16:35:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA18149 for ipsec-outgoing; Thu, 23 Jul 1998 16:35:27 -0400 (EDT) Message-ID: From: Greg Carter To: "'Moshe Litvin'" Cc: ipsec@tis.com Subject: RE: Comments on "Hybrid Auth. mode for IKE" Date: Thu, 23 Jul 1998 16:45:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk SecurID uses time based, the card MUST be synchronized to the server or it doesn't work, each response is valid for 2 minutes (I think). So that is plenty of time to do a look up of the response on the Gateway side. DES cards do not require perfect synchronization. The Next Challenge calculation can be emulated (in most cases, I only know how a few of the cards do the calculation) in software without the knowledge of the DES key, only the last response is needed. So you can display the expected Challenge to the user without going to the backend server. If it doesn't match the one displayed on the card all the user has to do is enter the one displayed by your software, and they are back in sync. If your software and the backend server get out of sync then have the Gateway configured to allow the user limited access to a www page where they can go get back in sync. Does the user care that IKE is used for synchronization ? probably not. Also either you or the card vendor can write the software to 'look ahead' X number of responses for auto resync. Although when used this way it means you are returned X number of keys to try to authenticate HASH_I or HASH_R. As long as a central server with some sort of look ahead is used I don't see synchronization being that big a deal where it can't be done by some means out of band to IKE since it will be infrequent. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > ---------- > From: Moshe Litvin[SMTP:moshe@CheckPoint.COM] > Sent: Thursday, July 23, 1998 1:45 PM > To: Greg Carter > Cc: moshe@CheckPoint.COM; ipsec@tis.com; Pat Calhoun (E-mail) > Subject: Re: Comments on "Hybrid Auth. mode for IKE" > > Greg, > > You proposal require perfect state synchronization between the client > and the server (either what is the last challenge "sent" or the exact > time). It is impossible in practice especially since there are no means > to synchronize them. > > Also notice that in the hybrid mode no challenge and no reply are > passing in the clear. > > Regards, > > Moshe > > > From owner-ipsec Thu Jul 23 21:56:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA19167 for ipsec-outgoing; Thu, 23 Jul 1998 21:55:39 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199807231505.IAA01112@hsmpka.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jul 1998 17:54:22 -0400 To: Pat.Calhoun@Eng.Sun.Com From: Stephen Kent Subject: RE: Comments on "Hybrid Auth. mode for IKE" Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Pat, I have not looked at EAP, but the notion of transporting auth data between endpoints who are not directly connected seems like a reasonable goal. However, if these endpoints are not IPsec implementations, I would see this as an adjunct to IKE, not an alternative underlying mechanism. SOCKS and PPP have modes in which only bind-time auth is provided, i.e., there is nothing that cryptographically ties each successive packet to the initial auth exchange. This differs from IPsec, where the keying materail used with AH or with ESP auth/integrity is tied directly to the initial auth and encryption exchange. Given this fundamental dichotomy, I would not expect auth mechanisms to be completely interchangeable among all of these protocols in all of thier modes of use. Steve From owner-ipsec Thu Jul 23 21:57:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA19169 for ipsec-outgoing; Thu, 23 Jul 1998 21:55:40 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jul 1998 18:23:27 -0400 To: Greg Carter From: Stephen Kent Subject: RE: Comments on "Hybrid Auth. mode for IKE" Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, Thanks for bringing up biometrics. I querstion their place in distributed system authentication, of the sort we are discussing. Consider the following: -these schemes tend to be create a template of some biometric, after a registration process in which the user is reliably identified by some out-of-band means. the template is then stored on some server for later access. this template cannot be stored in a one-way hashed fashion, as we would a password, because it must be possible to match the captured measurements against the template to "score" the auth attempt. in general, this means that if one were to break into a server where these templates are stored, it would be possible to gain access to the plaintext templates. also note that unlike a key or a password, if a compromise occurs, changing a biometric is generally infeasible! - with knowledge of a template, the scoring algorithm, and the biometric capture algorithm (all of which is known to vendors and should be assumed to be knowable by attacker), it is possible to work backwards to generate bit strings that will pass the scoring algorithm for the user template in question. - in a distributed system, one has little or no control over the biometric capture, i.e., one cannot tell if the bitstring being sent to the server is really a biometric, or is from some other source at the remote login site. this is fundamentally due to physical security limits on the capture technoogy. most systems do not protect the biometric in a fashion that provides data origin authentication. a few do try, but the packaging is not very tamper resistant (e.g., FIPS 140-1 level 3) and so it is safe to assume than one can spoof origin of the bitstring that is sent to the auth server, i.e., one can submit a manufactured bitstring. - thus, if a user's template for a given biometric is EVER compromised in any fashion, it would be possible for an attacker to generate a bit string that will appear to be from the user, and given the lack of physical security for capture, this bit string can be introduced into a system to authenticate the atacker as the purported, valid, user. Note that this analysis does not apply to situations where physical security of capture can be reasonably ensured, e.g., physical access control environments or ATM machines. In such circumstances the capture is not amenable to "spoofing." Steve From owner-ipsec Thu Jul 23 21:57:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA19168 for ipsec-outgoing; Thu, 23 Jul 1998 21:55:40 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jul 1998 18:36:13 -0400 To: Greg Carter From: Stephen Kent Subject: RE: Comments on "Hybrid Auth. mode for IKE" Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg, >Benefits - >No changes to IKE. >May increase security of DES based challenge/response cards since known >plain text/cipher text never flows over the network. DES cards when used >with protocols like RADIUS or TACACS do all the challenge/response in the >open. $250K and 56-224 hours later you have the key. In this mode DES is >combined with key hashes and no known text is transmitted over the network. >Supports DES cards, Time based cards (OK they'll have to write some code on >their server to give up the expected response based on ID, rather than a >simple yes/no response, but nothing is for free), PAP/CHAP (no reason to do >CHAP, just use the password as the secret... I don't disagree that this approach is better than sending the output of these tokens in the clear. But that's not the alternative we are considering in IPsec. The alternative is using certs and matching private keys to authenticate a user. >Drawbacks >Aggressive mode is the only practical choice. >Initialization and resync. Initialization is easily handled, resync is >doable. >Backend server will be needed to track card state. Not really a drawback, >every card manufacture I know offers a backend management server of some >sort which already does this. Since the backend server is now essentially a >key server you should probably run IPSEC over the link from the Gateway to >the server. > >Anyway my point is that it is doable with the current spec, no changes to >token hardware, maybe a little coding on the server side. Sure there are >some drawbacks but you want to use 1980's technology... Me, I don't want to use 80's technology :-)! Steve From owner-ipsec Thu Jul 23 21:58:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA19216 for ipsec-outgoing; Thu, 23 Jul 1998 21:58:38 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199807231521.IAA27088@kc.livingston.com> References: from "Stephen Kent" at Jul 22, 98 06:57:36 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jul 1998 19:24:10 -0400 To: suresh@livingston.com (Pyda Srisuresh) From: Stephen Kent Subject: Re: Comments on "Hybrid Auth. mode for IKE" Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Sures, >There may be a mis-understanding here. What I was saying was not what >you were alluding to. Re-authentication may be done any number of times, >if so desired, independent of what the authetication type is. CHAP allows >re-authentication. But, Re-authentication arguments you allude to apply >to existing authentication schemes as well as the exchange-type >authentication scheme being proposed. The re-auth issue seems to be a red herring at this point and I brought it up only because you cited it as a feature of XAUTH. I don't think it has a place in the usual IKE exchange, so I don't think it's true that it applies to all existing auth schemes. >I am drawing a distinction between an authentication mechanism that is >exchange oriented (starting with a ID_EXCH_START type payload, and >ending with a ID_EXCH_DONE payload) as opposed to a single-payload-type >authentication (ex: signature authentication). > >Within an exchange-type authentication, you could authenticate a >client in more than one-way. For example: Challenge/response >authentication, followed by smart token card authentication. >In general, the exchange type authentication could combine multiple >authentications and hence is a stronger mechanism for auth than a >single-payload-type authentcation. I don't agree. Several mediocre or poor methods are not necessarily as good much less better than one very good method. >Why do you call the current auth. mechanism continuous auth? They >authenticate each side just once using a single ID payload from either >side. Each IPsec packet is authenticated upon receipt (if one follows the recommendations in the IPsec arch doc) via AH or via ESP. That is continuous (data origin) authentication of the traffic. The keying material used to validate each packet is the product of an IKE D-H exchange, but that provides no intrinsic authentication. The exchange of certs and the demonstration of possesion of the corresponding private keys to sign selected data ties the IKE key material exchange to the continuous, per-packet autentication. >I dont quite parse you last sentence right. I am arguing for using smart >token cards for IKE authentication. I don't get that from your message. IKE works fine with a smart card or PC card that is used to perform the crypto in support of IKE. We need no changes to accommodate such use. The thrust of this discussion seems to be to accommodate legacy technology that operates in an offline mode, e.g., a SecurID card, that cannot perform the crypto operations needed for IKE. Such technologies don't provide two-way authentication, since the user's token is not prepared to validate any challenge from the other end of the SA. That would seem to make such techniques intrinsically less secure, right? >> >Lastly, certificate based authentication you suggests requires a vast >> >deployment of CA infrastructure, which is not in place yet. Many of the >> >ISP consortiums have to go with what is commonly available as opposed to >> >what a single enterprise or a limited no. of ISPs have. Would you rather >> >that remote access applications not utilize the benefits of IPsec until >> >the certificate deployment is common place? I would think not. >> >> Not true. I have personal experience establ;ishing PKIs that were derrived >> from name/password baselines. It can be done easily, especially for >> intranets and for closed user communities. Since I'm in the PKI business I >> may me accused of being biased ;-), but I also have some ammount of >> experience proving assertions of this sort to be false. >> > >You may be right in that there are CA deployments, based on name/password >baselines. But, CA deployment is still very small compared to RADIUS based >deployments for CHAP and token card authentications. I agree, but that does not make these technologies equivalent in terms of security nor desirable as alternatives. IPsec is a new, better technology and to fulfill its potential we should be making use of precisely the two-way auth mechanisms for which it was initially engineered. >> >> > However, it doesnt have to be that way. If desired, the remote >> >> > user could run the same token card/CHAP mechanisms to >>authenticate >> >> > the edge device. >> >> >> >> That's definately a step down in security! Why even suggest this? >> > >> >Well, not really. It is just an extension of the authentication >> >mechanism to both parties. Now I don't understand what you're saying. Either the token can do the crypto for IKE or it cannot. If it can, we are done aond don't need XAUTH. If not, I don't see how this is "an extension of the authentication mechanism to both parties." Both parties have an auth mechanism in IKE already. >> If we have authenticated end points using good keys associayted with certs, >> it's not at all clear that use of additional, weaker mechanisms adds to the >> strength of the system, while it certainly adds to the complexity of design >> and management! My clients want fewer user auth databases to manage, not >> more, and moving these databases to certs is the best approach from a >> security perspective, in most cases. >> > >Hmm... Seems to me, you have the logic the other way around. Certificate >based authentication is lot more complex to design, implement and manage >than CHAP type authentication. Certificate based CAs are yet another >infrastructure and auth database to deloy and manage. So are secure-DNS, >Kerberos and so forth. I say this again, slightly differently: If one has a password-based auth system, it can become the basis for user registration for a PKI. Registration is the most expensive part of PKI management. Steady state management is relatively easy. By the way, you use the phrase "Certificate based CAs" in your comment above, suggesting that there are CAs that are not cert based. I find that puzzling since a CA is a Certification Authority. Please explain what you meant by this phrase. >Customers want fewer databases. But, only time will tell which database >they would want to keep. In the mean time, it is important to support the >existing databases while trying to leap frog into other databases. I already explianed how one can do that. >> >> > 4. SA lifetime: >Let us say, there is a way to determine the connect time of a remote >user into enterprise network. I am refering to such a network-connected-time >as the metric. I was suggesting to keep the negotiated SAs alive for the >whole of network-connected-time, as opposed to an arbitrary time-bound >or data-bounbd lifetime. Of course, Network-connected-time could in >itself be combined with time-bound and/or data-bound lifetimes. Yes, one could do that, but in practice these two are likely to converge. I expect most SAs using reasonable algorithms to have an SA lifetime longer than the time one would be connected as a remote user (vs. an SG-SG tunnel). So, as I said before, why do you think a net connect time metric is needed. Steve From owner-ipsec Thu Jul 23 21:58:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA19217 for ipsec-outgoing; Thu, 23 Jul 1998 21:58:38 -0400 (EDT) Message-Id: <199807240212.WAA03248@penelope.ve3tla.ampr.org> To: ipsec@tis.com Subject: Re: Target date and implementation ? References: <199807231806.LAA04862@yupa.ca.mew.com> In-reply-to: mat's message of "Thu, 23 Jul 1998 14:12:07 -0400". <199807231806.LAA04862@yupa.ca.mew.com> From: "C. Harald Koch" Date: Thu, 23 Jul 1998 22:12:34 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199807231806.LAA04862@yupa.ca.mew.com>, Nobuo Matsuo writes: > Hello everyone, > > Are there any target date and/or schedule to fix IPSEC 2,ISAKMP > drafts as RFCs ? Ya, "Any day now". The fact that it's been "Any day now" for a *year* is frustrating, though. So, what is the holdup *this* time? I thought we had dealt with Thomas Narten's Discuss vote; have the drafts been resubmitted to the IESG since then? (Not that I care much anymore, as I'm no longer working on IPsec products after next week :-) -- Harald Koch From owner-ipsec Thu Jul 23 22:04:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19248 for ipsec-outgoing; Thu, 23 Jul 1998 22:04:37 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01B14308@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jul 1998 16:21:09 -0400 To: Stephen Waters From: Stephen Kent Subject: RE: ESP and AH used in tunnel mode by a Security Gateway Cc: Ben Rogers , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, > Yes, I suppose once I have applied ESP-Tunnel, using AH as well >become transport mode - unless > I really want to incur the overhead of yet another IP header. See my note to Ben. If an SA originates or termninates at an SG, it MUST be in tunnel mode. We've been over this several time before. Steve From owner-ipsec Thu Jul 23 22:04:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19254 for ipsec-outgoing; Thu, 23 Jul 1998 22:04:43 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Stephen Waters's message of Thu, 23 Jul 1998 14:45:29 +0100 <250F9C8DEB9ED011A14D08002BE4F64C01B14301@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jul 1998 16:17:15 -0400 To: Ben Rogers From: Stephen Kent Subject: Re: ESP and AH used in tunnel mode by a Security Gateway Cc: Stephen Waters , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, >You could do this. However, you'll want to be a little more precise >with your terminology. > >ESP and AH in tunnel mode: > >IP AH IP ESP IP DATA > >You probably intended to apply ESP in tunnel mode and AH in transport >mode on top of that: Steve cited an SG as the IPsec site in question, so transport mode is not applicable, since ALL transit traffic SAs at an SG are tunnel mode. >IP AH ESP IP DATA > >Note that in an ISAKMP negotiation, you would negotiate a single >proposal containing an ESP transform with the tunnel mode attribute >and an AH transform with the transport mode attribute. (This is >something we agreed to some time ago but which might not have made it >into the docs yet.) The arch doc does call for tunnel+transport mode support at hosts, not SGs. Steve From owner-ipsec Thu Jul 23 22:07:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19283 for ipsec-outgoing; Thu, 23 Jul 1998 22:07:40 -0400 (EDT) To: Stephen Kent Cc: Stephen Waters , ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway References: Stephen Waters's message of Thu, 23 Jul 1998 14:45:29 +0100 <250F9C8DEB9ED011A14D08002BE4F64C01B14301@wade.reo.dec.com> From: Ben Rogers Date: 23 Jul 1998 22:20:00 -0400 In-Reply-To: Stephen Kent's message of Thu, 23 Jul 1998 16:17:15 -0400 Message-ID: Lines: 56 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, > >IP AH IP ESP IP DATA > > > >You probably intended to apply ESP in tunnel mode and AH in transport > >mode on top of that: > > Steve cited an SG as the IPsec site in question, so transport mode is not > applicable, since ALL transit traffic SAs at an SG are tunnel mode. Even if it is on top of a tunnel mode header? Given the network: H1-----SG1------SG2-----H2 If we first do tunnel mode ESP: IP(SG1->SG2) ESP IP(H1->H2) DATA we are now sending a packet to the other end of the "tunnel" and can legally encapasulate it with AH in transport mode by absorbing a little bit of extra functionality. > >IP AH ESP IP DATA > > > >Note that in an ISAKMP negotiation, you would negotiate a single > >proposal containing an ESP transform with the tunnel mode attribute > >and an AH transform with the transport mode attribute. (This is > >something we agreed to some time ago but which might not have made it > >into the docs yet.) > > The arch doc does call for tunnel+transport mode support at hosts, not SGs. And that's not a problem. The issue is that if two Security Gateways want to speak both AH and ESP simultaneously (even though this isn't a requirement), they ought to be able to negotiate it with ISAKMP. Clearly, this is most accurately described by ESP in tunnel mode followed by AH in transport mode. However, as Dan points out, there are some serious configuration issues if you do this -- the least of which is the requirement to define two different entries in the SPD (an ESP, tunnel mode for the traffic between H1 and H2 and an AH transport mode for ESP traffic between SG1 and SG2). It would be simpler, as a result, to negotiate both the AH and ESP as a single ISAKMP proposal, AND to negotiate both with tunnel attributes. It doesn't seem that anyone has many strong feelings either way (especially since this isn't a requirement), but it would be nice to have an agreement documented somewhere in the working group drafts (my feeling is that ipsec-doi is most appropriate). It may also be helpful to describe this special-case use of transport mode AH by Security Gateways as a "MAY" in the arch-sec document. ben From owner-ipsec Thu Jul 23 23:17:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA19416 for ipsec-outgoing; Thu, 23 Jul 1998 23:16:38 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199807231806.LAA04862@yupa.ca.mew.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jul 1998 22:59:38 -0400 To: mat@ca.mew.com (Nobuo Matsuo) From: Stephen Kent Subject: Re: Target date and implementation ? Cc: ipsec@tis.com, mat@ca.mew.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Nobuo, The AH, ESP, and Ipsec Arch Doc have been revised and resubmitted to the IESG this week. A summary of the changes and rationale is being postede to the list. Steve From owner-ipsec Fri Jul 24 03:55:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA20057 for ipsec-outgoing; Fri, 24 Jul 1998 03:53:36 -0400 (EDT) Date: Fri, 24 Jul 1998 17:17:04 +0900 (JST) Message-Id: <199807240817.RAA06331@parasite.yokogawa.co.jp> From: Ne To: ipsec@tis.com Subject: PFKEYv2 and IKEd. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailer: mnews [version 1.21PL3] 1998-04/12(Sun) Sender: owner-ipsec@ex.tis.com Precedence: bulk I have some basic question of about concerned with PFKEYv2 and IKE. The first, the draft-mcdonald-pf-key-v2-06.txt says, 5.1 Simple IP Security Example Assume that no security associations currently exist for IPsec to use. Consider when a network application begins transmitting data (e.g. a TCP SYN). Because of policy, or the application's request, the kernel IPsec module needs an AH security association for this data. Since there is not one present, the following message is generated: Kernel->Registered: SADB_ACQUIRE for AH, addrs, ID, sens, The KMd reads the ACQUIRE message, especially the sadb_msg_seq number. Before it begins the negotiation, it sends down an SADB_GETSPI message with the sadb_msg_seq number equal to the one received in the ACQUIRE. The kernel returns the results of the GETSPI to all listening sockets. KMd->Kernel: SADB_GETSPI for AH, addr, SPI range Kernel->All: SADB_GETSPI for AH, assoc, addrs Who is this SPI for ? I think it is strange to do SADB_GETSPI on the sender system because the SPI must be decided by the receiver. The next, the draft-ietf-ipsec-isakmp-oakley-08.txt says, 5.5 Phase 2 - Quick Mode Quick Mode is essentially a SA negotiation and an exchange of nonces that provides replay protection. : : Quick Mode is defined as follows: Initiator Responder ----------- ----------- HDR*, HASH(1), SA, Ni [, KE ] [, IDci, IDcr ] --> <-- HDR*, HASH(2), SA, Nr [, KE ] [, IDci, IDcr ] HDR*, HASH(3) --> : : A single SA negotiation results in two security assocations-- one inbound and one outbound. I like to get the conviction. Are two security associations negotiated by a Quick Mode such as this figure ? If that is right, is it possible to negotiate a single direction of security association ? For example, the negotiation a SA for UDP packet. The another question about the figure, Which is the `Initiator' or `Responder' of which the packet causing this negotiation (e.g. a TCP SYN) ? I think there is a consistency to use both IKEd and PF_KEYv2. Please correct me when I'm wrong. Regards. ================== Shoichi Sakane From owner-ipsec Fri Jul 24 04:36:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA20209 for ipsec-outgoing; Fri, 24 Jul 1998 04:36:39 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01B14309@wade.reo.dec.com> From: Stephen Waters To: Ben Rogers Cc: ipsec@tis.com, John Bassett , Phil Ilett Subject: RE: ESP and AH used in tunnel mode by a Security Gateway Date: Fri, 24 Jul 1998 09:52:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, Having slept on this, I think I'm going to take a slightly different approach for the sake of the sanity of the folk configuring IPSEC. Since [IP AH IP ESP IP DATA] isn't of much use, my configuration tool asks if a given policy will apply tunnel OR transport mode. If for a tunnel mode policy, both ESP and AH are specified, I will interpret that as meaning [IP AH ESP IP DATA] - I don't really want to have to explain in the documentation that if you want a tunnel to be protected with ESP and AH, ESP needs to be specified as tunnel-mode and AH as transport mode! If this means I'll have to play tricks at the IKE API, then I'll live with that. Sound reasonable? Steve. > ---------- > From: Ben Rogers[SMTP:ben@ascend.com] > Sent: Thursday, July 23, 1998 6:58 PM > To: Stephen Waters > Cc: ipsec@tis.com > Subject: Re: ESP and AH used in tunnel mode by a Security Gateway > > Stephen Waters writes: > > > I seem to remember asking this question before, but.... > > > > Although not covered in the IPSEC architecture, is there any > > restriction on a Security Gateway > > applying both ESP and AH in tunnel mode? > > You could do this. However, you'll want to be a little more precise > with your terminology. > > ESP and AH in tunnel mode: > > IP AH IP ESP IP DATA > > You probably intended to apply ESP in tunnel mode and AH in transport > mode on top of that: > > IP AH ESP IP DATA > > Note that in an ISAKMP negotiation, you would negotiate a single > proposal containing an ESP transform with the tunnel mode attribute > and an AH transform with the transport mode attribute. (This is > something we agreed to some time ago but which might not have made it > into the docs yet.) > > > ben > From owner-ipsec Fri Jul 24 04:49:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA20251 for ipsec-outgoing; Fri, 24 Jul 1998 04:49:38 -0400 (EDT) To: Stephen Waters Cc: ipsec@tis.com, John Bassett , Phil Ilett Subject: Re: ESP and AH used in tunnel mode by a Security Gateway References: <250F9C8DEB9ED011A14D08002BE4F64C01B14309@wade.reo.dec.com> From: Ben Rogers Date: 24 Jul 1998 05:06:10 -0400 In-Reply-To: Stephen Waters's message of Fri, 24 Jul 1998 09:52:15 +0100 Message-ID: Lines: 39 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, Stephen Waters writes: > Ben, > > Having slept on this, I think I'm going to take a slightly different > approach for the sake of the > sanity of the folk configuring IPSEC. > > Since [IP AH IP ESP IP DATA] isn't of much use, my configuration > tool asks if a given policy > will apply tunnel OR transport mode. If for a tunnel mode policy, > both ESP and AH are specified, > I will interpret that as meaning [IP AH ESP IP DATA] - I don't > really want to have to explain in > the documentation that if you want a tunnel to be protected with ESP > and AH, ESP needs to be > specified as tunnel-mode and AH as transport mode! This is exactly the approach that I would recommend taking. There is no need to make things difficult on the user (unless you get a sadistic thrill from taunting them...). > If this means I'll have to play tricks at the IKE API, then I'll > live with that. I guess this depends on who designed your API and how forward-looking they were. I'm more concerned about what will get passed on the wire, and hope that we can agree to a combined proposal with both AH and ESP having tunnel attributes. > Sound reasonable? Sure. ben From owner-ipsec Fri Jul 24 10:14:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA21214 for ipsec-outgoing; Fri, 24 Jul 1998 10:10:38 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01B1430D@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Subject: key processing for manual and dynamic SA Date: Fri, 24 Jul 1998 15:27:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I have an 'interop' issue for keying material that I would like to hear some views on: 1) Manual Mode SA. As an example, I need to prompt the UI for a DES session key for an ESP SA. DES only actually requires a 56bit stream to do the calculation - although this 56bits is expanded to include parity-bits (probably for historic reasons - pre parity memory?). Should the UI ask for 56bits (14 hexadecimal digits) and then expand with parity bits and check against the weak-key list, or should the UI ask for 64bits. The problems with asking for 64bits are : a) either the use is expected to get the parity bit right b) or the management code applies the parity automatically a) is too much to ask and b) changes the key. For the sake of interop, I think we need to decide on a common way of presenting keying material at the UI. If one end of the link takes 56bits, and the other takes 64bits, converting between the two over the 'phone is not straightforward! For example, if one end gets a 56bit key at the UI of: 23fe45de56ab78 Given low-order-bit parity and auto-parity at the 64bit UI end, this key would be 'communicated' as: 22f790bae4b4acf0 (or something like that!). It sounds easiest (to me), if we could agree on using the non-parity version of the required key, where parity is an issue. Then I can easier 'communicate' manual keys without worrying about parity. 2) Dynamic Mode SA I am assuming the following process for generated keying material: Using DES as an example again, I strip 64bits from the generated keying material, apply parity bit logic and check the weak-key listings (again, this had better happen the same way on both systems). Question: What do I do if the constructed 64bit key is weak? Do I: a) reject the establishment b) move on one byte in the keying material and try again c) move on one-block (64bits) and try again? Again, the process needs to be standard. Thanks, Steve. From owner-ipsec Fri Jul 24 11:44:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21691 for ipsec-outgoing; Fri, 24 Jul 1998 11:42:40 -0400 (EDT) Message-Id: <199807241554.IAA11573@greatdane.cisco.com> To: Tim Jenkins cc: Ben Rogers , Stephen Waters , ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway In-reply-to: Your message of "Fri, 24 Jul 1998 11:12:40 EDT." <319A1C5F94C8D11192DE00805FBBADDF293D4F@exchange.timestep.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Jul 1998 08:54:47 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Yea, I completely forgot about that. Good point. Looking at this from the SA bundle point-of-view makes it even more compelling. Dan. On Fri, 24 Jul 1998 11:12:40 EDT you wrote > > Why has no one referred to "protection suites" as defined in the DOI > document and Oakley or "SA bundles" as defined in the architecture > document? > > Use of these concepts would simplify these discussions, since it would > reduce the ambiguity of application. For example, a gateway could apply > an IPCOMP-ESP-AH bundle as > > IP [AH ESP PCP] IP DATA > > where a host could do either > > IP [AH ESP PCP] IP DATA (tunnel mode) > or IP [AH ESP PCP] DATA (transport mode) > > In this case, there's no argument about whether AH and ESP are tunnel or > transport; they are part of a bundle that is tunnel or transport. > > Further, the rule that gateways may do only tunnel mode means that there > can be no confusion with security headers. What I mean is that all > security headers that are adjacent in packets must belong to the same > bundle. This is because the rule that gateways only use tunnel mode > means that there will always be an IP header between the layers of SA > bundles. > > An example: > > H1 --- SG1 ----- H2 > <-- AH --> (tunnel mode) > <---- ESP ------> (either mode) > > In this case packets between SG1 and H2 look like > > IP AH IP ESP DATA (H1 to H2 transport mode) > or IP AH IP ESP IP DATA (H1 to H2 tunnel mode) > > Now, all that is needed are explicit expiration rules to apply to > bundles. Implicitly, the entire bundle expires when any one of the SAs > in the bundle expires. > > Am I missing something here??? > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 > > > -----Original Message----- > From: Daniel Harkins [mailto:dharkins@cisco.com] > Sent: Thursday, July 23, 1998 4:16 PM > To: Ben Rogers > Cc: Stephen Waters; ipsec@tis.com > Subject: Re: ESP and AH used in tunnel mode by a Security Gateway > > > I really don't want to open this can-of-worms but it has some > interoperability implications. > > On 23 Jul 1998 13:58:28 EDT you wrote > > Stephen Waters writes: > > > > > I seem to remember asking this question before, but.... > > > > > > Although not covered in the IPSEC architecture, is there any > > > restriction on a Security Gateway > > > applying both ESP and AH in tunnel mode? > > > > You could do this. However, you'll want to be a little more precise > > with your terminology. > > > > ESP and AH in tunnel mode: > > > > IP AH IP ESP IP DATA > > > > You probably intended to apply ESP in tunnel mode and AH in transport > > mode on top of that: > > > > IP AH ESP IP DATA > > > > Note that in an ISAKMP negotiation, you would negotiate a single > > proposal containing an ESP transform with the tunnel mode attribute > > and an AH transform with the transport mode attribute. (This is > > something we agreed to some time ago but which might not have made it > > into the docs yet.) > > I don't remember agreeing to that. In fact, the only mention of this > I remember came up during the IPCOMP and IPSEC thread. On May 28, in > <199805282040.NAA01397@orna.mentat.com> Marc Hasson wrote: > > > > > I guess you could say that ESP is in transport mode, but what > about the > > case where both AH and ESP are applied to the same packet: > > > > [IP2][AH][ESP][IP1][data] > > > > Is AH in transport mode? > > Good point. I can hear people arguing it both ways and am sorry I > raised that side tidbit. Whats more important is that we all > understand > how to process the above, which I think is pretty clear in the > specs. > > Yes, I feel we can all process this but it's now apparent that we can't > all > negotiate it. > > The next header in AH is not IPinIP so I understand the point being > made. > But these two SAs are the result of a single rule. If PFS is also part > of > the rule it applies to both and the ID payloads passed in the QM > exchange > also apply to both. They are a single unit. > > If we have: > > H1 ------ SG1 ---------- SG2 ------- H2 > |<-- secured -->| | > |__ H3 > > the rules I've applied to SG1 (vice versa for SG2) is: > > For traffic from H1 to H2, apply AH and ESP and peer with SG2 > > If AH is in transport mode the rule becomes: > > For traffic from H1 to H2, apply ESP and peer with SG2 > For ESP traffic from SG1 to SG2 apply AH and peer with SG2 > > But if I want my packets from H1 to H2 to look like: > > IP[SG1-SG2] AH ESP IP[H1-H2] > > and from H1 to H3 to look like: > > IP[SG1-SG2] ESP [H1-H2] > > That'll break down because my packets ESP packets will match the rule > being applied for H1-H2 traffic and it'll have AH applied. There'd be > some > ugly code to prevent this from happening. SG2 would also have some ugly > spagetti code to make sure that, at decaps, AH is only applied to an ESP > > packet that was applied to H1-H2 traffic. That would be necessary since > the > AH+ESP negotiation specified H1-H2 and to use AH on an ESP packet that > was > H1-H3 would be in violation of that. > > Transport mode can't be applied by a SG to a packet in transit-- in > the > example a packet from H1 to H2. But if AH was treated as being in > transport > mode in IP AH ESP IP DATA then that's exactly what you'd be saying in > your > Quick Mode message. So you'd have to do two separate negotiations, one > for > ESP on IP between H1 and H2 and another for AH on ESP packets between > SG1 > and SG2, and that would have problems too because you would be unable to > > specify that traffic from H1 to H3 *not* have AH applied. > > I think it's better to treat AH as being in tunnel mode in this case. > It precludes lots of ugly, hard-to-maintain code, it makes UI much > simpler, > and it allows for a wider array of rules to be applied to various sorts > of > traffic. > > I'm not suggesting doing IP AH IP ESP IP DATA. I'm just suggesting > that > when we want to do IP AH ESP IP DATA that we negotiate it using the same > encapsulation attribute-- tunnel mode-- in both the AH and ESP > proposals. > This would also apply to IP ESP PCP IP DATA or IP AH ESP PCP IP DATA > too. > > Dan. > > ------ =_NextPart_001_01BDB715.801385E0 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3DUS-ASCII"> > 5.5.1960.3"> > RE: ESP and AH used in tunnel mode by a Security Gateway = > > > > >

Why has no one referred to "protection = > suites" as defined in the DOI document and Oakley or "SA = > bundles" as defined in the architecture document?

> >

Use of these concepts would simplify these = > discussions, since it would reduce the ambiguity of application. For = > example, a gateway could apply an IPCOMP-ESP-AH bundle as

> >

        IP [AH ESP = > PCP] IP DATA >

> >

where a host could do either >

> >

        IP [AH ESP = > PCP] IP DATA       (tunnel = > mode)

> >

  or  IP [AH ESP PCP] = > DATA      (transport mode) >

> >

In this case, there's no argument about whether AH = > and ESP are tunnel or transport; they are part of a bundle that is = > tunnel or transport.

> >

Further, the rule that gateways may do only tunnel = > mode means that there can be no confusion with security headers. What I = > mean is that all security headers that are adjacent in packets must = > belong to the same bundle. This is because the rule that gateways only = > use tunnel mode means that there will always be an IP header between = > the layers of SA bundles.

> >

An example: >

> >

  H1 --- SG1 ----- H2 >
SIZE=3D2>          <-- = > AH --> (tunnel mode) >
   <---- ESP ------> (either = > mode) >

> >

In this case packets between SG1 and H2 look = > like >

> >

        IP AH IP = > ESP DATA         (H1 to H2 transport = > mode) >
  or  IP AH IP ESP IP DATA  (H1 to H2 = > tunnel mode) >

> >

Now, all that is needed are explicit expiration rules = > to apply to bundles. Implicitly, the entire bundle expires when any one = > of the SAs in the bundle expires.

> >

Am I missing something here??? >

> >

--- >
Tim = > Jenkins           = > ;            = > TimeStep Corporation >
SIZE=3D2>tjenkins@timestep.com       = >    TARGET=3D"_blank">http://www.timestep.com >
(613) 599-3610 = > x4304           &= > nbsp;   Fax: (613) 599-3617 >

>
> >

-----Original Message----- >
From: Daniel Harkins [ HREF=3D"mailto:dharkins@cisco.com" = > TARGET=3D"_blank">mailto:dharkins@cisco.com] >
Sent: Thursday, July 23, 1998 4:16 PM >
To: Ben Rogers >
Cc: Stephen Waters; ipsec@tis.com >
Subject: Re: ESP and AH used in tunnel mode by a = > Security Gateway >

>
> >

  I really don't want to open this can-of-worms = > but it has some >
interoperability implications. >

> >

On 23 Jul 1998 13:58:28 EDT you wrote >
> Stephen Waters = > <Stephen.Waters@digital.com> writes: >
> >
> >     I seem to remember = > asking this question before, but.... >
> > >
> >     Although not covered in = > the IPSEC architecture, is there any >
> > restriction on a Security Gateway >
> >     applying both ESP and = > AH in tunnel mode? >
> >
> You could do this.  However, you'll want = > to be a little more precise >
> with your terminology. >
> >
> ESP and AH in tunnel mode: >
> >
> IP AH IP ESP IP DATA >
> >
> You probably intended to apply ESP in tunnel = > mode and AH in transport >
> mode on top of that: >
> >
> IP AH ESP IP DATA >
> >
> Note that in an ISAKMP negotiation, you would = > negotiate a single >
> proposal containing an ESP transform with the = > tunnel mode attribute >
> and an AH transform with the transport mode = > attribute.  (This is >
> something we agreed to some time ago but which = > might not have made it >
> into the docs yet.) >

> >

  I don't remember agreeing to that. In fact, = > the only mention of this >
I remember came up during the IPCOMP and IPSEC = > thread. On May 28, in >
<199805282040.NAA01397@orna.mentat.com> Marc = > Hasson wrote: >

> >

     > >
     > I guess you could say = > that ESP is in transport mode, but what about the >
     > case where both AH and = > ESP are applied to the same packet: >
     > >
     = > >      [IP2][AH][ESP][IP1][data] >
     > >
     > Is AH in transport = > mode? >
     >
     Good point.  I can = > hear people arguing it both ways and am sorry I >
     raised that side = > tidbit.  Whats more important is that we all understand >
     how to process the above, = > which I think is pretty clear in the specs. >
  >
Yes, I feel we can all process this but it's now = > apparent that we can't all >
negotiate it. >

> >

  The next header in AH is not IPinIP so I = > understand the point being made. >
But these two SAs are the result of a single rule. = > If PFS is also part of >
the rule it applies to both and the ID payloads = > passed in the QM exchange >
also apply to both. They are a single unit. >

> >

  If we have: >

> >

        H1 ------ = > SG1 ---------- SG2 ------- H2 >
SIZE=3D2>          &nb= > sp;       |<--  secured = > -->|     | >
SIZE=3D2>          &nb= > sp;           &nb= > sp;           &nb= > sp;      |__ H3 >

> >

the rules I've applied to SG1 (vice versa for SG2) = > is: >

> >

        For = > traffic from H1 to H2, apply AH and ESP and peer with SG2 >

> >

If AH is in transport mode the rule becomes: >

> >

        For = > traffic from H1 to H2, apply ESP and peer with SG2 >
        For ESP = > traffic from SG1 to SG2 apply AH and peer with SG2 >

> >

But if I want my packets from H1 to H2 to look = > like: >

> >

        SIZE=3D2>IP[SG1-SG2] AH ESP IP[H1-H2] >

> >

and from H1 to H3 to look like: >

> >

        SIZE=3D2>IP[SG1-SG2] ESP [H1-H2] >

> >

That'll break down because my packets ESP packets = > will match the rule >
being applied for H1-H2 traffic and it'll have AH = > applied. There'd be some >
ugly code to prevent this from happening. SG2 would = > also have some ugly >
spagetti code to make sure that, at decaps, AH is = > only applied to an ESP >
packet that was applied to H1-H2 traffic. That would = > be necessary since the >
AH+ESP negotiation specified H1-H2 and to use AH on = > an ESP packet that was >
H1-H3 would be in violation of that. >

> >

  Transport mode can't be applied by a SG to a = > packet in transit-- in the >
example a packet from H1 to H2. But if AH was = > treated as being in transport >
mode in IP AH ESP IP DATA then that's exactly what = > you'd be saying in your >
Quick Mode message. So you'd have to do two separate = > negotiations, one for >
ESP on IP between H1 and H2 and another for AH on = > ESP packets between SG1 >
and SG2, and that would have problems too because = > you would be unable to >
specify that traffic from H1 to H3 *not* have AH = > applied. >

> >

  I think it's better to treat AH as being in = > tunnel mode in this case. >
It precludes lots of ugly, hard-to-maintain code, it = > makes UI much simpler, >
and it allows for a wider array of rules to be = > applied to various sorts of >
traffic. >

> >

  I'm not suggesting doing IP AH IP ESP IP DATA. = > I'm just suggesting that >
when we want to do IP AH ESP IP DATA that we = > negotiate it using the same >
encapsulation attribute-- tunnel mode-- in both the = > AH and ESP proposals. >
This would also apply to IP ESP PCP IP DATA or IP AH = > ESP PCP IP DATA too. >

> >

  Dan. >

> > > > ------ =_NextPart_001_01BDB715.801385E0-- From owner-ipsec Fri Jul 24 12:10:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA21856 for ipsec-outgoing; Fri, 24 Jul 1998 12:09:39 -0400 (EDT) Date: Fri, 24 Jul 1998 12:25:32 -0400 Message-Id: <199807241625.MAA18358@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Stephen.Waters@digital.com Cc: ipsec@tis.com Subject: Re: key processing for manual and dynamic SA References: <250F9C8DEB9ED011A14D08002BE4F64C01B1430D@wade.reo.dec.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk The standard representation for DES keys is as 64 bit values, with the byte parity in the low order bit of each byte. The only sensible approach I can see for dealing with the parity bit is to ignore it. If the DES implementation requires valid parity (I've never seen one that does) then the software can invisibly supply the correct parity from the user supplied key. Passing just 56 bits as 14 hex digits does not strike me as a good approach, because it goes against well established precedent. As for dynamic keying and weak keys, there's an explicit list of weak keys to check for and a rule for how to deal with that. There are other keys ("possibly weak" in Scheier) in DES that you may or may not want to check for, as well as weak keys for other algorithms (IDEA, Blowfish). Since the spec doesn't explicitly require checking for those, you can't use a "move one byte and try again" approach. Instead, if you want to refuse such keys, the only method I can see that works is to negotiate another key (as if this key had already expired). paul From owner-ipsec Fri Jul 24 12:20:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA21954 for ipsec-outgoing; Fri, 24 Jul 1998 12:19:38 -0400 (EDT) From: Dan McDonald Message-Id: <199807241635.JAA28167@kebe.eng.sun.com> Subject: Re: key processing for manual and dynamic SA To: Stephen.Waters@digital.com (Stephen Waters) Date: Fri, 24 Jul 1998 09:35:33 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01B1430D@wade.reo.dec.com> from "Stephen Waters" at Jul 24, 98 03:27:02 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > 1) Manual Mode SA. > > As an example, I need to prompt the UI for a DES session key for an ESP SA. > DES only actually requires a 56bit stream to do the calculation - although > this 56bits is expanded to include parity-bits (probably for historic > reasons - pre parity memory?). > > Should the UI ask for 56bits (14 hexadecimal digits) and then expand with > parity bits and check against the weak-key list, or should the UI ask for > 64bits. I ask for 64 bits, and AFAIK everyone else's does too. > The problems with asking for 64bits are : > > a) either the use is expected to get the parity bit right > b) or the management code applies the parity automatically > > a) is too much to ask and b) changes the key. I do b), because it only changes the key if the parity is wrong. > For the sake of interop, I think we need to decide on a common way of > presenting keying material at the UI. If one end of the link takes 56bits, > and the other takes 64bits, converting between the two over the 'phone > is not straightforward! Everytime I've seen manual keys thrown around, it's been in 64-bit quantities. That's what we've done at the interoperability events. > It sounds easiest (to me), if we could agree on using the non-parity > version of the required key, where parity is an issue. Then I can easier > 'communicate' manual keys without worrying about parity. If the implementation fixes parity, you don't have to worry about it. If you and your friend agree that 1234567890abcdef is a good key, who cares if it gets adjusted to 1334577991abcdef (the standard "low-bit-parity" method)? > 2) Dynamic Mode SA You're right in that the derivation better be the same on both systems. > Question: What do I do if the constructed 64bit key is weak? Do I: > a) reject the establishment We discussed this before I think, and IIRC, the conclusion was to reject the establishment if weak key checks fail. Dan From owner-ipsec Fri Jul 24 13:40:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA22163 for ipsec-outgoing; Fri, 24 Jul 1998 13:38:42 -0400 (EDT) Date: Fri, 24 Jul 1998 13:50:35 -0400 (EDT) From: Henry Spencer To: Stephen Waters cc: ipsec@tis.com Subject: Re: key processing for manual and dynamic SA In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01B1430D@wade.reo.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > As an example, I need to prompt the UI for a DES session key for an ESP SA. > DES only actually requires a 56bit stream to do the calculation - although > this 56bits is expanded to include parity-bits (probably for historic > reasons - pre parity memory?). The reason for the parity bits, apparently, was to help protect "sealed box" crypto engines from attacks based on inducing one-bit errors by running them in extreme conditions (heat, voltage, electrical noise, etc.). It turns out that if you can induce such errors in the key, even randomly, then cryptanalysis of DES becomes quick and easy. With the parity bits, the crypto hardware can detect and reject keys with one-bit errors, which makes this attack vastly more difficult. > Should the UI ask for 56bits (14 hexadecimal digits) and then expand with > parity bits and check against the weak-key list, or should the UI ask for > 64bits. The user interface is not specified in the RFCs/drafts. However, there is overwhelming consensus among implementors that it is easiest to use a 64-bit UI, and have the interface to the crypto engine fix the parity bits as needed. Note that the IKE specs for DES specifically call for IKE to supply 64 random bits, so such an interface already has to be present. > For the sake of interop, I think we need to decide on a common way of > presenting keying material at the UI... We already have, de facto, although it's not exactly well documented. The test keys used at the interoperability workshops invariably are 64 bits with no attempt to supply correct parity. > It sounds easiest (to me), if we could agree on using the non-parity version > of the required key... This would probably have been the best solution -- supply 56 bits and let the implementations provide any necessary error protection -- but it's a lost battle now. > 2) Dynamic Mode SA ... > Question: What do I do if the constructed 64bit key is weak? Do I: > a) reject the establishment > b) move on one byte in the keying material and try again > c) move on one-block (64bits) and try again? It takes some searching to find any mention of this. The ciph-cbc draft appears to say that when you discover you have been given a weak key, you reject it and require that a new SA be generated. For the poorly-named "ISAKMP SA" (the communication path between the IKE daemons), the isakmp-oakley draft says that the first N non-weak bytes are used, which would seem to imply moving on one byte and trying again. > Again, the process needs to be standard. Given how rare weak keys are, it is quite possible that we will never know whether most implementations interoperate in this area. Other forms of rare error leading to communications failure will probably be more common. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Fri Jul 24 14:03:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22359 for ipsec-outgoing; Fri, 24 Jul 1998 14:03:40 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF293D4F@exchange.timestep.com> From: Tim Jenkins To: Daniel Harkins , Ben Rogers Cc: Stephen Waters , ipsec@tis.com Subject: RE: ESP and AH used in tunnel mode by a Security Gateway Date: Fri, 24 Jul 1998 11:12:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BDB715.801385E0" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BDB715.801385E0 Content-Type: text/plain; charset="iso-8859-1" Why has no one referred to "protection suites" as defined in the DOI document and Oakley or "SA bundles" as defined in the architecture document? Use of these concepts would simplify these discussions, since it would reduce the ambiguity of application. For example, a gateway could apply an IPCOMP-ESP-AH bundle as IP [AH ESP PCP] IP DATA where a host could do either IP [AH ESP PCP] IP DATA (tunnel mode) or IP [AH ESP PCP] DATA (transport mode) In this case, there's no argument about whether AH and ESP are tunnel or transport; they are part of a bundle that is tunnel or transport. Further, the rule that gateways may do only tunnel mode means that there can be no confusion with security headers. What I mean is that all security headers that are adjacent in packets must belong to the same bundle. This is because the rule that gateways only use tunnel mode means that there will always be an IP header between the layers of SA bundles. An example: H1 --- SG1 ----- H2 <-- AH --> (tunnel mode) <---- ESP ------> (either mode) In this case packets between SG1 and H2 look like IP AH IP ESP DATA (H1 to H2 transport mode) or IP AH IP ESP IP DATA (H1 to H2 tunnel mode) Now, all that is needed are explicit expiration rules to apply to bundles. Implicitly, the entire bundle expires when any one of the SAs in the bundle expires. Am I missing something here??? --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 -----Original Message----- From: Daniel Harkins [mailto:dharkins@cisco.com] Sent: Thursday, July 23, 1998 4:16 PM To: Ben Rogers Cc: Stephen Waters; ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway I really don't want to open this can-of-worms but it has some interoperability implications. On 23 Jul 1998 13:58:28 EDT you wrote > Stephen Waters writes: > > > I seem to remember asking this question before, but.... > > > > Although not covered in the IPSEC architecture, is there any > > restriction on a Security Gateway > > applying both ESP and AH in tunnel mode? > > You could do this. However, you'll want to be a little more precise > with your terminology. > > ESP and AH in tunnel mode: > > IP AH IP ESP IP DATA > > You probably intended to apply ESP in tunnel mode and AH in transport > mode on top of that: > > IP AH ESP IP DATA > > Note that in an ISAKMP negotiation, you would negotiate a single > proposal containing an ESP transform with the tunnel mode attribute > and an AH transform with the transport mode attribute. (This is > something we agreed to some time ago but which might not have made it > into the docs yet.) I don't remember agreeing to that. In fact, the only mention of this I remember came up during the IPCOMP and IPSEC thread. On May 28, in <199805282040.NAA01397@orna.mentat.com> Marc Hasson wrote: > > I guess you could say that ESP is in transport mode, but what about the > case where both AH and ESP are applied to the same packet: > > [IP2][AH][ESP][IP1][data] > > Is AH in transport mode? Good point. I can hear people arguing it both ways and am sorry I raised that side tidbit. Whats more important is that we all understand how to process the above, which I think is pretty clear in the specs. Yes, I feel we can all process this but it's now apparent that we can't all negotiate it. The next header in AH is not IPinIP so I understand the point being made. But these two SAs are the result of a single rule. If PFS is also part of the rule it applies to both and the ID payloads passed in the QM exchange also apply to both. They are a single unit. If we have: H1 ------ SG1 ---------- SG2 ------- H2 |<-- secured -->| | |__ H3 the rules I've applied to SG1 (vice versa for SG2) is: For traffic from H1 to H2, apply AH and ESP and peer with SG2 If AH is in transport mode the rule becomes: For traffic from H1 to H2, apply ESP and peer with SG2 For ESP traffic from SG1 to SG2 apply AH and peer with SG2 But if I want my packets from H1 to H2 to look like: IP[SG1-SG2] AH ESP IP[H1-H2] and from H1 to H3 to look like: IP[SG1-SG2] ESP [H1-H2] That'll break down because my packets ESP packets will match the rule being applied for H1-H2 traffic and it'll have AH applied. There'd be some ugly code to prevent this from happening. SG2 would also have some ugly spagetti code to make sure that, at decaps, AH is only applied to an ESP packet that was applied to H1-H2 traffic. That would be necessary since the AH+ESP negotiation specified H1-H2 and to use AH on an ESP packet that was H1-H3 would be in violation of that. Transport mode can't be applied by a SG to a packet in transit-- in the example a packet from H1 to H2. But if AH was treated as being in transport mode in IP AH ESP IP DATA then that's exactly what you'd be saying in your Quick Mode message. So you'd have to do two separate negotiations, one for ESP on IP between H1 and H2 and another for AH on ESP packets between SG1 and SG2, and that would have problems too because you would be unable to specify that traffic from H1 to H3 *not* have AH applied. I think it's better to treat AH as being in tunnel mode in this case. It precludes lots of ugly, hard-to-maintain code, it makes UI much simpler, and it allows for a wider array of rules to be applied to various sorts of traffic. I'm not suggesting doing IP AH IP ESP IP DATA. I'm just suggesting that when we want to do IP AH ESP IP DATA that we negotiate it using the same encapsulation attribute-- tunnel mode-- in both the AH and ESP proposals. This would also apply to IP ESP PCP IP DATA or IP AH ESP PCP IP DATA too. Dan. From owner-ipsec Fri Jul 24 14:05:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22394 for ipsec-outgoing; Fri, 24 Jul 1998 14:05:41 -0400 (EDT) Message-ID: <0171F2F8F9E5D011A4D10060B03CFB44114083@SCC-SERVER3> From: CJ Gibson To: Stephen Waters Cc: ipsec@tis.com Subject: RE: key processing for manual and dynamic SA Date: Fri, 24 Jul 1998 11:30:27 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Steven, I think this was discussed a long time ago (Detroit time frame?) and it was decided that 64-bits of keying material would be used for DES, and the code which received the 64-bits would modify the parity bits so each byte has odd parity. If this is no longer true, I'd like to hear about it also! -CJ -----Original Message----- From: Stephen Waters [SMTP:Stephen.Waters@digital.com] Sent: Friday, July 24, 1998 7:27 AM To: ipsec@tis.com Subject: key processing for manual and dynamic SA Hi, I have an 'interop' issue for keying material that I would like to hear some views on: 1) Manual Mode SA. As an example, I need to prompt the UI for a DES session key for an ESP SA. DES only actually requires a 56bit stream to do the calculation - although this 56bits is expanded to include parity-bits (probably for historic reasons - pre parity memory?). Should the UI ask for 56bits (14 hexadecimal digits) and then expand with parity bits and check against the weak-key list, or should the UI ask for 64bits. The problems with asking for 64bits are : a) either the use is expected to get the parity bit right b) or the management code applies the parity automatically a) is too much to ask and b) changes the key. For the sake of interop, I think we need to decide on a common way of presenting keying material at the UI. If one end of the link takes 56bits, and the other takes 64bits, converting between the two over the 'phone is not straightforward! For example, if one end gets a 56bit key at the UI of: 23fe45de56ab78 Given low-order-bit parity and auto-parity at the 64bit UI end, this key would be 'communicated' as: 22f790bae4b4acf0 (or something like that!). It sounds easiest (to me), if we could agree on using the non-parity version of the required key, where parity is an issue. Then I can easier 'communicate' manual keys without worrying about parity. 2) Dynamic Mode SA I am assuming the following process for generated keying material: Using DES as an example again, I strip 64bits from the generated keying material, apply parity bit logic and check the weak-key listings (again, this had better happen the same way on both systems). Question: What do I do if the constructed 64bit key is weak? Do I: a) reject the establishment b) move on one byte in the keying material and try again c) move on one-block (64bits) and try again? Again, the process needs to be standard. Thanks, Steve. From owner-ipsec Fri Jul 24 14:17:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22440 for ipsec-outgoing; Fri, 24 Jul 1998 14:14:43 -0400 (EDT) Message-Id: <199807241830.OAA22612@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-simpson-cbc-01.txt Date: Fri, 24 Jul 1998 14:30:48 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : ESP with Cipher Block Chaining (CBC) Author(s) : W. Simpson Filename : draft-simpson-cbc-01.txt Pages : 7 Date : 03-Jul-97 This document describes the Cipher Block Chaining (CBC) mode, used by a number of IP Encapsulating Security Payload (ESP) transforms. Internet-Drafts are 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-simpson-cbc-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-simpson-cbc-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-simpson-cbc-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980723171835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-cbc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-cbc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980723171835.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Jul 24 14:17:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22441 for ipsec-outgoing; Fri, 24 Jul 1998 14:14:43 -0400 (EDT) Message-Id: <199807241830.OAA22635@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-simpson-desx-02.txt Date: Fri, 24 Jul 1998 14:30:53 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The ESP DES-XEX3-CBC Transform Author(s) : W. Simpson, R. Baldwin Filename : draft-simpson-desx-02.txt Pages : 8 Date : 23-Jul-98 This document describes the 'DESX' DES-XEX3-CBC block cipher trans- form interface used with the IP Encapsulating Security Payload (ESP). Internet-Drafts are 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-simpson-desx-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-simpson-desx-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-simpson-desx-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: <19980723172403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-desx-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-desx-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980723172403.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Jul 24 15:38:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA22667 for ipsec-outgoing; Fri, 24 Jul 1998 15:37:42 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Daniel Harkins , Tim Jenkins Cc: Ben Rogers , Stephen Waters , ipsec@tis.com Subject: RE: ESP and AH used in tunnel mode by a Security Gateway Date: Fri, 24 Jul 1998 12:53:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, Tim > > Why has no one referred to "protection suites" as defined in the DOI > > document and Oakley or "SA bundles" as defined in the architecture > > document? > > > > Use of these concepts would simplify these discussions, > since it would > > reduce the ambiguity of application. For example, a gateway > could apply > > an IPCOMP-ESP-AH bundle as > > > > IP [AH ESP PCP] IP DATA > > > > where a host could do either > > > > IP [AH ESP PCP] IP DATA (tunnel mode) > > or IP [AH ESP PCP] DATA (transport mode) > > > > In this case, there's no argument about whether AH and ESP > are tunnel or > > transport; they are part of a bundle that is tunnel or transport. I agree that regarding the encapsulation mode as an attribute of the bundle, rather than as an attribute of the SA, is the cleanest way of looking at this. Should this imply that for a bundle, all the encapsulation mode values for each protocol (encoded in the Transform payloads) should have the same value, i.e. all transport or all tunnel, and that mixing them should be prohibited ? A couple of other questions for clarification The architecture spec talks about a wildcard value for the encapsulation mode, allowing a single SA to be used for both tunnel and transport, and says that a host must support this. However there is no codepoint assigned in the IPSEC DOI for "wildcard". How would I set up an IPSEC SA to use a wildcard encapsulation mode, and why would I ever want to do this ? Although it is spelled out clearly that for an ISAKMP SA, there cannot be two proposals with the same protocol-id (i.e. ISAKMP), I didn't spot any such restriction for Phase 2 SA negotiation. Does this imply that if I want to negotiate an ESP SA, using either DES or 3DES, I've got a choice in encoding this as 1 proposal with two transforms, or 2 proposals each with one transform ? Bryan Gleeson Shasta Networks. From owner-ipsec Fri Jul 24 16:05:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22735 for ipsec-outgoing; Fri, 24 Jul 1998 16:05:41 -0400 (EDT) To: Bryan Gleeson Cc: Daniel Harkins , Tim Jenkins , Stephen Waters , ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway References: From: Ben Rogers Date: 24 Jul 1998 16:17:40 -0400 In-Reply-To: Bryan Gleeson's message of Fri, 24 Jul 1998 12:53:31 -0700 Message-ID: Lines: 36 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk Bryan Gleeson writes: > A couple of other questions for clarification > > The architecture spec talks about a wildcard value for the > encapsulation mode, allowing a single SA to be used for > both tunnel and transport, and says that a host must support > this. However there is no codepoint assigned in the IPSEC DOI > for "wildcard". How would I set up an IPSEC SA to use a wildcard > encapsulation mode, and why would I ever want to do this ? I'm guessing that since the encapsulation mode attribute is optional, the wildcard would be the absence of this attribute. I think that it is a valuable thing to do on a Security Gateway which can also act as a Host implementation. That way, communication between hosts behind the SG to the remote end is in tunnel mode and between the SG and the remote end is in transport mode. This is the most efficient way to handle bandwidth in this case, since an unnecessary IP header is not added. > Although it is spelled out clearly that for an ISAKMP SA, > there cannot be two proposals with the same protocol-id (i.e. > ISAKMP), I didn't spot any such restriction for Phase 2 SA > negotiation. Does this imply that if I want to negotiate an > ESP SA, using either DES or 3DES, I've got a choice in encoding > this as 1 proposal with two transforms, or 2 proposals each > with one transform ? Yes, as long as the proposal numbers are distinct. Otherwise, the two proposals are AND'ed together. I really don't know how you would perform ESP AND ESP on a packet and call this a single Security Policy. This seems to be a necessary evil in order to allow the full AND/OR semantic described in ISAKMP 4.2. ben From owner-ipsec Fri Jul 24 16:14:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22768 for ipsec-outgoing; Fri, 24 Jul 1998 16:14:41 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Stephen Kent's message of Thu, 23 Jul 1998 16:17:15 -0400 Stephen Waters's message of Thu, 23 Jul 1998 14:45:29 +0100 <250F9C8DEB9ED011A14D08002BE4F64C01B14301@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Jul 1998 16:24:23 -0400 To: Ben Rogers From: Stephen Kent Subject: Re: ESP and AH used in tunnel mode by a Security Gateway Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, >> >IP AH IP ESP IP DATA >> > >> >You probably intended to apply ESP in tunnel mode and AH in transport >> >mode on top of that: >> >> Steve cited an SG as the IPsec site in question, so transport mode is not >> applicable, since ALL transit traffic SAs at an SG are tunnel mode. > >Even if it is on top of a tunnel mode header? Given the network: > > H1-----SG1------SG2-----H2 > >If we first do tunnel mode ESP: > >IP(SG1->SG2) ESP IP(H1->H2) DATA > >we are now sending a packet to the other end of the "tunnel" and can >legally encapasulate it with AH in transport mode by absorbing a >little bit of extra functionality. No, I'm afraid we can't. This is not just an issue of what IKE can negotiate. The Arch Doc is very clear on this point. Tunnel mode is needed at SGs to ensure unambiguous processing with regard to frammentation and with regard to what headers are checked against which SA selectors. In your example, the SA in question has selectors that are applicable to the inner IP header, not the outer header. Uniform processing for transport mode would call for the selectors to be matched against the outer IP header, which is not the intent here. >> >IP AH ESP IP DATA >> > >> >Note that in an ISAKMP negotiation, you would negotiate a single >> >proposal containing an ESP transform with the tunnel mode attribute >> >and an AH transform with the transport mode attribute. (This is >> >something we agreed to some time ago but which might not have made it >> >into the docs yet.) >> >> The arch doc does call for tunnel+transport mode support at hosts, not SGs. > >And that's not a problem. The issue is that if two Security Gateways >want to speak both AH and ESP simultaneously (even though this isn't a >requirement), they ought to be able to negotiate it with ISAKMP. No argument in principle, but the Arch Doc notes that such support is not required, and this admonition was made at the request of the implementor community. >Clearly, this is most accurately described by ESP in tunnel mode >followed by AH in transport mode. However, as Dan points out, there >are some serious configuration issues if you do this -- the least of >which is the requirement to define two different entries in the SPD >(an ESP, tunnel mode for the traffic between H1 and H2 and an AH >transport mode for ESP traffic between SG1 and SG2). I don't agree with the suggestion that AH should be in trnasport mode. As I said, any transit traffic SA involing an SG is in tunnel mode, for the reasons cited above. It is not the case that two SPD entries are required. If this combination of tunnel mode SAs were supported, it would be described as an SA bundle, since the requirement is that both AH and ESP be applied to each packet and both would be negotiated at the same time. The Arch Doc descibes this situation in section 4.4.3, page 18 in the July 98 draft. >It would be simpler, as a result, to negotiate both the AH and ESP as >a single ISAKMP proposal, AND to negotiate both with tunnel attributes. No argument there! >It doesn't seem that anyone has many strong feelings either way >(especially since this isn't a requirement), but it would be nice to >have an agreement documented somewhere in the working group drafts (my >feeling is that ipsec-doi is most appropriate). It may also be >helpful to describe this special-case use of transport mode AH by >Security Gateways as a "MAY" in the arch-sec document. Oh, please, let's not start introducing special cases of this sort :-(. IPsec processing is already complicated, and it will become even more so if we start introducing special cases of this sort. Steve From owner-ipsec Fri Jul 24 16:45:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22841 for ipsec-outgoing; Fri, 24 Jul 1998 16:43:43 -0400 (EDT) Message-Id: <199807242055.QAA28771@relay.hq.tis.com> Date: Fri, 24 Jul 98 16:56:02 EDT From: Karen Seo To: ipsec@tis.com cc: kseo@bbn.com Subject: IPsec Arch draft Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Following up on recent mailing list discussions, we've made the changes below to the IPsec Architecture document and submitted the draft to IETF secretariat. Thank you, Karen 1. Per email from Fukumoto Atsushi, we've fixed several may/MAY errors. Section "5.2.1 Selecting and Using an SA or SA Bundle", item 2, 4th sentence -- changed "MAY" to "may" From: 2. Use the SA found in (1) to do the IPsec processing... In general, a packet's source address MUST match the SA selector value. However, an ICMP packet received on a tunnel mode SA MAY have a source address other than that bound to *** the SA and thus such packets should be permitted as exceptions to this check. For an ICMP packet, the selectors from the enclosed problem packet (the source and destination addresses and ports should be swapped) should be checked against the selectors for the SA.... To: 2. Use the SA found in (1) to do the IPsec processing... In general, a packet's source address MUST match the SA selector value. However, an ICMP packet received on a tunnel mode SA may have a source address other than that bound to the SA and thus such packets should be permitted as exceptions to this check. For an ICMP packet, the selectors from the enclosed problem packet (the source and destination addresses and ports should be swapped) should be checked against the selectors for the SA.... Section "6.1.2.1 Propagation of PMTU", 2nd bullet -- changed "MAY" to "may" From: o PMTU message with >64 bits of IPsec header -- If the ICMP message contains more information from the original packet then there MAY be enough non-opaque information... *** To: o PMTU message with >64 bits of IPsec header -- If the ICMP message contains more information from the original packet then there may be enough non-opaque information ... Section "B.3.1 Identifying the Originating Host(s)", last paragraph -- changed "MAY" to "may" From: Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, if the ICMP message contains more information from the original packet, then there MAY be enough information to *** immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with the 5 fields (source address, destination address, source port, destination port, and transport protocol) needed to determine where to store/update the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. NOTE: The Next Protocol field MAY not be contained in the ICMP message and the use of *** ESP encryption MAY hide the selector fields that have been *** encrypted. To: Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, if the ICMP message contains more information from the original packet, then there may be enough information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with the 5 fields (source address, destination address, source port, destination port, and transport protocol) needed to determine where to store/update the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. NOTE: The Next Protocol field may not be contained in the ICMP message and the use of ESP encryption may hide the selector fields that have been encrypted. 2. Section "B.2 Fragmentation", first paragraph -- Per email from Karen Heron, clarified when to fragment by changing this section to match the text in AH (3.3.4) and ESP (3.3.5) documents: From: Fragmentation MUST be done after outbound IPsec processing. Reassembly MUST be done before inbound IPsec processing. The general reasoning is shown below (delimited by the ****'s). To: If required, IP fragmentation occurs after IPsec processing within an IPsec implementation. Thus, transport mode AH or ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH or ESP has been applied may itself be fragmented by routers en route, and such fragments MUST be reassembled prior to IPsec processing at a receiver. In tunnel mode, AH or ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway, "bump-in-the-stack" (BITS), or "bump-in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to such fragments. Note that a BITS or BITW implementation are examples of where a host IPsec implementation might receive fragments to which tunnel mode is to be applied. However, if transport mode is to be applied, then these implementations MUST reassemble the fragments prior to applying IPsec. 3. Section "4.4.3 Security Association Database (SAD)" -- Per email from the community, changed the following text to clarify what units to use for SA Lifetime. From: o Lifetime of this Security Association: a time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur. This may be expressed as a time or byte count. If time.... To: o Lifetime of this Security Association: a time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur. This may be expressed as a time or byte count, or a simultaneous use of both, the first lifetime to expire taking precedence. A compliant implementation MUST support both types of lifetimes, and must support a simultaneous use of both. If time... From owner-ipsec Fri Jul 24 16:54:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA22868 for ipsec-outgoing; Fri, 24 Jul 1998 16:54:44 -0400 (EDT) To: Stephen Kent Cc: ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway References: Stephen Kent's message of Thu, 23 Jul 1998 16:17:15 -0400 Stephen Waters's message of Thu, 23 Jul 1998 14:45:29 +0100 <250F9C8DEB9ED011A14D08002BE4F64C01B14301@wade.reo.dec.com> From: Ben Rogers Date: 24 Jul 1998 17:11:21 -0400 In-Reply-To: Stephen Kent's message of Fri, 24 Jul 1998 16:24:23 -0400 Message-ID: Lines: 89 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, Stephen Kent writes: > >And that's not a problem. The issue is that if two Security Gateways > >want to speak both AH and ESP simultaneously (even though this isn't a > >requirement), they ought to be able to negotiate it with ISAKMP. > > No argument in principle, but the Arch Doc notes that such support is not > required, and this admonition was made at the request of the implementor > community. Who are in turn getting pressure from their customers. We have several large customers who want to use AH as a strong integrity check for the packet and who don't much care about authenticity. Unless the authenticator in ESP can be modified to (optionally?) cover the outer IP header, we're going to be pretty well stuck with the concept of the combined transform for the Security Gateway. > >Clearly, this is most accurately described by ESP in tunnel mode > >followed by AH in transport mode. However, as Dan points out, there > >are some serious configuration issues if you do this -- the least of > >which is the requirement to define two different entries in the SPD > >(an ESP, tunnel mode for the traffic between H1 and H2 and an AH > >transport mode for ESP traffic between SG1 and SG2). > > I don't agree with the suggestion that AH should be in trnasport mode. As > I said, any transit traffic SA involing an SG is in tunnel mode, for the > reasons cited above. It is not the case that two SPD entries are required. > If this combination of tunnel mode SAs were supported, it would be > described as an SA bundle, since the requirement is that both AH and ESP be > applied to each packet and both would be negotiated at the same time. The > Arch Doc descibes this situation in section 4.4.3, page 18 in the July 98 > draft. Then we're not talking about pure AH and pure ESP, but about a funny protocol called IPsec (which further breaks the layering model, AND has two distinct protocol numbers). If you look at the following packet: IP AH ESP IP Data from the perspective of the AH, you are clearly talking about transport mode because there is not an IP header immediately following the AH. It seems that you are now talking about the AH ESP pair as a single block (SA bundle) which has either a tunnel or transport attribute. In this case, the way that we negotiate the bundle in ISAKMP doesn't make any sense because the attributes seem to be bound to individual transforms instead of to the entire bundle. Perhaps we need to change our description from (AH ESP in tunnel mode) to (AH ESP IP-in-IP) which is less ambiguous and more accurately meets the IP "Next Header" model. (And doesn't provide a second definition of IP-in-IP to boot!) > >It would be simpler, as a result, to negotiate both the AH and ESP as > >a single ISAKMP proposal, AND to negotiate both with tunnel attributes. > > No argument there! Great! Does anyone protest, or can we claim "rough consensus"? > >It doesn't seem that anyone has many strong feelings either way > >(especially since this isn't a requirement), but it would be nice to > >have an agreement documented somewhere in the working group drafts (my > >feeling is that ipsec-doi is most appropriate). It may also be > >helpful to describe this special-case use of transport mode AH by > >Security Gateways as a "MAY" in the arch-sec document. > > Oh, please, let's not start introducing special cases of this sort :-(. > IPsec processing is already complicated, and it will become even more so if > we start introducing special cases of this sort. Hmm... Is it not best to describe the current running systems? If we were to describe the way that AH+ESP is negotiated between Security Gateways, it would pretty much require having a pointer to somewhere in the Arch document. As a side note, I guess I missed the rationale for adding the complication beyond RFC1825. Defining a strict bond (currently called the SA bundle) inherently caused a combinitoric explosion in complexity. Anyone feel like enlightening me on a bit of ancient history? %) ben From owner-ipsec Fri Jul 24 17:04:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA22934 for ipsec-outgoing; Fri, 24 Jul 1998 17:04:44 -0400 (EDT) To: Dan McDonald Cc: Stephen.Waters@digital.com (Stephen Waters), ipsec@tis.com Subject: Re: key processing for manual and dynamic SA References: <199807241635.JAA28167@kebe.eng.sun.com> From: Ben Rogers Date: 24 Jul 1998 17:16:41 -0400 In-Reply-To: Dan McDonald's message of Fri, 24 Jul 1998 09:35:33 -0700 (PDT) Message-ID: Lines: 19 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan McDonald writes: > > The problems with asking for 64bits are : > > > > a) either the use is expected to get the parity bit right > > b) or the management code applies the parity automatically > > > > a) is too much to ask and b) changes the key. > > I do b), because it only changes the key if the parity is wrong. It may be useful to warn the user of this as well, as the parity can be used as a sanity check for typos. Whether this is helpful pretty much depends on how difficult you make it for someone to figure out they've entered the wrong key. Decryption errors are sometimes pretty subtle. ben From owner-ipsec Fri Jul 24 17:18:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA22999 for ipsec-outgoing; Fri, 24 Jul 1998 17:17:43 -0400 (EDT) To: Henry Spencer Cc: Stephen Waters , ipsec@tis.com Subject: Re: key processing for manual and dynamic SA References: From: Ben Rogers Date: 24 Jul 1998 17:30:05 -0400 In-Reply-To: Henry Spencer's message of Fri, 24 Jul 1998 13:50:35 -0400 (EDT) Message-ID: Lines: 33 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk Henry Spencer writes: > > 2) Dynamic Mode SA ... > > Question: What do I do if the constructed 64bit key is weak? Do I: > > a) reject the establishment > > b) move on one byte in the keying material and try again > > c) move on one-block (64bits) and try again? > > It takes some searching to find any mention of this. The ciph-cbc draft > appears to say that when you discover you have been given a weak key, you > reject it and require that a new SA be generated. For the poorly-named > "ISAKMP SA" (the communication path between the IKE daemons), the > isakmp-oakley draft says that the first N non-weak bytes are used, which > would seem to imply moving on one byte and trying again. This is actually ambiguous. I would have interpreted it as the first non-weak N-byte block, meaning that if bytes (0, ... ,N-1) are weak, you would try bytes (N, ... ,2N-1) instead. > > Again, the process needs to be standard. > > Given how rare weak keys are, it is quite possible that we will never know > whether most implementations interoperate in this area. Other forms of > rare error leading to communications failure will probably be more common. If anyone wants to ressurect their DES-MAC prf code, I can provide an ISAKMP daemon which will force a given key.... :) Otherwise, it is probably most wise to reject the negotiation and start from scratch. That way you are certain to interoperate. ben From owner-ipsec Fri Jul 24 17:33:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23090 for ipsec-outgoing; Fri, 24 Jul 1998 17:32:42 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807242149.OAA08423@kc.livingston.com> Subject: Re: Comments on "Hybrid Auth. mode for IKE" To: kent@bbn.com (Stephen Kent) Date: Fri, 24 Jul 1998 14:49:55 -0700 (PDT) Cc: suresh@livingston.com, ipsec@tis.com In-Reply-To: from "Stephen Kent" at Jul 23, 98 07:24:10 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Sures, > > >There may be a mis-understanding here. What I was saying was not what > >you were alluding to. Re-authentication may be done any number of times, > >if so desired, independent of what the authetication type is. CHAP allows > >re-authentication. But, Re-authentication arguments you allude to apply > >to existing authentication schemes as well as the exchange-type > >authentication scheme being proposed. > > The re-auth issue seems to be a red herring at this point and I brought it > up only because you cited it as a feature of XAUTH. I don't think it has a > place in the usual IKE exchange, so I don't think it's true that it applies > to all existing auth schemes. > OK. However, Re-auth does make sense, for example, if the remote site's authentication becomes questionable based on some application specific payload (or) some policy that requires it. But, I digress. > >I am drawing a distinction between an authentication mechanism that is > >exchange oriented (starting with a ID_EXCH_START type payload, and > >ending with a ID_EXCH_DONE payload) as opposed to a single-payload-type > >authentication (ex: signature authentication). > > > >Within an exchange-type authentication, you could authenticate a > >client in more than one-way. For example: Challenge/response > >authentication, followed by smart token card authentication. > >In general, the exchange type authentication could combine multiple > >authentications and hence is a stronger mechanism for auth than a > >single-payload-type authentcation. > > I don't agree. Several mediocre or poor methods are not necessarily as > good much less better than one very good method. > Well, exchange-type authentication is a strong requirement for legacy verification schemes. To that extent, it is valuable. I was merely extrapolating the process to suggest that we could use the scheme to perform multiple authentications in succession (example - 2 very good methods, one after the other). Apparantly, I have not been able to articulate this well. So, I will drop that line of discussion for the time being. Say, the Certification Authoriy is down for some reason and noone can get certs from there. Wouldnt you agree, it would be a good idea to have a backup authentication scheme in such a case? > >Why do you call the current auth. mechanism continuous auth? They > >authenticate each side just once using a single ID payload from either > >side. > > Each IPsec packet is authenticated upon receipt (if one follows the > recommendations in the IPsec arch doc) via AH or via ESP. That is > continuous (data origin) authentication of the traffic. The keying > material used to validate each packet is the product of an IKE D-H > exchange, but that provides no intrinsic authentication. The exchange of > certs and the demonstration of possesion of the corresponding private keys > to sign selected data ties the IKE key material exchange to the continuous, > per-packet autentication. > No argument there. I agree, ISAKMP Authentication is key to ensuring intrinsic authentication to session based SAs. Having said that, I also believe, it is important that people have multiple options to pursue. Let the market place decide what auth. scheme they like in different scenarios. > >I dont quite parse you last sentence right. I am arguing for using smart > >token cards for IKE authentication. > > I don't get that from your message. IKE works fine with a smart card or PC > card that is used to perform the crypto in support of IKE. We need no > changes to accommodate such use. The thrust of this discussion seems to be > to accommodate legacy technology that operates in an offline mode, e.g., a > SecurID card, that cannot perform the crypto operations needed for IKE. > Such technologies don't provide two-way authentication, since the user's > token is not prepared to validate any challenge from the other end of the > SA. That would seem to make such techniques intrinsically less secure, > right? > Hmm, I am confused. By smart token cards, I am refering to cards like SecurID card. Why should they perform any crypto operations for IKE? SecurID cards do provide 1-way authentication (Card user is authenticated by card verifier). Why should the authentication be 2-way? Each party can be independently Authenticated in a different way, whichever works best. > > >> >Lastly, certificate based authentication you suggests requires a vast > >> >deployment of CA infrastructure, which is not in place yet. Many of the > >> >ISP consortiums have to go with what is commonly available as opposed to > >> >what a single enterprise or a limited no. of ISPs have. Would you rather > >> >that remote access applications not utilize the benefits of IPsec until > >> >the certificate deployment is common place? I would think not. > >> > >> Not true. I have personal experience establ;ishing PKIs that were derrived > >> from name/password baselines. It can be done easily, especially for > >> intranets and for closed user communities. Since I'm in the PKI business I > >> may me accused of being biased ;-), but I also have some ammount of > >> experience proving assertions of this sort to be false. > >> > > > >You may be right in that there are CA deployments, based on name/password > >baselines. But, CA deployment is still very small compared to RADIUS based > >deployments for CHAP and token card authentications. > > I agree, but that does not make these technologies equivalent in terms of > security nor desirable as alternatives. IPsec is a new, better technology > and to fulfill its potential we should be making use of precisely the > two-way auth mechanisms for which it was initially engineered. > I disagree. I dont believe, two-way auth. mechanism has anything to with the strength of authentication. The market place decides based on multiple criteria including ease of use, security requirements, legacy requirements, cost associated and so forth. For this reason, I would not restrict options to just one kind. > >> >> > However, it doesnt have to be that way. If desired, the remote > >> >> > user could run the same token card/CHAP mechanisms to > >>authenticate > >> >> > the edge device. > >> >> > >> >> That's definately a step down in security! Why even suggest this? > >> > > >> >Well, not really. It is just an extension of the authentication > >> >mechanism to both parties. > > Now I don't understand what you're saying. Either the token can do the > crypto for IKE or it cannot. If it can, we are done aond don't need XAUTH. > If not, I don't see how this is "an extension of the authentication > mechanism to both parties." Both parties have an auth mechanism in IKE > already. > Token card based auth. is independent of XAUTH. Token card based auth. simply requires an exchange-type-authentication. > >> If we have authenticated end points using good keys associayted with certs, > >> it's not at all clear that use of additional, weaker mechanisms adds to the > >> strength of the system, while it certainly adds to the complexity of design > >> and management! My clients want fewer user auth databases to manage, not > >> more, and moving these databases to certs is the best approach from a > >> security perspective, in most cases. > >> > > > >Hmm... Seems to me, you have the logic the other way around. Certificate > >based authentication is lot more complex to design, implement and manage > >than CHAP type authentication. Certificate based CAs are yet another > >infrastructure and auth database to deloy and manage. So are secure-DNS, > >Kerberos and so forth. > > I say this again, slightly differently: If one has a password-based auth > system, it can become the basis for user registration for a PKI. > Registration is the most expensive part of PKI management. Steady state > management is relatively easy. By the way, you use the phrase "Certificate > based CAs" in your comment above, suggesting that there are CAs that are > not cert based. I find that puzzling since a CA is a Certification > Authority. Please explain what you meant by this phrase. > Oops.. I wasnt implying anything different. I guess, I just wanted the word "certificate" spelled out in the sentence :-) > >Customers want fewer databases. But, only time will tell which database > >they would want to keep. In the mean time, it is important to support the > >existing databases while trying to leap frog into other databases. > > I already explianed how one can do that. > > >> >> > 4. SA lifetime: > > >Let us say, there is a way to determine the connect time of a remote > >user into enterprise network. I am refering to such a network-connected-time > >as the metric. I was suggesting to keep the negotiated SAs alive for the > >whole of network-connected-time, as opposed to an arbitrary time-bound > >or data-bounbd lifetime. Of course, Network-connected-time could in > >itself be combined with time-bound and/or data-bound lifetimes. > > Yes, one could do that, but in practice these two are likely to converge. > I expect most SAs using reasonable algorithms to have an SA lifetime longer > than the time one would be connected as a remote user (vs. an SG-SG > tunnel). So, as I said before, why do you think a net connect time metric > is needed. > Say, the user chose an infinite lifetime option. When a user is disconnected from the network, the SAs are presumably still valid, right. In such a case, someone else could get on to the same machine and happily use the session SAs. By limiting the SA lifetime to "network-connected-time", the SAs automaitcally become invalid when the user is not connected to the network. > Steve > > cheers, suresh From owner-ipsec Fri Jul 24 19:55:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA23354 for ipsec-outgoing; Fri, 24 Jul 1998 19:54:42 -0400 (EDT) Date: Fri, 24 Jul 1998 17:01:48 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Re: Comments on "Hybrid Auth. mode for IKE" To: suresh@livingston.com Cc: ipsec@tis.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tWHr3a+ej+k9V+q7tiPJUA== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: suresh@livingston.com (Pyda Srisuresh) > Say, the user chose an infinite lifetime option. When a user is disconnected > from the network, the SAs are presumably still valid, right. In such a case, > someone else could get on to the same machine and happily use the session > SAs. By limiting the SA lifetime to "network-connected-time", the SAs > automaitcally become invalid when the user is not connected to the network. > Suresh, I am still not clear about the notion of "network-connected-time". If I access my corporate intranet using IPSec from a LAN in the IETF computer room, what is my "network-connected-time" and how does the corporate IPSec gateway detect that I am no longer on the network? Isn't it simpler to negotiate a finite lifetime (for remote access this might be a couple of hours) and renew it as needed? When the user is done communicating with the corporate intranet, he could, in addition, delete the IPSec and ISAKMP SAs protecting traffic to/from the corporate intranet from the local SA database and send a delete notification to the IPSec gateway. Even if the notification is lost and the gateway does not delete SAs on its end immediately (according to the current drafts, delete notifications are not requests for the receiver to delete its SA), at least a new user won't be able to gain unauthorized access. Clearly, establishment of any SAs used in remote access must be contingent on being able to authenticate the remote user, not just the remote host. Another possibility for IPSecond might be to associate idle times with SAs -- an SA is deleted if it hasn't been used for a while. Is this what you meant by "network-connected-time"? vipul From owner-ipsec Fri Jul 24 20:21:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA23404 for ipsec-outgoing; Fri, 24 Jul 1998 20:21:42 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807250039.RAA18546@kc.livingston.com> Subject: Re: Comments on "Hybrid Auth. mode for IKE" To: vgupta@nobel.Eng.Sun.COM Date: Fri, 24 Jul 1998 17:39:11 -0700 (PDT) Cc: suresh@livingston.com, ipsec@tis.com In-Reply-To: from "Vipul Gupta" at Jul 24, 98 05:01:48 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > > From: suresh@livingston.com (Pyda Srisuresh) > > > Say, the user chose an infinite lifetime option. When a user is disconnected > > from the network, the SAs are presumably still valid, right. In such a case, > > someone else could get on to the same machine and happily use the session > > SAs. By limiting the SA lifetime to "network-connected-time", the SAs > > automaitcally become invalid when the user is not connected to the network. > > > > Suresh, > > I am still not clear about the notion of "network-connected-time". > If I access my corporate intranet using IPSec from a LAN in the > IETF computer room, what is my "network-connected-time" and how does > the corporate IPSec gateway detect that I am no longer on the network? You state a mechanism to monitor connected-time in the last paragraph below. There may be other means. For example, if you negotiated an SA for a telnet session, then the SA would be retired soon after the session is done. > > Isn't it simpler to negotiate a finite lifetime (for remote access > this might be a couple of hours) and renew it as needed? > When the user is done communicating with the corporate intranet, > he could, in addition, delete the IPSec and ISAKMP SAs protecting > traffic to/from the corporate intranet from the local SA > database and send a delete notification to the IPSec gateway. > Even if the notification is lost and the gateway does not delete > SAs on its end immediately (according to the current drafts, delete > notifications are not requests for the receiver to delete its SA), > at least a new user won't be able to gain unauthorized access. > Clearly, establishment of any SAs used in remote access must be > contingent on being able to authenticate the remote user, not just > the remote host. > Are you saying it should be made mandatory for the user to do the clean up, when done with connecting to the enterprise. This is exactly what the network-connected-time metric would do. > Another possibility for IPSecond might be to associate > idle times with SAs -- an SA is deleted if it hasn't been used > for a while. Is this what you meant by "network-connected-time"? > Yes. > vipul > > cheers, suresh From owner-ipsec Fri Jul 24 22:05:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA23578 for ipsec-outgoing; Fri, 24 Jul 1998 22:04:44 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Ben Rogers , Bryan Gleeson Cc: Daniel Harkins , Tim Jenkins , Stephen Waters , ipsec@tis.com Subject: RE: ESP and AH used in tunnel mode by a Security Gateway Date: Fri, 24 Jul 1998 19:21:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, > > The architecture spec talks about a wildcard value for the > > encapsulation mode, allowing a single SA to be used for > > both tunnel and transport, and says that a host must support > > this. However there is no codepoint assigned in the IPSEC DOI > > for "wildcard". How would I set up an IPSEC SA to use a wildcard > > encapsulation mode, and why would I ever want to do this ? > > I'm guessing that since the encapsulation mode attribute is optional, > the wildcard would be the absence of this attribute. I think that it > is a valuable thing to do on a Security Gateway which can also act as > a Host implementation. That way, communication between hosts behind > the SG to the remote end is in tunnel mode and between the SG and the > remote end is in transport mode. This is the most efficient way to > handle bandwidth in this case, since an unnecessary IP header is not > added. The spec says that an omitted encapsulation mode attribute means "unspecified (host-dependent)". If the "host-dependent" qualifier wasn't there I would have taken this to mean "wildcard", but because it is there I'm so sure. What is host-dependent about the semantics of wildcard as defined in the architecture spec? Isn't it just that transport and tunnel mode packets can be carried on the same SA? > > Although it is spelled out clearly that for an ISAKMP SA, > > there cannot be two proposals with the same protocol-id (i.e. > > ISAKMP), I didn't spot any such restriction for Phase 2 SA > > negotiation. Does this imply that if I want to negotiate an > > ESP SA, using either DES or 3DES, I've got a choice in encoding > > this as 1 proposal with two transforms, or 2 proposals each > > with one transform ? > > Yes, as long as the proposal numbers are distinct. Otherwise, the two > proposals are AND'ed together. I really don't know how you would > perform ESP AND ESP on a packet and call this a single Security > Policy. This seems to be a necessary evil in order to allow the full > AND/OR semantic described in ISAKMP 4.2. > Seems unfortunate that the protocol allows exactly the same semantics to be encoded in two different ways, as it increases the chances of interoperability problems and the amount of code needed. I don't think there would be any reduction in the range of things it is possible to express if there was a rule that proposals with different proposal numbers had to have distinct (bundles of) protocol-ids. Bryan From owner-ipsec Fri Jul 24 22:44:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA23647 for ipsec-outgoing; Fri, 24 Jul 1998 22:43:45 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199807241625.MAA18358@tonga.xedia.com> References: <250F9C8DEB9ED011A14D08002BE4F64C01B1430D@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Jul 1998 16:59:08 -0400 To: Paul Koning From: Stephen Kent Subject: Re: key processing for manual and dynamic SA Cc: Stephen.Waters@digital.com, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul, Most of the DES hardware I've seen does require a parity check on DES keys. Steve From owner-ipsec Sat Jul 25 03:00:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA24063 for ipsec-outgoing; Sat, 25 Jul 1998 02:58:46 -0400 (EDT) Message-ID: <008201bdb79b$7a544980$030b0ac0@cta1> From: "Todd S. Glassey" To: "Steve Bellovin" Cc: "Daniel Harkins" , , Subject: Re: Patent & licence for IPSec ? Date: Sat, 25 Jul 1998 00:11:25 -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.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, my apologies it took so long for me to answer as well as for involving the IPSec list in my efforts to resolve what I consider the ambiguity and shortcomings of the IP sections of RFC2026. It, this effort, belongs on the POISSON WG's list to say the least and so if you want to continue it, lets either take it offline or onto the POISSON WG. As a side note I am working on a new IP policy statement for potential inclusion in the next revision of RFC2026 that I will be filing in the next week or so in preparation for IETF-42. The new process eliminates the possibility of these types of events by creating a structure where the legal ability of the submitter to file the I-D, RFC, or other documents is established and substantiated. The intent, unlike the current RFC2026 IP text (see SS10 in particular), is to totally eliminate the possibility of this type of Submarine IP Warfare from occurring, not to just "state that it will not be tolerated". I'm sure that it will raise a lot of eyebrows but in the long run, I think that some version of it might pass. BTW - I totally disagree with your interpretation of the Dell Settlement. Although your argument looks good at the 50,000 foot level, if you are careful and read paragraph's one and two of the URL you provided, you will read that VESA established the VL-Bus working group in response to a number of already underway development processes and that in this case the cause-of-action is that an "official of Dell allegedly made a false statement to the standards board" as part of the board's voting on the standard. If this is true, then the act here is that Dell, with some level of direct intention "fraudulently misrepresented" that there were no impending IP issues regarding VL-Bus technologies and it makes sense that they got caught. As they stand today, there is really nothing in the IETF filing process that mandates this type of testimony or that any documented state of IP "state" is necessary to achieve a RFC or Standards' status - so this type of activity could not even happen with the current IETF process. If we had such a policy then we would have some legal recourse in these matters. So in closing - while I understand your intent, I still disagree with your analysis and believe that my original commentary is valid. Todd -----Original Message----- From: Steve Bellovin To: Todd S. Glassey Cc: Daniel Harkins ; ipsec@tis.com Date: 1998 July 21, Tuesday 10:48 Subject: Re: Patent & licence for IPSec ? >In message <014e01bdb4cc$fdd16ad0$030b0ac0@cta1>, "Todd S. Glassey" writes: >> >> If the IETF cannot make the use of it's standards more than a crap shoot >> then it may be doomed. What's the point of banking on a set of standards >> where the entry fee can be years in court and millions of dollars. >> >> This is a serious issue, because it gets at the standards process and the >> root of who pays for all our playpens and sandboxes. Whether we as engineers >> like it or not, Business and Business Process are driving the NII and all it >> stands fo'. >> >> Sorry to disagree with you but ... If the IETF cannot make its standards >> more secure from a commercial sense then its long term form and fashion are >> likely to change or to be changed. >> >> The first time somebody sues the IETF/IESG/ISOC for creating a standard and >> allowing the standard-process to complete when it has either "direct >> knowledge" or "enforced ignorance" as to the patent status of any given >> effort - The standards effort will change forever. After all if the IETF >> knowingly ignores the charter and in particular the IP issues inside of >> RFC2026 and its follow successors, IMHO - the IETF could wind up liable for >> damages by not enforcing its publicly stated operational processes and >> policies. > >Have you read RFC 2026, the current description of the IETF standards >process? While it's certainly true that anyone can be sued for more >or less anything, the relevant provisions were indeed drawn up in >consultation with a lawyer. Briefly -- the IETF *can't* have complete >knowledge of intellectual property claims on its work. (Nor, I might >add, can other standards bodies.) What is done is to require that anyone >who submits anything to the IETF agrees to disclose any intellectual >property rights in the submitted material. We also encourage people >to make the IETF aware of any possible conflicts. This is precisely >what Paul Lambert has just done. > >Btw -- not complying with the IETF process has reprecussions for folks >who lie about patents. See http://www.ftc.gov/opa/9511/dell.htm for >one example. > From owner-ipsec Sat Jul 25 15:32:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25121 for ipsec-outgoing; Sat, 25 Jul 1998 15:30:46 -0400 (EDT) Message-ID: From: "Grillo, John" To: "'ipsec@tis.com'" Subject: Network Management with IP Sec Date: Fri, 24 Jul 1998 17:23:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Currently, I manage tools which keep track of application percentages across the LAN and WAN based on TCP/UDP port number. The way I read the IP Sec RFC, the original packet will be encapsulated, a checksum is calculated, and then all information in the original packet is encrypted (or something along those line -- that's not the important part). If this is the case, I loose visibility into the original packet and therefore cannot determine the port it was using (the important part). I haven't read anything in the description of the headers that will translate to "application". I've asked a few network managment vendors how they will account for this protocol but no one had a good answer. I'm sure this was discussed, is there any information posted? Thanks, John D Grillo Global Network Planning and Design Compaq Computer Corporation Voice: (281) 514-3842 Pager: 1-800-724-3329 PIN 382-1086 From owner-ipsec Sat Jul 25 15:32:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25122 for ipsec-outgoing; Sat, 25 Jul 1998 15:30:47 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF293D4F@exchange.timestep.com> From: Tim Jenkins To: Daniel Harkins , Ben Rogers Cc: Stephen Waters , ipsec@tis.com Subject: RE: ESP and AH used in tunnel mode by a Security Gateway Date: Fri, 24 Jul 1998 11:12:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BDB715.801385E0" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BDB715.801385E0 Content-Type: text/plain; charset="iso-8859-1" Why has no one referred to "protection suites" as defined in the DOI document and Oakley or "SA bundles" as defined in the architecture document? Use of these concepts would simplify these discussions, since it would reduce the ambiguity of application. For example, a gateway could apply an IPCOMP-ESP-AH bundle as IP [AH ESP PCP] IP DATA where a host could do either IP [AH ESP PCP] IP DATA (tunnel mode) or IP [AH ESP PCP] DATA (transport mode) In this case, there's no argument about whether AH and ESP are tunnel or transport; they are part of a bundle that is tunnel or transport. Further, the rule that gateways may do only tunnel mode means that there can be no confusion with security headers. What I mean is that all security headers that are adjacent in packets must belong to the same bundle. This is because the rule that gateways only use tunnel mode means that there will always be an IP header between the layers of SA bundles. An example: H1 --- SG1 ----- H2 <-- AH --> (tunnel mode) <---- ESP ------> (either mode) In this case packets between SG1 and H2 look like IP AH IP ESP DATA (H1 to H2 transport mode) or IP AH IP ESP IP DATA (H1 to H2 tunnel mode) Now, all that is needed are explicit expiration rules to apply to bundles. Implicitly, the entire bundle expires when any one of the SAs in the bundle expires. Am I missing something here??? --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 -----Original Message----- From: Daniel Harkins [mailto:dharkins@cisco.com] Sent: Thursday, July 23, 1998 4:16 PM To: Ben Rogers Cc: Stephen Waters; ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway I really don't want to open this can-of-worms but it has some interoperability implications. On 23 Jul 1998 13:58:28 EDT you wrote > Stephen Waters writes: > > > I seem to remember asking this question before, but.... > > > > Although not covered in the IPSEC architecture, is there any > > restriction on a Security Gateway > > applying both ESP and AH in tunnel mode? > > You could do this. However, you'll want to be a little more precise > with your terminology. > > ESP and AH in tunnel mode: > > IP AH IP ESP IP DATA > > You probably intended to apply ESP in tunnel mode and AH in transport > mode on top of that: > > IP AH ESP IP DATA > > Note that in an ISAKMP negotiation, you would negotiate a single > proposal containing an ESP transform with the tunnel mode attribute > and an AH transform with the transport mode attribute. (This is > something we agreed to some time ago but which might not have made it > into the docs yet.) I don't remember agreeing to that. In fact, the only mention of this I remember came up during the IPCOMP and IPSEC thread. On May 28, in <199805282040.NAA01397@orna.mentat.com> Marc Hasson wrote: > > I guess you could say that ESP is in transport mode, but what about the > case where both AH and ESP are applied to the same packet: > > [IP2][AH][ESP][IP1][data] > > Is AH in transport mode? Good point. I can hear people arguing it both ways and am sorry I raised that side tidbit. Whats more important is that we all understand how to process the above, which I think is pretty clear in the specs. Yes, I feel we can all process this but it's now apparent that we can't all negotiate it. The next header in AH is not IPinIP so I understand the point being made. But these two SAs are the result of a single rule. If PFS is also part of the rule it applies to both and the ID payloads passed in the QM exchange also apply to both. They are a single unit. If we have: H1 ------ SG1 ---------- SG2 ------- H2 |<-- secured -->| | |__ H3 the rules I've applied to SG1 (vice versa for SG2) is: For traffic from H1 to H2, apply AH and ESP and peer with SG2 If AH is in transport mode the rule becomes: For traffic from H1 to H2, apply ESP and peer with SG2 For ESP traffic from SG1 to SG2 apply AH and peer with SG2 But if I want my packets from H1 to H2 to look like: IP[SG1-SG2] AH ESP IP[H1-H2] and from H1 to H3 to look like: IP[SG1-SG2] ESP [H1-H2] That'll break down because my packets ESP packets will match the rule being applied for H1-H2 traffic and it'll have AH applied. There'd be some ugly code to prevent this from happening. SG2 would also have some ugly spagetti code to make sure that, at decaps, AH is only applied to an ESP packet that was applied to H1-H2 traffic. That would be necessary since the AH+ESP negotiation specified H1-H2 and to use AH on an ESP packet that was H1-H3 would be in violation of that. Transport mode can't be applied by a SG to a packet in transit-- in the example a packet from H1 to H2. But if AH was treated as being in transport mode in IP AH ESP IP DATA then that's exactly what you'd be saying in your Quick Mode message. So you'd have to do two separate negotiations, one for ESP on IP between H1 and H2 and another for AH on ESP packets between SG1 and SG2, and that would have problems too because you would be unable to specify that traffic from H1 to H3 *not* have AH applied. I think it's better to treat AH as being in tunnel mode in this case. It precludes lots of ugly, hard-to-maintain code, it makes UI much simpler, and it allows for a wider array of rules to be applied to various sorts of traffic. I'm not suggesting doing IP AH IP ESP IP DATA. I'm just suggesting that when we want to do IP AH ESP IP DATA that we negotiate it using the same encapsulation attribute-- tunnel mode-- in both the AH and ESP proposals. This would also apply to IP ESP PCP IP DATA or IP AH ESP PCP IP DATA too. Dan. ------ =_NextPart_001_01BDB715.801385E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ESP and AH used in tunnel mode by a Security Gateway =

Why has no one referred to "protection = suites" as defined in the DOI document and Oakley or "SA = bundles" as defined in the architecture document?

Use of these concepts would simplify these = discussions, since it would reduce the ambiguity of application. For = example, a gateway could apply an IPCOMP-ESP-AH bundle as

        IP [AH ESP = PCP] IP DATA

where a host could do either

        IP [AH ESP = PCP] IP DATA       (tunnel = mode)

  or  IP [AH ESP PCP] = DATA      (transport mode)

In this case, there's no argument about whether AH = and ESP are tunnel or transport; they are part of a bundle that is = tunnel or transport.

Further, the rule that gateways may do only tunnel = mode means that there can be no confusion with security headers. What I = mean is that all security headers that are adjacent in packets must = belong to the same bundle. This is because the rule that gateways only = use tunnel mode means that there will always be an IP header between = the layers of SA bundles.

An example:

  H1 --- SG1 ----- H2
          <-- = AH --> (tunnel mode)
   <---- ESP ------> (either = mode)

In this case packets between SG1 and H2 look = like

        IP AH IP = ESP DATA         (H1 to H2 transport = mode)
  or  IP AH IP ESP IP DATA  (H1 to H2 = tunnel mode)

Now, all that is needed are explicit expiration rules = to apply to bundles. Implicitly, the entire bundle expires when any one = of the SAs in the bundle expires.

Am I missing something here???

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


-----Original Message-----
From: Daniel Harkins [mailto:dharkins@cisco.com]
Sent: Thursday, July 23, 1998 4:16 PM
To: Ben Rogers
Cc: Stephen Waters; ipsec@tis.com
Subject: Re: ESP and AH used in tunnel mode by a = Security Gateway


  I really don't want to open this can-of-worms = but it has some
interoperability implications.

On 23 Jul 1998 13:58:28 EDT you wrote
> Stephen Waters = <Stephen.Waters@digital.com> writes:
>
> >     I seem to remember = asking this question before, but....
> >
> >     Although not covered in = the IPSEC architecture, is there any
> > restriction on a Security Gateway
> >     applying both ESP and = AH in tunnel mode?
>
> You could do this.  However, you'll want = to be a little more precise
> with your terminology.
>
> ESP and AH in tunnel mode:
>
> IP AH IP ESP IP DATA
>
> You probably intended to apply ESP in tunnel = mode and AH in transport
> mode on top of that:
>
> IP AH ESP IP DATA
>
> Note that in an ISAKMP negotiation, you would = negotiate a single
> proposal containing an ESP transform with the = tunnel mode attribute
> and an AH transform with the transport mode = attribute.  (This is
> something we agreed to some time ago but which = might not have made it
> into the docs yet.)

  I don't remember agreeing to that. In fact, = the only mention of this
I remember came up during the IPCOMP and IPSEC = thread. On May 28, in
<199805282040.NAA01397@orna.mentat.com> Marc = Hasson wrote:

     >
     > I guess you could say = that ESP is in transport mode, but what about the
     > case where both AH and = ESP are applied to the same packet:
     >
     = >      [IP2][AH][ESP][IP1][data]
     >
     > Is AH in transport = mode?
    
     Good point.  I can = hear people arguing it both ways and am sorry I
     raised that side = tidbit.  Whats more important is that we all understand
     how to process the above, = which I think is pretty clear in the specs.
 
Yes, I feel we can all process this but it's now = apparent that we can't all
negotiate it.

  The next header in AH is not IPinIP so I = understand the point being made.
But these two SAs are the result of a single rule. = If PFS is also part of
the rule it applies to both and the ID payloads = passed in the QM exchange
also apply to both. They are a single unit.

  If we have:

        H1 ------ = SG1 ---------- SG2 ------- H2
          &nb= sp;       |<--  secured = -->|     |
          &nb= sp;           &nb= sp;           &nb= sp;      |__ H3

the rules I've applied to SG1 (vice versa for SG2) = is:

        For = traffic from H1 to H2, apply AH and ESP and peer with SG2

If AH is in transport mode the rule becomes:

        For = traffic from H1 to H2, apply ESP and peer with SG2
        For ESP = traffic from SG1 to SG2 apply AH and peer with SG2

But if I want my packets from H1 to H2 to look = like:

        IP[SG1-SG2] AH ESP IP[H1-H2]

and from H1 to H3 to look like:

        IP[SG1-SG2] ESP [H1-H2]

That'll break down because my packets ESP packets = will match the rule
being applied for H1-H2 traffic and it'll have AH = applied. There'd be some
ugly code to prevent this from happening. SG2 would = also have some ugly
spagetti code to make sure that, at decaps, AH is = only applied to an ESP
packet that was applied to H1-H2 traffic. That would = be necessary since the
AH+ESP negotiation specified H1-H2 and to use AH on = an ESP packet that was
H1-H3 would be in violation of that.

  Transport mode can't be applied by a SG to a = packet in transit-- in the
example a packet from H1 to H2. But if AH was = treated as being in transport
mode in IP AH ESP IP DATA then that's exactly what = you'd be saying in your
Quick Mode message. So you'd have to do two separate = negotiations, one for
ESP on IP between H1 and H2 and another for AH on = ESP packets between SG1
and SG2, and that would have problems too because = you would be unable to
specify that traffic from H1 to H3 *not* have AH = applied.

  I think it's better to treat AH as being in = tunnel mode in this case.
It precludes lots of ugly, hard-to-maintain code, it = makes UI much simpler,
and it allows for a wider array of rules to be = applied to various sorts of
traffic.

  I'm not suggesting doing IP AH IP ESP IP DATA. = I'm just suggesting that
when we want to do IP AH ESP IP DATA that we = negotiate it using the same
encapsulation attribute-- tunnel mode-- in both the = AH and ESP proposals.
This would also apply to IP ESP PCP IP DATA or IP AH = ESP PCP IP DATA too.

  Dan.

------ =_NextPart_001_01BDB715.801385E0-- From owner-ipsec Sat Jul 25 15:32:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25090 for ipsec-outgoing; Sat, 25 Jul 1998 15:28:47 -0400 (EDT) Date: Thu, 23 Jul 1998 05:24:07 +0900 (JST) Message-Id: <199807222024.FAA08353@kame219.kame.net> From: Ne To: ipsec@tis.com Subject: PFKEYv2 and IKEd. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailer: mnews [version 1.21PL3] 1998-04/12(Sun) Sender: owner-ipsec@ex.tis.com Precedence: bulk I have some basic question of about concerned with PFKEYv2 and IKE. The first, the draft-mcdonald-pf-key-v2-06.txt says, 5.1 Simple IP Security Example Assume that no security associations currently exist for IPsec to use. Consider when a network application begins transmitting data (e.g. a TCP SYN). Because of policy, or the application's request, the kernel IPsec module needs an AH security association for this data. Since there is not one present, the following message is generated: Kernel->Registered: SADB_ACQUIRE for AH, addrs, ID, sens, The KMd reads the ACQUIRE message, especially the sadb_msg_seq number. Before it begins the negotiation, it sends down an SADB_GETSPI message with the sadb_msg_seq number equal to the one received in the ACQUIRE. The kernel returns the results of the GETSPI to all listening sockets. KMd->Kernel: SADB_GETSPI for AH, addr, SPI range Kernel->All: SADB_GETSPI for AH, assoc, addrs Who is this SPI for ? I think it is strange to do SADB_GETSPI on the sender system because the SPI must be decided by the receiver. The next, the draft-ietf-ipsec-isakmp-oakley-08.txt says, 5.5 Phase 2 - Quick Mode Quick Mode is essentially a SA negotiation and an exchange of nonces that provides replay protection. : : Quick Mode is defined as follows: Initiator Responder ----------- ----------- HDR*, HASH(1), SA, Ni [, KE ] [, IDci, IDcr ] --> <-- HDR*, HASH(2), SA, Nr [, KE ] [, IDci, IDcr ] HDR*, HASH(3) --> : : A single SA negotiation results in two security assocations-- one inbound and one outbound. I like to get the conviction. Are two security associations negotiated by a Quick Mode such as this figure ? If that is right, is it possible to negotiate a single direction of security association ? For example, the negotiation a SA for UDP packet. The another question about the figure, Which is the `Initiator' or `Responder' of which the packet causing this negotiation (e.g. a TCP SYN) ? I think there is a consistency to use both IKEd and PF_KEYv2. Please correct me when I'm wrong. Regards. P.S. Thank you for your help and sorry for my bad english ================== Shoichi Sakane From owner-ipsec Sat Jul 25 15:32:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25089 for ipsec-outgoing; Sat, 25 Jul 1998 15:28:46 -0400 (EDT) Message-Id: <199807231806.LAA04862@yupa.ca.mew.com> X-Mailer: Macintosh Eudora Pro Version 2.1.4-J Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Date: Thu, 23 Jul 1998 11:12:07 -0700 To: ipsec@tis.com From: mat@ca.mew.com (Nobuo Matsuo) Subject: Target date and implementation ? Cc: mat@ca.mew.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello everyone, Are there any target date and/or schedule to fix IPSEC 2,ISAKMP drafts as RFCs ? Are there any reference information regarding which version of each spec. to implement as the latest implementation ? Nobuo ------------------------------------------------------- Nobuo Matsuo Email : mat@ca.mew.com Matsushita Electric Works R&D Lab, Inc. 1975 West El Camino Real, Suite #102 Mountain View, CA 94040 Phone: (650) 938-6639, (Ext. 203), Fax : (650) 938-6629 From owner-ipsec Sat Jul 25 15:32:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25078 for ipsec-outgoing; Sat, 25 Jul 1998 15:27:46 -0400 (EDT) Message-ID: <71F9F43682B7D011BDA20020C5E2CCB31F7A3A@routerware.com> From: Biao Wang To: ipsec@tis.com Subject: need help understanding the Commit bit Date: Wed, 22 Jul 1998 02:40:16 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk [ The Commit Bit can be set (at anytime) by either party participating in the SA establishment, and can be used during both phases of an ISAKMP SA establishment. ...] [... In this instance, the Message ID field of the Informational Exchange MUST contain the Message ID of the original ISAKMP Phase 2 SA negotiation. This is done to ensure that the Informational Exchange with the CONNECTED Notify Message can be associated with the correct Phase 2 SA.] The Commit/CONNTECTED exchange can happend completely within Phase 1(e.g. in Identity Protection Exchange/IKE Main Mode), then why the above discussion make it tie to Phase 2 ??? Really confused here. Let's assume it happens in phase 1, then where is the "original ISAKMP Phase 2 SA negotiation" coming from? We are still in phase I right? why do we need to associate with "the correct phase 2 SA]? Thanks for any comment. Biao RouterWare Inc. From owner-ipsec Sat Jul 25 17:11:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25780 for ipsec-outgoing; Sat, 25 Jul 1998 17:09:49 -0400 (EDT) Message-ID: <35BA4D15.17693115@cs.umass.edu> Date: Sat, 25 Jul 1998 17:24:37 -0400 From: Lewis McCarthy Organization: Theoretical Computer Science Group, University of Massachusetts at Amherst X-Mailer: Mozilla 4.03 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: IPsec List CC: Pyda Srisuresh Subject: Re: Comments on "Hybrid Auth. mode for IKE" References: <199807242149.OAA08423@kc.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda Srisuresh writes: [...much elided...] > Say, the Certification Authoriy is down for some reason and noone can > get certs from there. Wouldnt you agree, it would be a good idea to > have a backup authentication scheme in such a case? That depends on the strength of your backup auth scheme and the types of attacks that most concern you. Switching to a backup scheme invites selective denial-of-service attacks in which the adversary prevents you from getting the desired certs from the CAs. Instead you are forced to the security level of your backup auth scheme. If the secondary auth scheme is weaker than the primary, then it's easier for the adversary to subvert the authentication than it would have been with no backup scheme. (This is somewhat similar to the rollback attacks on SSL wherein the parties are coerced to negotiate an unnecessarily weak common auth scheme.) -Lewis From owner-ipsec Sat Jul 25 19:41:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA26128 for ipsec-outgoing; Sat, 25 Jul 1998 19:39:50 -0400 (EDT) Message-ID: From: Bryan Gleeson To: suresh@livingston.com, kent@bbn.com Cc: ipsec@tis.com Subject: RE: Comments on "Hybrid Auth. mode for IKE" Date: Sat, 25 Jul 1998 16:55:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Suresh, Steve > > >Within an exchange-type authentication, you could authenticate a > > >client in more than one-way. For example: Challenge/response > > >authentication, followed by smart token card authentication. > > >In general, the exchange type authentication could combine multiple > > >authentications and hence is a stronger mechanism for auth than a > > >single-payload-type authentcation. > > > > I don't agree. Several mediocre or poor methods are not > necessarily as > > good much less better than one very good method. > > > > Well, exchange-type authentication is a strong requirement for legacy > verification schemes. To that extent, it is valuable. I was merely > extrapolating the process to suggest that we could use the scheme to > perform multiple authentications in succession (example - 2 very good > methods, one after the other). Apparantly, I have not been able to > articulate this well. So, I will drop that line of discussion for the > time being. For mobile users I think a good case can be made for having more than one round of authentication for the same reason that in order to take money out of an ATM machine I need a card and a PIN. If I lose my wallet containing all my token cards and smart cards, then it helps that they are useless to anyone else unless they also know the associated PIN / passwords etc. No matter how strong the authentication used to verify that the remote party is in possession of a valid card, it doesn't mean that it hasn't fallen into the wrong hands. Bryan From owner-ipsec Sat Jul 25 20:39:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA26251 for ipsec-outgoing; Sat, 25 Jul 1998 20:37:50 -0400 (EDT) Date: Sat, 25 Jul 1998 20:49:50 -0400 (EDT) From: Henry Spencer To: "Grillo, John" cc: "'ipsec@tis.com'" Subject: Re: Network Management with IP Sec In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > The way I read the IP Sec RFC, the original packet will be encapsulated, a > checksum is calculated, and then all information in the original packet is > encrypted (or something along those line -- that's not the important part). > If this is the case, I loose visibility into the original packet and > therefore cannot determine the port it was using... Basically correct. To a considerable extent, this is a feature, since it conceals not only the data but also details of where it's going. (There is a whole branch of technical espionage -- traffic analysis -- devoted to learning things by looking at message sources, destinations, sizes, flow rates, etc., without ever knowing the *content*. An amazing variety of information can be inferred that way, given cleverness and patience.) The problems that full-packet encryption causes for firewalls, smart routers, network monitors, etc., which currently do their job partly by spying on the traffic, have been noticed before. There appears to be no simple solution. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Sat Jul 25 21:10:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA26302 for ipsec-outgoing; Sat, 25 Jul 1998 21:08:49 -0400 (EDT) Date: Sat, 25 Jul 1998 21:24:48 -0400 Message-Id: <199807260124.VAA02800@rsts-11.mit.edu> To: pkoning@xedia.com CC: Stephen.Waters@digital.com, ipsec@tis.com In-reply-to: <199807241625.MAA18358@tonga.xedia.com> (message from Paul Koning on Fri, 24 Jul 1998 12:25:32 -0400) Subject: Re: key processing for manual and dynamic SA From: tytso@MIT.EDU Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 References: <250F9C8DEB9ED011A14D08002BE4F64C01B1430D@wade.reo.dec.com> <199807241625.MAA18358@tonga.xedia.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Fri, 24 Jul 1998 12:25:32 -0400 From: Paul Koning The only sensible approach I can see for dealing with the parity bit is to ignore it. If the DES implementation requires valid parity (I've never seen one that does) then the software can invisibly supply the correct parity from the user supplied key. I'd be careful before making that assumption. There was very notable case (involving telnet and Kerberos V4), where a non-crypto person at Berkeley designed the original session key negotiation for doing telnet encryption. They didn't bother making sure the DES key had the correct key parity, and the DES library they used checked for correct key parity and returned an error in that case (leaving the key schedule as all zeros). The telnet code, both client and server, demonstrated the same level of cleverness by not checking the return value from the DES key scheduling function, and continued along their merry way with an all zero key schedule, with an only 1 in 256 chance that the session key negotiation would generate a key with the correct parity, and not fall into this trap! The problem has since been fixed (and it involved a fairly nasty hack in the telnet client to force the session key negotiation such that the key would have the correct parity). But as far as good implementation practice is concerned, it's a really *BAD* idea to assume that DES key parity doesn't matter, and of course you should always check the return code from your library routines. :-) As for dynamic keying and weak keys, there's an explicit list of weak keys to check for and a rule for how to deal with that. There are other keys ("possibly weak" in Scheier) in DES that you may or may not want to check for, as well as weak keys for other algorithms (IDEA, Blowfish). Since the spec doesn't explicitly require checking for those, you can't use a "move one byte and try again" approach. Instead, if you want to refuse such keys, the only method I can see that works is to negotiate another key (as if this key had already expired). A number of people have already commented that weak key detection really isn't necessary. It's important to understand what weak keys mean --- a weak key K is a key for which there exists another key K' where DES_ENCRYPT(K, DES_ENCRYPT(K',M)) == M It is not the case that it is possible, merely by inspection of the ciphertext, to determine that a weak key was used. (This is unlike a class of weak keys in IDEA, which does have this property). For this reason, there is no real harm done if a weak key happens to get negotiated. The chance that (a) a weak key is negotiated, and (b) a IPSEC packet is re-encrypted in another key, and (C) the key used to re-encrypt the packet is the weak key's analogue. The chance of this happen is small enough as to not really be worth bothering about. On the flip side, writing code which deals with DES weak keys means writing code which will be very rarely tested, since the chance that a weak key will be negotiated is also very small. So if there's a problem with that code, it's likely that it won't be detected until after it's been shipped. That's the reason why the spec doesn't require checking for weak keys, because it's not clear that it's really a good idea to do so. Of course, different encryption algorithsm may have weak keys with different properties, such that it would be a good idea to do something to avoid weak keys. However, for DES, this does not seem to be the case. (Of course, given the results of Deep Crack, all this discussion about single DES is somewhat moot at this point. :-) - Ted P.S. In other news, if people where wondering why I haven't responded in a while, it's because I've been on vacation in Alaska. (Denali National park is definitely well worth visiting.) I'm actually still on the road (although back in the lower 48), and will be back in the office as of Tuesday. I'm currently catching up on my mail at this point, so it may take me a while before I'm completely caught up. In the meantime, in answer to what must be the #1 asked question on people's minds, right before I left for vacation two weeks, I got the last of the updated I-D's with the changes required by Thomas Narten. I gave the list to Jeff Schiller, and it's now back in the hands of the IESG. I'd expect action at the next IESG teleconference, if nothing happened last Thursday, but being on the road, I haven't heard back from Jeff about any updated status for the drafts. I'm fairly confident that if they haven't been approved by the IESG yet, they will be in fairly short order. From owner-ipsec Sun Jul 26 07:45:55 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA27151 for ipsec-outgoing; Sun, 26 Jul 1998 07:42:50 -0400 (EDT) Message-ID: <35BB1970.DABF344C@cale.checkpoint.com> Date: Sun, 26 Jul 1998 14:56:32 +0300 From: Moshe Litvin X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Greg Carter CC: "'Moshe Litvin'" , ipsec@tis.com Subject: Re: Comments on "Hybrid Auth. mode for IKE" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Let's try to see how it will work with SecurID: The user connects to his ISP and initiate an aggressive exchange (main mode is not possible when using pre-shared secret). The GW ask an imaginary new version of ACE server(*) for the current value shown on the user screen. When it gets the answer it considers it as the pre-shared secret and sends the response for the user. The user types what he see on his token as his shared secret. If the minute when the the types is not exactly what the ACE server thought that it was (because of network delay, clock drifts or other problem) the authentication will fail. With challenge type tokens you have the problem of failed negotiation when the server thinks that the challenge reached the user but it didn't or vice versa. (*) About that imaginary ACE server: You dismiss as trivial the problem of the server disclosing a secret information. How would Entrust fills about disclosing a one time password to a Fire Wall? why would SDTI should think otherwise? Apart from loosing control of the security of their system they also loose the ability to guarantee that each code can be used only once. Regards, Moshe Greg Carter wrote: > > SecurID uses time based, the card MUST be synchronized to the server or it > doesn't work, each response is valid for 2 minutes (I think). So that is > plenty of time to do a look up of the response on the Gateway side. DES > cards do not require perfect synchronization. The Next Challenge > calculation can be emulated (in most cases, I only know how a few of the > cards do the calculation) in software without the knowledge of the DES key, > only the last response is needed. So you can display the expected Challenge > to the user without going to the backend server. If it doesn't match the > one displayed on the card all the user has to do is enter the one displayed > by your software, and they are back in sync. If your software and the > backend server get out of sync then have the Gateway configured to allow the > user limited access to a www page where they can go get back in sync. Does > the user care that IKE is used for synchronization ? probably not. Also > either you or the card vendor can write the software to 'look ahead' X > number of responses for auto resync. Although when used this way it means > you are returned X number of keys to try to authenticate HASH_I or HASH_R. > As long as a central server with some sort of look ahead is used I don't see > synchronization being that big a deal where it can't be done by some means > out of band to IKE since it will be infrequent. > > Bye. > ---- > Greg Carter, Entrust Technologies > greg.carter@entrust.com > > > ---------- > > From: Moshe Litvin[SMTP:moshe@CheckPoint.COM] > > Sent: Thursday, July 23, 1998 1:45 PM > > To: Greg Carter > > Cc: moshe@CheckPoint.COM; ipsec@tis.com; Pat Calhoun (E-mail) > > Subject: Re: Comments on "Hybrid Auth. mode for IKE" > > > > Greg, > > > > You proposal require perfect state synchronization between the client > > and the server (either what is the last challenge "sent" or the exact > > time). It is impossible in practice especially since there are no means > > to synchronize them. > > > > Also notice that in the hybrid mode no challenge and no reply are > > passing in the clear. > > > > Regards, > > > > Moshe > > > > > > -- ----------------------------------------------------------------------- Moshe Litvin Check Point Software Technologies Ltd. moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555) Fax: +972-3-575-9256 ----------------------------------------------------------------------- From owner-ipsec Sun Jul 26 14:36:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27643 for ipsec-outgoing; Sun, 26 Jul 1998 14:31:51 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Stephen Kent's message of Fri, 24 Jul 1998 16:24:23 -0400 Stephen Kent's message of Thu, 23 Jul 1998 16:17:15 -0400 Stephen Waters's message of Thu, 23 Jul 1998 14:45:29 +0100 <250F9C8DEB9ED011A14D08002BE4F64C01B14301@wade.reo.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 25 Jul 1998 16:31:28 -0400 To: Ben Rogers From: Stephen Kent Subject: Re: ESP and AH used in tunnel mode by a Security Gateway Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, >> >And that's not a problem. The issue is that if two Security Gateways >> >want to speak both AH and ESP simultaneously (even though this isn't a >> >requirement), they ought to be able to negotiate it with ISAKMP. >> >> No argument in principle, but the Arch Doc notes that such support is not >> required, and this admonition was made at the request of the implementor >> community. > >Who are in turn getting pressure from their customers. We have >several large customers who want to use AH as a strong integrity check >for the packet and who don't much care about authenticity. Unless the >authenticator in ESP can be modified to (optionally?) cover the outer >IP header, we're going to be pretty well stuck with the concept of the >combined transform for the Security Gateway. I'm very confused by this statement. The context we were discussing was that of SAs terminating at an SG. There was agreement that there was at least one inner IP header, consistent with ESP use in tunnel mode. The argument seemed to be about use of AH in conjunction with this tunnel mode ESP, and whether it too was in tunnel mode or whether transport mode was applicable, in an effort to save an extra IP header. Under these circumstances, what exactly do your clients feel they will gain fro use of AH? The only difference between the tunnel mode ESP authentcation (assuing they have elected to employ HMAC in ESP, as most folks seem to) and the AH authentication is coverage of the external IP header. But we discard that header and use the inner one for the packet that is passed to the ultimate destination. We can still discuss the header issue, but it would be nice to understand why people this this config, which was removed before has now become "important." > >Then we're not talking about pure AH and pure ESP, but about a funny >protocol called IPsec (which further breaks the layering model, AND >has two distinct protocol numbers). If you look at the following >packet: > >IP AH ESP IP Data > >from the perspective of the AH, you are clearly talking about >transport mode because there is not an IP header immediately following >the AH. > >It seems that you are now talking about the AH ESP pair as a single >block (SA bundle) which has either a tunnel or transport attribute. >In this case, the way that we negotiate the bundle in ISAKMP doesn't >make any sense because the attributes seem to be bound to individual >transforms instead of to the entire bundle. > >Perhaps we need to change our description from (AH ESP in tunnel mode) >to (AH ESP IP-in-IP) which is less ambiguous and more accurately meets >the IP "Next Header" model. (And doesn't provide a second definition >of IP-in-IP to boot!) I haven't examined it carefully, but I might not have big problem with viewing the AH-ESP bundle (with just one inner IP header) as being a valid tunnel, since they were noth applied at the same time and will be decapsulated together. The critical issue is how fragmentation is handled and what headers are checked upon decapsulation. (We stopped using the term "transform" a long time ago, so I don't know how to reconcile some of what you said, but ...) Yes, we've tried to move toward an IP-in-IP tunnel notion over time. Ran used to argue that there was a fundamental difference between what we were doing and IP-in-IPf tunneling, but I've not been able to really understand what the differences were, so they have tended to blur over time. >Hmm... Is it not best to describe the current running systems? If we >were to describe the way that AH+ESP is negotiated between Security >Gateways, it would pretty much require having a pointer to somewhere >in the Arch document. The current crop of running suystems embody a variety of characteristics, not all of which are consistent with one another, or with the specs. Also, none of the ones I;ve seen is completely compliant with the specs, despite receiving ICSA certification! So, no, I don't want to change the spec to match what the current crop is doing, if that deviates from what this WG has labored long and hard to agree upon. The last time we adopted this rationale we deleted the ability for ESP to have null encryption because the "then current" crop of implementations didn't support it; this feature was rediscovered as important a number of months later, and added back at that time. Let's not repeat history. >As a side note, I guess I missed the rationale for adding the >complication beyond RFC1825. Defining a strict bond (currently called >the SA bundle) inherently caused a combinitoric explosion in >complexity. Anyone feel like enlightening me on a bit of ancient >history? %) At this point, not me!' Steve From owner-ipsec Sun Jul 26 14:36:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27644 for ipsec-outgoing; Sun, 26 Jul 1998 14:31:51 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Bryan Gleeson's message of Fri, 24 Jul 1998 12:53:31 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 25 Jul 1998 16:10:25 -0400 To: Ben Rogers From: Stephen Kent Subject: Re: ESP and AH used in tunnel mode by a Security Gateway Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, >I'm guessing that since the encapsulation mode attribute is optional, >the wildcard would be the absence of this attribute. I think that it >is a valuable thing to do on a Security Gateway which can also act as >a Host implementation. That way, communication between hosts behind >the SG to the remote end is in tunnel mode and between the SG and the >remote end is in transport mode. This is the most efficient way to >handle bandwidth in this case, since an unnecessary IP header is not >added. The Arch Doc states that the wildcard value in the SAD is applicable to host implemnetations and reiterates that gateways must use tunnel mode. (See section 4.4.3, pages 24-25, latest I-D.) Thus, the discussion of this wildcard feature does not apply to the security gateway SA mode discussion you're having here. Steve From owner-ipsec Sun Jul 26 14:37:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27650 for ipsec-outgoing; Sun, 26 Jul 1998 14:34:50 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199807242149.OAA08423@kc.livingston.com> References: from "Stephen Kent" at Jul 23, 98 07:24:10 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 25 Jul 1998 18:10:58 -0400 To: suresh@livingston.com (Pyda Srisuresh) From: Stephen Kent Subject: Re: Comments on "Hybrid Auth. mode for IKE" Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Suresh, > >However, Re-auth does make sense, for example, if the remote site's >authentication becomes questionable based on some application specific >payload (or) some policy that requires it. But, I digress. I think we have another mis-communication here. IPsec is an Internet layer protocol. When an SA is established it it fixed in its security characteristics for the duration of the SA. There is no notion that a specific application payload, sent over an SA, should elicit a different set of services. So, for example, if an application performs some operation for which a re-authentication is appropriate, that should be provided via an application later security mechanism, not IPsec. > >Well, exchange-type authentication is a strong requirement for legacy >verification schemes. To that extent, it is valuable. I was merely >extrapolating the process to suggest that we could use the scheme to >perform multiple authentications in succession (example - 2 very good >methods, one after the other). Apparantly, I have not been able to >articulate this well. So, I will drop that line of discussion for the >time being. A large part of this debate hinges on the desirability of accommodating legacy user authentication mechansims in IPsec. I have no objection to this so long as it does not degrade the fundamental level of two-way authentication that we get from IKE. I do not agree that the legacy support goal is so important that it should cause us to degrade this critical security feature. Look at SSL. It has a capability for client certificates, which provides a user authentication facility analogous to what IKE can do for IPsec. However, most systems are still employing static passwords protected by SSL encryption, which results in a number of vulnerabilities. I'd rather not see IPsec fall into the same trap. >Say, the Certification Authoriy is down for some reason and noone can >get certs from there. Wouldnt you agree, it would be a good idea to >have a backup authentication scheme in such a case? First, one does not retrieve a cert from a CA; one retrieves it from a repository of some sort, and such repositories need to be highly available. Second, IKE provides a facility to pass certs (and CRLs) as payloads, thus avoinding the possibility that an unavailable repository will prevent authentication. In the systems we are engineering based on IPsec, we require vendors to make use of this approach, to avoid such problems. > >No argument there. I agree, ISAKMP Authentication is key to ensuring >intrinsic authentication to session based SAs. Having said that, I also >believe, it is important that people have multiple options to pursue. >Let the market place decide what auth. scheme they like in different >scenarios. Again, a disagreement over goals. The marketplace has consistently chosen weaker security mechanisms in the past. In creating IPsec the intent was to significantly raise the bar, not make minor, incremental improvements. >Hmm, I am confused. By smart token cards, I am refering to cards like >SecurID card. Why should they perform any crypto operations for IKE? >SecurID cards do provide 1-way authentication (Card user is authenticated >by card verifier). Why should the authentication be 2-way? Each party can >be independently Authenticated in a different way, whichever works best. Your suggestion is to employ two different authentication methods, one for the user and one for the "system." This requires the user code to be able to parse certs and CRLs, so it has many of the capabilities needed for support cert-based auth for the user. Thus the addition of other user auth capabilities adds complexity to the user code, increasing the likelihood of errors. That seems to be a downside to this proposal that has not been addressed. > >I disagree. I dont believe, two-way auth. mechanism has anything to with >the strength of authentication. Oh come now! Of course two-way auth is superior to one-way auth, so there must be a deeper message you're trying to express here. >The market place decides based on multiple criteria including ease of use, >security requirements, legacy requirements, cost associated and so forth. >For this reason, I would not restrict options to just one kind. My comments above about the marketplace stand. > >Token card based auth. is independent of XAUTH. >Token card based auth. simply requires an exchange-type-authentication. Perhaps we've gotten confused over terminoloy here. Let's skip this one. >Oops.. I wasnt implying anything different. I guess, I just wanted the >word "certificate" spelled out in the sentence :-) OK. > >Say, the user chose an infinite lifetime option. When a user is disconnected >from the network, the SAs are presumably still valid, right. In such a case, >someone else could get on to the same machine and happily use the session >SAs. By limiting the SA lifetime to "network-connected-time", the SAs >automaitcally become invalid when the user is not connected to the network. I think you need to explain the assumptions underlying this example. For a remote (dialup) user, when I disconnect from the network, I expect the IPsec implementation to clean up and the SA state to go away, thus removing any chance of SA reuse. If the disconnect is the result of a crash, I expect the state to go away at my end, even though the other end may still have SAD entries for the SA(s). This too renders the SAs useless. The primary circumstance in which your comments seem to apply would be a multiuser machine with a faulty IPsec implementation, one that fails to maintain the mapping between users and their SAs. In my environment I see few (actually, no) such machines, but I agree that under thise circumstances, and IF re-auth were employed for extant SAs, then the use of a separate user auth method would have some merit. But, since I am leery of actual use of re-auth, and since the example you provided above to motivate it had problems, I don't find this a compelling argument. Maybe with more detail it would be more persuasive. Steve From owner-ipsec Sun Jul 26 19:55:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA28016 for ipsec-outgoing; Sun, 26 Jul 1998 19:48:49 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807270005.RAA05146@kc.livingston.com> Subject: Re: Comments on "Hybrid Auth. mode for IKE" To: kent@bbn.com (Stephen Kent) Date: Sun, 26 Jul 1998 17:05:31 -0700 (PDT) Cc: suresh@livingston.com, ipsec@tis.com In-Reply-To: from "Stephen Kent" at Jul 25, 98 06:10:58 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Suresh, > > > > >However, Re-auth does make sense, for example, if the remote site's > >authentication becomes questionable based on some application specific > >payload (or) some policy that requires it. But, I digress. > > I think we have another mis-communication here. IPsec is an Internet layer > protocol. When an SA is established it it fixed in its security > characteristics for the duration of the SA. There is no notion that a > specific application payload, sent over an SA, should elicit a different > set of services. So, for example, if an application performs some > operation for which a re-authentication is appropriate, that should be > provided via an application later security mechanism, not IPsec. > OK, I understand what you are saying. I need to think about this some more. I would like to defer this thread on Re-auth to some other time. > > > >Well, exchange-type authentication is a strong requirement for legacy > >verification schemes. To that extent, it is valuable. I was merely > >extrapolating the process to suggest that we could use the scheme to > >perform multiple authentications in succession (example - 2 very good > >methods, one after the other). Apparantly, I have not been able to > >articulate this well. So, I will drop that line of discussion for the > >time being. > > A large part of this debate hinges on the desirability of accommodating > legacy user authentication mechansims in IPsec. I have no objection to > this so long as it does not degrade the fundamental level of two-way > authentication that we get from IKE. I do not agree that the legacy support > goal is so important that it should cause us to degrade this critical > security feature. Look at SSL. It has a capability for client > certificates, which provides a user authentication facility analogous to > what IKE can do for IPsec. However, most systems are still employing > static passwords protected by SSL encryption, which results in a number of > vulnerabilities. I'd rather not see IPsec fall into the same trap. > The hybrid authentication scheme is not arguing for taking away the 2-way authentication scheme. The edge device is still having to authenticate itself to remote users (using public key encryption). It is just the matter of adapting varying degrees of authentication schemes into the protocol for authentication each way. > >Say, the Certification Authoriy is down for some reason and noone can > >get certs from there. Wouldnt you agree, it would be a good idea to > >have a backup authentication scheme in such a case? > > First, one does not retrieve a cert from a CA; one retrieves it from a > repository of some sort, and such repositories need to be highly available. > Second, IKE provides a facility to pass certs (and CRLs) as payloads, thus > avoinding the possibility that an unavailable repository will prevent > authentication. In the systems we are engineering based on IPsec, we > require vendors to make use of this approach, to avoid such problems. > Sounds good. That does not mean other authentication schemes have no place. > > > >No argument there. I agree, ISAKMP Authentication is key to ensuring > >intrinsic authentication to session based SAs. Having said that, I also > >believe, it is important that people have multiple options to pursue. > >Let the market place decide what auth. scheme they like in different > >scenarios. > > Again, a disagreement over goals. The marketplace has consistently chosen > weaker security mechanisms in the past. In creating IPsec the intent was > to significantly raise the bar, not make minor, incremental improvements. > OK, I will go with that. I have a specific goal to apply current Ipsec techniques to remote access applications. > > >Hmm, I am confused. By smart token cards, I am refering to cards like > >SecurID card. Why should they perform any crypto operations for IKE? > >SecurID cards do provide 1-way authentication (Card user is authenticated > >by card verifier). Why should the authentication be 2-way? Each party can > >be independently Authenticated in a different way, whichever works best. > > Your suggestion is to employ two different authentication methods, one for > the user and one for the "system." This requires the user code to be able > to parse certs and CRLs, so it has many of the capabilities needed for > support cert-based auth for the user. Thus the addition of other user auth > capabilities adds complexity to the user code, increasing the likelihood of > errors. That seems to be a downside to this proposal that has not been > addressed. > I see your clever rewording :-). In reality, users dont have certs and there is a strong demand to support existing auth. mechanisms to avail of the IPsec services. > > > >I disagree. I dont believe, two-way auth. mechanism has anything to with > >the strength of authentication. > > Oh come now! Of course two-way auth is superior to one-way auth, so there > must be a deeper message you're trying to express here. > I didnt say it right. I was refering to symmetrical 2-way authentication vs. hybrid 2-way authentication. I was merely saying that the former doesnt have any intrinsic superiority over the latter. Sorry for the confusion. > >The market place decides based on multiple criteria including ease of use, > >security requirements, legacy requirements, cost associated and so forth. > >For this reason, I would not restrict options to just one kind. > > My comments above about the marketplace stand. > > > > >Token card based auth. is independent of XAUTH. > >Token card based auth. simply requires an exchange-type-authentication. > > Perhaps we've gotten confused over terminoloy here. Let's skip this one. > > > >Oops.. I wasnt implying anything different. I guess, I just wanted the > >word "certificate" spelled out in the sentence :-) > > OK. > > > > >Say, the user chose an infinite lifetime option. When a user is disconnected > >from the network, the SAs are presumably still valid, right. In such a case, > >someone else could get on to the same machine and happily use the session > >SAs. By limiting the SA lifetime to "network-connected-time", the SAs > >automaitcally become invalid when the user is not connected to the network. > > I think you need to explain the assumptions underlying this example. For a > remote (dialup) user, when I disconnect from the network, I expect the > IPsec implementation to clean up and the SA state to go away, thus removing > any chance of SA reuse. Is that a draft requirement? From what I can make out, it is a draft requirement to clean up only the retired SAs. Anyways, thats the idea of proposing the network-connected-time metric. > If the disconnect is the result of a crash, I > expect the state to go away at my end, even though the other end may still > have SAD entries for the SA(s). This too renders the SAs useless. The > primary circumstance in which your comments seem to apply would be a > multiuser machine with a faulty IPsec implementation, one that fails to > maintain the mapping between users and their SAs. In my environment I see > few (actually, no) such machines, but I agree that under thise > circumstances, and IF re-auth were employed for extant SAs, then the use of > a separate user auth method would have some merit. But, since I am leery > of actual use of re-auth, and since the example you provided above to > motivate it had problems, I don't find this a compelling argument. Maybe > with more detail it would be more persuasive. > I responded to this independently on a seperately e-mail thread to Vipul. The basic idea is to allow SAs to remain as long as necessary (given strong crypto for the SAs) while the remote user is connected. And, when the user is no longer connected, enforce cleaning up of SAs established. cheers, suresh From owner-ipsec Sun Jul 26 21:00:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA28147 for ipsec-outgoing; Sun, 26 Jul 1998 20:55:50 -0400 (EDT) To: Stephen Kent Cc: ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway References: Bryan Gleeson's message of Fri, 24 Jul 1998 12:53:31 -0700 From: Ben Rogers Date: 26 Jul 1998 21:11:56 -0400 In-Reply-To: Stephen Kent's message of Sat, 25 Jul 1998 16:10:25 -0400 Message-ID: Lines: 34 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent writes: > The Arch Doc states that the wildcard value in the SAD is applicable to > host implemnetations and reiterates that gateways must use tunnel mode. > (See section 4.4.3, pages 24-25, latest I-D.) Thus, the discussion of this > wildcard feature does not apply to the security gateway SA mode discussion > you're having here. Unfortunately, many gateways will be acting both as a SG and as a Host implementation (IPsec protection for configuration sessions or L2TP tunnels comes to mind). The wildcard characteristic becomes increasingly useful for the SG in the case where we might be protecting a second tunneling protocol, as well as using straigt IPsec in tunnel mode. For example: H1-----SG1=====SG2-----H2 If H1 has the option of connecting to SG1 as either an IP client or a PPP client, SG1 might be configured to transfer that traffic either in an IPsec tunnel, or in an L2TP tunnel (which in this case would be protected by transport mode IPsec). In order to reduce the complexity of this configuration, it would be nice to allow the same SA's to protect all traffic, whether being used in Tunnel Mode or in Transport Mode. I think that this provides a valid case for wanting the "Security Gateway" (or perhaps some extension of this concept) for using an SA in a wildcard fashion much as a Host implementation might. The question then begins to involve the question of how we might represent that in terms of SAD notation and how we would negotiate it with ISAKMP. ben From owner-ipsec Sun Jul 26 22:13:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA28259 for ipsec-outgoing; Sun, 26 Jul 1998 22:09:54 -0400 (EDT) To: ipsec@tis.com Subject: Working group home page From: Ben Rogers Date: 26 Jul 1998 22:25:57 -0400 Message-ID: Lines: 23 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk Seems to have the incorrect statement: Archive: ftp://ftp.tis.com/pub/lists/ipsec OR ftp.ans.net/pub/archive/ipsec Which I believe should be an 'AND'. The second only goes until February '96 and the first picks up from there. One of the following changes would be appropriate: 1. Modify the WG Page to make this an "AND" 2. "Port" the archive at ans.net to tis.com, and change the page to no longer include the reference to ans.net 3. Move the tis.com archive to ans.net (probably not a good idea since ans.net seems to be defunct). I'd prefer option #2. It would be nice to get this fixed soon -- I was about to send a message off without appropriate research which would probably have caused unnecessary conflict on the list. ben From owner-ipsec Sun Jul 26 23:21:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA28413 for ipsec-outgoing; Sun, 26 Jul 1998 23:18:52 -0400 (EDT) To: Stephen Kent Cc: ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway References: Stephen Kent's message of Fri, 24 Jul 1998 16:24:23 -0400 Stephen Kent's message of Thu, 23 Jul 1998 16:17:15 -0400 Stephen Waters's message of Thu, 23 Jul 1998 14:45:29 +0100 <250F9C8DEB9ED011A14D08002BE4F64C01B14301@wade.reo.dec.com> From: Ben Rogers Date: 26 Jul 1998 23:34:46 -0400 In-Reply-To: Stephen Kent's message of Sat, 25 Jul 1998 16:31:28 -0400 Message-ID: Lines: 104 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, Stephen Kent writes: [AH discussion snipped -- I need to think some more before responding] > I haven't examined it carefully, but I might not have big problem with > viewing the AH-ESP bundle (with just one inner IP header) as being a valid > tunnel, since they were noth applied at the same time and will be > decapsulated together. The critical issue is how fragmentation is handled > and what headers are checked upon decapsulation. (We stopped using the > term "transform" a long time ago, so I don't know how to reconcile some of > what you said, but ...) Yes, we've tried to move toward an IP-in-IP tunnel > notion over time. Ran used to argue that there was a fundamental difference > between what we were doing and IP-in-IPf tunneling, but I've not been able > to really understand what the differences were, so they have tended to blur > over time. I guess this must have been a result of private discussions (or inadequately documented IETF meetings) because the first reference I can find to the DF bit is Ran responding to me (11. Feb 97): Ran wrote (M-ID = ): > It is worth noting that none of the IPsec RFCs cite any of the IP-in-IP > RFCs. This is not an accident. With IPsec, one is not performing IP-in-IP. > Rather, one is performing IP-in-AH or IP-in-ESP. The IP-in-IP RFCs don't > include IPsec within their scope. > It was quite intentional that this was done. It is equally intentional > that the IPsec RFCs haven't been citing the IP-in-IP RFCs. > In effect, ESP tunnel mode uses the outer IP as a link-layer. Copying > DF bit is not prohibited for IPsec tunneling, but neither is it required > for IPsec tunneling. Perhaps I'm clouded by my own implementation experience, but I really don't see a fundamental difference between our objective and that of IP-in-IP. With time, our methods for achieving this objective have diverged and the current docs don't mesh well. However, I don't see why we couldn't currently merge them and simplify the lives of future implementors. The one major difference I have seen has been in the handling of the DF bit. I guess I missed somthing in my archive search, but I don't really see any strong rationale for handling it different from IP-in-IP. If (as a SG) I receive a packet from a host with the DF bit set, it is my job to interpret this as a willingness for that host to reduce its segment size in order to avoid the overhead of the fragmented packet. I am misrepresenting that machine (and further conjesting the network) if I don't include it in the outer header and perform PMTU discovery for the tunnel (which looks like a single-hop link to that host). The only reason I can see to change this behavior would be to provide an extra bit of security (if I never set the DF bit on the outer IP header, there is slightly less information that can be learned concerning the hosts in my network). Should this be a valid concern? Is there any other fundamental difference I'm missing? Back to quoting Steve: > >Hmm... Is it not best to describe the current running systems? If we > >were to describe the way that AH+ESP is negotiated between Security > >Gateways, it would pretty much require having a pointer to somewhere > >in the Arch document. > > The current crop of running suystems embody a variety of characteristics, > not all of which are consistent with one another, or with the specs. Also, > none of the ones I;ve seen is completely compliant with the specs, despite > receiving ICSA certification! So, no, I don't want to change the spec to > match what the current crop is doing, if that deviates from what this WG > has labored long and hard to agree upon. The last time we adopted this > rationale we deleted the ability for ESP to have null encryption because > the "then current" crop of implementations didn't support it; this feature > was rediscovered as important a number of months later, and added back at > that time. Let's not repeat history. Your fear is well stated. However, it seems that this attitude might well steer us towards making the opposite mistake. This is something that several of us would like to do that is currently ommited from the documents. Not documenting it means that interoperability will be entirely goverened by chance and interop attendance (and not by a correct implementation of the specs). The only result of our past labors is to decide that AH+ESP should not be a requirement for Security Gateways. Some of us have chosen to implement it because it seems useful. Now, we'd like to agree upon a way to negotiate this using the IPsec DOI (which is merely a matter of choosing one of several possible good solutions). The DOI document is an appropriate place to put this OPTIONAL configuration mode. However, it is not an appropriate place to describe the optional encapsulation mode that it refers to. All I'm asking is to document this optional encapsulation mode in the Architecture document. It is not required functionality and should be documented that way (probably using a "MAY"). However, it is an option that some of us would like to support and it should be documented. ben From owner-ipsec Sun Jul 26 23:30:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA28452 for ipsec-outgoing; Sun, 26 Jul 1998 23:28:52 -0400 (EDT) To: Bryan Gleeson Cc: Daniel Harkins , Tim Jenkins , Stephen Waters , ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway References: From: Ben Rogers Date: 26 Jul 1998 23:41:02 -0400 In-Reply-To: Bryan Gleeson's message of Fri, 24 Jul 1998 19:21:08 -0700 Message-ID: Lines: 56 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk Bryan, > > I'm guessing that since the encapsulation mode attribute is optional, > > the wildcard would be the absence of this attribute. I think that it > > is a valuable thing to do on a Security Gateway which can also act as > > a Host implementation. That way, communication between hosts behind > > the SG to the remote end is in tunnel mode and between the SG and the > > remote end is in transport mode. This is the most efficient way to > > handle bandwidth in this case, since an unnecessary IP header is not > > added. > > The spec says that an omitted encapsulation mode attribute means > "unspecified (host-dependent)". If the "host-dependent" qualifier > wasn't there I would have taken this to mean "wildcard", but > because it is there I'm so sure. What is host-dependent about the > semantics of wildcard as defined in the architecture spec? Isn't > it just that transport and tunnel mode packets can be carried on > the same SA? Perhaps it makes sense to add a wildcard value for this attribute? I've been treating it as host-dependent on my system, but would like to have the ability to configure this mode with other vendors. > > Yes, as long as the proposal numbers are distinct. Otherwise, the two > > proposals are AND'ed together. I really don't know how you would > > perform ESP AND ESP on a packet and call this a single Security > > Policy. This seems to be a necessary evil in order to allow the full > > AND/OR semantic described in ISAKMP 4.2. > > > > Seems unfortunate that the protocol allows exactly the same semantics > to be encoded in two different ways, as it increases the chances of > interoperability problems and the amount of code needed. I don't think > there would be any reduction in the range of things it is possible to > express if there was a rule that proposals with different proposal > numbers had to have distinct (bundles of) protocol-ids. Hmm.. There is a reduction, but I don't know if it is necessary. You need the flexibility to negotiate the following policy: (ESP(DES) and AH(MD5-HMAC)) or (ESP(CAST) and AH(SHA1-HMAC)) (which does not permit DES to be used with SHA1 nor CAST to be used with MD5). I can't see why this would be a particulary valuable proposal unless a class of encryption/authentication algorithms is found which interact poorly with one another (ie. authenticating using algorithm A1 the data encrypted using algorithm E1 leaks key bits for either A1 or E1, while A1 works fine with E2 and E1 works fine with A2). But, given that our current knowledge is necessarily uncomplete, I wouldn't want to throw this away just yet. ben From owner-ipsec Sun Jul 26 23:43:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA28479 for ipsec-outgoing; Sun, 26 Jul 1998 23:42:00 -0400 (EDT) To: Tim Jenkins Cc: Daniel Harkins , Stephen Waters , ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway References: <319A1C5F94C8D11192DE00805FBBADDF293D4F@exchange.timestep.com> From: Ben Rogers Date: 26 Jul 1998 23:53:59 -0400 In-Reply-To: Tim Jenkins's message of Fri, 24 Jul 1998 11:12:40 -0400 Message-ID: Lines: 79 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim, Tim Jenkins wrote (with removed MIME headers): > Why has no one referred to "protection suites" as defined in the DOI > document and Oakley or "SA bundles" as defined in the architecture > document? > > Use of these concepts would simplify these discussions, since it would > reduce the ambiguity of application. For example, a gateway could apply > an IPCOMP-ESP-AH bundle as > > IP [AH ESP PCP] IP DATA > > where a host could do either > > IP [AH ESP PCP] IP DATA (tunnel mode) > or IP [AH ESP PCP] DATA (transport mode) > > In this case, there's no argument about whether AH and ESP are tunnel or > transport; they are part of a bundle that is tunnel or transport. Unfortunately, in ISAKMP, there is no way to attach an attribute to a protection suite, but only to a transform. (We could resolve this by standardizing on including the same attribute in each transform of the suite, or some such solution.) > An example: > > H1 --- SG1 ----- H2 > <-- AH --> (tunnel mode) > <---- ESP ------> (either mode) Yes. That situation is necessarily unambiguous (and is, in fact two protection suites). However, the following: H1 ---- SG1 ============== SG2 ---- H2 <-- AH + ESP --> is not. There, if we only allow the options enumerated in the Architecture document, and follow the "Security Gateways must always use tunnel mode" rule, we end up with the following bloated packet: IP(SG1->SG2) AH IP(SG1->SG2) ESP IP(H1->H2) Data n which contains no more information than the slimmer: IP(SG1->SG2) AH ESP IP(H1->H2) Data Technically AH is in transport mode here, while ESP is in tunnel mode if you look at the individual transforms, or we are using an AH+ESP protection suite which is itself in tunnel mode if you use the protection suite concept. In theory, to accurately represent all possible situations, you'd need ISAKMP messages of the following form: Proposal 1 Propsal attributes (*) Protocol 1 Transform 1 Transform attributes Transform 2 Transform attributes [...] Protocol 2 [...] Proposal 2 [...] where the proposal attributes (*) field is the only fundamental difference from what we've got right now. We can emulate this in our current language by playing tricks with the Transform attributes. The only problem is getting consensus on how to do this. ben From owner-ipsec Mon Jul 27 00:57:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA28562 for ipsec-outgoing; Mon, 27 Jul 1998 00:54:52 -0400 (EDT) Message-Id: <199807270507.WAA11538@greatdane.cisco.com> To: Ben Rogers cc: Tim Jenkins , Stephen Waters , ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway In-reply-to: Your message of "26 Jul 1998 23:53:59 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 26 Jul 1998 22:07:05 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On 26 Jul 1998 23:53:59 EDT you wrote > > Tim Jenkins wrote (with removed MIME headers): > > > Why has no one referred to "protection suites" as defined in the DOI > > document and Oakley or "SA bundles" as defined in the architecture > > document? > > > > Use of these concepts would simplify these discussions, since it would > > reduce the ambiguity of application. For example, a gateway could apply > > an IPCOMP-ESP-AH bundle as > > > > IP [AH ESP PCP] IP DATA > > > > where a host could do either > > > > IP [AH ESP PCP] IP DATA (tunnel mode) > > or IP [AH ESP PCP] DATA (transport mode) > > > > In this case, there's no argument about whether AH and ESP are tunnel or > > transport; they are part of a bundle that is tunnel or transport. > > Unfortunately, in ISAKMP, there is no way to attach an attribute to a > protection suite, but only to a transform. (We could resolve this by > standardizing on including the same attribute in each transform of the > suite, or some such solution.) I thought a "protection suite" was an ISAKMP notion not an IPSec notion. Each protection suite is, in fact, represented as an offer by a single transform which contains the attributes to describe the protection suite: encryption algorithm, hash algorithm, authentication method, group. Protection suites are not logically related to each other. For IPSec we have SA bundles and there is verbage in the IKE document that states the all offers in a single Quick Mode are logically related. The example given is for PFS and it states that each offer must have the same group attribute, and that client identities, when passed, apply to all SAs. Unfortunately this does not explicitly spell out the encapsulation attribute. Sigh. Since that is not an IKE attribute perhaps it shouldn't, but something should. > > > An example: > > > > H1 --- SG1 ----- H2 > > <-- AH --> (tunnel mode) > > <---- ESP ------> (either mode) > > Yes. That situation is necessarily unambiguous (and is, in fact two > protection suites). However, the following: > > H1 ---- SG1 ============== SG2 ---- H2 > <-- AH + ESP --> > > is not. There, if we only allow the options enumerated in the > Architecture document, and follow the "Security Gateways must always > use tunnel mode" rule, we end up with the following bloated packet: > > IP(SG1->SG2) AH IP(SG1->SG2) ESP IP(H1->H2) Data I thought we had agreed that that is not necessary and that in IP AH ESP IP DATA, AH is in tunnel mode. The two protocols are negotiated together, they have the same retrictions (from the ID payloads), and, if PFS is negotiated their keys are related. They're functionally a unit; a bundle. > which contains no more information than the slimmer: > > IP(SG1->SG2) AH ESP IP(H1->H2) Data Which, provide you're talking about IPv4 and the non-deprecated transforms is no more secure than the even slimmer: IP(SG1->SG2) ESP IP(H1->H2) Data. > Technically AH is in transport mode here, while ESP is in tunnel mode > if you look at the individual transforms, or we are using an AH+ESP > protection suite which is itself in tunnel mode if you use the > protection suite concept. It's an SA bundle, not a protection suite, but that's the idea. AH isn't in transport mode. > In theory, to accurately represent all possible situations, you'd need > ISAKMP messages of the following form: > > Proposal 1 > Propsal attributes (*) > Protocol 1 > Transform 1 > Transform attributes > Transform 2 > Transform attributes > [...] > Protocol 2 > [...] > Proposal 2 > [...] > > where the proposal attributes (*) field is the only fundamental > difference from what we've got right now. We can emulate this in our > current language by playing tricks with the Transform attributes. The > only problem is getting consensus on how to do this. I thought we already did. In on the 23rd of July you responded to my point that AH is for all intents and purposes in tunnel mode by saying "I agree wholeheartedly". No one has said anything to the contrary. And I don't think adding new payloads or fields to existing payloads is necessary. If anything we just need some further clarification about the relatedness of proposals and the transforms they encompass. Or we could solve this problem by just doing away with AH.... :-) Dan. From owner-ipsec Mon Jul 27 03:02:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA28744 for ipsec-outgoing; Mon, 27 Jul 1998 02:59:53 -0400 (EDT) To: Daniel Harkins Cc: Tim Jenkins , Stephen Waters , ipsec@tis.com Subject: Re: ESP and AH used in tunnel mode by a Security Gateway References: <199807270507.WAA11538@greatdane.cisco.com> From: Ben Rogers Date: 27 Jul 1998 02:32:48 -0400 In-Reply-To: Daniel Harkins's message of Sun, 26 Jul 1998 22:07:05 -0700 Message-ID: Lines: 63 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins writes: > I thought a "protection suite" was an ISAKMP notion not an IPSec notion. > Each protection suite is, in fact, represented as an offer by a single > transform which contains the attributes to describe the protection suite: > encryption algorithm, hash algorithm, authentication method, group. Protection > suites are not logically related to each other. Oops. > For IPSec we have SA bundles and there is verbage in the IKE document that > states the all offers in a single Quick Mode are logically related. The > example given is for PFS and it states that each offer must have the same > group attribute, and that client identities, when passed, apply to all SAs. > Unfortunately this does not explicitly spell out the encapsulation attribute. > Sigh. Since that is not an IKE attribute perhaps it shouldn't, but something > should. Hmm... it makes more sense for this to be in draft-ietf-ipsec-isakmp. I expect to find most of the details for generating IPsec SAs in either DOI or ISAKMP. (Key material generation being the one piece tied necessarily to IKE.) The DOI probably ought to define which transform attributes need to be consistent across the proposal. > > Yes. That situation is necessarily unambiguous (and is, in fact two > > protection suites). However, the following: > > > > H1 ---- SG1 ============== SG2 ---- H2 > > <-- AH + ESP --> > > > > is not. There, if we only allow the options enumerated in the > > Architecture document, and follow the "Security Gateways must always > > use tunnel mode" rule, we end up with the following bloated packet: > > > > IP(SG1->SG2) AH IP(SG1->SG2) ESP IP(H1->H2) Data > > I thought we had agreed that that is not necessary and that in > IP AH ESP IP DATA, AH is in tunnel mode. The two protocols are negotiated > together, they have the same retrictions (from the ID payloads), and, > if PFS is negotiated their keys are related. They're functionally a unit; > a bundle. Great. Derrell -- can we get this into the DOI document as soon as the RFCs are cut? [Lots of my rambling cut out.] > I thought we already did. In on the > 23rd of July you responded to my point that AH is for all intents and > purposes in tunnel mode by saying "I agree wholeheartedly". No one has > said anything to the contrary. And I don't think adding new payloads or > fields to existing payloads is necessary. If anything we just need some > further clarification about the relatedness of proposals and the transforms > they encompass. I guess I'm just beating a dead horse. I'll stop now. > Or we could solve this problem by just doing away with AH.... :-) Unless, of course, you start _that_ conversation up again... :) :) ben From owner-ipsec Mon Jul 27 03:06:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA28761 for ipsec-outgoing; Mon, 27 Jul 1998 03:04:53 -0400 (EDT) From: Kai Martius Organization: Uniklinik TUD To: moshe@checkpoint.com Date: Mon, 27 Jul 1998 08:58:54 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Comments on "Hybrid Auth. mode for IKE" Reply-to: kai@imib.med.tu-dresden.de CC: ipsec@tis.com X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: <5B017CF69E1@fltserv.imib.med.tu-dresden.de> Sender: owner-ipsec@ex.tis.com Precedence: bulk Moshe, just another opinion to the "hybrid authentication draft". First some general thoughts: There's no doubt to need good migration paths from "80's technology" to new one but I have some concerns doing it the way your I-D proposes: 1. In general, I believe, providing too much of backward compatibility would probably delay the implementation of more secure authentication mechanisms, especially certificate based auth. including a global PKI. IKE could be a good catalyst deploying stronger auth. schemes. And it already provides a good migration path by its pre-shared key mode (PSK) where NO PKI is needed. So the compatibitility to older systems should build on this mode. (All token systems I know are based on symmetric crypto - like PSK mode. At least for S/KEY I could imagine it's very easy to use it in a kind of "one-time-PSK" mode). 2. The discussion on more or less databases to manage I don't understand - basically there is _one_ importent database which assigns certain rights to a USER. With cert-based auth. you have less databases, because there is already an authenticated user name - with any symmetric token system you need to assign the users to the token first. 3. A basic IKE-design principle is the 2-phase-approach of authenticating the IKE instances in a first phase and in the second phase to exchange keys for clients. Comparing XAUTH and hybrid mode, XAUTH keeps the 2-phase-separation cleaner, I think. In detail to your I-D: 3. You propose using Public-Key-based auth. for the edge device, which means a certificate must be known to the mobile user or transmitted during "hybrid auth mode"-exchange - so you need to verify the cert. on the mobile station, and therefore you need a basic kind of PKI, at least with a one-level certification hierarchy. But within this hierarcy you can certify your clients too... (I absolutely agree Steve, that it's not so difficult to build PKIs in a limited organizational environment) 4. (last) your comparison to SSL (Sect. 2.2) is not correct, at least not understandable: If a server requests client auth. during the SSL handshake the client MUST reply with a certificate. With SSL you always need a kind of PKI - there is no migration path with pre-shared secrets like in IKE. Anything else above SSL mostely can't be called client auth. (especially not a credit card number...)- it only depends on the application running on SSL. For the Web, real client auth. would only be provided by S-HTTP on a per-document basis. Kai # Kai Martius # # Dpt. of Medical CS and Biometrics / Dresden University of Technology # # PGP Fingerprint: to be compared after download of my key # # Key and more info see my Homepage # # http://www.imib.med.tu-dresden.de/imib/personal/kai.html # From owner-ipsec Mon Jul 27 09:13:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29513 for ipsec-outgoing; Mon, 27 Jul 1998 09:06:53 -0400 (EDT) Message-ID: From: "Grillo, John" To: "'ipsec@tis.com'" Subject: Network Management with IP Sec Date: Fri, 24 Jul 1998 17:23:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Currently, I manage tools which keep track of application percentages across the LAN and WAN based on TCP/UDP port number. The way I read the IP Sec RFC, the original packet will be encapsulated, a checksum is calculated, and then all information in the original packet is encrypted (or something along those line -- that's not the important part). If this is the case, I loose visibility into the original packet and therefore cannot determine the port it was using (the important part). I haven't read anything in the description of the headers that will translate to "application". I've asked a few network managment vendors how they will account for this protocol but no one had a good answer. I'm sure this was discussed, is there any information posted? Thanks, John D Grillo Global Network Planning and Design Compaq Computer Corporation Voice: (281) 514-3842 Pager: 1-800-724-3329 PIN 382-1086 From owner-ipsec Mon Jul 27 09:14:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29543 for ipsec-outgoing; Mon, 27 Jul 1998 09:12:52 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807271329.GAA11627@kc.livingston.com> Subject: IKE drfat - draft-ietf-ipsec-isakmp-oakley-08.txt To: iesg@ietf.org, ipsec@tis.com Date: Mon, 27 Jul 1998 06:29:39 -0700 (PDT) Cc: suresh@livingston.com (Pyda Srisuresh) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I understand everyone is waiting for the IPsec drafts to advance into RFCs. But, I am afraid, a serious flaw was uncoverd in the IKE draft recently (late June). I believe, this flaw needs to be corrected before the draft is advanced into an RFC. The issue came up during a discussion between Bryan Gleeson, Vipul Gupta, myself and others. I mentioned the problem on the ipsec mailing list briefly at that time and have been trying to resolve this independently with Daniel harkins via private e-mail. But, to no avail. Dan is opposed to altering the draft. I would like the IESG to review the problem. Ref: Section 5.4. Phase I authenticated with Pre-shared-key Problem: While Main mode of negotiation and pre-shared-key based authentication are independently stated as mandatory for IKE draft compliance, together they do not work. I.e., Pre-shared-key based authentication in Main mode does not work or is seriously flawed in the way it is stated to work. Explanantion + A possible fix: Section 5.4 states that pre-shared-key based authentication in main mode requires either party to assume the source IP address of the partner (found in IP header) as the ID of partner. This is because the SKEYID used to encrypt the ID payload is based on pre-shared-key. And, the pre-shared-key couldnt be known without knowledge of the ID of the partner. Clearly, the draft cornered itself into a chicken-and-egg problem. If IP-Address type was the only valid ID type, we could take the IP address in IP header (layer 3) as a replacement for IP address in ID payload (layer 4), as the draft says. But, that would be a layer violation (assuming layer 3 info in place of layer 4 info). Even with the layer violation, this assumption is workable only with an IP-address type ID. For an IP DOI, the ID can be many different things, including a user-name, device-name, DER encoded Distintinguished Name etc. IKE negotiation would simply not work with these ID payloads. Suggestions that we should get around this by using aggressive mode or use a different type of authentication mode only enhance the argument that the protocol is inadequate for minimally compliant IKE implementations(ie, Main mode + Pre-shared-key auth). One approach I could think of to fix this problem was to disassociate authentication mechanism from key derivation (SKEYID). I am not a cryptographer and I do not understand why SKEYID is evaluated differently based on authentication schemes used. I would suggest making derivation of SKEYID uniform for all authentications, like SKEYID = prf (hash(Ni_b | Nr_b), g^xy) At a minimum, I would suggest the above SKEYID key derivation change to pre-shared-key based authentications. The chicken-and-egg problem with pre-shared-key based authentication is created because, SKEYID is derived as a function of pre-shared-key. For all other types of athentications, SKEYID derivation does not require peer ID info. Authentication based distinctions could be restricted simply to the way HASH_I and HASH_R are evaluated. For example, HASH_I and HASH_R for pre-shared key authentication could have been evaluated differently by concatenating pre-shared key to the message argument (i.e., arg2) of prf. Thanks. Regards, suresh From owner-ipsec Mon Jul 27 10:06:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA29721 for ipsec-outgoing; Mon, 27 Jul 1998 10:05:55 -0400 (EDT) Date: Mon, 27 Jul 1998 10:22:06 -0400 (EDT) Message-Id: <199807271422.KAA26412@pong.morningstar.com> From: leonard_samuelson@ascend.com (Len Samuelson) To: "Grillo, John" CC: ipsec@tis.com Subject: Network Management with IP Sec In-Reply-To: References: Reply-To: leonard_samuelson@ascend.com (Len Samuelson) Sender: owner-ipsec@ex.tis.com Precedence: bulk John Grillo writes: > Currently, I manage tools which keep track of application percentages across > the LAN and WAN based on TCP/UDP port number. > > The way I read the IP Sec RFC, the original packet will be encapsulated, a > checksum is calculated, and then all information in the original packet is > encrypted (or something along those line -- that's not the important part). > If this is the case, I loose visibility into the original packet and > therefore cannot determine the port it was using (the important part). I > haven't read anything in the description of the headers that will translate > to "application". > > I've asked a few network managment vendors how they will account for this > protocol but no one had a good answer. > > I'm sure this was discussed, is there any information posted? > > Thanks, > > John D Grillo Yup yessir, absolutely. It's been discussed ad nauseam. The answer is: If a packet is to be examined in transit, then it can't be encrypted. Use authentication only. On the other hand, if I were a person who wanted to make sure my addresses and port numbers don't become public knowledge, I would encrypt my packets. Note (as has been observed many times before) that the goal of information hiding is to hide _all_ the information, including hints and clues (such as addresses and port numbers). One way around this is for an organization to monitor the movement of packets on the private side of a security gateway. Be sure to impose some form of restriction on internal systems to prevent them from encrypting their packets! :-) -- Leonard Samuelson, Ascend Communications, Inc. 614-760-4024 From owner-ipsec Mon Jul 27 10:11:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA29744 for ipsec-outgoing; Mon, 27 Jul 1998 10:10:52 -0400 (EDT) Message-ID: From: Greg Carter To: "'Moshe Litvin'" Cc: ipsec@tis.com Subject: RE: Comments on "Hybrid Auth. mode for IKE" Date: Mon, 27 Jul 1998 10:21:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Not that I want to design something for SecurID but its a very small modification to their existing technology. Literally adding a loop with some keyed hash calculations... In a regular SecurID authentication the server is presented with the "token" displayed on the card. The token is valid at X moment in time. The server validates the token at Y moment in time. The ACE server has a window of acceptable tokens for W-X-Y-Z moments in time. The ACE server checks its window of tokens and replies back to the Gateway with a yes or no. In the imaginary shared secret mode the token is used in the HASH_I and HASH_R validation. Assuming the client is the initiator (only works with client as initiator) the client will enter the token, the IKE engine uses that to calculate HASH_I and sends HASH_I to the responder for verification. Since you are already prepared to off load the Yes/NO decision to the ACE server all you need to do is send over HASH_I to the server with the other pieces of data, all of which are sent in the clear (Aggressive mode) so there isn't any greater security risk. The ACE server tries to validate HASH_I with the tokens it has in its window. When it finds one that validates it then calculates SKEYID and returns this to you. You can then perform the rest of IKE. This is no less secure than the typical SecurID exchange. They only have to ensure that the channel between the Gateway and the ACE server is protected, which they should be doing anyway. This does not expose the one time password, in fact in typical SecurID exchanges the "Token" travels in the CLEAR to the Gateway, so SecurID is already prepared to "give up" its one time passwords. In this mode it never leaves the users machine. Only HASH_I/HASH_R, which are protected from replay by the IKE nonce. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > ---------- > From: Moshe Litvin[SMTP:moshe@checkpoint.com] > Sent: Sunday, July 26, 1998 7:56 AM > To: Greg Carter > Cc: 'Moshe Litvin'; ipsec@tis.com > Subject: Re: Comments on "Hybrid Auth. mode for IKE" > > Let's try to see how it will work with SecurID: > > The user connects to his ISP and initiate an aggressive exchange (main > mode is not possible when using pre-shared secret). The GW ask an > imaginary new version of ACE server(*) for the current value shown on > the user screen. When it gets the answer it considers it as the > pre-shared secret and sends the response for the user. > The user types what he see on his token as his shared secret. If the > minute when the the types is not exactly what the ACE server thought > that it was (because of network delay, clock drifts or other problem) > the authentication will fail. > > With challenge type tokens you have the problem of failed negotiation > when the server thinks that the challenge reached the user but it didn't > or vice versa. > > (*) About that imaginary ACE server: You dismiss as trivial the problem > of the server disclosing a secret information. How would Entrust fills > about disclosing a one time password to a Fire Wall? why would SDTI > should think otherwise? Apart from loosing control of the security of > their system they also loose the ability to guarantee that each code can > be used only once. > > Regards, > Moshe > > From owner-ipsec Mon Jul 27 10:20:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA29769 for ipsec-outgoing; Mon, 27 Jul 1998 10:18:55 -0400 (EDT) Date: Mon, 27 Jul 1998 17:34:47 +0300 (EET DST) From: Markku Savela Message-Id: <199807271434.RAA03949@anise.tte.vtt.fi> To: ipsec@tis.com Subject: Algorithm types in PF_KEY? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk Why is explicitly #defining algorithm types as described in page 43 (3.5 Algorithm types) in draft-mcdonald-pf-key-v2-06.txt (June 3 1998)? The problem I have with this: - assume IPSEC implementation supporting a set of algorithms - assume Keymanagement application talking to it with PF_KEY As written, when I add a new algorithm to the IPSEC implementation, I have to rewrite or at least recompile the Key management application. Why not just specify that algorithm numbers are integers specified by IANA, or use the ISAKMP transform ids as is? No defines in pfkeyv2.h. I want it to be possible to load new algorithms to both ends without a need to recompile the complex key management application or the kernel containing IPSEC. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Mon Jul 27 11:13:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00065 for ipsec-outgoing; Mon, 27 Jul 1998 11:12:57 -0400 (EDT) Message-Id: <199807271529.LAA16835@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-ripemd-160-96-02.txt Date: Mon, 27 Jul 1998 11:29:30 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-RIPEMD-160-96 within ESP and AH Author(s) : A. Keromytis, N. Provos Filename : draft-ietf-ipsec-auth-hmac-ripemd-160-96-02.txt Pages : 6 Date : 24-Jul-98 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. Internet-Drafts are 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-auth-hmac-ripemd-160-96-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-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: <19980724173944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-ripemd-160-96-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980724173944.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Jul 27 11:14:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00071 for ipsec-outgoing; Mon, 27 Jul 1998 11:13:02 -0400 (EDT) Message-Id: <199807271529.PAA00765@orchard.arlington.ma.us> To: "Grillo, John" cc: "'ipsec@tis.com'" Subject: Re: Network Management with IP Sec In-Reply-To: Message from "Grillo, John" of "Fri, 24 Jul 1998 17:23:04 CDT." Date: Mon, 27 Jul 1998 11:29:05 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > The way I read the IP Sec RFC, the original packet will be encapsulated, a > checksum is calculated, and then all information in the original packet is > encrypted (or something along those line -- that's not the important part). > If this is the case, I loose visibility into the original packet and > therefore cannot determine the port it was using (the important part). I > haven't read anything in the description of the headers that will translate > to "application". That's correct. this information is intentionally obscured because in many (most) cases, the networks in between the endpoints have no need to know.. > I've asked a few network managment vendors how they will account for this > protocol but no one had a good answer. I can think of several.. 1) Do a "why do we *really* want this" analysis on the what data is being collected now.. - how does knowing what the applications are help you run your network? - can you collect the information you need purely from statistics on packet sizes and the shapes of varous flows? I'm willing to bet that, in the absence of extra padding and "cover traffic", with a little effort you can discriminate between different applications based purely on packet direction, size, and timing... 2) within an enterprise, do monitoring in hosts or SG's after decryption or before encryption, and transmit appropriately condensed summaries (secured by ipsec :-) ) to a properly authorized network management station. The administrator of the host gets to control whether such monitoring happens and who gets to do how much of it; the administrator of the net gets to control whether hosts which refuse to play the game get to connect to the network.. - Bill From owner-ipsec Mon Jul 27 11:46:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00249 for ipsec-outgoing; Mon, 27 Jul 1998 11:45:02 -0400 (EDT) Message-ID: <35BCA37C.DD9C1DBB@cale.checkpoint.com> Date: Mon, 27 Jul 1998 18:57:48 +0300 From: Moshe Litvin X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Greg Carter CC: "'Moshe Litvin'" , ipsec@tis.com Subject: Re: Comments on "Hybrid Auth. mode for IKE" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Note that for this scheme to work HASH_I must be sent before HASH_R which limit the negotiation to the wrong direction for aggressive. It may work in some revised form of pre-shared secret in main mode (one that sends the ID's in the clear). So we have a way that needs a new draft, specific to one token (and a server for that token that is yet to be designed). How is it better than the hybrid mode? Moshe Greg Carter wrote: > > Not that I want to design something for SecurID but its a very small > modification to their existing technology. Literally adding a loop with > some keyed hash calculations... > > In a regular SecurID authentication the server is presented with the "token" > displayed on the card. The token is valid at X moment in time. The server > validates the token at Y moment in time. The ACE server has a window of > acceptable tokens for W-X-Y-Z moments in time. The ACE server checks its > window of tokens and replies back to the Gateway with a yes or no. > > In the imaginary shared secret mode the token is used in the HASH_I and > HASH_R validation. Assuming the client is the initiator (only works with > client as initiator) the client will enter the token, the IKE engine uses > that to calculate HASH_I and sends HASH_I to the responder for verification. > Since you are already prepared to off load the Yes/NO decision to the ACE > server all you need to do is send over HASH_I to the server with the other > pieces of data, all of which are sent in the clear (Aggressive mode) so > there isn't any greater security risk. The ACE server tries to validate > HASH_I with the tokens it has in its window. When it finds one that > validates it then calculates SKEYID and returns this to you. You can then > perform the rest of IKE. This is no less secure than the typical SecurID > exchange. They only have to ensure that the channel between the Gateway and > the ACE server is protected, which they should be doing anyway. This does > not expose the one time password, in fact in typical SecurID exchanges the > "Token" travels in the CLEAR to the Gateway, so SecurID is already prepared > to "give up" its one time passwords. In this mode it never leaves the users > machine. Only HASH_I/HASH_R, which are protected from replay by the IKE > nonce. > > Bye. > ---- > Greg Carter, Entrust Technologies > greg.carter@entrust.com > > > ---------- > > From: Moshe Litvin[SMTP:moshe@checkpoint.com] > > Sent: Sunday, July 26, 1998 7:56 AM > > To: Greg Carter > > Cc: 'Moshe Litvin'; ipsec@tis.com > > Subject: Re: Comments on "Hybrid Auth. mode for IKE" > > > > Let's try to see how it will work with SecurID: > > > > The user connects to his ISP and initiate an aggressive exchange (main > > mode is not possible when using pre-shared secret). The GW ask an > > imaginary new version of ACE server(*) for the current value shown on > > the user screen. When it gets the answer it considers it as the > > pre-shared secret and sends the response for the user. > > The user types what he see on his token as his shared secret. If the > > minute when the the types is not exactly what the ACE server thought > > that it was (because of network delay, clock drifts or other problem) > > the authentication will fail. > > > > With challenge type tokens you have the problem of failed negotiation > > when the server thinks that the challenge reached the user but it didn't > > or vice versa. > > > > (*) About that imaginary ACE server: You dismiss as trivial the problem > > of the server disclosing a secret information. How would Entrust fills > > about disclosing a one time password to a Fire Wall? why would SDTI > > should think otherwise? Apart from loosing control of the security of > > their system they also loose the ability to guarantee that each code can > > be used only once. > > > > Regards, > > Moshe > > > > -- ----------------------------------------------------------------------- Moshe Litvin Check Point Software Technologies Ltd. moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555) Fax: +972-3-575-9256 ----------------------------------------------------------------------- From owner-ipsec Mon Jul 27 11:54:11 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00318 for ipsec-outgoing; Mon, 27 Jul 1998 11:54:04 -0400 (EDT) Date: Mon, 27 Jul 1998 09:10:19 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: Comments on "Hybrid Auth. mode for IKE" To: Stephen Kent Cc: Pat.Calhoun@Eng.Sun.Com, ipsec@tis.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Pat, > > I have not looked at EAP, but the notion of transporting auth data between > endpoints who are not directly connected seems like a reasonable goal. > However, if these endpoints are not IPsec implementations, I would see this > as an adjunct to IKE, not an alternative underlying mechanism. > > SOCKS and PPP have modes in which only bind-time auth is provided, i.e., > there is nothing that cryptographically ties each successive packet to the > initial auth exchange. This differs from IPsec, where the keying materail > used with AH or with ESP auth/integrity is tied directly to the initial > auth and encryption exchange. Given this fundamental dichotomy, I would > not expect auth mechanisms to be completely interchangeable among all of > these protocols in all of thier modes of use. Agreed, however if we can agree on a single authentication protocol "encapsulation" scheme, then the same scheme can be used by PPP, SOCKS and IPSEC (unless I am missing something fundamental here). Note that it is highly possible that the authentication mechanism used is completely different from PPP to IPSEC, but a consistent way to "tunnel" it would allow the same backend server to support more than one single application (of course the backend server would have to know about IPSEC Auth methods as well as PPP auth methods). It seems this would be quite useful for remote access. PatC > > Steve > > From owner-ipsec Mon Jul 27 13:00:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00636 for ipsec-outgoing; Mon, 27 Jul 1998 12:59:13 -0400 (EDT) Message-ID: <35BCB4C2.11651EA9@cale.checkpoint.com> Date: Mon, 27 Jul 1998 20:11:30 +0300 From: Moshe Litvin X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: kai@imib.med.tu-dresden.de, ipsec@tis.com Subject: Re: Comments on "Hybrid Auth. mode for IKE" References: <5B017CF69E1@fltserv.imib.med.tu-dresden.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Kai Martius wrote: > > Moshe, > > just another opinion to the "hybrid authentication draft". > > First some general thoughts: > > There's no doubt to need good migration paths from "80's technology" > to new one but I have some concerns doing it the way your I-D > proposes: Let's face it, the legacy tokens are not 80's technology, they are 90's technology. How many such tokens where sold in the 80's? How many where sold in the first half 98? > > 1. In general, I believe, providing too much of backward > compatibility would probably delay the implementation of more > secure authentication mechanisms, especially certificate based auth. > including a global PKI. IKE could be a good catalyst deploying > stronger auth. schemes. And it already provides a good migration > path by its pre-shared key mode (PSK) where NO PKI is needed. So the > compatibitility to older systems should build on this mode. pre-shared key for user authentication is very week. Are you saying that you agree to have a week authentication but that the hybrid is strong enough to delay the use of PK smart cards? I will take it as a compliment :-) Currently we can give our customers remote access using IPSEC, and we can give them remote access using their legacy hardware tokens for authentication. But we can't offer them both. I want to change this. > (All > token systems I know are based on symmetric crypto - like PSK mode. > At least for S/KEY I could imagine it's very easy to use it in a kind > of "one-time-PSK" mode). How would you do it with S/KEY? I can't see how it can be done. > > 2. The discussion on more or less databases to manage I don't > understand - basically there is _one_ importent database which > assigns certain rights to a USER. With cert-based auth. you have less > databases, because there is already an authenticated user name - with > any symmetric token system you need to assign the users to the token > first. The more than one data base issue is related to a separate authentication of machine and user, as in XAUTH. > > 3. A basic IKE-design principle is the 2-phase-approach of > authenticating the IKE instances in a first phase and in the second > phase to exchange keys for clients. Comparing XAUTH and hybrid mode, > XAUTH keeps the 2-phase-separation cleaner, I think. The IKE designe principle is 2-phase one phase of authentication and one phase to exchange keys. XAUTH breaks it by providing 3 phases (one to authenticate the machine, one to authenticate the user and one to exchange keys). The hybrid keeps it by being a complete mutual authentication in phase 1. > > In detail to your I-D: > > 3. You propose using Public-Key-based auth. for the edge device, > which means a certificate must be known to the mobile user or > transmitted during "hybrid auth mode"-exchange - so you need to > verify the cert. on the mobile station, and therefore you need a > basic kind of PKI, at least with a one-level certification hierarchy. > But within this hierarcy you can certify your clients too... (I > absolutely agree Steve, that it's not so difficult to build PKIs in > a limited organizational environment) I have worked on implementation of full blown PKI, and of a very minimal PKI of the sort needed for the hybrid (which for small organization may be only one key). There is a huge difference in the complexity of the code and of the management effort. > > 4. (last) your comparison to SSL (Sect. 2.2) is not correct, at > least not understandable: If a server requests client auth. during > the SSL handshake the client MUST reply with a certificate. With SSL > you always need a kind of PKI - there is no migration path with > pre-shared secrets like in IKE. Anything else above SSL mostely can't > be called client auth. (especially not a credit card number...)- it > only depends on the application running on SSL. For the Web, real > client auth. would only be provided by S-HTTP on a per-document > basis. Offcourse the comparison was not to a pure SSL but for a combination of S-HTTP server and application requiring more authentication. Maybe we should make it clearer. > > Kai > > # Kai Martius # > # Dpt. of Medical CS and Biometrics / Dresden University of Technology # > # PGP Fingerprint: to be compared after download of my key # > # Key and more info see my Homepage # > # http://www.imib.med.tu-dresden.de/imib/personal/kai.html # -- ----------------------------------------------------------------------- Moshe Litvin Check Point Software Technologies Ltd. moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555) Fax: +972-3-575-9256 ----------------------------------------------------------------------- From owner-ipsec Mon Jul 27 13:11:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA00695 for ipsec-outgoing; Mon, 27 Jul 1998 13:11:12 -0400 (EDT) Message-Id: <199807271727.KAA11919@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins owned process doing -bs X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins@localhost didn't use HELO protocol To: suresh@livingston.com (Pyda Srisuresh) cc: iesg@ietf.org, ipsec@tis.com Subject: Re: IKE drfat - draft-ietf-ipsec-isakmp-oakley-08.txt In-reply-to: Your message of "Mon, 27 Jul 1998 06:29:39 PDT." <199807271329.GAA11627@kc.livingston.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11917.901560442.1@cisco.com> Date: Mon, 27 Jul 1998 10:27:23 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 27 Jul 1998 06:29:39 PDT you wrote > > Hi, > > I understand everyone is waiting for the IPsec drafts to advance > into RFCs. But, I am afraid, a serious flaw was uncoverd in the > IKE draft recently (late June). I believe, this flaw needs to be > corrected before the draft is advanced into an RFC. The issue > came up during a discussion between Bryan Gleeson, Vipul Gupta, > myself and others. It's seriousness is debatable. Also, this is not a recently uncovered issue. Way back in March of 1997, Shawn Mamros mentioned this in <199703171625.LAA21108@portal.ex.tis.com>. It was noted that version -02 of the draft did not have this restriction while version -03 did. We're now on version -08. > I mentioned the problem on the ipsec mailing list briefly at that > time and have been trying to resolve this independently with Daniel > harkins via private e-mail. But, to no avail. Dan is opposed to > altering the draft. I would like the IESG to review the problem. > > Ref: Section 5.4. Phase I authenticated with Pre-shared-key > > Problem: While Main mode of negotiation and pre-shared-key based > authentication are independently stated as mandatory for > IKE draft compliance, together they do not work. The mandatory-to-implement options of IKE work just fine together. In fact, right now I'm accessing my mail remotely over an IPSec tunnel that was established by IKE in Main Mode and authenticated with a pre-shared key. > I.e., Pre-shared-key based authentication in Main mode > does not work or is seriously flawed in the way it is > stated to work. > > Explanantion + A possible fix: > > Section 5.4 states that pre-shared-key based authentication > in main mode requires either party to assume the source IP > address of the partner (found in IP header) as the ID of partner. > > This is because the SKEYID used to encrypt the ID payload is > based on pre-shared-key. And, the pre-shared-key couldnt be > known without knowledge of the ID of the partner. Clearly, the > draft cornered itself into a chicken-and-egg problem. > > If IP-Address type was the only valid ID type, we could take the > IP address in IP header (layer 3) as a replacement for IP address > in ID payload (layer 4), as the draft says. But, that would be a > layer violation (assuming layer 3 info in place of layer 4 info). > Even with the layer violation, this assumption is workable only > with an IP-address type ID. For an IP DOI, the ID can be many > different things, including a user-name, device-name, DER encoded > Distintinguished Name etc. IKE negotiation would simply not work > with these ID payloads. Given that the whole point of doing this IKE exchange is to do network layer security I fail to see this layer violation when using a network layer identifier in the protocol. I also take issue with the statement: "IKE negotiation would simply not work with these (not IP address) ID payloads." Main Mode and pre-shared keys, while being mandatory-to-implement, are not the only exchange and auth- entication method (respectively) defined in the draft. > Suggestions that we should get around this by using aggressive > mode or use a different type of authentication mode only enhance > the argument that the protocol is inadequate for minimally > compliant IKE implementations(ie, Main mode + Pre-shared-key auth). I fail to see the inadequacy. I'm using IPSec right now whose SAs were established by IKE doing a Main Mode exchange and authenticated with a pre-shared key. It works just fine. No problem here. > One approach I could think of to fix this problem was to > disassociate authentication mechanism from key derivation > (SKEYID). I am not a cryptographer and I do not understand > why SKEYID is evaluated differently based on authentication > schemes used. I would suggest making derivation of SKEYID > uniform for all authentications, like > SKEYID = prf (hash(Ni_b | Nr_b), g^xy) Hugo Krawczyk (a cryptographer) suggested the -02 to -03 key derivation changes. His rationale was to _directly_ authenticate SKEYID. Therefore information known only to the peers should be included in the computation. For the encrypted nonce method of authentication, including the plain-text nonces in SKEYID satisfies this; in pre-shared key authentication, including the pre-shared key in SKEYID satisfies this. Signature based authentication does not have anything known only to the peers and Hugo said that it is weaker because of it. Since the nonces are passed in the clear the suggested method of derivation is open to a man-in-the-middle attack, at least for pre-shared key and encrypted nonce methods of authentiction. > At a minimum, I would suggest the above SKEYID key derivation > change to pre-shared-key based authentications. The > chicken-and-egg problem with pre-shared-key based authentication > is created because, SKEYID is derived as a function of > pre-shared-key. For all other types of athentications, SKEYID > derivation does not require peer ID info. This is incorrect. For both methods of encrypted nonce authentication one must know the identity of the peer prior to generation of SKEYID. It is only signature-based authentication which does not have this limitation, and, as Hugo pointed out, it's probably weaker because of it. Lowering the security of all authentication methods to their lowest common denominator is an unwise thing to do. > Authentication based distinctions could be restricted simply > to the way HASH_I and HASH_R are evaluated. For example, > HASH_I and HASH_R for pre-shared key authentication could have > been evaluated differently by concatenating pre-shared key to > the message argument (i.e., arg2) of prf. In this message, Suresh has characterized this as being a newly uncovered flaw. He states that one cannot use the full range of identities in IKE because of it. He also states that Main Mode and pre-shared keys do not work together. These are all startling statements and they have the desired effect: one sits up and takes notice. Unfortunately, all three statements are incorrect. There is a limitation in using Main Mode with pre-shared keys: the pre-shared key must be bound to the IP address of the peer. This limitation has been known for quite some time now. It does not mean that Main Mode authenticated with a pre-shared key does not work together. The numerous multi-vendor "bakeoffs" which all test Main Mode authenticated with a pre- shared key illustrate this. Nor does it mean that the full range of ID types cannot be used in IKE-- only that they cannot be used with Main Mode and pre-shared key authentication. The "fix" suggested here is insecure. I hope the IESG does not delay advancement of the IPSec documents because of this. regards, Dan. From owner-ipsec Mon Jul 27 13:45:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA00803 for ipsec-outgoing; Mon, 27 Jul 1998 13:44:15 -0400 (EDT) Message-Id: <199807271800.LAA11935@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins owned process doing -bs X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins@localhost didn't use HELO protocol To: suresh@livingston.com (Pyda Srisuresh) cc: iesg@ietf.org, ipsec@tis.com Subject: Re: IKE drfat - draft-ietf-ipsec-isakmp-oakley-08.txt In-reply-to: Your message of "Mon, 27 Jul 1998 06:29:39 PDT." <199807271329.GAA11627@kc.livingston.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11933.901562446.1@cisco.com> Date: Mon, 27 Jul 1998 11:00:47 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Let me also note that the issue raised here is, in fact, mentioned in draft-ietf-ipsec-isakmp-oakley-08.txt (in section 5.4). Characterizing this as a recently uncovered flaw implies that the author either has not fully read the draft or is intentionally mischaracterizing the issue for dramatic effect. Dan. On Mon, 27 Jul 1998 06:29:39 PDT you wrote > > Hi, > > I understand everyone is waiting for the IPsec drafts to advance > into RFCs. But, I am afraid, a serious flaw was uncoverd in the > IKE draft recently (late June). I believe, this flaw needs to be > corrected before the draft is advanced into an RFC. The issue > came up during a discussion between Bryan Gleeson, Vipul Gupta, > myself and others. > > I mentioned the problem on the ipsec mailing list briefly at that > time and have been trying to resolve this independently with Daniel > harkins via private e-mail. But, to no avail. Dan is opposed to > altering the draft. I would like the IESG to review the problem. > > Ref: Section 5.4. Phase I authenticated with Pre-shared-key > > Problem: While Main mode of negotiation and pre-shared-key based > authentication are independently stated as mandatory for > IKE draft compliance, together they do not work. > I.e., Pre-shared-key based authentication in Main mode > does not work or is seriously flawed in the way it is > stated to work. > > Explanantion + A possible fix: > > Section 5.4 states that pre-shared-key based authentication > in main mode requires either party to assume the source IP > address of the partner (found in IP header) as the ID of partner. > > This is because the SKEYID used to encrypt the ID payload is > based on pre-shared-key. And, the pre-shared-key couldnt be > known without knowledge of the ID of the partner. Clearly, the > draft cornered itself into a chicken-and-egg problem. > > If IP-Address type was the only valid ID type, we could take the > IP address in IP header (layer 3) as a replacement for IP address > in ID payload (layer 4), as the draft says. But, that would be a > layer violation (assuming layer 3 info in place of layer 4 info). > Even with the layer violation, this assumption is workable only > with an IP-address type ID. For an IP DOI, the ID can be many > different things, including a user-name, device-name, DER encoded > Distintinguished Name etc. IKE negotiation would simply not work > with these ID payloads. > > Suggestions that we should get around this by using aggressive > mode or use a different type of authentication mode only enhance > the argument that the protocol is inadequate for minimally > compliant IKE implementations(ie, Main mode + Pre-shared-key auth). > > One approach I could think of to fix this problem was to > disassociate authentication mechanism from key derivation > (SKEYID). I am not a cryptographer and I do not understand > why SKEYID is evaluated differently based on authentication > schemes used. I would suggest making derivation of SKEYID > uniform for all authentications, like > SKEYID = prf (hash(Ni_b | Nr_b), g^xy) > > At a minimum, I would suggest the above SKEYID key derivation > change to pre-shared-key based authentications. The > chicken-and-egg problem with pre-shared-key based authentication > is created because, SKEYID is derived as a function of > pre-shared-key. For all other types of athentications, SKEYID > derivation does not require peer ID info. > > Authentication based distinctions could be restricted simply > to the way HASH_I and HASH_R are evaluated. For example, > HASH_I and HASH_R for pre-shared key authentication could have > been evaluated differently by concatenating pre-shared key to > the message argument (i.e., arg2) of prf. > > Thanks. > > Regards, > suresh From owner-ipsec Mon Jul 27 14:24:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01003 for ipsec-outgoing; Mon, 27 Jul 1998 14:21:13 -0400 (EDT) Message-Id: <199807271837.OAA04580@penelope.ve3tla.ampr.org> To: suresh@livingston.com (Pyda Srisuresh) cc: iesg@ietf.org, ipsec@tis.com Subject: Re: IKE drfat - draft-ietf-ipsec-isakmp-oakley-08.txt References: <199807271329.GAA11627@kc.livingston.com> In-reply-to: suresh's message of "Mon, 27 Jul 1998 09:29:39 -0400". <199807271329.GAA11627@kc.livingston.com> From: "C. Harald Koch" Date: Mon, 27 Jul 1998 14:37:43 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199807271329.GAA11627@kc.livingston.com>, Pyda Srisuresh writes: > > Problem: While Main mode of negotiation and pre-shared-key based > authentication are independently stated as mandatory for > IKE draft compliance, together they do not work. > I.e., Pre-shared-key based authentication in Main mode > does not work or is seriously flawed in the way it is > stated to work. [ snip ] > If IP-Address type was the only valid ID type, we could take the > IP address in IP header (layer 3) as a replacement for IP address > in ID payload (layer 4), as the draft says. But, that would be a > layer violation (assuming layer 3 info in place of layer 4 info). > Even with the layer violation, this assumption is workable only > with an IP-address type ID. For an IP DOI, the ID can be many > different things, including a user-name, device-name, DER encoded > Distintinguished Name etc. IKE negotiation would simply not work > with these ID payloads. The pre-shared key issue doesn't mean that the only ID acceptable is the IP address; it says that you must be able to lookup the remote peer's key *using* their IP address. This can be done, for example, by maintaining a cache of ID -> IP address mapping pairs. Also, the second most common implementation of IPsec we see is two statically addressed Security Gateways creating a static tunnel between them; in this context, pre-shared keys in main mode work flawlessly, and have the advantage of not requiring any other supporting infrastructure. In short, your're wrong. Pre-shared keying is perfectly valid and useable, within its limitations. If you can't live with those limitations, you must use either Agressive mode or a different authentication method. Can we please publish these documents now? -- C. Harald Koch "Madness takes its toll. Please have exact change." -Karen Murphy From owner-ipsec Tue Jul 28 01:32:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA02523 for ipsec-outgoing; Tue, 28 Jul 1998 01:25:35 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Daniel Harkins , suresh@livingston.com Cc: iesg@ietf.org, ipsec@tis.com Subject: RE: IKE drfat - draft-ietf-ipsec-isakmp-oakley-08.txt Date: Mon, 27 Jul 1998 22:41:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, > Let me also note that the issue raised here is, in fact, mentioned > in draft-ietf-ipsec-isakmp-oakley-08.txt (in section 5.4). > Characterizing > this as a recently uncovered flaw implies that the author > either has not > fully read the draft or is intentionally mischaracterizing > the issue for > dramatic effect. As you pointed out the issue was discussed a long time ago (Mar 97), and the answer then was essentially "use aggressive mode". This is not a mandatory feature, so it is possible to be fully ISAKMP/IPSEC compliant and yet not be able to support hosts that do not have a fixed IP address (mobile or use DHCP). From an interoperability point of view this seems a bit weak, given that hosts with dynamic IP addresses are not uncommon. Since this issue has come up again - I'll make the same suggestion I made before - make support of aggressive mode mandatory for the pre-shared key case. Bryan From owner-ipsec Tue Jul 28 06:08:49 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA03259 for ipsec-outgoing; Tue, 28 Jul 1998 06:07:34 -0400 (EDT) From: Kai Martius Organization: Uniklinik TUD To: ipsec@tis.com Date: Tue, 28 Jul 1998 12:00:49 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: IKE drfat - draft-ietf-ipsec-isakmp-oakley-08.txt Reply-to: kai@imib.med.tu-dresden.de CC: suresh@livingston.com In-reply-to: <199807271727.KAA11919@dharkins-ss20.cisco.com> References: Your message of "Mon, 27 Jul 1998 06:29:39 PDT." <199807271329.GAA11627@kc.livingston.com> X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: <5CB20DE1755@fltserv.imib.med.tu-dresden.de> Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda, > > One approach I could think of to fix this problem was to > > disassociate authentication mechanism from key derivation > > (SKEYID). I am not a cryptographer and I do not understand > > why SKEYID is evaluated differently based on authentication > > schemes used. I would suggest making derivation of SKEYID > > uniform for all authentications, like > > SKEYID = prf (hash(Ni_b | Nr_b), g^xy) As Dan outlined, there are STRONG cryptographic reasons to run the protocol and key derivation as it is. There are too much potholes a "hobby cryptographer" can fall in by changing only the smallest detail here for whatever reason. I believe there was an extensive review on IKE by *really good* cryptographers and one should trust in their knowledge to do IKE the way it is (one of the reasons to separate auth. from key derivation is to keep the long-living authentication key "away" from the short-living encrytion keys, i.e. to let *no* information about the auth. key "leak" into the enc. keys. For SIG-Mode this is not possible, so it might be a bit weaker.) The only way to apply your need would be to change the MANDATORY IKE features, but I really can't see a reason for this, especially not for the "compatibility mode (PSK)". Finally the market will decide what's mandatory - I trust in the market: this will be certificate-based mechanisms ;-) Kai # Kai Martius # # Dpt. of Medical CS and Biometrics / Dresden University of Technology # # PGP Fingerprint: to be compared after download of my key # # Key and more info see my Homepage # # http://www.imib.med.tu-dresden.de/imib/personal/kai.html # From owner-ipsec Tue Jul 28 10:29:21 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04095 for ipsec-outgoing; Tue, 28 Jul 1998 10:26:40 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807281443.HAA19634@kc.livingston.com> Subject: Re: IKE drfat - draft-ietf-ipsec-isakmp-oakley-08.txt To: dharkins@cisco.com (Daniel Harkins) Date: Tue, 28 Jul 1998 07:43:46 -0700 (PDT) Cc: suresh@livingston.com, iesg@ietf.org, ipsec@tis.com In-Reply-To: <199807271727.KAA11919@dharkins-ss20.cisco.com> from "Daniel Harkins" at Jul 27, 98 10:27:23 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > On Mon, 27 Jul 1998 06:29:39 PDT you wrote > > > > Hi, > > > > I understand everyone is waiting for the IPsec drafts to advance > > into RFCs. But, I am afraid, a serious flaw was uncoverd in the > > IKE draft recently (late June). I believe, this flaw needs to be > > corrected before the draft is advanced into an RFC. The issue > > came up during a discussion between Bryan Gleeson, Vipul Gupta, > > myself and others. > > It's seriousness is debatable. Also, this is not a recently uncovered > issue. Way back in March of 1997, Shawn Mamros mentioned this in > <199703171625.LAA21108@portal.ex.tis.com>. It was noted that version -02 > of the draft did not have this restriction while version -03 did. We're > now on version -08. > I was not aware of the earlier finding. But, It is funny you think that I was mentioning the recent finding to dramatize the effect :-) > > I mentioned the problem on the ipsec mailing list briefly at that > > time and have been trying to resolve this independently with Daniel > > harkins via private e-mail. But, to no avail. Dan is opposed to > > altering the draft. I would like the IESG to review the problem. > > > > Ref: Section 5.4. Phase I authenticated with Pre-shared-key > > > > Problem: While Main mode of negotiation and pre-shared-key based > > authentication are independently stated as mandatory for > > IKE draft compliance, together they do not work. > > The mandatory-to-implement options of IKE work just fine together. In fact, > right now I'm accessing my mail remotely over an IPSec tunnel that was > established by IKE in Main Mode and authenticated with a pre-shared key. > > > I.e., Pre-shared-key based authentication in Main mode > > does not work or is seriously flawed in the way it is > > stated to work. > > > > Explanantion + A possible fix: > > > > Section 5.4 states that pre-shared-key based authentication > > in main mode requires either party to assume the source IP > > address of the partner (found in IP header) as the ID of partner. > > > > This is because the SKEYID used to encrypt the ID payload is > > based on pre-shared-key. And, the pre-shared-key couldnt be > > known without knowledge of the ID of the partner. Clearly, the > > draft cornered itself into a chicken-and-egg problem. > > > > If IP-Address type was the only valid ID type, we could take the > > IP address in IP header (layer 3) as a replacement for IP address > > in ID payload (layer 4), as the draft says. But, that would be a > > layer violation (assuming layer 3 info in place of layer 4 info). > > Even with the layer violation, this assumption is workable only > > with an IP-address type ID. For an IP DOI, the ID can be many > > different things, including a user-name, device-name, DER encoded > > Distintinguished Name etc. IKE negotiation would simply not work > > with these ID payloads. > > Given that the whole point of doing this IKE exchange is to do network > layer security I fail to see this layer violation when using a network layer > identifier in the protocol. > IKE is a UDP based end-to-end negotiation protocol. The negotiating processes apparently process the UDP payload (i.e., transport data), not IP header. With the exception of PSK, no other auth. assumes knowledge of peer based on peer's IP address. Take for example, encryption based auth. in main mode. The initiator knows the peer it is trying to access and its public key. But,the responder does not. The initiator sends nonce and ID payload encrypted based on the public key of responder. The responder knows the public key of initiator only after it decrypts the ID payload. > I also take issue with the statement: "IKE negotiation would simply not work > with these (not IP address) ID payloads." Main Mode and pre-shared keys, > while being mandatory-to-implement, are not the only exchange and auth- > entication method (respectively) defined in the draft. > I was refering to minimally compliant IKE application. > > Suggestions that we should get around this by using aggressive > > mode or use a different type of authentication mode only enhance > > the argument that the protocol is inadequate for minimally > > compliant IKE implementations(ie, Main mode + Pre-shared-key auth). > > I fail to see the inadequacy. I'm using IPSec right now whose SAs were > established by IKE doing a Main Mode exchange and authenticated with > a pre-shared key. It works just fine. No problem here. > I cannot make comments on your specific implementation. The inadequacy is that the protocol assumes knowledge of pre-shared-key (PSK) based on the IP address of peer, and not its ID. There may be implementations that tie the IP address to an ID (like in GW-to-GW negotiation), but that wouldnt work with IDentifiers that are mobile and may not be tied to a single address. > > One approach I could think of to fix this problem was to > > disassociate authentication mechanism from key derivation > > (SKEYID). I am not a cryptographer and I do not understand > > why SKEYID is evaluated differently based on authentication > > schemes used. I would suggest making derivation of SKEYID > > uniform for all authentications, like > > SKEYID = prf (hash(Ni_b | Nr_b), g^xy) > > Hugo Krawczyk (a cryptographer) suggested the -02 to -03 key derivation > changes. His rationale was to _directly_ authenticate SKEYID. Therefore > information known only to the peers should be included in the computation. That somehow you could know the PSK without knowledge of ID is the oversight. > For the encrypted nonce method of authentication, including the plain-text > nonces in SKEYID satisfies this; in pre-shared key authentication, including > the pre-shared key in SKEYID satisfies this. Signature based authentication > does not have anything known only to the peers and Hugo said that it is > weaker because of it. > And, Signature based authentication works. > Since the nonces are passed in the clear the suggested method of derivation > is open to a man-in-the-middle attack, at least for pre-shared key and > encrypted nonce methods of authentiction. > I agree. Authentication is the principal strength against a man-in-the-middle atack for both PSK and signature based authentications. Nonces are encrypted only for encryption based authentications. > > At a minimum, I would suggest the above SKEYID key derivation > > change to pre-shared-key based authentications. The > > chicken-and-egg problem with pre-shared-key based authentication > > is created because, SKEYID is derived as a function of > > pre-shared-key. For all other types of athentications, SKEYID > > derivation does not require peer ID info. > > This is incorrect. For both methods of encrypted nonce authentication one > must know the identity of the peer prior to generation of SKEYID. That's because the Nonces used to derive SKEYID were exchanged along with ID, in messages 3 & 4. > It is > only signature-based authentication which does not have this limitation, > and, as Hugo pointed out, it's probably weaker because of it. Lowering the > security of all authentication methods to their lowest common denominator > is an unwise thing to do. > If you need authentication prior to key derivation (in order to ensure crypto strength of the derived key), the protocol should have been designed keeping that in mind. The protocol for both PSK based auth and signature based authentications fail that sequence. > > Authentication based distinctions could be restricted simply > > to the way HASH_I and HASH_R are evaluated. For example, > > HASH_I and HASH_R for pre-shared key authentication could have > > been evaluated differently by concatenating pre-shared key to > > the message argument (i.e., arg2) of prf. > > In this message, Suresh has characterized this as being a newly uncovered > flaw. He states that one cannot use the full range of identities in IKE > because of it. He also states that Main Mode and pre-shared keys do not > work together. These are all startling statements and they have the > desired effect: one sits up and takes notice. Unfortunately, all three > statements are incorrect. > > There is a limitation in using Main Mode with pre-shared keys: the > pre-shared key must be bound to the IP address of the peer. This limitation > has been known for quite some time now. It does not mean that Main Mode > authenticated with a pre-shared key does not work together. The numerous > multi-vendor "bakeoffs" which all test Main Mode authenticated with a pre- > shared key illustrate this. Nor does it mean that the full range of ID > types cannot be used in IKE-- only that they cannot be used with Main Mode > and pre-shared key authentication. > The limitation you cite essentially makes main mode with PSK auth. contrived and unworkable in many situations. Most people dont bother using the combination for this reason. This, in my opinion, is unacceptable for a minimally compliant IKE implementation. > The "fix" suggested here is insecure. > Well, given a choice between unworkable vs less-secure, I would go with the latter. Apparently, the protocol proposed for both signature and PSK based authentication is insecure (prone to man-in-the-middle attack). But, signature based authentication is more secure than the PSK based authentication, by virtue of the strength of signature authentication. May be, the draft could make aggressive mode mandatory for signature and PSK based authentications. > I hope the IESG does not delay advancement of the IPSec documents > because of this. > > regards, > > Dan. > > Regards, suresh From owner-ipsec Tue Jul 28 12:36:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA04512 for ipsec-outgoing; Tue, 28 Jul 1998 12:34:00 -0400 (EDT) Date: Tue, 28 Jul 1998 12:49:44 -0400 Message-Id: <199807281649.MAA29047@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: tytso@MIT.EDU Cc: Stephen.Waters@digital.com, ipsec@tis.com Subject: Re: key processing for manual and dynamic SA References: <250F9C8DEB9ED011A14D08002BE4F64C01B1430D@wade.reo.dec.com> <199807241625.MAA18358@tonga.xedia.com> <199807260124.VAA02800@rsts-11.mit.edu> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "tytso" == tytso writes: tytso> Date: Fri, 24 Jul 1998 12:25:32 -0400 From: Paul Koning tytso> paul> The only sensible approach I can see for dealing with the paul> parity bit is to ignore it. If the DES implementation paul> requires valid parity (I've never seen one that does) then the paul> software can invisibly supply the correct parity from the user paul> supplied key. tytso> I'd be careful before making that assumption. There was very tytso> notable case (involving telnet and Kerberos V4), where a tytso> non-crypto person at Berkeley designed the original session tytso> key negotiation for doing telnet encryption. ... tytso> The problem has since been fixed (and it involved a fairly tytso> nasty hack in the telnet client to force the session key tytso> negotiation such that the key would have the correct parity).... My comment wasn't so much an assumption as rather an observation, but anyway... Forcing valid parity outcome of the negotation sounds like a nightmare. The obvious approach -- which I assume ISAKMP uses even though it doesn't seem to be terribly clear -- is that the DES key is defined to be passed around as 8 bytes in which the low order bit is a don't care. If the implementation internally requires good parity, then the code feeding that piece of the implementation is responsible for supplying that good parity, but as far as the protocol is concerned there is no such thing as parity. paul> As for dynamic keying and weak keys, there's an explicit list paul> of weak keys to check for and a rule for how to deal with paul> that. There are other keys ("possibly weak" in Scheier) in paul> DES that you may or may not want to check for, as well as weak paul> keys for other algorithms (IDEA, Blowfish). Since the spec paul> doesn't explicitly require checking for those, you can't use a paul> "move one byte and try again" approach. Instead, if you want paul> to refuse such keys, the only method I can see that works is paul> to negotiate another key (as if this key had already expired). tytso> A number of people have already commented that weak key tytso> detection really isn't necessary. It's important to tytso> understand what weak keys mean --- a weak key K is a key for tytso> which there exists another key K' where tytso> DES_ENCRYPT(K, DES_ENCRYPT(K',M)) == M tytso> It is not the case that it is possible, merely by inspection tytso> of the ciphertext, to determine that a weak key was used. tytso> (This is unlike a class of weak keys in IDEA, which does have tytso> this property). For this reason, there is no real harm done tytso> if a weak key happens to get negotiated. The chance that (a) tytso> a weak key is negotiated, and (b) a IPSEC packet is tytso> re-encrypted in another key, and (C) the key used to tytso> re-encrypt the packet is the weak key's analogue. The chance tytso> of this happen is small enough as to not really be worth tytso> bothering about. So I think what you're saying is that *DES* weak key checking isn't crucial. tytso> On the flip side, writing code which deals with DES weak keys tytso> means writing code which will be very rarely tested, since the tytso> chance that a weak key will be negotiated is also very small. tytso> So if there's a problem with that code, it's likely that it tytso> won't be detected until after it's been shipped. tytso> That's the reason why the spec doesn't require checking for tytso> weak keys, because it's not clear that it's really a good idea tytso> to do so. Of course, different encryption algorithsm may have tytso> weak keys with different properties, such that it would be a tytso> good idea to do something to avoid weak keys. However, for tytso> DES, this does not seem to be the case. (Of course, given the tytso> results of Deep Crack, all this discussion about single DES is tytso> somewhat moot at this point. :-) My understanding is that there is a piece of weak key checking that IS required, namely the rule of taking the first 8 bytes that are non-weak. That has to be requires or else the two ends won't pick the same keying material. Of course, any weak key checking that simply invokes rekeying is not a protocol issue and can be done optionally. Then there's also the 3DES draft, which says you must check for K1==K2 || K2==K3. paul From owner-ipsec Tue Jul 28 23:23:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA06462 for ipsec-outgoing; Tue, 28 Jul 1998 23:20:59 -0400 (EDT) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807290337.UAA13776@kc.livingston.com> Subject: Re: IKE drfat - draft-ietf-ipsec-isakmp-oakley-08.txt To: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) Date: Tue, 28 Jul 1998 20:37:03 -0700 (PDT) Cc: suresh@livingston.com, dharkins@cisco.com, iesg@ietf.org, ipsec@tis.com In-Reply-To: <3.0.32.19980728144058.00947a10@bl-mail1.corpeast.baynetworks.com> from "Shawn Mamros" at Jul 28, 98 02:40:59 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > I hope the IESG does not mind if I add my two cents to this discussion, > but since my name was mentioned... > > Yes, way back when, in March 1997, I did voice some concerns about the > changes made at the time as to how key material is derived when using > pre-shared key authentication in Main Mode. And, if one examines the > ipsec mailing list traffic at the time, those concerns were addressed > by the addition of a new identification type (ID_KEY_ID) to the DOI > draft (draft-ietf-ipsec-ipsec-doi-10.txt). The use of ID_KEY_ID, > coupled with Aggressive Mode, allows one to use pre-shared key > authentication for identities other than IP addresses, without having > to reveal the "true" identities in the clear. This mode of operation > does work, and there are implementations out there which make use of > this capability. Using aggressive mode is fine. But, to suggest that somehow you would be able to hide the ID under a "blob" (ID_KEY_ID type ID) with aggressive mode is not. A "blob" cannot be a replacement for the kind of ID protection you are assured in main mode. Besides, there are many cases, where remote users cannot use a "blob", and have to simply use Network Access Identifiers (USER_ID type ID), that are well-known across a consortium of providers. Aggressive mode does not provide ID protection. However, I dont have a problem with making aggressive mode mandatory for signature and PSK based authentications. > > Main Mode using pre-shared keys also works, perhaps for a slightly > restricted set of circumstances, but it does in fact work, as has > been demonstrated on numerous occasions for a variety of applications. > If one requires a mode of operation which cannot be supported by Main > Mode and pre-shared keys, then one can use either a different authenticaion > type (digital signatures, etc.), or use Aggressive Mode, both of which are > defined in the current drafts. The fact that neither Aggressive Mode nor > the other authentication types are MUSTs should not be a hindrance. Unless, you have a minimally compliant IKE implementation. > There > are, for example, Telnet options which are not mandatory, yet which no self- > respecting modern Telnet implementation would think of doing without. The > same should hold true for Aggressive Mode in IKE and the other authentication > options - if one needs them, one should implement them; if not, one can do > without them. > > The current round of IPsec drafts have been delayed long enough. To delay > them further would be a grave disservice to the Internet community. To make > drastic changes at this late date - particularly when different vendors have > demonstrated interoperability using the existing drafts, and are fielding > successful products based on them - would be an atrocity. > > -Shawn Mamros > E-mail to: smamros@BayNetworks.com > > regards, suresh From owner-ipsec Wed Jul 29 10:51:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA08217 for ipsec-outgoing; Wed, 29 Jul 1998 10:47:22 -0400 (EDT) Date: Wed, 29 Jul 1998 10:58:46 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199807291458.KAA20584@earth.hpc.org> To: trustmgt@east.isi.edu, ipsec@tis.com, cat-ietf@MIT.EDU, ietf-ssh@clinet.fi, www-security@ns2.rutgers.edu Subject: Trust Management BOF, Chicago, Thursday Sender: owner-ipsec@ex.tis.com Precedence: bulk There will be a BOF on trust management expression and negotiation Thursday afternoon, 3:30. The agenda is still forming, so let me know if you are interested in presenting ideas. The purpose of the BOF is to discuss the need for a working group to develop data representations and protocols that allow entities in different organizations to express and negotiate the conditions under which they will communicate for various network services. The conditions are expected to include security-related mechanisms for authentication and integrity; the representations and protocols for accomplishing the negotiation are themselves security relevant and may be the subject of analysis. The BOF will discuss trust management issues in current and planned protocols and the question of whether or not the policy expression and negotiation are distinct enough from activities in the other groups to warrant the formation of a new WG. From owner-ipsec Wed Jul 29 10:51:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA08214 for ipsec-outgoing; Wed, 29 Jul 1998 10:47:18 -0400 (EDT) Message-Id: <3.0.32.19980728144058.00947a10@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 28 Jul 1998 14:40:59 -0400 To: suresh@livingston.com, dharkins@cisco.com From: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) Subject: Re: IKE drfat - draft-ietf-ipsec-isakmp-oakley-08.txt Cc: iesg@ietf.org, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I hope the IESG does not mind if I add my two cents to this discussion, but since my name was mentioned... Yes, way back when, in March 1997, I did voice some concerns about the changes made at the time as to how key material is derived when using pre-shared key authentication in Main Mode. And, if one examines the ipsec mailing list traffic at the time, those concerns were addressed by the addition of a new identification type (ID_KEY_ID) to the DOI draft (draft-ietf-ipsec-ipsec-doi-10.txt). The use of ID_KEY_ID, coupled with Aggressive Mode, allows one to use pre-shared key authentication for identities other than IP addresses, without having to reveal the "true" identities in the clear. This mode of operation does work, and there are implementations out there which make use of this capability. Main Mode using pre-shared keys also works, perhaps for a slightly restricted set of circumstances, but it does in fact work, as has been demonstrated on numerous occasions for a variety of applications. If one requires a mode of operation which cannot be supported by Main Mode and pre-shared keys, then one can use either a different authenticaion type (digital signatures, etc.), or use Aggressive Mode, both of which are defined in the current drafts. The fact that neither Aggressive Mode nor the other authentication types are MUSTs should not be a hindrance. There are, for example, Telnet options which are not mandatory, yet which no self- respecting modern Telnet implementation would think of doing without. The same should hold true for Aggressive Mode in IKE and the other authentication options - if one needs them, one should implement them; if not, one can do without them. The current round of IPsec drafts have been delayed long enough. To delay them further would be a grave disservice to the Internet community. To make drastic changes at this late date - particularly when different vendors have demonstrated interoperability using the existing drafts, and are fielding successful products based on them - would be an atrocity. -Shawn Mamros E-mail to: smamros@BayNetworks.com From owner-ipsec Wed Jul 29 22:20:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA10266 for ipsec-outgoing; Wed, 29 Jul 1998 22:18:56 -0400 (EDT) Date: Wed, 29 Jul 1998 19:29:12 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Remote access from ubiquitous IPSec hosts To: ipsec@tis.com Cc: vgupta@nobel.Eng.Sun.COM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8gyt6hDSTIOxVzHgyDff5Q== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk GSM phone users on this list are probably quite familiar with the idea of "user mobility" v/s "device mobility". These users can take any generic (some prefer the term "identity-less") GSM phone and "personalize" it by inserting their SIM card (a highly portable card about the size of a thumbprint). Assuming that appropriate administrative agreements are in place, users can roam between countries without even having to carry their personal device (phone). Now imagine if you will, ubiquitous IPSec-capable hosts at airports, hotels and other public places (we are not there yet with IPSec, but SSL in the form of HTTPS already enjoys this level of ubiquity). It would be really cool if mechanisms developed by the IPSec/IPSecond working group would allow a mobile corporate employee to walk up to one of these "identity-less" hosts and securely access network resources on his/her company's intranet (let's put aside device trust issues for a while ... more on those a little later). The key requirement here is that even the Phase I exchange must rely on a "portable" authentication mechanism, i.e. authentication should be based on information supplied by the user and on such information alone. If authentication is based on certificates, there's the problem of easily transferring a user's keys into the IPSec host. While this is doable, it requires several infrastructure changes. People have been drawn to more portable authentication mechanisms like token cards and OTPs for this reason. The current XAUTH proposal assumes that mutual authentication in Phase I can be accomplished without any user-specific input. This is hard to ensure in the remote access scenario above. The hybrid authentication proposal, on the other hand, is applicable. This is not to say that the proposal is perfect (e.g. objections to its use of the NOTIFY payload are quite valid in my opinion). However, the ability to support IPSec-based remote access from identity-less hosts is certainly worth preserving IMHO. Some of you might be thinking: Is it really wise to trust such identity-less hosts for remote access? Isn't it possible for the host to intercept sensitive information? These are valid concerns but not unique to this scenario. Even if you carry your own device, how do you know that the IPSec stack is trustworthy (most OS vendors don't offer code in source form). Similar device trust issues also arise everytime you use a bank card to withdraw cash from an ATM. The trust in these cases comes from existing laws. Thanks for your time. I'd like to hear what others think about this. vipul p.s. BTW, it is possible to achieve some of this with the existing IPSec drafts, e.g. by using aggressive exchange with pre-shared keys along with the ID_KEY_ID identifier payload and letting the user type in the pre-shared key. The only wrinkles are: IPSec compliant implementations are not required to support aggressive mode and users are notoriously bad at remembering large keys (small keys are susceptible to off-line guessing attacks). Is anyone looking into adapting schemes like Bellovin-Merritt's EKE for Phase I authentication? From owner-ipsec Thu Jul 30 01:44:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA10634 for ipsec-outgoing; Thu, 30 Jul 1998 01:42:59 -0400 (EDT) Message-Id: <199807292017.QAA00542@istari.sandelman.ottawa.on.ca> To: Vipul Gupta CC: ipsec@tis.com Subject: Re: Remote access from ubiquitous IPSec hosts In-reply-to: Your message of "Wed, 29 Jul 1998 19:29:12 PDT." Date: Wed, 29 Jul 1998 16:17:02 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Vipul" == Vipul Gupta writes: Vipul> portable card about the size of a thumbprint). Assuming Vipul> that appropriate administrative agreements are in place, users Vipul> can roam between countries without even having to carry their Vipul> personal device (phone). Grumble. Users *CAN'T* take their phone sets because there are three sets of frequencies assigned in the world: North America (1900Mhz), Europe (900Mhz, and 1800Mhz) and Asia (parts are 1800Mhz, parts are 1980Mhz or something) Vipul> It would be really cool if mechanisms developed by the IPSec/IPSecond Vipul> working group would allow a mobile corporate employee to walk up to Vipul> one of these "identity-less" hosts and securely access network Vipul> resources on his/her company's intranet (let's put aside device trust Vipul> issues for a while ... more on those a little later). Sure. Do you know the hack that was done with the ATMs (Automatic teller machine, not Accoustic Transmission Media)? There were two hacks: 1. someone put up a totally phony ATM. It just collected their card number, PIN and then reported that it had network troubles. It had no connection to any banking network. 2. someone put up an ATM in front of another ATM. They then did a man-in-the-middle attack. So, unless you carry your IPsec code in your smart card, you will be supsectible to this kind of "Radar O'Reilly" attack. Vipul> The current XAUTH proposal assumes that mutual authentication Vipul> in Phase I can be accomplished without any user-specific input. No, it assume that a *level* of mutual authentication can be accomplished without any user-specific input. The level can be *increased* via XAUTH. Vipul> However, the ability to support IPSec-based remote access from Vipul> identity-less hosts is certainly worth preserving IMHO. I think it is a waste of time given the cost and power of PDAs, notebooks, and GSM phones. (My Nokia dual mode phone has games, a calculator, a calendar, and I can get a digital interface to connect it to a pilot, which has TCP/IP and even SSH.) Vipul> Some of you might be thinking: Is it really wise to trust such Vipul> identity-less hosts for remote access? Isn't it possible for the host Vipul> to intercept sensitive information? These are valid concerns but Vipul> not unique to this scenario. Even if you carry your own device, Vipul> how do you know that the IPSec stack is trustworthy (most OS vendors Vipul> don't offer code in source form). Similar device trust issues In your public access terminal case I have to truyst the vendor, and *ALSO* every single person who has used it before me, all the system administration people who took care of it, the security guards who watched it and the people who dusted the fingerprints off the screen! :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNb+DPdiXVu0RiA21AQFu8wL/bgBbEemLduMQ0woEaV0Zv12ppxZEdYz9 XnzMePLUGJhKje3ls+LZfFQ1AgrjLIYcpHhRLdXkbf3OK5e6itSKhryQnYZa2Gaw OkO/EoYRD25V2NNIOIVwJ0Y8/0O+uSB2 =Xzha -----END PGP SIGNATURE----- From owner-ipsec Thu Jul 30 05:25:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA11231 for ipsec-outgoing; Thu, 30 Jul 1998 05:21:14 -0400 (EDT) Date: Thu, 30 Jul 1998 12:37:11 +0300 (EET DST) From: Markku Savela Message-Id: <199807300937.MAA06006@anise.tte.vtt.fi> To: mcr@sandelman.ottawa.on.ca CC: vgupta@nobel.Eng.Sun.COM, ipsec@tis.com In-reply-to: <199807292017.QAA00542@istari.sandelman.ottawa.on.ca> (mcr@sandelman.ottawa.on.ca) Subject: Re: Remote access from ubiquitous IPSec hosts Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk My vision of the future is [perhaps this drivel is not appropriate for the IPSEC mailing list, just flame me privately and I will restrict my future posts to strictly technical issues :-] Home Base Home base is a system with reasonably fixed and permanent connection to the internet. With "reasonable" I mean that it can receive e-mail by SMTP with known address. It may be a machine at home or at the office or even a mobile host. Every person will have a home base and permanent internet address, just map standard phone number into IPv6 address directly. Once the telcos move fully into IP phone world, every one who has a phone, also has a potential for having fixed IP address. The phone unit is replaced with Home Base. Home base should have IPSEC enabled. Mobile host Mobile host is a portable system you carry with you while travelling (it could be a laptop, pda or mobile phone). It will have TCP/IP stack and IPSEC. When one needs to access the home base (for example for a mail check), one could enter some "internet cafe", a lounge at the airport or whatever place that is offering fast internet access. Such places could offer a selection of interfaces (IR, ethernet, Bluetooth, etc) to hook up your portable to the local net. The local net should accept all IP addresses (and NAT, so that you don't need to reconfigure), or the hookup defines dynamic IP. In any case, the HOME BAsE will see pretty random IP source address. So, the SA must be negotiated based on some ID that the Mobile Host supplies. I wouldn't trust security of any host on such places. The IPSEC must be in your own portable unit, which you trust. Of course, if your data speed requirement is not too high, you can always connect directly from mobile to your home base using PPP over GSM data or whatever similar method. In conclusion, I believe address based policy decisions will have less significance as the time goes (other than saying that all addresses need IPSEC, perhaps excluding incoming mail and http, if you run your own web server on your home base). And finally, you don't need any firewalls to protect your homebase, ipsec does it all for you :-) -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Thu Jul 30 05:58:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA11288 for ipsec-outgoing; Thu, 30 Jul 1998 05:54:00 -0400 (EDT) To: ipsec@tis.com Subject: ISAKMP + IKE, questions. Message-Id: From: Niels Provos Date: Thu, 30 Jul 1998 12:09:51 +0200 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, a few questions about draft-ietf-ipsec-isakmp-{10,oakley-08}.txt. The questions concern Cookie Exchange to protect against Denial-of-Service, PRF, IV generation in phase 1 resp. 2 and finally size of the Diffie-Hellman groups. In '1.7.1 Anti-Clogging' it is stated: A ``cookie'' or anti-clogging token (ACT) is aimed at protecting the computing resources from attack without spending excessive CPU resources to determine its authenticity. [...] Such aggressive memory management techniques SHOULD be employed by protocols using ISAKMP that do not go through an initial, anti- clogging only phase, as was done in [Karn]. Originally in Photuris the Responder Cookie was generated on behalf of a Cookie Request from the Initiator. The Responder would not create any state at all. The cookie is generated by hashing i.a. a local secret. The passage in the draft should probably be modified to: A ``cookie'' or anti-clogging token (ACT) is aimed at protecting the responder against resource starvation, e.g. spending exessive CPU resources to determine its authenticity or exessive memory allocation due to faked initiator messages. In '2.5.3 Anti-Clogging Token (``Cookie'') Creation' it is stated: ' ... the cookie be unique for each SA establishment to help prevent replay attacks, therefore, the date and time MUST be added to the information hashed.' This passage seems to be very implementation dependant. Hashing the date and time will force you to keep state. The section should probably state: ' ... the cooke be unique for each SA establishment to help prevent replay attacks, therefore, a conforming implementation MUST ensure that the generated cookies are unique.' In 4.1 ISAKMP Exchange Types: Additionally, none of the examples include an initial exchange of ISAKMP Headers (containing initiator and responder cookies) which would provide protection against clogging (see section 2.5.3). All in all, the draft is not very precise about how the cookies protect against clogging. The easiest solution would probably be to remove the references to Denial of Service in sections 1.7.1 and 2.5.3 and define the cookie pairs as a token which is used to reference the ISAKMP SA. Another solution would be to add a Cookie Exchange to Main Mode in IKE, or define a new exchange type 'Conservative' which adds a separate Cookie Exchange at the beginning and afterwards just proceeds as Main Mode does. In Appendix A of oakley-08.txt: - PRF There are currently no pseudo-random functions defined. is a bit confusing when you want to lookup what prf does. One should probably add a sentence like: 'When no prf has been negotiated the HMAC version of negotiated hash algorithm is used (see 4. Introduction).' In Appendix B of oakley-08.txt: 'Subsequent messages MUST use the last CBC encryption block from the previous message as their initialization vector.' Normally I would interpret this as using the last CBC encypted block from the last message I sent, virtually one CBC encryption of the concatention of all payloads sent. It seems the SSH ISAKMP/Oakley testing site uses the last encrypted block of the last message received. This should be clarified. It might read as: 'Subsequent messages MUST use the last CBC encryption block from the previous message received by this party.' Regarding the predefined DH groups, MODP(1-2) and EC2N(3-4). The group orders are probably not high enough, at least when only considering the time complexities (as stated in P1363). The DL in MODP1 has an asymptotic running time of O(2**72) and in MODP2 in O(2**82) using GNFS with O(exp(1.9223 * (ln q)^(1/3) (ln ln q)^(2/3))). For large groups finding the DL using GNFS is probably infeasable because of storage complexity. For EC2N this is about O(2**76) for group 3 and O(2**91) for group 4, roughly. Also, for the elliptic curve case there have been rumours that composite exponents reduce the time needed to obtain the DL. Since nearly all implementations will support at least the predefined groups, it would be advisable to include groups in the draft with group orders high enough to derive keys for at least 3DES. In the section about Security Consideration there should be paragraph which discusses how many key bits are assumed to be derivable from the predefined groups. It might also be helpful for implementors if references to P1363 (http://stdsbbs.ieee.org/groups/1363/) or perhaps A. Menezes, Elliptic Curve Public Key Cryptosystems, Kluwer Academic Publishers, 1993. would be added. Greetings, Niels - PHYSnet Rechnerverbund PGP V2.6 Public key via finger or key server Niels Provos Universitaet Hamburg WWW: http://www.physnet.uni-hamburg.de/provos/ Jungiusstrasse 9 E-Mail: provos@wserver.physnet.uni-hamburg.de Germany 20355 Hamburg Tel.: +49 40 4123-2404 Fax: -6571 From owner-ipsec Thu Jul 30 07:48:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA11556 for ipsec-outgoing; Thu, 30 Jul 1998 07:43:00 -0400 (EDT) Date: Thu, 30 Jul 1998 14:59:33 +0300 (EET DST) Message-Id: <199807301159.OAA32164@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Vipul Gupta Cc: ipsec@tis.com Subject: Remote access from ubiquitous IPSec hosts In-Reply-To: References: X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 11 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Vipul Gupta writes: > The key requirement here is that even the Phase I exchange must > rely on a "portable" authentication mechanism, i.e. authentication > should be based on information supplied by the user and on such > information alone. If authentication is based on certificates, > there's the problem of easily transferring a user's keys into > the IPSec host. While this is doable, it requires several Whats wrong with the same idea that is used in the GSM phones, i.e. using smartcards to handle the authentication (the SIM (subscriber identity module) is really a smartcard that contains a keys and other information for the customer). You just take your smartcard with you and those machines have smartcard reader where you can put your card in. The smartcard will then do the certificate based authentication for you, and because the private key never leaves the smartcard you can be sure that it cannot be stored to the machine you are using. > infrastructure changes. People have been drawn to more portable > authentication mechanisms like token cards and OTPs for this reason. > The current XAUTH proposal assumes that mutual authentication > in Phase I can be accomplished without any user-specific input. > This is hard to ensure in the remote access scenario above. Not at all. If the company who is offering those machines are trusted they propably will get the certificate for each machine from the trusted CA vendor (or from several CA vendors). The company just have to allow certificates signed by one of those CA vendors to create ISAKMP SA with their security gateway and then they can allow extended authentication using one time passwords or token cards. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Thu Jul 30 09:33:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA12145 for ipsec-outgoing; Thu, 30 Jul 1998 09:32:03 -0400 (EDT) From: Niels Provos MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13760.12800.12305.3450@power5.physnet.uni-hamburg.de> Date: Thu, 30 Jul 1998 10:42:40 +0200 (DFT) To: ipsec@tis.com CC: Niklas Hallqvist Subject: ISAKMP + IKE, questions. X-Mailer: VM 6.46 under 19.14 XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hello, a few questions about draft-ietf-ipsec-isakmp-{10,oakley-08}.txt. The questions concern Cookie Exchange to protect against Denial-of-Service, PRF, IV generation in phase 1 resp. 2 and finally size of the Diffie-Hellman groups. In '1.7.1 Anti-Clogging' it is stated: A ``cookie'' or anti-clogging token (ACT) is aimed at protecting the computing resources from attack without spending excessive CPU resources to determine its authenticity. [...] Such aggressive memory management techniques SHOULD be employed by protocols using ISAKMP that do not go through an initial, anti- clogging only phase, as was done in [Karn]. Originally in Photuris the Responder Cookie was generated on behalf of a Cookie Request from the Initiator. The Responder would not create any state at all. The cookie is generated by hashing i.a. a local secret. The passage in the draft should probably be modified to: A ``cookie'' or anti-clogging token (ACT) is aimed at protecting the responder against resource starvation, e.g. spending exessive CPU resources to determine its authenticity or exessive memory allocation due to faked initiator messages. In '2.5.3 Anti-Clogging Token (``Cookie'') Creation' it is stated: ' ... the cookie be unique for each SA establishment to help prevent replay attacks, therefore, the date and time MUST be added to the information hashed.' This passage seems to be very implementation dependant. Hashing the date and time will force you to keep state. The section should probably state: ' ... the cooke be unique for each SA establishment to help prevent replay attacks, therefore, a conforming implementation MUST ensure that the generated cookies are unique.' In 4.1 ISAKMP Exchange Types: Additionally, none of the examples include an initial exchange of ISAKMP Headers (containing initiator and responder cookies) which would provide protection against clogging (see section 2.5.3). All in all, the draft is not very precise about how the cookies protect against clogging. The easiest solution would probably be to remove the references to Denial of Service in sections 1.7.1 and 2.5.3 and define the cookie pairs as a token which is used to reference the ISAKMP SA. Another solution would be to add a Cookie Exchange to Main Mode in IKE, or define a new exchange type 'Conservative' which adds a separate Cookie Exchange at the beginning and afterwards just proceeds as Main Mode does. In Appendix A of oakley-08.txt: - PRF There are currently no pseudo-random functions defined. is a bit confusing when you want to lookup what prf does. One should probably add a sentence like: 'When no prf has been negotiated the HMAC version of negotiated hash algorithm is used (see 4. Introduction).' In Appendix B of oakley-08.txt: 'Subsequent messages MUST use the last CBC encryption block from the previous message as their initialization vector.' Normally I would interpret this as using the last CBC encypted block from the last message I sent, virtually one CBC encryption of the concatention of all payloads sent. It seems the SSH ISAKMP/Oakley testing site uses the last encrypted block of the last message received. This should be clarified. It might read as: 'Subsequent messages MUST use the last CBC encryption block from the previous message received by this party.' Regarding the predefined DH groups, MODP(1-2) and EC2N(3-4). The group orders are probably not high enough, at least when only considering the time complexities (as stated in P1363). The DL in MODP1 has an asymptotic running time of O(2**72) and in MODP2 in O(2**82) using GNFS with O(exp(1.9223 * (ln q)^(1/3) (ln ln q)^(2/3))). For large groups finding the DL using GNFS is probably infeasable because of storage complexity. For EC2N this is about O(2**76) for group 3 and O(2**91) for group 4, roughly. Also, for the elliptic curve case there have been rumours that composite exponents reduce the time needed to obtain the DL. Since nearly all implementations will support at least the predefined groups, it would be advisable to include groups in the draft with group orders high enough to derive keys for at least 3DES. In the section about Security Consideration there should be paragraph which discusses how many key bits are assumed to be derivable from the predefined groups. It might also be helpful for implementors if references to P1363 (http://stdsbbs.ieee.org/groups/1363/) or perhaps A. Menezes, Elliptic Curve Public Key Cryptosystems, Kluwer Academic Publishers, 1993. would be added. Greetings, Niels - -- - - PHYSnet Rechnerverbund PGP V2.6 Public key via finger or key server Niels Provos Universitaet Hamburg WWW: http://www.physnet.uni-hamburg.de/provos/ Jungiusstrasse 9 E-Mail: provos@wserver.physnet.uni-hamburg.de Germany 20355 Hamburg Tel.: +49 40 4123-2404 Fax: -6571 -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBNcAx+DZ8FqYKL4flAQHevAf8CKRW54u4e/ka2/v68jDMVIy/2uiPwv2t EwaWHptV6ZNUOEVtHLJQIM9yvhXSHdHtXJPd+iAy4AX17MILyMjzkuzVpvlQEmgS TYTXbyVlt0f/kHILQQL1bbgvT6WPGtHNZGXUcUspXiGRihiFHbTXwMXP29rTpMh2 asaErGwNzade9U5UNvHF/t+jVFSfKmA+dX3KrLTGdNK/TxsOKb1c6g68zoqqXXZb /AHm/G4lGWFwDZzRGEtpIM51GRydYjDi5ZY/vEZW+FEyqdIe8njrhuRtv/DkrDXY 702CTBSKORpg6Wp5E4ALCInmrfJeM9nPx23WScrRHka+4W1qTEZ+gg== =kgIT -----END PGP SIGNATURE----- From owner-ipsec Thu Jul 30 14:16:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13318 for ipsec-outgoing; Thu, 30 Jul 1998 14:13:32 -0400 (EDT) Date: Thu, 30 Jul 1998 11:22:37 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Re: Remote access from ubiquitous IPSec hosts To: kivinen@ssh.fi Cc: vgupta@nobel.Eng.Sun.COM, ipsec@tis.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: PTV+wk8GgganV+Evr6b0EA== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk > Vipul wrote: > > The key requirement here is that even the Phase I exchange must > > rely on a "portable" authentication mechanism, i.e. authentication > > should be based on information supplied by the user and on such > > information alone. If authentication is based on certificates, > > there's the problem of easily transferring a user's keys into > > the IPSec host. While this is doable, it requires several > to which Tero responded: > Whats wrong with the same idea that is used in the GSM phones, i.e. > using smartcards to handle the authentication (the SIM (subscriber > identity module) is really a smartcard that contains a keys and other > information for the customer). There is nothing wrong with this. Infact, this would be the ideal way to do it. As you mention below, the private key never leaves the smartcard and that is a big plus. It is just that I am not sure how long it would take for smartcards and smart card readers to become as common place as keyboards (I personally would love it if this happened soon). vipul > You just take your smartcard with you and those machines have > smartcard reader where you can put your card in. The smartcard will > then do the certificate based authentication for you, and because the > private key never leaves the smartcard you can be sure that it cannot > be stored to the machine you are using. > From owner-ipsec Thu Jul 30 16:27:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA13827 for ipsec-outgoing; Thu, 30 Jul 1998 16:25:50 -0400 (EDT) From: avs@winner.lc.lucent.com Message-ID: <35C0D907.C02E9D2@winner.lc.lucent.com> Date: Thu, 30 Jul 1998 16:35:19 -0400 Original-From: Sashidhar Annaluru Organization: Lucent Technologies X-Mailer: Mozilla 4.05 [en]C-EMS-1.4 (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: A small question about the ESP proposals. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, I am referring to the "Domain of Interpretation for ISAKMP" document, section 4.4.4. In the second para, it says the following: "when authentication, integrity protection, and replay detection are required, the ^^^^ Authentication Algorithm attribute MUST be specified to identify the appropriate ESP protection suite." Does that mean that we can have an ESP without authentication? Can any body clarify? Thanks in advance Sashidhar V Annaluru avs@winner.lc.lucent.com From owner-ipsec Thu Jul 30 16:31:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA13848 for ipsec-outgoing; Thu, 30 Jul 1998 16:30:50 -0400 (EDT) Date: Thu, 30 Jul 1998 23:47:29 +0300 (EET DST) Message-Id: <199807302047.XAA19677@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Goss, Chad" Cc: ipsec@tis.com Subject: Examples? In-Reply-To: References: X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 8 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Goss, Chad writes: > Can someone point me to a location where I can find samples(hex dumps) of a > complete IKE Exchange, Phase I Agressive Mode? Would these be > available, or is it easier just to run some of the reference code > that exists. You can generate those samples using our test site at . Just take two web browsers point isakmp-test.ssh.fi to both of them, and configure the both to use ip-address 194.100.55.1. Then configure one to use ports 2111 and 2112 and the another to use portsd 2112 and 2111. Then just select the configuration values and remember to configure the another end to initiator and another as a responder. When the whole configuration is done, just start testing and you see the debug dump of the negotiation. Each payload is printed out in hex when the packet is assembled and the whole packet is also printed when it is sent or received. I just updated it to new version, and now it also includes RC5 and IDEA ciphers in the phase I. Here is a latest announcement text: ---------------------------------------------------------------------- The SSH ISAKMP/Oakley test site is now available for testing. See: . This site was already announced in the Washington IETF IPSec session, and has been operational since then, but this is official announcement for its availability for testing. The SSH ISAKMP/Oakley test site is web based test site for ISAKMP/Oakley servers and it allows your implementation to perform negotiations against the test server. It gives you sufficient debugging output, so you can resolve most problems yourself; we are happy to work with you on the remaining ones (send mail to isakmp-support@ssh.fi). For demonstration purposes, you can also put our implementation negotiating against itself by giving 194.100.55.1 as the IP address for the other end and using different port number for each end. I've now configured the system so that you can also use port 500 for testing at the SSH end. So if you couldn't test earlier because you couldn't configure the remote port, now you can also use port 500. Because only one user can be testing in the same port at same time (the test servers are each completely separate from each other, but running on same machine), it would be good to use some other port if you can, and leave port 500 for those who cannot choose... The SSH ISAKMP/Oakley test site supports latest drafts (isakmp-10, oakley-02, isakmp-oakley-08, doi-10), and following options in those drafts: - Several compatibility flags. - Authentication with Pre-Shared keys and limited support for DSA/RSA signatures and RSA encryption authentications. Authentication via signatures or encryption is slightly limited because you have to configure your own system so it trusts our test CA key (certificate for it can be found on the main page) or just trusts any certificate sent by the other end (you also need to put the "trust all certificates" flag on in SSH end so it will trust your certificates). The certificate sent by the other end must have the correct IP address in the alt name field. We can also manually do some CA operations here, so send mail to isakmp-support@ssh.fi if you want to do even more complicated certificate testing. - Both responder and initiator ends. - Both Main mode and Aggressive mode. - New group mode between main or aggressive mode and quick mode. - Quick mode. - Encryption algorithms: DES, IDEA, Blowfish, RC5, 3DES, and CAST-128. - Hash algorithms: MD5, and SHA - Diffie-Hellman Groups: 1, 2, private group arguments given in ISAKMP proposal, and private group negotiated in new group mode (for quick mode). It also supports 1536 bit modp group created by Richard Schroeppel and posted to linux-ipsec list. This is numbered to be group 5. - With or without PFS in quick mode. - Limited configuration mode support, it will respond to any configuration mode (or extended authentication) requests, but the user interface doesn't allow you to initiate them. The ISAKMP/Oakley test site is NOT connected to an IPSec engine so it will just print out the resulting keys after negotiation, so you can check them (note, that it will print just raw key material, parity bits etc are fixed in the IPSec engine level, not in this level). If you have any comments, problems, enchancements etc please send mail to isakmp-support@ssh.fi. I will try to add some more help texts to the pages later, but I think implementators should be able to understand the user interface and debug output already. I really hope this service will be usefull to IPSec community. For more information about SSH ipsec see http://www.ssh.fi/ipsec/ -- 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 Fri Jul 31 15:09:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17297 for ipsec-outgoing; Fri, 31 Jul 1998 15:01:06 -0400 (EDT) Message-ID: From: William Dixon To: "'ipsec@tis.com'" Subject: clarification: end-to-end tunnel carries ALL traffic Date: Fri, 31 Jul 1998 12:17:29 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk A quick clarification on the current architecture doc regarding what is required to be compliant for end-to-end host tunneling: MUST: end-to-end host tunnel SA covers ALL transport IP between the two hosts NOT a MUST: end-to-end host tunnel SA per selector - for example one tunnel to carry all UDP, another for all TCP If implementations supported the latter, then some others might not interoperate if they only support the former. Thanks, Wm William Dixon, 425-703-8729, wdixon@microsoft.com Program Manager, Internet Protocol Security PBS Windows Networking & Communications Microsoft Corporation From owner-ipsec Fri Jul 31 18:24:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17986 for ipsec-outgoing; Fri, 31 Jul 1998 18:22:04 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <35C0D907.C02E9D2@winner.lc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 31 Jul 1998 18:38:06 -0400 To: avs@winner.lc.lucent.com From: Stephen Kent Subject: Re: A small question about the ESP proposals. Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >I am referring to the "Domain of Interpretation for ISAKMP" document, section >4.4.4. >In the second para, it says the following: > >"when authentication, integrity protection, and replay detection are required, >the > ^^^^ >Authentication Algorithm attribute MUST be specified to identify the >appropriate >ESP protection suite." > >Does that mean that we can have an ESP without authentication? >Can any body clarify? Yes, authentication is optional for ESP, although the Arch Doc warns about using ESP w/o auth by itsefl. Note, for example, that a combined AH-ESP SA bunlde might not employ auth in ESP as it would be redundant. Steve From owner-ipsec Fri Jul 31 18:24:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17988 for ipsec-outgoing; Fri, 31 Jul 1998 18:22:04 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 31 Jul 1998 18:27:41 -0400 To: William Dixon From: Stephen Kent Subject: Re: clarification: end-to-end tunnel carries ALL traffic Cc: "'ipsec@tis.com'" Sender: owner-ipsec@ex.tis.com Precedence: bulk William, >A quick clarification on the current architecture doc regarding what is >required to be compliant for end-to-end host tunneling: > >MUST: end-to-end host tunnel SA covers ALL transport IP between the two >hosts >NOT a MUST: end-to-end host tunnel SA per selector - for example one tunnel >to carry all UDP, another for all TCP > >If implementations supported the latter, then some others might not >interoperate if they only support the former. The former capability is NOT compliant if that is the ONLY granularity at which you can specify a tunnel between two hosts, two security gateways, or between a host and a security gateway. A compliant implementation MUST support a full range of selectors for both transport and tunnel mode SAs. Use of the transport protocol selectors would allow UPD vs. TCP SA separation, as in your second example. You must also allow for per-port selectors, so that Telnet traffic is separate from HTTP or SMTP, for example. Steve