From ipsec-request@ans.net Wed Jun 1 13:20:36 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18296 (5.65c/IDA-1.4.4 for ); Wed, 1 Jun 1994 17:35:52 -0400 Received: by interlock.ans.net id AA08165 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Jun 1994 17:20:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Jun 1994 17:20:32 -0400 Message-Id: <199406012120.AA20959@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Jun 1994 17:20:32 -0400 Date: Wed, 1 Jun 94 17:20:36 EDT From: "Juan A. Garay" To: ipsec@ans.net Cc: amir@watson.ibm.com, hugo@watson.ibm.com Subject: Tunnel protocol revisited Jim, We (Amir Herzberg, Hugo Krawczyk and I) took a look at your key negotiation protocol for encrypting tunnels. We applaud your bringing up the issue; we fully agree that this constitutes an essential component of any secure architecture for Internet. In this note we present a secure tunnel establishment protocol that is related to, but different than yours. The remainder of the note is organized as follows. We first sketch the requirements/goals for/of a key establishment protocol. This is combined with comments and observations about your proposal. We then present the protocol in two stages: a high level design, followed by an implementation-oriented description. We conclude with a review and more detailed comparison. (WARNING: this is a long note.) GOALS OF A KEY EXCHANGE PROTOCOL 1. Provide a shared session key. Your protocol achieves this from public keys. However, it should be possible in general to obtain a session key from a "master" shared key. The master key itself could be obtained from the public key, but not exclusively. Besides being more efficient, this approach would accommodate a variety of solutions, like key distribution centers, manual key installation, key cacheing, etc. In particular, the life span of a master shared key can cover several sessions; in each of these sessions a new (session) key is derived from the master key using conventional functions which are significantly more efficient than public-key operations. We maintain this distinction between master and session key throughout the rest of this note. An integral part of a key exchange and session establishment protocol is the mutual authentication of the parties. This provides to each party assurance on the authentic identity of the other. Also, included in these protocols is the negotiation of tunnel parameters. 2. Efficiency. It is important to minimize both the number of flows and the the number of exponentiations (with large exponents). While the number of exponentiations required by your proposal is 8, our scheme support different variants that require from 2 to 4 exponentiations only (and no exponentiation at all if the parties already share a master key). Our scheme does not use Diffie-Helman, although it can be accommodated in the protocol. The reason is that D-H is expensive (4 exponentiations), but, as you mention, takes care of the "rubber hose" attack. This effectively poses a tradeoff in terms of the number of exponentiations that are required to achieve a certain level of security (see item (3) below). Key cacheing is also an important efficiency consideration. In your protocol, public keys are used in each session to derive the session keys. In our approach, public keys are used to obtain master shared keys, which in turn are used to obtain the session keys. 3. Level of Security. Our protocol is immune to the exposure of one of the private keys (indeed, an adversary needs to discover the private keys of both sender and receiver to derive the tunnel's key). We feel that this should be sufficient for the vast majority of applications. Your protocol, on the other hand, is secure even if both keys are exposed, at the expense of using Diffie-Helman. Simplicity and being amenable to analysis and proof are important features of any cryptographic protocol. Our protocol is structured, simple, and thus easier to analyze. (Indeed, methods similar to those of [1,2] can be used to establish the protocol's desired properties.) Here's our proposal. We first present the high-level design, including only the relevant information - the additional information (e.g., tunnel parameters) which requires authentication is omitted here for simplicity. We then specify the optimized implementation in more detail. Also for the sake of clarity, in the high level description we present the two protocols (i.e., master key exchange and session establishment) separately, and then indicate how to combine them. THE MASTER KEY EXCHANGE PROTOCOL There are two parties, S and R. We assume that S and R posses an authentic public key of each other, as well as share a nonce (a random number). The nonce serves as a challenge for guaranteeing the freshness of the authentication (i.e., avoid replay attacks). Sharing a nonce is not essential; it can be replaced by use of time stamps (at the expense of requiring good clock synchronization) or by adding an extra flow to the protocol (at the expense of performance). The nonce also serves the purpose of your Reply Identifier, namely, alleviating the effect of clogging. In any case, we stress that our nonces require no secrecy, i.e., they can be transmitted in the clear. S (for sender) is the party that initiates the protocol. We first include a brief explanation of the terminology: K_X: Random string chosen by party X. N_X: A nonce (i.e., a random number) chosen by X. E_X: RSA encryption with X's public key (this is your RSA1). We assume that the information is padded with a random string prior to encryption. SIGN_X: X's RSA signature (your RSA2). More specifically, by SIGN we mean first apply MD5 to the signed information, and then apply RSA (i.e., exponentiation with X's private key.) Since RSA operations require an argument as long as its modulus, and the MD5 output is shorter than this modulus, then the RSA operation will be performed on the concatenation of MD5 and some other fields in the packet to complete the modulus length (probably, with added randomness and redundancy). Details TBD. K: The shared master key, outcome of the protocol. MAC_K: A Message Authentication Code (or function) which is applied to a piece of information for authentication using a secret key K. Examples include block ciphers, e.g. DES, in MAC mode, or key-ed cryptographic hash functions, e.g. MD5 with prefixed/suffixed key. (MAC mode of block ciphers is like CBC encryption mode but only the last block is output.) Here's the two-flow protocol. Initially, S and R share N_R: S R S randomly chooses K_S, N_S Let E_1 = E_R(K_S) E_1, N_S, SIGN_S(E_1, TIME, N_S, N_R) ------------------------------------> R randomly chooses K_R, N'_R Let E_2 = E_S (K_R) E_2, N'_R, SIGN_R(E_2, N'_R, N_S) <------------------------------------- Both S and R compute the new master key as K = K_S XOR K_R. N'_R is the nonce to be used next time, i.e., S and R set N_R:=N'_R. Observations: 1) The use of TIME in the S-->R flow is not strictly necessary. If the random nonce is not kept, then R may agree to use the time instead. 2) SIGN_R in the return flow is not really necessary either, it can be replaced by MAC_K(E_2, N_S, N'_R). The advantage of this is efficiency (i.e., less exponentiations), at the price of not being homogeneous in both flows. This replacement of SIGN by MAC doesn't hold for the first flow, where the signature is mandatory (i.e., anybody can choose K_S and compute E_R(K_S) and MAC_K_S(...)). 3) R first verifies the signature, and only if this succeeds it decrypts K_R (this reduces computational overhead, e.g., against clogging, since signature verification is much cheaper than decryption). 4) The protocol is in some sense minimal, since 2 flows are always needed, as well as secrecy and authentication each way (thus the 2 exponentiations). This can be made even cheaper by letting only one party choose the key (in which case the compromise of the private key of this party would compromise the exchanged key). 5) The above protocol uses 4 exponentiations in total (2 by each party). Using variant 2) reduces the number to 3 (2 by S and 1 by R). By using also 4) the number of exponetiations can further be reduced to 2 (1 per party). Our proposal is based on variant 2). THE SESSION ESTABLISHMENT PROTOCOL We now turn to the process of establishing a session between S and R. This includes mutual authentication and the exchange of a session key (SK). We assume that S and R already share a master key K, as well as the nonce N_R. The protocol becomes: S R N_S, MAC_K(TIME, N_S, N_R) ------------------------------------> R randomly chooses N'_R N'_R, MAC_K(N'_R, N_S) <------------------------------------ Let T be the MAC expression in the return flow, i.e., T = MAC_K(N'_R, N_S). Then, both S and R compute SK = F_K(T) and SK becomes the new session key. Here F_K is a pseudorandom function with index K (K is the shared master key). Roughly speaking, pseudorandom functions are characterized by the pseudorandomness of their output, namely, each bit in the output of the function is unpredictable if K is unknown. Some of the functions used as MAC are also used as pseudorandom functions, e.g., DES in MAC mode. Some key-ed hash functions, as MD5, are also conjectured to be pseudorandom (although there exists less evidence for that than in the case of DES; the same is true for the use of these functions as MAC). Observations: 1. Notice that the session key SK is not explicitly transmitted. This avoids the need to encrypt this key as well as the need to authenticate it. The authenticity of SK is derived from the authenticity of the expression T. 2. The method can be readily extended to derive in turn several session keys (different keys may be needed, for example, for confidentiality and for integrity verification). 3. Notice that this protocol involves no public key at all. THE COMBINED PROTOCOL When exchanging a master key it is desirable to also have a mechanism to derive a session key. This is obtained by combining the two protocols presented above. This allows S and R to establish, starting with their public keys, both a master key AND a session key in just two flows. The first flow (from S to R) is the same as in the master key exchange protocol described above. For efficiency, the second flow uses observation 2) of that protocol. S R E_1, N_S, SIGN_S(E_1, TIME, N_S, N_R) ------------------------------------> E_2, N'_R, MAC_K(E_2, N'_R, N_S) <------------------------------------- Let T' be the MAC expression in the return flow, i.e., T' = MAC_K(E_2, N'_R, N_S). Then, both S and R compute SK = F_K(T') and SK becomes the new session key. Remark: the similarity between this protocol and the above session establishment protocol allows having the same packet format for the flows of both protocols. This is presented in detail in the next section. IMPLEMENTATION We now describe the implementation aspects in more detail. (We are borrowing the layout you used in your note.) Most importantly, we stress that both the master key exchange protocol and the session establishment protocol use the SAME packet format for the different flows. Thus, we get added functionality without the penalty of managing more packets. For the sake of clarity we start with a description of the packet for the case of master key exchange, and then comment on the use of the same packet format for the session key establishment task. Some of the details are still left undefined. Some of them are already treated in your proposal; others will be added once/if the group shows interest in this proposal. The contents of the protocol's first flow (in the master key exchange protocol) are as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | S's IP address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | R's IP address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Protocol Id; flow #; length of signature (16 bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Length of public key; Options (prot. mode, tunnel param., etc)| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | K_S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E_1 | | Random pad | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | * | Time | MD5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | N_S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SIGN_S | N_R | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | HASH | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Where: "Tunnel parameters" includes all the administrative data, such as tunnel lifetime, etc. "Protocol Id" "Protocol Mode" is basically a bit(s) indicating how should the contents be interpreted. The field K_S and the subsequent random pad do not appear in plain but encrypted under RSA_R (this is E_1 in our notation). The encryption can be extended, if desired, to hide additional fields (e.g., the protocol parameters). The HASH field contains the result of MD5 (or other one-way hash function, if desired) computed on all previous fields (or in all fields that require authentication). NOTE: The position of N_S and N_R as the last arguments in the computation of MD5 is intentional. The effectiveness of these nonces as freshness guarantee is enhanced by fixing their offset relative to the beginning or end of the authenticated arguments. The signature (using the private key of S) is applied to information of the length of the RSA modulus in use. This information MUST include the result of the HASH in the last field and may include other authentication fields as well as additional random padding and redundancy. These details TBD. We recommend, as Jim did, having the nonce N_R included since this represents a good check against clogging. (Notice that the variability on the signature scope is represented in the above figure by the *). The order of operations is as follows. For S: - Encrypt (i.e., E_1); - perform MD5; and - sign. For R (upon receiving): - Open signature; - verify N_R; - verify MD5; and - decrypt. Here's the master key exchange protocol's second flow: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | S's IP address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | R's IP address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Protocol Id; flow #; length of signature (16 bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Length of public key; Options (prot. mode, tunnel param., etc)| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | K_R | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E_2 | | Random pad | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Time | MAC_K +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | N'_R | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | N_S | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The field K_R and the subsequent random pad do not appear in plain but encrypted under RSA_S (this is E_2 in our notation). The encryption can be extended, if desired, to hide additional fields. The MAC field contains the result of MAC_K computed on all previous fields (or in all fields that require authentication). As explained above for MD5 computation, also here the position of N'_R and N_S as the last fields in the computation of MD5 is intentional. The order of operations. For R: - Encrypt (i.e., E_2); and - compute MAC_K(...). Upon receiving (S): - Verify N_S; - decrypt; and - compute MAC_K(...) and compare with MAC field. USE OF ABOVE PACKETS FOR THE SESSION ESTABLISHMENT PROTOCOL. Notice that the second flow of both protocols (master key exchange and session establishment) is identical except for the field E_2 in the first case. Therefore, the packet for the second flow of the session establishment protocol is identical to the one described above with the E_2 field omitted. Since E_2 is a variable length field (depending on the modulus size) one can use length 0 to accommodate the second flow of session establishment. As for the first flow, in the case of session establishment no public key operations are required. This means the following: a) There is no need to use the field E_1 (this is similar to the omission of E_2, discussed above); and b) the HASH field in the above packet is used as the MAC field of the session establishment protocol (128-160 bits will accommodate both cases). SUMMARY We have presented a protocol for the establishment of a secure tunnel. The protocol supports the exchange of a shared (master) key for the communicating parties as well as the establishment of secure sessions between them. The sharing of a master key uses public key to a minimum, and for session establishment (including session key exchange) no public key is required. Moreover, our solution supports scenarios where shared keys are obtained by different means, e.g., manual key installation ("sneaker-net"), key distribution centers, etc., and takes advantage of the cacheing of these keys. This added flexibility and functionality relative to Jim's proposal comes without additional price in complexity (system- and computation-wise). On the contrary, our solution accommodates the above scenarios with protocols that require a) minimal interaction (i.e., two flows), b) a single and compact packet format, and c) minimal computational overhead (only 3 long exponentiations). REFERENCES [1] R. Bird et al., "Systematic Design of Two-Party Authentication Protocols," Proc. Crypto '91, August 1991. [2] Bellare, P. Rogaway, "Entity Authentication and Key Distribution", Advances in Cryptography '93, Springer-Verlag Lecture Notes on Computer Science #773 From ipsec-request@ans.net Thu Jun 2 01:57:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18048 (5.65c/IDA-1.4.4 for ); Thu, 2 Jun 1994 12:18:43 -0400 Received: by interlock.ans.net id AA19500 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 2 Jun 1994 11:58:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 2 Jun 1994 11:58:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 2 Jun 1994 11:58:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 2 Jun 1994 11:58:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 2 Jun 1994 11:58:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 2 Jun 1994 11:58:38 -0400 Message-Id: <00112.2853392457.15273@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: hart@chaos.bsu.edu (Jim Hart) Cc: Scott_Jenkins@poncho.phx.sectel.mot.com (Scott Jenkins), ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Thu, 2 Jun 1994 8:57:28 MST Subject: FWD>Crypto IP Subject: Time:8:26 AM OFFICE MEMO FWD>Crypto IP Date:6/2/94 Hello Jim, I saw your note and as a chair of the IP Security working group I thought I would try to give you a quick update. So far, there are quite a few emerging implementations of IP layer cryptographic security, but no interoperable implementations. I believe that this will change in the next few months. You may want to subscribe to: ipsec-request@ans.net archives in ftp.ans.net This is our IETF mail list for IP security, it is currently quite slow, but with a meeting of the IETF in July, this should get more active. There will be a public domain version real soon for BSD. I do not think that the U.S. versions are necessarily weakened. For example, the UUNET implementation runs a very fast version of triple DES. What are the foreign versions that you feel are higher quality? Hope this helps, Paul A. Lambert Motorola, Inc. M/S AZ49-R1209 Internet: Paul_Lambert@email.mot.com 8220 E. Roosevelt Rd. Phone: +1-602-441-3646 Scottsdale, Az. Fax: +1-602-441-8864 85257 USA -------------------------------------- Does anybody have an update on crypto IP efforts? I've heard there are several commercial products, including weakened U.S. DES versions from Semaphore Technologies, Motorola, Hughes, and UUNET technologies. Also, some higher quality foreign versions. How many of these products interoperate across vendors? Are there any public domain versions available or in the works? Any emerging standards, so that if I wrote my own system it could interoperate with other crypto IP based clients and servers? thanks, Jim Hart hart@chaos.bsu.edu From ipsec-request@ans.net Fri Jun 3 17:37:52 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18254 (5.65c/IDA-1.4.4 for ); Fri, 3 Jun 1994 22:05:39 -0400 Received: by interlock.ans.net id AA09170 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 3 Jun 1994 21:37:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 3 Jun 1994 21:37:46 -0400 Message-Id: <199406040137.AA13774@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 3 Jun 1994 21:37:46 -0400 Date: Fri, 3 Jun 94 21:37:52 EDT From: hugo@watson.ibm.com To: ipsec@ans.net Subject: comment on swIPe Draft I happened to take a look at the swIPe IP Security Protocol Draft by Ioannidis and Blaze which, just by chance, expires today. So before the day is over let me provide you with the following comment. (I guess that at least Matt is busy with other things now, for example, giving interviews and rejecting jobs...) My comment regards the specification in the draft of the information on which the encryption is performed. According to the draft (section 2): The swIPe header is prepended to the (inner) IP datagram. The sequence number is copied into the packet and incremented. If authentication is to be performed, the authenticator field (of the appropriate length) is zeroed, and the authentication algorithm is applied to the authentication information part of the header (i.e., the swIPe header minus the first 32 bits) and the original IP datagram. The checksum resulting from the application of the authentication algorithm is copied into the authenticator field. If authentication is not performed, then the authenticator field is not present. Next, if encryption is (also) specified, the appropriate algorithm and crypto variable are selected and applied to the same parts of the datagram as the authentication. The algorithm may require padding, which is appended to the packet after encryption has been performed. The resulting datagram is then transmitted to its destination (which may not be the same as that of inner packet). Some message authentication algorithms (e.g. based on universal hashing) work by computing a checksum on the authenticated information and then encrypting this checksum. In this case one would want to apply encryption not only to the raw information but also to the authenticator field. Therefore, the specification that the encryption is "applied to the same parts of the datagram as the authentication" may be too restrictive for these cases. The option to encrypt the authenticator should then be included. Hugo Krawczyk PS: and never use a 16 bit checksum... From ipsec-request@ans.net Sun Jun 5 09:25:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15623 (5.65c/IDA-1.4.4 for ); Sun, 5 Jun 1994 02:38:22 -0400 Received: by interlock.ans.net id AA12598 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 5 Jun 1994 02:25:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 5 Jun 1994 02:25:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 5 Jun 1994 02:25:45 -0400 Date: Sun, 05 Jun 1994 09:25:43 +0000 (O) From: ERI2@FRCU.EUN.EG Subject: To: ipsec@ans.net Message-Id: <01HD6F5B07Y00024G2@FRCU.EUN.EG> X-Vms-To: IN%"ipsec@ans.net" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Hello, my name is Heba Kamal and I am working in the field of security of computer networks. Please if you can help be in finding references and where to find them in FTP, I will be very pleased. Thanks and best wishes. From ipsec-request@ans.net Mon Jun 6 12:02:07 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04192 (5.65c/IDA-1.4.4 for ); Mon, 6 Jun 1994 08:22:38 -0400 Received: by interlock.ans.net id AA21815 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Jun 1994 08:02:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 6 Jun 1994 08:02:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 6 Jun 1994 08:02:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Jun 1994 08:02:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Jun 1994 08:02:19 -0400 Message-Id: <9406061202.AA08023@snark.imsi.com> To: hugo@watson.ibm.com Cc: ipsec@ans.net Subject: Re: comment on swIPe Draft In-Reply-To: Your message of "Fri, 03 Jun 1994 21:37:52 EDT." <199406040137.AA13774@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 06 Jun 1994 08:02:07 -0400 From: "Perry E. Metzger" hugo@watson.ibm.com says: > I happened to take a look at the swIPe IP Security Protocol Draft > by Ioannidis and Blaze which, just by chance, expires today. I suspect that something newer will be replacing it. Incidently, I will be distributing swIPe code suitable for use on SunOS 4.x (and easily portable among BSD derived systems) this week at Usenix. > My comment regards the specification in the draft of the information > on which the encryption is performed. According to the draft (section 2): I'll forward your comments on to ji and Matt just in case they aren't reading their mail... Perry From ipsec-request@ans.net Mon Jun 6 17:41:31 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04141 (5.65c/IDA-1.4.4 for ); Mon, 6 Jun 1994 13:58:39 -0400 Received: by interlock.ans.net id AA13850 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Jun 1994 13:41:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Jun 1994 13:41:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Jun 1994 13:41:28 -0400 From: "Ken Hardwick" Message-Id: <9406061041.ZM1265@morkeleb.dragonsden.sherwood.or.us> Date: Mon, 6 Jun 1994 10:41:31 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: ipsec@ans.net Subject: Re: Tunnel Protocol Revisited Cc: garay@watson.ibm.com, amir@watson.ibm.com, hugo@watson.ibm.com, hughes@anubis.network.com, ken@morkeleb.dragonsden.sherwood.or.us Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hello all, I haven't been to an IPSEC meeting yet (hope to make Toronto). However, I'm working at Network Systems with Jim Hughes and we are jointly working on ways to incorporate data privacy to our products. Here are my reactions to the Garay/Herzberg/Krawcyzk (GHK) proposal for tunnel establishment. With several worthy contributions now hopefully tunnel establishment issues will pick up from their formally glacial pace. 1. One of the ideas is to improve performance by using a master key to derive session keys over the course of several sessions. I am having trouble seeing how this is any more secure than just using the same master key for several sessions and eventually going through a full negotiation for a new one. First, it implies that there will be many "sessions" during a reasonable master key lifetime. I'm not sure why this should be so. Sessions should indeed time out due to inactivity, etc. but the overhead of maintaining dozens/hundreds of tunnels is limited. I suppose it might apply in a host where there is a distinct event when sessions (binds) have initiated and terminated. Second, if my eavesdropper has recorded my encrypted conversations and, with extreme effort, eventually decrypts some part of the message stream, will not the rest of the traffic encrypted with a descendant of the same master key be open? This is certainly true if our eavesdropper computes the master key K, as the next key computation SK=F_K(T) is all based on known data. If the eavesdropper has cracked one SK, can K or the next SK be derived from that? 2. I have a problem with both the Hughes and GHK techniques to prevent replay prevention of sleeve establishment. My concern centers around what I personally call "administrative robustness" -- the neophyte sysadmin setting up a tunnel needs to be able to do so with a minimum of coordination with the other end (another person who may be a [also marginally qualified] total stranger); further the tunnel must not be fragile to adminstrative screwups (like planned or unplanned time of day/ daylight savings/ timezone equipment move) that fundamentally don't affect the security of the system. Replay prevention using time requires that all entities have and maintain a reasonably correct notion of absolute GMT. For a naive user's PC or a small site feeder router, that's asking a lot. The nonce approach of GHK looks a bit nicer. I assume that if time is used that the *initial* nonce must be distributed by means sufficently secure to ignore the replay prevention threat -- that sending "here's my initial nonce" in the clear before beginning an initial session is open to man-in-the-middle attacks. Am I right? If otherwise the nonce can be sent over an unsecured medium then this system will do the entire job. My personal preference is to have a three way handshake before data is sent. Each side gets to have a random string of its own returned back to it, ensuring that none of the messages are old ones. No knowledge of the other party than their public key is required or assumed. Yes, it takes more elapsed time, but it's far more idiotproof. A second possibility (although it mixes tunnel establishment and traffic protocols) is to return the responding party's random string with the initial traffic message which has presumably caused the originator to establish the tunnel in the first place. This does not deal with the "clogging" concern first voiced by Jim. In fact a replay attack will force a responder to receive two messages and perform one decrypt in order to recognize a replay attack. However, there is nothing subtle about a *detected* replay attack, and I personally don't have a problem with denial of service through message storms so long as the cause is detected and reported. There are *so many* ways to take out an IP node with saturation transmissions if that's what you want to do. 3. Jim Hughes and I both feel that Diffie-Hellman needs to be *available* as part of tunnel negotiation. GHK laid the issue out nicely: without D-H, a good technique requires that an intruder coerce or steal *both* private keys of the entities of each end of a tunnel in order to derive the traffic key of old sessions. This will be sufficient for many people who feel that *their* router or host won't be stolen, just the other guy's. Many of our customers are governmental and commercial professional paranoids who attach high value to the privacy of *ancient* (years old) information that may have been recorded enroute. The fact that such information is laid open if attackers got hold of several old private keys through theft, administrative error or "social engineering" is not acceptable. The down side of this is that D-H is *very* expensive in CPU time. Playing with the RSAREF code showed me that one side of a 1024 bit D-H key negotiation took 4.5 sec on a 16MHz Sparc, contrasted with 1.0 sec for a 1024 bit RSA encrypt plus decrypt. Yes, it's a case of creeping features but I'd like to see how we can make traffic keys cryptographically unknowable after the fact. 4. A point I have raised with Jim before is that there must be a clear mechanism to establish *several* tunnels between a pair of IP nodes. Each tunnel may have different crypto, compression, etc. options, and each may have a different forwarding policy when their traffic messages are decrypted. None of the proposals so far prohibit this in their formative stages, but this objective needs some airing before a standard emerges. The following comments are at a lower level of detail: 5. The session re-establishment protocol where the MAC_K() quantities are exchanged depends on both parties being able to build the payload that was MAC_K() hashed and compare the result. However the receiver must know the *exact* time sent by the sender in order to compute MAC_K(TIME, N_S, N_R), or cast about through trial and error for times that are very close. If the nonces are refreshed in every negotiation is the time needed? 6. If session establishment response is lost, the sender holds N_R while the receiver is working with N'_R. How do they get back in sync? 7. In note 2 of the master key exchange protocol the return flow can be replaced with MAC_K(E_2, N_S, N'_R). This confuses me. How can the sender compute K if K_R is not sent? How will it know N'_R for the next session exchange? 8. In note 3 of the master key exchange protocol it's stated that signature verification is much cheaper than decryption. Huh? Step 1 in verifying the signature is to *do* an RSA decrypt. Am I missing something? - Ken From ipsec-request@ans.net Mon Jun 6 04:02:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04272 (5.65c/IDA-1.4.4 for ); Mon, 6 Jun 1994 14:28:15 -0400 Received: by interlock.ans.net id AA23598 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Jun 1994 14:11:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 6 Jun 1994 14:11:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 6 Jun 1994 14:11:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 6 Jun 1994 14:11:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Jun 1994 14:11:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Jun 1994 14:11:21 -0400 Message-Id: <00112.2853745665.15962@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: perry#064#imsi.com%INTERNET@email.mot.com (perry 064 imsi.com) Cc: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Mon, 6 Jun 1994 11:02:05 MST Subject: Re: >comment on swIPe Draft Reply to: RE>>comment on swIPe Draft Perry, Its great to see some code become available! Is there an ftp site where we can obtain the code? Paul -------------------------------------- Date: 6/6/94 5:36 AM To: Paul Lambert From: perry 064 imsi.com Date: 6 Jun 94 08:02:07 -0400 Reply-To: perry#064#imsi.com%INTERNET@email.mot.com To: hugo#064#watson.ibm.com%INTERNET@email.mot.com Cc: ipsec#064#ans.net%INTERNET@email.mot.com Subject: Re: comment on swIPe Draft In-Reply-To: <199406040137.AA13774@interlock.ans.net> Message-Id: <9406061202.AA08023@snark.imsi.com> X-Reposting-Policy: redistribute only with permission hugo@watson.ibm.com says: > I happened to take a look at the swIPe IP Security Protocol Draft > by Ioannidis and Blaze which, just by chance, expires today. I suspect that something newer will be replacing it. Incidently, I will be distributing swIPe code suitable for use on SunOS 4.x (and easily portable among BSD derived systems) this week at Usenix. > My comment regards the specification in the draft of the information > on which the encryption is performed. According to the draft (section 2): I'll forward your comments on to ji and Matt just in case they aren't reading their mail... Perry From ipsec-request@ans.net Mon Jun 6 18:16:22 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18415 (5.65c/IDA-1.4.4 for ); Mon, 6 Jun 1994 14:31:47 -0400 Received: by interlock.ans.net id AA24949 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Jun 1994 14:16:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 6 Jun 1994 14:16:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 6 Jun 1994 14:16:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Jun 1994 14:16:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Jun 1994 14:16:38 -0400 Message-Id: <9406061816.AA08969@snark.imsi.com> To: Paul_Lambert@poncho.phx.sectel.mot.com Cc: "ip security mailing list" Subject: Re: >comment on swIPe Draft In-Reply-To: Your message of "06 Jun 1994 11:02:05 PDT." <00112.2853745667.15963@poncho.phx.sectel.mot.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 06 Jun 1994 14:16:22 -0400 From: "Perry E. Metzger" > Its great to see some code become available! > Is there an ftp site where we can obtain the code? Very soon. I'm making arrangements. Perry From ipsec-request@ans.net Mon Jun 6 11:27:25 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17231 (5.65c/IDA-1.4.4 for ); Mon, 6 Jun 1994 15:46:24 -0400 Received: by interlock.ans.net id AA23706 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Jun 1994 15:27:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Mon, 6 Jun 1994 15:27:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 6 Jun 1994 15:27:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 6 Jun 1994 15:27:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Jun 1994 15:27:36 -0400 Date: Mon, 6 Jun 94 15:27:25 EDT From: perry@imsi.com (Perry E. Metzger) Message-Id: <9406061927.AA17011@webster.imsi.com> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Jun 1994 15:27:36 -0400 To: ipsec@ans.net Subject: swIPe documents Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission swIPe documents can be found (via ftp) in research.att.com:/dist/mab/swipe* Floppies with swIPe for BSD (most easily SunOS 4.x) will appear at Usenix starting tomorrow evening. We only have a limited number -- hopefully FTP will be set up fairly soon. Perry From ipsec-request@ans.net Tue Jun 7 18:15:25 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18520 (5.65c/IDA-1.4.4 for ); Tue, 7 Jun 1994 14:23:28 -0400 Received: by interlock.ans.net id AA17432 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 7 Jun 1994 14:13:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 7 Jun 1994 14:13:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 7 Jun 1994 14:13:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 7 Jun 1994 14:13:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 7 Jun 1994 14:13:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 7 Jun 1994 14:13:09 -0400 Date: Tue, 7 Jun 1994 14:15:25 -0400 From: pau@watson.ibm.com (Pau-Chen Cheng) Message-Id: <9406071815.AA18273@ixextra2.watson.ibm.com> To: cat-ietf@mit.edu Subject: IMAP r 4 Cc: ipsec@ans.net Hi, could somebody give me some pointers to the "Internet Message Access Protocol" version 4 ? How did it start ? Any special message sequence or API, etc ? Thanks in advance. Regards, Pau-Chen From ipsec-request@ans.net Tue Jun 7 19:13:48 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15547 (5.65c/IDA-1.4.4 for ); Tue, 7 Jun 1994 15:23:03 -0400 Received: by interlock.ans.net id AA17453 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 7 Jun 1994 15:14:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 7 Jun 1994 15:14:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 7 Jun 1994 15:14:09 -0400 Subject: Re: IMAP r 4 From: Matti Aarnio To: pau@watson.ibm.com (Pau-Chen Cheng) Date: Tue, 7 Jun 1994 22:13:48 +0300 Cc: cat-ietf@mit.edu, ipsec@ans.net In-Reply-To: <9406071815.AA18273@ixextra2.watson.ibm.com> from "Pau-Chen Cheng" at Jun 7, 94 09:15:25 pm Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT Content-Length: 653 Message-Id: <94Jun7.221352eet_dst.167149-1@utu.fi> > Hi, could somebody give me some pointers to the > "Internet Message Access Protocol" version 4 ? > > How did it start ? Any special message sequence or API, etc ? It is email oriented message-access-protocol, though it can be used for other similar uses (like reading news). Send a question to: imap-request@cac.washington.edu (ask to join to the list, and/or for logs of past discussions, there is a lot information available, including pointers to sample APIs.) At the moment IETF-draft repositories contain two draft-ietf-imap-* -documents regarding IMAP4. > Thanks in advance. > > Regards, Pau-Chen /Matti Aarnio From ipsec-request@ans.net Fri Jun 10 14:10:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15664 (5.65c/IDA-1.4.4 for ); Fri, 10 Jun 1994 10:26:59 -0400 Received: by interlock.ans.net id AA20923 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 10 Jun 1994 10:17:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 10 Jun 1994 10:17:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 10 Jun 1994 10:17:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 10 Jun 1994 10:17:42 -0400 Message-Id: <9406101410.AA00956@skidrow.lkg.dec.com> To: amir@watson.ibm.com Cc: ipsec@ans.net Subject: Re: Two keys to differentiate directions In-Reply-To: Your message of "Fri, 20 May 94 13:59:46 EDT." <199405201800.AA15749@interlock.ans.net> Date: Fri, 10 Jun 94 10:10:05 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: amir@watson.ibm.com To: ipsec@ans.net >Donald, > >>> I think the simplest answer is not to use the same key for both >>> directions. > >This would work but it is a wasteful solution. A much simpler and >more efficient solution is to have a clear direction indicator, What is it you are wasting? You usually have plenty of keying material, relative to the requirements of most symetric algorithms, if you do Diffie-Hellman, and it adds some small amount of cryptographic strengh for the adversary to have to break two keys to see the entire conversation. Why is using a bit simpler? Why is using a bit more efficient? Sure, the bit is probably free in most designs, but using different keys potentially frees up the bit for other uses. >this is also simpler to reason about, and is a standard and well Why is it simpler to reason about? If you use different keys, they any confusion in communications or attempt to reply in the wrong direction will result in garbage and authentication/integrity failure. >known technique. In particular you could use the sender/recipient in >the authenticated information (although it is enough, for this purpose, >to use only one bit e.g. do I have the lower or higher address). I do agree that using a bit is a standard and well known technique. >best, Amir Herzberg Donald From ipsec-request@ans.net Sat Jun 11 22:24:56 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19138 (5.65c/IDA-1.4.4 for ); Sat, 11 Jun 1994 12:46:05 -0400 Received: by interlock.ans.net id AA03597 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 11 Jun 1994 12:22:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 11 Jun 1994 12:22:34 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 11 Jun 1994 12:22:34 -0400 Date: Sat, 11 Jun 94 18:24:56 -0400 From: ntg@ritsec.com.eg (Ahmed Ashraf Zaglul) Message-Id: <9406112224.AA07481@ritsec.com.eg> To: ipsec@ans.net Subject: Where swIPe IP Security Protocol Cc: ntg@vrit01.eg Dear sir, I am Eng. Waleed Hosny from Egypt. I started my research point in the last few weeks. My research point handles securing the routed IP data packets. I read Radia perlman book for this point, and it give me a good technique for building a robust network. I want to know a brief comment about what you call swIPe IP security protocol. Also I want to know the site that contain the explaination for this protocol knowing that i tried to make FTP for ans.net site to get it but the site refused my trial to login with Anonymous and Guest. Thank you sir, Waleed Hosny NTG@RITSEC.COM.EG From ipsec-request@ans.net Sun Jun 12 00:04:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16929 (5.65c/IDA-1.4.4 for ); Sun, 12 Jun 1994 00:04:23 -0400 Received: by interlock.ans.net id AA29799 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 11 Jun 1994 23:29:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Sat, 11 Jun 1994 23:29:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 11 Jun 1994 23:29:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 11 Jun 1994 23:29:23 -0400 Date: Sat, 11 Jun 94 19:23:03 From: "Housley, Russ" Encoding: 662 Text Message-Id: <9405117713.AA771387783@uu0892.spyrus.com> To: amir@watson.ibm.com, "Donald E. Eastlake 3rd (Beast)" Cc: ipsec@ans.net Subject: Re[2]: Two keys to differentiate directions Don: >>>> I think the simplest answer is not to use the same key for both >>>> directions. >> >>This would work but it is a wasteful solution. A much simpler and >>more efficient solution is to have a clear direction indicator, > >What is it you are wasting? You usually have plenty of keying >material, relative to the requirements of most symetric algorithms, if you >do Diffie-Hellman, and it adds some small amount of cryptographic strengh >for the adversary to have to break two keys to see the entire >conversation. What if you want to use Kerberos to distribute keys? Then, you do not have "plenty" pf keying material. Russ From ipsec-request@ans.net Sun Jun 12 14:29:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13264 (5.65c/IDA-1.4.4 for ); Sun, 12 Jun 1994 10:44:50 -0400 Received: by interlock.ans.net id AA04229 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 12 Jun 1994 10:30:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 12 Jun 1994 10:30:19 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 12 Jun 1994 10:30:19 -0400 Date: Sun, 12 Jun 1994 07:29:59 -0700 Message-Id: <199406121429.AA03006@darkstar.isi.edu> From: Clifford Neuman To: housley@spyrus.com Cc: amir@watson.ibm.com, dee@skidrow.lkg.dec.com, ipsec@ans.net In-Reply-To: "Housley, Russ"'s message of Sat, 11 Jun 94 19:23:03 <9405117713.AA771387783@uu0892.spyrus.com> Subject: Re[2]: Two keys to differentiate directions Date: Sat, 11 Jun 94 19:23:03 From: "Housley, Russ" What if you want to use Kerberos to distribute keys? Then, you do not have "plenty" pf keying material. If you are using V5 of Kerberos, keys of arbitrary size and length can be exchanged as part of the application request and response. It is up to the application to decide how to use these keys, i.e. whether it will use different keys in different directions, or otherwise. See section 3.2.5 of the Kerberos RFC, RFC1510. ~ Cliff From ipsec-request@ans.net Mon Jun 13 03:10:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15437 (5.65c/IDA-1.4.4 for ); Sun, 12 Jun 1994 17:28:50 -0400 Received: by interlock.ans.net id AA22425 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 12 Jun 1994 17:07:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 12 Jun 1994 17:07:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 12 Jun 1994 17:07:37 -0400 Date: Sun, 12 Jun 94 23:10:59 -0400 From: ntg@ritsec.com.eg (Ahmed Ashraf Zaglul) Message-Id: <9406130310.AA10327@ritsec.com.eg> To: ipsec@ans.net Subject: Expired swIPe Cc: ntg@vrit01.eg Dear sir, I read the swIPe protocol document available in research.att.com . I notices that the expiraiton date is reached. Are there a new version of the draft issued. Thank you sir Waleed Hosny From ipsec-request@ans.net Mon Jun 13 12:52:35 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16172 (5.65c/IDA-1.4.4 for ); Mon, 13 Jun 1994 09:07:49 -0400 Received: by interlock.ans.net id AA22444 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 13 Jun 1994 08:57:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 13 Jun 1994 08:57:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 13 Jun 1994 08:57:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 13 Jun 1994 08:57:28 -0400 Message-Id: <9406131252.AA23670@skidrow.lkg.dec.com> To: ntg@ritsec.com.eg (Ahmed Ashraf Zaglul) Cc: ipsec@ans.net Subject: Re: Where swIPe IP Security Protocol In-Reply-To: Your message of "Sat, 11 Jun 94 18:24:56 EDT." <9406112224.AA07481@ritsec.com.eg> Date: Mon, 13 Jun 94 08:52:35 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Try users anonymous at ftp.ans.net and log in with your id ( ntg@ritsec.com.eg ) as password. Stuff is in /pub/archive/ipsec. Donald From: ntg@ritsec.com.eg (Ahmed Ashraf Zaglul) To: ipsec@ans.net Cc: ntg@vrit01.eg >Dear sir, >I am Eng. Waleed Hosny from Egypt. I started my research point in the last >few weeks. My research point handles securing the routed IP data packets. >I read Radia perlman book for this point, and it give me a good technique >for building a robust network. I want to know a brief comment about what >you call swIPe IP security protocol. Also I want to know the site that >contain the explaination for this protocol knowing that i tried to >make FTP for ans.net site to get it but the site refused my trial to login >with Anonymous and Guest. >Thank you sir, >Waleed Hosny >NTG@RITSEC.COM.EG From ipsec-request@ans.net Mon Jun 13 14:56:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13832 (5.65c/IDA-1.4.4 for ); Mon, 13 Jun 1994 11:10:25 -0400 Received: by interlock.ans.net id AA10911 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 13 Jun 1994 10:58:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 13 Jun 1994 10:58:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 13 Jun 1994 10:58:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 13 Jun 1994 10:58:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 13 Jun 1994 10:58:05 -0400 Message-Id: <9406131456.AA16338@snark.imsi.com> To: ntg@ritsec.com.eg (Ahmed Ashraf Zaglul) Cc: ipsec@ans.net, ntg@vrit01.eg Subject: Re: Expired swIPe In-Reply-To: Your message of "Sun, 12 Jun 1994 23:10:59 EDT." <9406130310.AA10327@ritsec.com.eg> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 13 Jun 1994 10:56:43 -0400 From: "Perry E. Metzger" No new version of the draft has been issued. I'm sure one will be fairly soon. BTW, we distributed about 150 copies of the swIPe reference implementation done by John Ioannidis at Usenix. Several people were very enthusiastic about ports. There should be a swIPe mailing list for discussion/fixes/improvements, and an FTP site, within a few days. Perry Ahmed Ashraf Zaglul says: > Dear sir, > I read the swIPe protocol document available in research.att.com . I notices > that the expiraiton date is reached. Are there a new version of the draft > issued. > Thank you sir > Waleed Hosny From ipsec-request@ans.net Mon Jun 13 01:47:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15436 (5.65c/IDA-1.4.4 for ); Mon, 13 Jun 1994 12:05:12 -0400 Received: by interlock.ans.net id AA15301 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 13 Jun 1994 11:47:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 13 Jun 1994 11:47:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 13 Jun 1994 11:47:22 -0400 Message-Id: Date: Mon, 13 Jun 94 08:47 PDT X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net From: brian@lloyd.com (Brian Lloyd) Subject: Re: Expired swIPe Cc: perry@imsi.com, ntg@ritsec.com.eg (Ahmed Ashraf Zaglul), ntg@vrit01.eg At 10:56 6/13/94 -0400, Perry E. Metzger wrote: >No new version of the draft has been issued. I'm sure one will be >fairly soon. Since there is at least one implementation (I believe that there are two, Phil Karn's and the one of which Perry speaks) so we should be able to take the swIPe draft from "draft" to "proposed standard" state. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From ipsec-request@ans.net Tue Jun 14 00:24:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12713 (5.65c/IDA-1.4.4 for ); Mon, 13 Jun 1994 20:34:08 -0400 Received: by interlock.ans.net id AA21105 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 13 Jun 1994 20:24:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 13 Jun 1994 20:24:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 13 Jun 1994 20:24:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 13 Jun 1994 20:24:16 -0400 Message-Id: <9406140025.AA16942@dun-dun-noodles.aktis.com> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: it just occured to me... In-Reply-To: perry@imsi.com's message of 30 May 1994 18:27:50 -0000 Date: Mon, 13 Jun 1994 20:24:59 -0400 From: Marc Horowitz Now that I have one of the swIPe disks in hand, I decided to read the draft (now expired, oh well), and I have a few comments. You describe the authenticator: An authenticator, computed over the entire swIPe packet (minus the outer IP header), but before any confidentiality processing is performed. When the authenticator is computed, the authentication data field is zeroed. There's a problem with this. First, even given a particular policy identifier, it may not be possible to determine the length of the authenticator until the authenticator is chosen. For example, if you use GSS-API, you don't know what the underlying mechanism or encoding is, so the length could even change from packet to packet (say, if an ASN.1 encoded length was a part of the checksum). This makes it impossible to put the "correct" number of zeros in place before computing the authenticator. If authentication is to be performed, the authenticator field (of the appropriate length) is zeroed, and the authentication algorithm is applied to the authentication information part of the header (i.e., the swIPe header minus the first 32 bits) and the original IP datagram. The checksum resulting from the application of the Why not include the first 32 bits as well? That seems like useful information to have signed, and the overhead is small. As a fix, I would propose changing the authenticator to be defined as the signature over the (virtualized) buffer resulting from the first 8 octets of the sWIpe header concatenated to the inner packet. It also occurs to me that even this might be an overspecification; it doesn't seem to me that the authenticator needs to be defined this rigidly. If one particular encryption system wants to stick 16 bytes of zeros in the middle of the buffer to make way for an MD5 hash, I have no problem with that. As long as the mechanism can be determined from the policy identifer, the exact details of the authenticator construction should be a mechanism-specific issue. Some security algorithms (such as DES) require padding to bring the length of the data to an integral multiple of the block size. The padding is added after the authentication data have been computed. Some integrity algorithms (such as DES MAC) also require padding. In both cases, does the padding need to be transmitted? In addition, the padding could be useful for foiling traffic analysis, etc. In short, I think this field is overspecified, too. Marc From ipsec-request@ans.net Tue Jun 14 08:25:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05877 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 12:38:19 -0400 Received: by interlock.ans.net id AA09835 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 12:27:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 12:27:40 -0400 Message-Id: <199406141627.AA21095@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 12:27:40 -0400 Date: Tue, 14 Jun 94 12:25:42 EDT From: hugo@watson.ibm.com To: ipsec@ans.net Cc: garay@watson.ibm.com Subject: Tunnnel protocol - answers and clarifications Tunnel Protocol Revisited - Response to Ken Hardwick's comments --------------------------------------------------------------- Ken, Thanks much for your comments on our tunnel proposal. They help us clarifying some important points. Here's our response to your suggestions/questions: >1. One of the ideas is to improve performance by using a master key > to derive session keys over the course of several sessions. I am > having trouble seeing how this is any more secure than just using > the same master key for several sessions and eventually going through > a full negotiation for a new one. The principle here is the fact that the more you use a key the more it is exposed (e.g., using key with weak encryption). This motivates the derivation of a different key for each session. > First, it implies that there will be many "sessions" during a reasonable > master key lifetime. I'm not sure why this should be so. Sessions > should indeed time out due to inactivity, etc. but the overhead of > maintaining dozens/hundreds of tunnels is limited. I suppose it > might apply in a host where there is a distinct event when > sessions (binds) have initiated and terminated. The basic comment here is that there is a significant cost associated with master key exchange (regardless of the procedure: manual, public-key, key dist. center,etc.). Many users will prefer to maintain shared master keys for relatively long periods of time and use newly derived session keys for data encryption/authentication. Life-time of keys will need to be negotiated between the parties as well as the particular cryptographic algorithms for use. > Second, if my eavesdropper has recorded my encrypted conversations and, > with extreme effort, eventually decrypts some part of the message > stream, will not the rest of the traffic encrypted with a descendant > of the same master key be open? This is certainly true if our eavesdropper > computes the master key K, as the next key computation SK=F_K(T) > is all based on known data. If the eavesdropper has cracked one > SK, can K or the next SK be derived from that? No, having derived SK doesn't allow the eavesdropper to derive future SK's (and, in particular, not K itself). This is a property of pseudorandom functions. >2. I have a problem with both the Hughes and GHK techniques to prevent > replay prevention of sleeve establishment. My concern centers around > what I personally call "administrative robustness" -- the neophyte > sysadmin setting up a tunnel needs to be able to do so with a minimum > of coordination with the other end (another person who may be a > [also marginally qualified] total stranger); further the tunnel must > not be fragile to adminstrative screwups (like planned or unplanned > time of day/ daylight savings/ timezone equipment move) that > fundamentally don't affect the security of the system. We don't understand your emphasis on human intervention here, but let's first make some general comments about the use of time as a measure against replay: a. We are, in principle, against, as we believe consistent timestamps are hard to maintain, especially in adversarial scenarios, and therefore untrustable. b. Our nonce mechanism avoids the use of time, but assumes a nonce is shared between S & R; c. (Already clarified in the original note) In cases the nonce is not shared (or is lost), there exist 2 options: extra flow, or use of timestamp. We would prefer the extra flow option, but believe many people in Internet will not. (We would like to know the group's opinion on the issue.) d. One can let S send the time only (if it does not have or did not keep N_R) in which case it will be R's decision (policy) whether it accepts or not the TIME value for a valid authentication. One reason we included in our (schematic) flow from S to R both TIME and N_R is to cover the case in which S has kept the N_R value but R did not. As before, R may decide whether TIME only is sufficient or not. e. If time is chosen to be used by some users, it may make sense only in the S to R flow (R will always have N_S for the response). An adversary that takes advantage of this weak freshness mechanism and manages to re-send an old S-R flow that R accepts as fresh, will succeed in clogging R but not in finding the new (master or session) key. Notice that in the case of a master key exchange, R chooses a fresh K_R which the adversary (not knowing S's private key) cannot find. In the case of a session key exchange, the incorporation of N_R' which is chosen by R into the MAC expression guarantees the freshness of the key. The adversary, not knowing K, cannot find it. We stress that this function of N_R' is necessary even if one decides that S does not keep N_R' for future use. IMPORTANT: The flows of our protocol may be used for the parties' mutual authentication regardless of a key exchange. In that case, the freshness of the time/nonce IS essential. > Replay prevention using time requires that all entities have and maintain > a reasonably correct notion of absolute GMT. For a naive user's PC or > a small site feeder router, that's asking a lot. > > The nonce approach of GHK looks a bit nicer. I assume that if time > is used that the *initial* nonce must be distributed by means sufficently > secure to ignore the replay prevention threat -- that sending "here's my > initial nonce" in the clear before beginning an initial session is > open to man-in-the-middle attacks. Am I right? If otherwise the nonce > can be sent over an unsecured medium then this system will do the entire > job. There is no need for secrecy or integrity protection of the nonce on its way between S and R, so in a way the extra flow does the job. > My personal preference is to have a three way handshake before data is > sent. Each side gets to have a random string of its own returned back > to it, ensuring that none of the messages are old ones. No knowledge > of the other party than their public key is required or assumed. > Yes, it takes more elapsed time, but it's far more idiotproof. > A second possibility (although it mixes tunnel establishment and > traffic protocols) is to return the responding party's random string > with the initial traffic message which has presumably caused the > originator to establish the tunnel in the first place. > > This does not deal with the "clogging" concern first voiced by Jim. > In fact a replay attack will force a responder to receive two > messages and perform one decrypt in order to recognize a replay attack. > However, there is nothing subtle about a *detected* replay attack, > and I personally don't have a problem with denial of service through > message storms so long as the cause is detected and reported. There > are *so many* ways to take out an IP node with saturation transmissions > if that's what you want to do. > We feel that the proposed solution deals well with the clogging problem. It helps alleviating the problem without adding unnecessary complexity to the normal use of the protocol. > >3. Jim Hughes and I both feel that Diffie-Hellman needs to be *available* > as part of tunnel negotiation. GHK laid the issue out nicely: without > D-H, a good technique requires that an intruder coerce or steal *both* > private keys of the entities of each end of a tunnel in order to > derive the traffic key of old sessions. This will be sufficient for many > people who feel that *their* router or host won't be stolen, just the > other guy's. > > Many of our customers are governmental and commercial professional > paranoids who attach high value to the privacy of *ancient* (years > old) information that may have been recorded enroute. The fact that > such information is laid open if attackers got hold of several old > private keys through theft, administrative error or "social engineering" > is not acceptable. > > The down side of this is that D-H is *very* expensive in CPU time. > Playing with the RSAREF code showed me that one side of a 1024 bit > D-H key negotiation took 4.5 sec on a 16MHz Sparc, contrasted with > 1.0 sec for a 1024 bit RSA encrypt plus decrypt. > > Yes, it's a case of creeping features but I'd like to see how we can > make traffic keys cryptographically unknowable after the fact. We agree, but feel that Internet is heterogeneous enough that many people may not need it and refuse to pay that price. If there is enough interest, D-H could be incorporated to the protocol as an option/extension. >4. A point I have raised with Jim before is that there must be a clear > mechanism to establish *several* tunnels between a pair of IP nodes. > Each tunnel may have different crypto, compression, etc. options, and > each may have a different forwarding policy when their traffic messages > are decrypted. None of the proposals so far prohibit this in their > formative stages, but this objective needs some airing before > a standard emerges. We agree. Our solutions are designed to support multiple tunnels between a pair of nodes. Again, it would be nice to hear from the group before we go on. >The following comments are at a lower level of detail: > >5. The session re-establishment protocol where the MAC_K() quantities > are exchanged depends on both parties being able to build the > payload that was MAC_K() hashed and compare the result. However the > receiver must know the *exact* time sent by the sender in order to > compute MAC_K(TIME, N_S, N_R), or cast about through trial and > error for times that are very close. If the nonces are refreshed > in every negotiation is the time needed? As explained above, time is required only in the case that a nonce is not shared. About knowing the time, this is not required since the time is also transmitted outside the MAC expression (please refer to the packet figures in our proposal). >6. If session establishment response is lost, the sender holds N_R while > the receiver is working with N'_R. How do they get back in sync? Getting back in sync is done exactly as in the case where a nonce is not shared (i.e., use time or exchange new nonce with extra flow). >7. In note 2 of the master key exchange protocol the return flow > can be replaced with MAC_K(E_2, N_S, N'_R). This confuses me. > How can the sender compute K if K_R is not sent? How will it > know N'_R for the next session exchange? K_R *is* sent (encrypted) in E_2. Further, note that we are indeed using this option (See COMBINED PROTOCOL in our proposal). >8. In note 3 of the master key exchange protocol it's stated that > signature verification is much cheaper than decryption. Huh? > Step 1 in verifying the signature is to *do* an RSA decrypt. > Am I missing something? Verification *is* cheaper than encryption. For example, assuming 512 bits, if the public exponent is 3, verification is 256 times faster; if the p.e. is 2^16 + 1, then verification is 512/17 (~ 30) times faster. BTW, these exponentiations (the "long" ones) are the ones we count in our proposal. GHK From ipsec-request@ans.net Tue Jun 14 17:43:21 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13980 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 14:18:13 -0400 Received: by interlock.ans.net id AA41116 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 14:05:25 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 14:05:25 -0400 Message-Id: <199406141805.AA28056@interlock.ans.net> To: Brian Lloyd Cc: ipsec@ans.net, perry@imsi.com Subject: Re: Expired swIPe In-Reply-To: Your message of Mon, 13 Jun 94 08:47:00 -0700. Date: Tue, 14 Jun 94 13:43:21 -0400 From: Steve Kent Brian, I think it would be nice to reach concensus within the WG on an IPSP protocol spec before declaring any particular implementations as compliant. Steve From ipsec-request@ans.net Tue Jun 14 18:44:15 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12749 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 14:55:30 -0400 Received: by interlock.ans.net id AA21180 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 14:44:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 14 Jun 1994 14:44:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Jun 1994 14:44:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 14:44:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 14:44:37 -0400 Message-Id: <9406141844.AA20850@snark.imsi.com> To: Steve Kent Cc: ipsec@ans.net Subject: Re: Expired swIPe In-Reply-To: Your message of "Tue, 14 Jun 1994 13:43:21 EDT." <199406141805.OAA06796@wintermute.imsi.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Jun 1994 14:44:15 -0400 From: "Perry E. Metzger" Steve Kent says: > Brian, > > I think it would be nice to reach concensus within the WG on > an IPSP protocol spec before declaring any particular implementations > as compliant. Steve; Just curious, but are there any other contenders running on a wide variety of platforms today, other than swIPe? Perry From ipsec-request@ans.net Tue Jun 14 11:12:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13765 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 15:23:05 -0400 Received: by interlock.ans.net id AA41010 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 15:12:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 14 Jun 1994 15:12:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Jun 1994 15:12:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 15:12:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 15:12:20 -0400 Date: Tue, 14 Jun 94 15:12:00 EDT From: Marcus J Ranum Message-Id: <9406141912.AA24169@tis.com> To: kent@BBN.COM, perry@imsi.com Subject: Re: Expired swIPe Cc: ipsec@ans.net >Just curious, but are there any other contenders running on a wide >variety of platforms today, other than swIPe? Does anyone have a list of the platforms swIPe has been ported to?? I noticed the distribution looks pretty Sun-specific. Anyone done a port to BSDI/4.4? How big *is* swIPe's installed base? (not counting floppies that were handed out at USENIX) mjr. From ipsec-request@ans.net Tue Jun 14 19:24:20 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16140 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 15:33:44 -0400 Received: by interlock.ans.net id AA15014 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 15:24:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 14 Jun 1994 15:24:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Jun 1994 15:24:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 15:24:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 15:24:36 -0400 Message-Id: <9406141924.AA20939@snark.imsi.com> To: Marcus J Ranum Cc: ipsec@ans.net Subject: Re: Expired swIPe In-Reply-To: Your message of "Tue, 14 Jun 1994 15:12:00 EDT." <9406141912.AA24169@tis.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Jun 1994 15:24:20 -0400 From: "Perry E. Metzger" Marcus J Ranum says: > Does anyone have a list of the platforms swIPe has been ported > to?? I noticed the distribution looks pretty Sun-specific. Anyone done > a port to BSDI/4.4? John wrote original code for Mach and BSD on PCs. He ported it to make it modloadable on suns. The decision to do that was because of the number of suns that are around, and the fact that a modloadable implemenation can be played with with little investment in kernel configuration. However, to my knowledge, its been running on non-suns as long or longer than on suns. I know a couple of people are trying to do ports to other BSD platforms (NetBSD in particular, which has a 4.4 style kernel), but we only handed them the code last week at Usenix. There should be a mailing list set up at Columbia within a few days for people hacking swIPe -- I'll announce it when it happens. > How big *is* swIPe's installed base? (not counting floppies > that were handed out at USENIX) The number of people playing with it is significant, but the number of people using it for real work is likely close to zero. There isn't a key management protocol yet, and without one its hard (unless you are building a secure bridge or point to point link for which sneakernet is sufficient for key management) to use such a thing without key management. Myself, I (obviously) think key management is the key to everything, and thats what I'm spending my neurons on these days. Perry From ipsec-request@ans.net Tue Jun 14 20:05:03 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16135 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 16:18:19 -0400 Received: by interlock.ans.net id AA14937 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 16:09:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 14 Jun 1994 16:09:30 -0400 X400-Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 14 Jun 1994 16:09:30 -0400 X400-Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Jun 1994 16:09:30 -0400 X400-Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 16:09:30 -0400 X400-Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 16:09:30 -0400 Date: Tue, 14 Jun 1994 16:05:03 -0400 X400-Originator: /dd.id=1638487/g=marcus/i=md/s=leech/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.962:14.05.94.20.05.05] X400-Content-Type: P2-1984 (2) Content-Identifier: Granularity o... From: "marcus (m.d.) leech" Message-Id: <"17004 Tue Jun 14 16:05:59 1994"@bnr.ca> To: ipsec@ans.net Subject: Granularity of authentication in swIPe Organization: Bell-Northern Research, Information Technology Division X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2154 I just read the swipe I-D. My comments are from the point of view of someone involved in providing secured access to a corporate network from coporate networks of other companies networks. We have three major requirements: a) Transparency of client/server communications, both for TCP and UDP. We need more than managed TELNET and FTP access. b) Granularity of identification down to the individual user level. We don't necessarily trust all of the individuals from another corporation, and they may migrate from ip-address to ip-address. c) Use of a firewall/bastion host to mediate access. Both for high-confidence isolation, and session-layer logging. We perceive that we have two choices here: a) Embed Kerberos in every client/server application we have control over. This may involve cross-realm authentication. b) Use an encapsulation scheme, like SOCKS, with some authentication extensions. We have decided that for the short-term, we want to use (b), since we can implement it entirely at the user-level, without custom kernels and custom router software; and with a few clever tricks, without recompiling any code. Further to that, I'm working on a document that I hope to make an I-D to describe SOCKS encapsulation, with the authentication extensions I mentioned. Like swIPe, the new SOCKS protocol specification defines authentication information very loosely, relying on 'out-of-band' techniques for key-management, etc. How does this relate to IPSP/swIPe? It occurs to me that swIPe would be a potentially better way for us to go in the long-term, but there is an implicit assumption in the protocol that an authenticator is bound in some way to a source ip-address, and not an individual user of the network. That is, a swIPe packet carries with it an AUTHENTICATOR, but no corresponding IDENTIFIER. Unless I've mis-read the I-D. -- Marcus Leech |Any opinions expressed are mine. |+1 613 763 9145 VE3MDL | and not those of my employer |+1 613 567 5484 mleech@bnr.ca | | From ipsec-request@ans.net Tue Jun 14 21:06:54 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19074 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 17:22:31 -0400 Received: by interlock.ans.net id AA09474 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 17:13:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 17:13:24 -0400 Message-Id: <199406142113.AA09726@interlock.ans.net> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: Expired swIPe In-Reply-To: Your message of Tue, 14 Jun 94 14:44:15 -0400. <9406141844.AA20850@snark.imsi.com> Date: Tue, 14 Jun 94 17:06:54 -0400 From: Steve Kent Perry, No, Perry, I don't know one way or the other. But I'm sure you know that the development of open standards is more than a popularity contest, measured in terms of installed base or variety of supported hardware platforms. Otherwise, we would have declared IPX and DOS standards a long time ago. Steve From ipsec-request@ans.net Tue Jun 14 13:29:02 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19654 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 17:37:14 -0400 Received: by interlock.ans.net id AA15043 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 17:29:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 14 Jun 1994 17:29:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Jun 1994 17:29:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 17:29:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 17:29:03 -0400 Date: Tue, 14 Jun 94 17:29:02 EDT From: Marcus J Ranum Message-Id: <9406142129.AA04218@tis.com> To: ipsec@ans.net, mleech@bnr.ca Subject: Re: Granularity of authentication in swIPe >How does this relate to IPSP/swIPe? It occurs to me that swIPe would be > a potentially better way for us to go in the long-term, but there is > an implicit assumption in the protocol that an authenticator is bound > in some way to a source ip-address, and not an individual user of the > network. I don't think protocols like swIPe are going to solve the problem of distributed TCBs (sorry!) :) In effect, swIPe gives you the ability to rely that packets claiming to come from host "alice" that you have exchanged keys with are indeed from that host. It also ensures (within some reasonable tolerance) that the data hasn't been inspected or tampered with in transit. swIPe isn't going to be able to solve the problem of distributing trust between networks -- in other words, if host "alice" has yet another sendmail hole that lets anyone on "alice" become root, then you can't really trust that "mjr@alice" is in fact "mjr" -- it could be anyone. One might attempt to address this by pushing one's authentication up into the application layer, and doing encrypted application-to-application communication (something I think there is a place for) which would possibly be more resistant to spoofing userids -- but the problem remains that someone who is smart/motivated enough to swipe a live TCP connection is also smart/motivated enough to steal a connected tty/pty session. Suppose "mjr@alice" is using encrypted telnet with kerberos authentication and key exchange to log in as "mjr@bob". Let's imagine that Bad Guy has properly prepared himself, and simply punches down into /dev/kmem and rewires a few sockets manually, so that "mjr@alice"s established terminal session is now connected to Bad Guy's terminal. He's "mjr@bob" and he's authenticated, validated, etc. In short: untrusted hosts remain untrustworthy. :) All that being said, I think there are very good uses to which tools like swIPe can be put. First and foremost, we need something we can experiment with, to see how some of the problems I've described above actually *work* in real life. After all, if we sit back and try to design the perfect be-all-end-all system, we might overlook something we'd have discovered if we had a chance to actually experiment with (and improve on) things like swIPe. That is, unless I'm mistaken, The Internet Way. mjr. From ipsec-request@ans.net Tue Jun 14 21:29:18 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06861 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 17:38:58 -0400 Received: by interlock.ans.net id AA09678 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 17:29:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 14 Jun 1994 17:29:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Jun 1994 17:29:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 17:29:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 17:29:39 -0400 Message-Id: <9406142129.AA21251@snark.imsi.com> To: "marcus leech" Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of "Tue, 14 Jun 1994 16:05:03 EDT." <"17004 Tue Jun 14 16:05:59 1994"@bnr.ca> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Jun 1994 17:29:18 -0400 From: "Perry E. Metzger" "marcus (m.d.) leech" says: > How does this relate to IPSP/swIPe? It occurs to me that swIPe would be > a potentially better way for us to go in the long-term, but there is > an implicit assumption in the protocol that an authenticator is bound > in some way to a source ip-address, and not an individual user of the > network. That is, a swIPe packet carries with it an AUTHENTICATOR, but > no corresponding IDENTIFIER. Unless I've mis-read the I-D. Of course it is bound to the IP address, just as a TCP port number makes sense only in the context of an IP address. There isn't any way to get around this -- networks connect computers, not people. That said, if you want to authenticate on a user level, you simply have a user controlled program negotiate a policy between the two hosts using authentication information that would only be known by the user. For instance, the user's public/private key pair could be an element of the negotiation, thus demonstrating that only the entity holding that private key could have been involved in the negotiation of the keys for that policy. Given that, if your system has reliable information that only that user should be in possession of the private key in question, then you can know that the user (or someone who has stolen his key) is the entity on the remote host. (Kerberos could also be used for such a negotiation -- I'm just a fan of public key methods.) swIPe is NOT a key management system or a key negotiation system. Its just a way of standardizing the encapsulation of authenticated and encrypted IPv4 packets. On top of it, it is possible to build a wide variety of systems. You can, for instance, build a system that permits negotiation on a per user basis as described above and use it on top of swIPe -- that is in fact the intention. However, swIPe is not a layer that knows about users, just as IP is not a layer that knows about users. Perry From ipsec-request@ans.net Tue Jun 14 13:53:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19081 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 18:02:23 -0400 Received: by interlock.ans.net id AA12056 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 17:53:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 14 Jun 1994 17:53:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Jun 1994 17:53:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 17:53:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 17:53:22 -0400 Date: Tue, 14 Jun 94 17:53:43 EDT From: Marcus J Ranum Message-Id: <9406142153.AA05932@tis.com> To: kent@BBN.COM, perry@imsi.com Subject: Re: Expired swIPe Cc: ipsec@ans.net > But I'm sure >you know that the development of open standards is more than a >popularity contest, measured in terms of installed base or variety of >supported hardware platforms. Darwinian processes tend to look a lot like "popularity contests" depending on which eye you look out of. Open standards (as opposed to artificial standards) need to be relevant, available, and useful if they're going to be anything other than ignored. Installed base, variety and support of platforms correlates directly with usefulness to whatever community is adopting a technology. I think releasing swIPe was doing us a favor, since it'll give us a chance to experiment with something concrete, and if it turns out to be "good enough" (for some degree of good) or repairable it may become widely deployed -- if it's not, it won't get off the ground. No matter what, we will have learned something. > Otherwise, we would have declared IPX >and DOS standards a long time ago. I have news for you, Steve -- they *ARE* standards. The question is "which community?" -- IPX and DOS aren't *internet* standards because they don't do the job for *us*. mjr - Software Darwinist. From ipsec-request@ans.net Tue Jun 14 21:53:24 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12686 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 18:03:24 -0400 Received: by interlock.ans.net id AA13602 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 17:53:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 14 Jun 1994 17:53:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Jun 1994 17:53:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 17:53:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 17:53:39 -0400 Message-Id: <9406142153.AA21315@snark.imsi.com> To: Steve Kent Cc: ipsec@ans.net Subject: Re: Expired swIPe In-Reply-To: Your message of "Tue, 14 Jun 1994 17:06:54 EDT." <199406142113.RAA07635@wintermute.imsi.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Jun 1994 17:53:24 -0400 From: "Perry E. Metzger" Steve Kent says: > No, Perry, I don't know one way or the other. But I'm sure > you know that the development of open standards is more than a > popularity contest, measured in terms of installed base or variety of > supported hardware platforms. Otherwise, we would have declared IPX > and DOS standards a long time ago. My point is not that swIPe is popular -- in fact, at the moment, its barely used because key management isn't in place. However, absent another serious proposal being made, those of us who need such a protocol for our day to day work are faced with either waiting for a theoretically possible other protocol to show up or taking up swIPe as a serious candidate. That said, its entirely possible that swIPe needs to have modifications made to it, or that it's flawed -- but discussing that is what the IETF process is for. I'm not mocking anyone here. I am being quite serious. I have no intellectual stake in any particular scheme -- I merely have a stake in seeing something, anything reasonable, deployed. I'm willing to look at realistic alternatives. I define realistic as "implemented and available in a public implementation very soon so deployment can occur in the near future." If anyone has anything else that meets this criterion, please speak up. The IPSEC group has been dormant for too long. Its time to see some real work done. Perry From ipsec-request@ans.net Tue Jun 14 22:06:33 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18078 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 18:15:40 -0400 Received: by interlock.ans.net id AA12522 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 18:06:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 14 Jun 1994 18:06:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Jun 1994 18:06:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 18:06:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 18:06:50 -0400 Message-Id: <9406142206.AA21363@snark.imsi.com> To: kent@BBN.COM, ipsec@ans.net Subject: Re: Expired swIPe In-Reply-To: Your message of "Tue, 14 Jun 1994 17:53:43 EDT." <9406142153.AA05932@tis.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Jun 1994 18:06:33 -0400 From: "Perry E. Metzger" Marcus J Ranum says: > I have news for you, Steve -- they *ARE* standards. > The question is "which community?" -- IPX and DOS aren't *internet* > standards because they don't do the job for *us*. > > mjr - Software Darwinist. Marcus has an excellent point. IPX became a standard -- a real standard, count IPX machines sometime -- because no one bothered to produce a decent IP stack with utilities for PCs and market it with more than half an effort. Novell is NOT an engineering or marketing powerhouse -- they filled a vacuum. (Of course, as Rob Pike said, sometimes when you fill a vacuum it still sucks.) The point I am making by mentioning IPX again is this: there is a vacuum out there right now. Seventy committees are out there adding security to this package and security to that. An IP level system once appropriate higher level layers are added fills a huge vacuum. I'm not pretending that swIPe is necessarily perfect -- its not. However, if people want to see the best possible outcome the best thing to do is constructively engage at this point rather than attempt to obstruct, because obstructing won't mean anything, because even if you can stop formal standardization you can never stop de facto standardization except by providing something better early enough in the process. Perry From ipsec-request@ans.net Tue Jun 14 22:23:54 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12760 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 18:30:48 -0400 Received: by interlock.ans.net id AA21472 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 18:24:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 14 Jun 1994 18:24:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Jun 1994 18:24:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 18:24:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 18:24:07 -0400 Message-Id: <9406142223.AA21403@snark.imsi.com> To: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of "Tue, 14 Jun 1994 17:29:02 EDT." <9406142129.AA04218@tis.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Jun 1994 18:23:54 -0400 From: "Perry E. Metzger" Marcus J Ranum says: > swIPe isn't going to be able to solve the problem of > distributing trust between networks -- in other words, if host "alice" > has yet another sendmail hole that lets anyone on "alice" become > root, then you can't really trust that "mjr@alice" is in fact "mjr" -- > it could be anyone. One might attempt to address this by pushing one's > authentication up into the application layer, and doing encrypted > application-to-application communication (something I think there > is a place for) which would possibly be more resistant to spoofing > userids -- but the problem remains that someone who is smart/motivated > enough to swipe a live TCP connection is also smart/motivated enough > to steal a connected tty/pty session. Marcus' point is sufficiently important that I feel that I must re-emphasize it. Nothing is perfectly secure. Things are only reasonably secure with respect to a given threat model. If one's threat model includes "the enemy has root on both the local and remote host" nothing will help you, period. The purpose of swIPe is to give you the capacity to allow trusted hosts to communicate over untrusted internets. Given untrusted hosts, you lose. Now, its possible to rig things to make sure that given a partially trusted host a user can authenticate himself -- this is the kerberos model, and kerberos style authentication systems will doubtless be layered on top of swIPe. (Someone at Usenix was in fact proposing to use kerberos itself, btw.) However, such authentication systems can never be perfect. If the bad guy owns the kernel on the machine, all you will know is that the victim gave his secret information to the machine at some point -- not whether you are actually talking to them or not. > All that being said, I think there are very good uses to > which tools like swIPe can be put. First and foremost, we need > something we can experiment with, to see how some of the problems > I've described above actually *work* in real life. After all, if > we sit back and try to design the perfect be-all-end-all system, > we might overlook something we'd have discovered if we had a > chance to actually experiment with (and improve on) things like > swIPe. That is, unless I'm mistaken, The Internet Way. I couldn't have said it better myself. Perry From ipsec-request@ans.net Tue Jun 14 22:18:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04120 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 18:37:59 -0400 Received: by interlock.ans.net id AA12078 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 18:30:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 18:30:13 -0400 Message-Id: <199406142230.AA35114@interlock.ans.net> To: Marcus J Ranum Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Tue, 14 Jun 94 17:29:02 -0400. <9406142129.AA04218@tis.com> Date: Tue, 14 Jun 94 18:18:45 -0400 From: Steve Kent Marcus, Fortunately, one can experiment with protocols without making them standards. We have Informational and Experimental designations for RFCs to allow description of such protocols. Steve From ipsec-request@ans.net Tue Jun 14 23:13:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA03828 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 19:26:41 -0400 Received: by interlock.ans.net id AA13668 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 19:14:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 14 Jun 1994 19:14:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Jun 1994 19:14:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 19:14:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 19:14:05 -0400 Message-Id: <9406142313.AA21507@snark.imsi.com> To: Steve Kent Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of "Tue, 14 Jun 1994 18:18:45 EDT." <199406142230.AA35114@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Jun 1994 19:13:55 -0400 From: "Perry E. Metzger" Steve Kent says: > Marcus, > > Fortunately, one can experiment with protocols without making > them standards. We have Informational and Experimental designations > for RFCs to allow description of such protocols. > > Steve Steve; You seem to think that swIPe should not be standards track. (Unfortunately, its difficult to know people's intent in EMail because so much of the context and tone is lost -- please let me know if my assessment is wrong.) Do you have objections to the way swIPe does things? Please say so if you do -- that way they can be worked on and the improvements will benefit everyone. If you would like a copy of the code, I'll be happy to send that to you so that you can experiment with it along with the rest of us. Perry From ipsec-request@ans.net Tue Jun 14 16:10:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA03620 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 20:20:14 -0400 Received: by interlock.ans.net id AA08584 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 20:11:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 20:11:22 -0400 Message-Id: <199406150011.AA29826@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 20:11:22 -0400 To: perry@imsi.com Cc: Steve Kent , ipsec@ans.net Subject: Re: Granularity of authentication in swIPe Date: Tue, 14 Jun 94 20:10:23 EDT You seem to think that swIPe should not be standards track. (Unfortunately, its difficult to know people's intent in EMail because so much of the context and tone is lost -- please let me know if my assessment is wrong.) Do you have objections to the way swIPe does things? Please say so if you do -- that way they can be worked on and the improvements will benefit everyone. If you would like a copy of the code, I'll be happy to send that to you so that you can experiment with it along with the rest of us. I haven't had a chance to unpack the Usenix disk yet; as I recall, though, swIPe has a one-byte keyid, which is unacceptable to me. It also has a packet sequence number, which is a rather dubious construct that needs a *lot* of debate, at the very least. From ipsec-request@ans.net Wed Jun 15 03:48:20 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14171 (5.65c/IDA-1.4.4 for ); Tue, 14 Jun 1994 23:49:21 -0400 Received: by interlock.ans.net id AA35139 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 14 Jun 1994 23:41:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 14 Jun 1994 23:41:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Jun 1994 23:41:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 23:41:35 -0400 Posted-Date: Tue, 14 Jun 94 23:48:20 -0400 Message-Id: <9406150340.AA11937@big.l1135.att.com> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 23:41:35 -0400 To: smb@research.att.com Cc: perry@imsi.com, Steve Kent , ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of "Tue, 14 Jun 94 20:10:23 EDT." <199406150011.AA29826@interlock.ans.net> Date: Tue, 14 Jun 94 23:48:20 -0400 From: Matt Blaze I don't have an opinion as to whether swIPe should be "standards track" or not. We put it forward as an example, to show that a generally useful security protocol doesn't have to be complex. I hope it continues to serve in that role. If the grown-ups want to turn it into a standard, that's OK, too. I've therefore been loathe to enter this emerging flamewar, but... smb sez: >swIPe has a one-byte keyid, which is unacceptable to me. It also has a >packet sequence number, which is a rather dubious construct that needs >a *lot* of debate, at the very least. Actually, it's a two byte keyid. I agree that the sequence number introduces a number of semantic and performance issues that need to be discussed. JI and I included it as a conceptually simple way to thwart replay attacks (which we regard as an essential semantic in any security service), without a needing lot of state at either side. Other suggestions welcome... -matt From ipsec-request@ans.net Tue Jun 14 15:03:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01602 (5.65c/IDA-1.4.4 for ); Wed, 15 Jun 1994 01:10:43 -0400 Received: by interlock.ans.net id AA24612 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Jun 1994 01:03:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 15 Jun 1994 01:03:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Jun 1994 01:03:49 -0400 Message-Id: Date: Tue, 14 Jun 94 22:03 PDT X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net From: brian@lloyd.com (Brian Lloyd) Subject: Re: Expired swIPe At 15:12 6/14/94 -0400, Marcus J Ranum wrote: >>Just curious, but are there any other contenders running on a wide >>variety of platforms today, other than swIPe? > > Does anyone have a list of the platforms swIPe has been ported >to?? I noticed the distribution looks pretty Sun-specific. Anyone done >a port to BSDI/4.4? > > How big *is* swIPe's installed base? (not counting floppies >that were handed out at USENIX) I thought that Phil Karn had done an implementation in his KA9Q package. Would someone please correct me if this is an erronious impression. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From ipsec-request@ans.net Tue Jun 14 15:03:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17991 (5.65c/IDA-1.4.4 for ); Wed, 15 Jun 1994 01:10:44 -0400 Received: by interlock.ans.net id AA21035 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Jun 1994 01:03:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 15 Jun 1994 01:03:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Jun 1994 01:03:53 -0400 Message-Id: Date: Tue, 14 Jun 94 22:03 PDT X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Steve Kent , Brian Lloyd From: brian@lloyd.com (Brian Lloyd) Subject: Re: Expired swIPe Cc: ipsec@ans.net, perry@imsi.com At 13:43 6/14/94 -0400, Steve Kent wrote: >Brian, > > I think it would be nice to reach concensus within the WG on >an IPSP protocol spec before declaring any particular implementations >as compliant. > >Steve I am not trying to imply that swIPe is necessarily the final output from the WG. The swIPe draft has expired and we need something to keep it current and moving. I was just pointing out that swIPe has met the requirements to move along the track to at least "draft standard." There is a draft and there appear to be at least two independent implementations. I would say that swIPe is certainly useful for collecting experiential information. Just because we do that doesn't mean that we can't make significant changes and/or even adopt a different protocol. I have no axe to grind nor do I have a preference for swIPe. I would just like to see it placed where it can help move the work of the WG along. More than anything else I was just asking the question as to why this draft couldn't proceed. Something tells me that I might be stepping on a political "mine" here. I get the feeling that things might happening in the background to which I am not privvy. If so, would someone please fill me in (privately). Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From ipsec-request@ans.net Wed Jun 15 05:12:38 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15251 (5.65c/IDA-1.4.4 for ); Wed, 15 Jun 1994 09:27:20 -0400 Received: by interlock.ans.net id AA25758 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Jun 1994 09:12:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 15 Jun 1994 09:12:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 15 Jun 1994 09:12:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 15 Jun 1994 09:12:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 15 Jun 1994 09:12:49 -0400 Date: Wed, 15 Jun 94 09:12:38 EDT From: perry@imsi.com (Perry E. Metzger) Message-Id: <9406151312.AA05384@webster.imsi.com> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Jun 1994 09:12:49 -0400 To: ipsec@ans.net Subject: swIPe available for FTP. Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission swIPe is now available at ftp://ftp.csua.berkeley.edu/pub/cypherpunks/swIPe/swipe.tar.Z I wish I had a better archive site for it, but it seemed important to get it out in a hurry. BTW, I want to make it clear that I don't think that swIPe is necessarily perfect and needs no changes, and that I don't think it should be made a standard tomorrow with no discussion. I do think that we've been avoiding playing with real proposals for too long, and that it is important that things get back on track. swIPe is an opportunity to experiment with a real protocol that fits nicely into the spirit of the existing internet protocols. If someone comes up with something better, I will naturally support it. However, make no mistake that we need something, and soon -- the internet is increasingly experiencing problems caused by the lack of a security infrastructure. This is a good chance for people to begin working with real code instead of chatting ad infinitum. Too often, the community has sat back as a real need has gone unfilled for too long, only to have something bad come out of it. Take HTTP. Personally, I don't like it, but all the "good" people decided it wasn't an interesting issue and played elsewhere until it was too late. Mosaic filled a real need, and even though badly written and on top of a bad protocol it saw wide deployment -- now its too late to fix. I think that a fire has to be lit under people to spend time working on the issue of IP security, and this seems like a golden opportunity to me to pour some charcoal and stand by with a match. To repeat: I am NOT being sarcastic when I say "if you see flaws in swIPe, speak up; if you have an alternative, please present it." I want to see discussion, which hasn't gone on for far too long. Don't mistake this for a claim that I think swIPe is flawed and should NOT be pushed along the track towards standardization. I personally find swIPe very attractive. However, I'll be happy provided a reasonable solution arrives and is adopted, regardless of who's it is. Perry From ipsec-request@ans.net Wed Jun 15 05:32:29 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01772 (5.65c/IDA-1.4.4 for ); Wed, 15 Jun 1994 09:43:40 -0400 Received: by interlock.ans.net id AA12353 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Jun 1994 09:32:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 15 Jun 1994 09:32:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Jun 1994 09:32:15 -0400 Date: Wed, 15 Jun 94 09:32:29 EDT From: Robert Glenn Message-Id: <9406151332.AA01652@osi.ncsl.nist.gov> To: ipsec@ans.net Subject: Another "open" implementation, with some similarities to swIPe I've recently finished an IP layer security protocol prototype that has some similarities to swIPe (the similarities are more intentional than not). The prototype was developed on a BSD/386 1.1 PC and is currently being ported to a BSD4.4-lite kernel. Only the Host to Host mode is implemented at this point. The packet format was developed with the following in mind. o 64 bit word header alignmnet o fixed-length fields o minimal overhead o IP like proto field functionality o no sequence numbers The packet format follows: Host to Host Mode: 1 2 3 0123 4567 8901 2345 6789 0123 4567 8901 +----+----+---------+-------------------+ ------------ |Ver |IHL | TOS | Total Length | +-------------------+--+----------------+ | Identifier |Fl| Frag. Offset | +---------+---------+-------------------+ | TTL | Protocol| Header Checksum | IPv4 | | (52) | | Header +---------+---------+-------------------+ | Source Address | +---------------------------------------+ | Destination Address | +---------------------------------------+ | Options + Padding | +---------+----+----+-------------------+ ----------- | Prot |Ver | Fl | Length | +---------+----+----+-------------------+ SDT PDU | SAID | Reserved | Header +-------------------+-------------------+ ----------- | Alg_Param + D_Length | +-------------------+-------------------+ Protected | | Octet | Data | String +---------------------------------------+ | Pad + ICV | +---------------------------------------+ ----------- Host to Router & Router to Router Mode: 1 2 3 0123 4567 8901 2345 6789 0123 4567 8901 +----+----+---------+-------------------+ ------------ |Ver |IHL | TOS | Total Length | +-------------------+--+----------------+ | Identifier |Fl| Frag. Offset | +---------+---------+-------------------+ | TTL | Protocol| Header Checksum | IPv4 | | (52) | | Header +---------+---------+-------------------+ | Source Address | +---------------------------------------+ | Destination Address | +---------------------------------------+ | Options + Padding | +---------+----+----+-------------------+ ----------- | Prot(94)|Ver | Fl | Length | +---------+----+----+-------------------+ SDT PDU | SAID | Reserved | Header +-------------------+-------------------+ ----------- | Alg_Param + D_Length | +----+----+---------+-------------------+ |Ver |IHL | TOS | Total Length | +-------------------+--+----------------+ | Identifier |Fl| Frag. Offset | +---------+---------+-------------------+ | TTL | Proto | Header Checksum | Protected | | | | Octet +---------+---------+-------------------+ String | Source Address | +---------------------------------------+ | Destination Address | +---------------------------------------+ | Options + Padding | +---------------------------------------+ | | | Data | +---------------------------------------+ | Pad + ICV | +---------------------------------------+ ----------- There are some differences between this and swIPe, but most of them are for efficiency sake, not security. I chose not to include sequence numbers because of various off-line discussions and the negative response at the Feb. ISOC meeting. Having the ICV in the tail of the packet may have some advantages, but that isn't clear to me at this point. I also don't see any reason to include the entire IPv4 header in the security envelope when the security is applied Host to Host. I do think that a two-byte SAID is long enough until a better definition on how it will be used in the future is available. I have included a version number and two-bytes of reserved that will allow for growth. Integrity is applied from the Algorithm Parameters to the end of the Data. Encryption is applied over the Data Length (D_Length) to the end of the packet (including the ICV). The prototype runs straight over IPv4 and has "manual" key managment built into the kernel. Access to the key management information is via a socket. Currently I only have DES CBC for both integrity and confidentiality, but I am getting very reasonable performance (operational using ftp, ping, telnet, etc., no actual performance-specific testing at this point). I'd be more than happy to provide anyone (US-only because of the DES and export laws), with a copy of this and instructions on how to install and operate. I am hesitant to widely distribute the prototype, because it is still "under development". I would like to add other algorithms to the code, implement the Router Mode, and add a diffie-helman exchange to the key-managment code. The Proto number, 52, is registered in case anyone else would like to implement this protocol and do some testing. For more information on this protocol, the details can be found in the internet draft entitled INLSP for TUBA. A revised version of this draft is forthcoming. Rob G. glenn@osi.ncsl.nist.gov From ipsec-request@ans.net Wed Jun 15 05:57:55 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18539 (5.65c/IDA-1.4.4 for ); Wed, 15 Jun 1994 10:14:34 -0400 Received: by interlock.ans.net id AA05468 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Jun 1994 10:00:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 15 Jun 1994 10:00:42 -0400 Message-Id: <199406151400.AA05464@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Jun 1994 10:00:42 -0400 To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: swIPe available for FTP. Date: Wed, 15 Jun 94 09:57:55 EDT Apart from problems with the architecture, there are three serious flaws in the implementation. One, of course, is the lack of key management. That's known and admitted. Indeed, swIPe is a good vehicle for experimenting with it. The second problem is the lack of filtering on input. That is, you may have a key -- which guarantees authenticity -- between you and some host Foo. But no check is made to ensure that packets from Foo are properly encrypted. This means that you can't trust a received packet; you only know that genuine packets haven't been tampered with. Third, there is no notice to the higher levels -- TCP or the application -- of the security status of the received packet. This makes it difficult to build a secure application on top of swIPe. swIPe isn't useless, by any means. But a lot more work is needed to make it really useful. From ipsec-request@ans.net Wed Jun 15 14:42:57 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04238 (5.65c/IDA-1.4.4 for ); Wed, 15 Jun 1994 10:55:27 -0400 Received: by interlock.ans.net id AA27108 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Jun 1994 10:44:29 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 15 Jun 1994 10:44:29 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 15 Jun 1994 10:44:29 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 15 Jun 1994 10:44:29 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Jun 1994 10:44:29 -0400 Message-Id: <9406151442.AA22528@snark.imsi.com> To: smb@research.att.com Cc: ji@tla.org, ipsec@ans.net Subject: Re: swIPe available for FTP. In-Reply-To: Your message of "Wed, 15 Jun 1994 09:57:55 EDT." <199406151400.KAA09013@wintermute.imsi.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 15 Jun 1994 10:42:57 -0400 From: "Perry E. Metzger" I'm going to forward your comments on to ji; Matt is already reading the group. There should be an explicit statement in the definition that packets not conforming to a policy should be dropped. If I'm using a policy for communication between two hosts on a particular higher level service, if it isn't encrypted in the policy it should go on the floor -- possibly after having been logged. There IS a way for the higher levels to determine what policy is being applied to packets -- via ioctls in the implementation. The interface should perhaps be better documented. Perry smb@research.att.com says: > Apart from problems with the architecture, there are three serious > flaws in the implementation. > > One, of course, is the lack of key management. That's known and admitted. > Indeed, swIPe is a good vehicle for experimenting with it. > > The second problem is the lack of filtering on input. That is, you > may have a key -- which guarantees authenticity -- between you and > some host Foo. But no check is made to ensure that packets from Foo > are properly encrypted. This means that you can't trust a received > packet; you only know that genuine packets haven't been tampered with. > > Third, there is no notice to the higher levels -- TCP or the application -- > of the security status of the received packet. This makes it difficult > to build a secure application on top of swIPe. > > swIPe isn't useless, by any means. But a lot more work is needed to > make it really useful. From ipsec-request@ans.net Wed Jun 15 14:59:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA03733 (5.65c/IDA-1.4.4 for ); Wed, 15 Jun 1994 11:21:00 -0400 Received: by interlock.ans.net id AA36719 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Jun 1994 11:11:21 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Jun 1994 11:11:21 -0400 Message-Id: <199406151511.AA05483@interlock.ans.net> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Tue, 14 Jun 94 19:13:55 -0400. <9406142313.AA21507@snark.imsi.com> Date: Wed, 15 Jun 94 10:59:28 -0400 From: Steve Kent Perry, I don't object to swIPe being a candidate for a standards track IP security protocol. I do object to arguments that suggest we must adopt swIPe as THE standards track protocol because it has the widest deployment at this point in time or because we need to gain experience with SOME network layer security protocol. My observation is that the latter argument can be addressed by publishing swIPe, or any other protocols, as Experimental or Informational RFCs, and thus it is not a good argument in favor of selecting swIPe at this time. As for specific concerns about swIPe, yes, I do have several, based on a cursory reading the protocol. I think the SAID-like field should be larger. It should be emphasized that this field is used to select previously negotiated security association options: the key(s), sequence number management rules, optional use of compression algorithms, security labels, etc. That argues against a structure for the field. I also would like to see the the sequence number field be made larger, or at least provide for negotiation of a larger field, to avoid the need to provide for rekeying during an association. My motivation for this field is not the same as yours, but rather as a means of detecting replay attepmts in a denial of service context. To that end, if an association elects to invoke this option, I'd like to see a more explicit and more stringent sequence number management algorithm spelled out, rather than leaving it to each implementation to decide. Upon further analysis, there may be more suggestions I will be able to put forward. My experience with developing several other security protocols suggests that we should strive to make the steady-state protocol capable of working with a variety of key management procedures, but that until we work out all of the details of several such procedures, we are unlikely to have all of the necessary hooks in the protocol. So, until we have such details, it may be premature to progress a network layer security protocol on the standards track, but it might be appropriate to gain experience with several candidates via the other routes I mentioned above. Steve From ipsec-request@ans.net Wed Jun 15 15:22:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19657 (5.65c/IDA-1.4.4 for ); Wed, 15 Jun 1994 11:38:35 -0400 Received: by interlock.ans.net id AA26953 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Jun 1994 11:27:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 15 Jun 1994 11:27:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 15 Jun 1994 11:27:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Jun 1994 11:27:08 -0400 Date: Wed, 15 Jun 1994 11:22:01 -0400 From: John Ioannidis Message-Id: <199406151522.LAA11801@pizza.cs.columbia.edu> To: perry@imsi.com, smb@research.att.com Subject: Re: swIPe available for FTP. Cc: ipsec@ans.net Steve, > Apart from problems with the architecture, there are three serious > flaws in the implementation. I beg to differ. 1. Key management is an orthogonal issue. The hooks are there in the kernel code; all you have to do is plug in your own key management. Key management is NOT part of the swIPe protocol! 2. Filtering on input can best be performed by any number of products already available (screening routers, host-based filtering). THe swIPe implementation is by no means a one-stop solution to all your firewall problems. 3. I would welcome suggestions on how to notify higher protocols. I have a number of ideas, but I don't particularly like any of them. As a start, packets which arrived swIPed, made it through the un-swIPe-ing procedure, and reappear at the IP input stream appear as if they are coming from the swIPe virtual interface (rather than the real interace the packet came in). One more thing: the code that I released does NOT pretend to be a complete or final implementation of swIPe. It is working code with which to experiment in a live situation rather than theorise endlessly about what should and should not be done. Aside from the fact that a lot of people will find it useful just the way it is, I released it so that people have a starting point to play with. If you have a problem with the implementation, please feel free to go ahead and fix it, and share the fixes with the rest of us. /ji From ipsec-request@ans.net Wed Jun 15 15:48:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18494 (5.65c/IDA-1.4.4 for ); Wed, 15 Jun 1994 11:58:30 -0400 Received: by interlock.ans.net id AA27944 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Jun 1994 11:48:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 15 Jun 1994 11:48:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 15 Jun 1994 11:48:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 15 Jun 1994 11:48:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Jun 1994 11:48:26 -0400 Message-Id: <9406151548.AA22738@snark.imsi.com> To: Steve Kent Cc: perry@imsi.com, ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of "Wed, 15 Jun 1994 10:59:28 EDT." <199406151511.LAA09220@wintermute.imsi.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 15 Jun 1994 11:48:05 -0400 From: "Perry E. Metzger" Steve Kent says: > Perry, > > I don't object to swIPe being a candidate for a standards > track IP security protocol. I do object to arguments that suggest we > must adopt swIPe as THE standards track protocol because it has the > widest deployment at this point in time or because we need to gain > experience with SOME network layer security protocol. In that case, I suspect this conversation has largely been a misunderstanding, because I don't believe that anyone has suggested that swIPe is "the" protocol -- only that its a nice candidate and that its worth giving special note to because nothing else is currently out there to play with. Thanks, by the way, for the comments on the protocol itself -- I will reply to them seperately. Perry From ipsec-request@ans.net Wed Jun 15 16:15:26 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17984 (5.65c/IDA-1.4.4 for ); Wed, 15 Jun 1994 12:35:31 -0400 Received: by interlock.ans.net id AA27563 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Jun 1994 12:16:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 15 Jun 1994 12:16:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 15 Jun 1994 12:16:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 15 Jun 1994 12:16:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Jun 1994 12:16:15 -0400 Message-Id: <9406151615.AA22769@snark.imsi.com> To: Steve Kent Cc: ji@tla.org, ipsec@ans.net Subject: swIPe comments In-Reply-To: Your message of "Wed, 15 Jun 1994 10:59:28 EDT." <199406151511.LAA09220@wintermute.imsi.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 15 Jun 1994 12:15:26 -0400 From: "Perry E. Metzger" Steve Kent says: > As for specific concerns about swIPe, yes, I do have several, > based on a cursory reading the protocol. I think the SAID-like field > should be larger. Why specifically? Since its on a per host pair basis, 64,000 policies seems sufficient -- the sum of the the number of TCP and UDP sockets on a host only twice that. Is there a concern that two hosts might want to have more than 64,000 key/policy identifiers between them, or is there another notion here? > It should be emphasized that this field is used to select previously > negotiated security association options: the key(s), sequence number > management rules, optional use of compression algorithms, security > labels, etc. That argues against a structure for the field. I assume you are just mentioning that the draft language should be made to emphasize this -- that seems reasonable. > I also would like to see the the sequence number field be made > larger, or at least provide for negotiation of a larger field, to > avoid the need to provide for rekeying during an association. My > motivation for this field is not the same as yours, but rather as a > means of detecting replay attepmts in a denial of service context. Actually, I believe that this was to some extent envisioned. The current field is 32 bits. 1) How large do you think it needs to be? 2) What exactly is the sort of attack you think could be played on the current field? > To that end, if an association elects to invoke this option, I'd > like to see a more explicit and more stringent sequence number > management algorithm spelled out, rather than leaving it to each > implementation to decide. There are several things that ought to be standardized but not part of the "visible" layer of swipe. As an example, the exact algorithms for using DES, 3-DES, IDEA, Skipjack (:-) and other ciphers with swIPe ought to be standardized so that different implementations can interoperate based purely on the written spec -- should swIPe ever be made a standard my feeling is that this should be part of a seperate RFC since the exact algorithms being used are visible only to the two endpoints, which can feel free to negotiate the use of nonstandard ones. Similarly, I would agree that good algorithms for the management of the sequence number are important -- but aren't part of the "surface" layer of swIPe since two hosts could easily negotiate another one if need be and not harm any other hosts on the net. I'd be interested to hear what you feel would be optimal algorithms for managing the sequence number, by the way. Perry From ipsec-request@ans.net Wed Jun 15 02:51:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04180 (5.65c/IDA-1.4.4 for ); Wed, 15 Jun 1994 13:12:16 -0400 Received: by interlock.ans.net id AA36779 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Jun 1994 12:53:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 15 Jun 1994 12:53:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Jun 1994 12:53:20 -0400 Message-Id: Date: Wed, 15 Jun 94 09:51 PDT X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: smb@research.att.com, perry@imsi.com From: brian@lloyd.com (Brian Lloyd) Subject: Re: swIPe available for FTP. Cc: ipsec@ans.net At 9:57 6/15/94 -0400, smb@research.att.com wrote: >The second problem is the lack of filtering on input. That is, you >may have a key -- which guarantees authenticity -- between you and >some host Foo. But no check is made to ensure that packets from Foo >are properly encrypted. This means that you can't trust a received >packet; you only know that genuine packets haven't been tampered with. The approach we have been considering is to combine the IP security protocol (swIPe, IPSP, etc.) with the packet filtering/screening code so that we can establish security policy through the filter/screening rules. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From ipsec-request@ans.net Wed Jun 15 17:08:14 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15290 (5.65c/IDA-1.4.4 for ); Wed, 15 Jun 1994 13:24:10 -0400 Received: by interlock.ans.net id AA04217 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Jun 1994 13:08:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 15 Jun 1994 13:08:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Jun 1994 13:08:09 -0400 Date: Wed, 15 Jun 1994 10:08:14 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199406151708.KAA00476@netcom.com> To: perry@imsi.com, smb@research.att.com Subject: Re: swIPe available for FTP. Cc: ipsec@ans.net >The second problem is the lack of filtering on input. That is, you >may have a key -- which guarantees authenticity -- between you and >some host Foo. But no check is made to ensure that packets from Foo >are properly encrypted. This means that you can't trust a received >packet; you only know that genuine packets haven't been tampered with. Can you explain this on more detail? Just curious. thanks rich From ipsec-request@ans.net Wed Jun 15 21:42:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12148 (5.65c/IDA-1.4.4 for ); Wed, 15 Jun 1994 18:00:19 -0400 Received: by interlock.ans.net id AA24416 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 15 Jun 1994 17:49:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 15 Jun 1994 17:49:46 -0400 Message-Id: <199406152149.AA36700@interlock.ans.net> To: Marcus J Ranum Cc: ipsec@ans.net Subject: Re: Expired swIPe In-Reply-To: Your message of Tue, 14 Jun 94 17:53:43 -0400. <9406142153.AA05932@tis.com> Date: Wed, 15 Jun 94 17:42:59 -0400 From: Steve Kent Marcus, I never suggested that swIPe should not be released nor that interested parties should not experiment with it. I just suggested that declaring it to be the concensus protocol of the IPSEC WG was premature, based on my attendance at all of the WG meetings and monitoring of this mailing list. Presumably the folks who are most interested in experimentation do not require this, or any other protocol, to be named a proposed standard before they are able to carry out such experiments. As for IPX and DOS, they are not Internet standards for a variety of reasons, among which is the requirement that the things being standardized must be under the change control of the Internet, something that neither Microsoft nor Novell is likely to agree to, irrespective of the utility of these things to the Internet community. Biological Darwinism is an often misunderstood evolutionary theory. Its analogous application to commercial software creates even more opportunities for confusion. Does that latter "theory" suggest that software evolves as a result of random mutations (vs. bug fixes and feature extensions)? A recent article in Technology Review, "Is Life the Product of a Grand Design?" might be relevent reading on this topic. Steve From ipsec-request@ans.net Thu Jun 16 12:32:57 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18083 (5.65c/IDA-1.4.4 for ); Thu, 16 Jun 1994 07:46:30 -0400 Received: by interlock.ans.net id AA29098 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Jun 1994 07:34:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 16 Jun 1994 07:34:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 16 Jun 1994 07:34:17 -0400 Return-Path: Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Jun 1994 07:34:17 -0400 From: Dean Jagels Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Jun 1994 07:34:17 -0400 Sender: Message-Id: <9406161132.AA05482@hunnypot.sware.com> Subject: Re: swIPe To: ipsec@ans.net Date: Thu, 16 Jun 1994 07:32:57 -0500 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 733 Pardon an intrusion from a lurker. May I suggest that this recent thread concerning swIPe has been beaten to death? I believe that it is clear that there is a group of people who are glad to get some code. There is another group of people who are concerned that we not ordain swIPe just yet. It sounds as though these two groups can live together - for the time being. Could we redirect passions away from swIPe for the moment and towards key management? Key management is a topic that seems to be causing a lot of people a lot of concern. Could someone please summarize the efforts currently focusing on key management, or point me to the appropriate FAQ or mailing list? Thanks. Dean Jagels SecureWare, Inc. dpj@sware.com From ipsec-request@ans.net Thu Jun 16 13:12:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14172 (5.65c/IDA-1.4.4 for ); Thu, 16 Jun 1994 09:25:47 -0400 Received: by interlock.ans.net id AA04279 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Jun 1994 09:12:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 16 Jun 1994 09:12:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 16 Jun 1994 09:12:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Jun 1994 09:12:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Jun 1994 09:12:49 -0400 Message-Id: <9406161312.AA00463@snark.imsi.com> To: Dean Jagels Cc: ipsec@ans.net Subject: Re: swIPe In-Reply-To: Your message of "Thu, 16 Jun 1994 07:32:57 CDT." <9406161132.AA05482@hunnypot.sware.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 16 Jun 1994 09:12:28 -0400 From: "Perry E. Metzger" Dean Jagels says: > Pardon an intrusion from a lurker. May I suggest that this recent > thread concerning swIPe has been beaten to death? I believe that we had already gone past the mini-argument and were moving on to discuss swIPe itself, which is certainly within the group's charter. Everyone involved has a great deal of respect for everyone else, and very few people have emotional investment in one scheme vs. another -- there is no real risk of a religious war breaking out. Perry From ipsec-request@ans.net Wed Jun 15 11:53:36 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15139 (5.65c/IDA-1.4.4 for ); Thu, 16 Jun 1994 10:03:21 -0400 Received: by interlock.ans.net id AA08462 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Jun 1994 09:45:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Jun 1994 09:45:42 -0400 Message-Id: <199406161345.AA13320@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Jun 1994 09:45:42 -0400 To: kck@netcom.com (Richard Fox) Cc: ipsec@ans.net Subject: Re: swIPe available for FTP. Date: Wed, 15 Jun 94 15:53:36 EDT >The second problem is the lack of filtering on input. That is, you >may have a key -- which guarantees authenticity -- between you and >some host Foo. But no check is made to ensure that packets from Foo >are properly encrypted. This means that you can't trust a received >packet; you only know that genuine packets haven't been tampered with . Can you explain this on more detail? Just curious. Let me use this message as an opportunity to respond to several other folks as well, and to further explain my thinking. First of all, I'm not criticizing swIPe (at least, not yet...). In fact, though I'd advocated similar ideas in the past, the availability of tangible code made me think about just how I'd deploy it, how I'd really use it, today. My tentative conclusion was that the current implementation -- as opposed to the architecture -- is deficient, in that it doesn't let me do the sorts of things I'd like to do. Nor do I find most of the suggestions by the designers to be suitable. The basic problem is that the application has no knowledge of the cryptographic state of an arriving packet. It thus does not know what sorts of activities are appropriate. Consider, for example, a login process. If the stream is encrypted, a simple password may be accepted; if not, perhaps it will demand a one-time password. But there's no way for it to know with swIPe; the best it can do is tell what policies will be applied to outgoing packets. Similarly, consider a Morris sequence number attack on rsh. Network-level authentication should prevent this, since it provides one with strong assurance of the source of the packet. But that information has been lost by the time rsh sees the input data. Another example would be a cryptographically protected tunnel from outside of a firewall. Again, the tunnel relay doesn't know if the packets are really genuine. The suggestion made here is to have an external filter that drops unswIPed packets from sources that should know how to encrypt them. The problem, though, is that implementing this scheme requires that the same information be in two places. Maintaining consistency here is *hard*. At best, a single high-level tool could parse a single configuration file and tell two different gadgets what to do. (The filter gadget might be an internal per-host component, or it might be a border router.) I'm willing to ignore the race condition, at least for now -- but I'm still not happy with putting such a delicate data structure in more than one place. As JI has noted, implementation of the kind of capability I want is rather difficult in a Berkeley-derived socket() environment. My first thought was to look up the source address on all incoming packets, and to determine what security policy should have been associated with it. The expense of that could be offset by caching; most incoming packets will be followed very quickly by a reply which will need the same information. And you can integrate the security function lookup with the outbound routing table. Such a scheme would, I think, work, but the implementation is likely to be more complex than I'd really like. (I've become quite allergic to complexity in my declining years....) A better model might be to mimic what RFC793 says to do for the security option. When a protected packet arrives, add a pseudo-IP option to it. Delete any such option arriving from vanilla interfaces, of course, though you may want to preserve the notion of a `secure' interface protected by outboard cryptography. An application can use getsockopt() to find out what policies are in force for that connection. Similarly, it can use setsockopt() to require some policies -- and packets arriving with the wrong option should be dropped. (RFC793 requires that TCP abort the connection via RST; I'm not sure which is proper here. In an environment without true multilevel security, dropping the connection might leave you open to denial of service attacks.) I think this conveys the sense of my objections, and what I'd like an implementation (as opposed to an architecture) to look like. None of this is cast in concrete (or even etched in silicon), of course. But I think we need to decide what we want our security mechanisms to do, in our real world, before we deploy them. As for key management -- it's probably just as well that it isn't there yet. I don't completely agree with mjr that it would be a negative feature; what I do think is that we don't yet understand what it should look like. swIPe will provide us with a platform for experimentation and development -- but only in the context of application and site- specific needs. --Steve Bellovin From ipsec-request@ans.net Thu Jun 16 06:14:41 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14323 (5.65c/IDA-1.4.4 for ); Thu, 16 Jun 1994 10:29:28 -0400 Received: by interlock.ans.net id AA22741 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Jun 1994 10:15:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Jun 1994 10:15:06 -0400 Message-Id: <199406161415.AA22481@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Jun 1994 10:15:06 -0400 To: perry@imsi.com Cc: Dean Jagels , ipsec@ans.net Subject: Re: swIPe Date: Thu, 16 Jun 94 10:14:41 EDT Dean Jagels says: > Pardon an intrusion from a lurker. May I suggest that this recent > thread concerning swIPe has been beaten to death? I believe that we had already gone past the mini-argument and were moving on to discuss swIPe itself, which is certainly within the group's charter. Actually, at least part of the discussion has moved beyond swIPe, and on to a more important question: what is it we want/need from a security layer? What sorts of functionality should it provide? That applies at least as much to key management as to the encryption layer per se. From ipsec-request@ans.net Thu Jun 16 16:28:24 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12602 (5.65c/IDA-1.4.4 for ); Thu, 16 Jun 1994 12:48:26 -0400 Received: by interlock.ans.net id AA27374 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Jun 1994 12:37:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Jun 1994 12:37:30 -0400 Message-Id: <199406161637.AA36842@interlock.ans.net> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: swIPe comments In-Reply-To: Your message of Wed, 15 Jun 94 12:15:26 -0400. <9406151615.AA22769@snark.imsi.com> Date: Thu, 16 Jun 94 12:28:24 -0400 From: Steve Kent Perry, When IPSP is used between two routers, I have that the SAID would identify the associations between these two points, not based on the addresses of the ultimate source and destination end systems. Between a couple of a large organization nets, this could ammount to quite a few associations, depending on the granularity at which associations are otherwise managed. For multiply-homed nets, if multiple devices implement IPSP and they are configured to be "equivalent" (to allow for any device to process and packet), there would be a need to avoid collisions in the SAID space, and that would argue for not too tight a space. Also, for multicast support, one might want to carve out a portion of the space, since multicast SAIDs need to be unique across a broader set of endpoints. In the IEEE 802.10B protocol, they devote a bit to marking multicast SAIDs, which takes away 1/2 the sapce. Given these observations, 16 bits of SAID might not be enough. As for sequence numbers, in an ATM environment, one can move a lot of packets in a hurry. At the other end of the spectrum, if two large organization nets want to establish a single, encrypted tunnel between them, then the volume of traffic might be pretty significant at ATM speeds. With small, e.g., about 100 bytes, IP packets, one can go through a 32 bit sequence number space in about 2 hours using a 620Mb/s access line. If we are confident that key changeover will be smooth, 32 bits may be adequate, but if want to limit changeover because of possible disruption to the association, then a bigger sequence number may be required. I just want to make sure that we make these decisions with a clear understanding of the implications. As for sequence number management, I think it would be good to specify a sliding window on a per-association basis, within which packets are accepted. A bit map and sequence number counters can be used to manage the window, to prevent replays. The window size and the sequence number size would be negotiated parameters at association establishment, perhaps with enumerated options for both. Use of no sequence numbers also should be a valid option. I also think we should consider requiring that all IPSP-protected packets be sent with the DNF bit set, to avoid a range of nasty denial of service attacks. This would require the IPSP implementation to employ MTU discovery, and to pass the info along to hosts behind an IPSP router implementation. Steve From ipsec-request@ans.net Thu Jun 16 20:07:09 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05778 (5.65c/IDA-1.4.4 for ); Thu, 16 Jun 1994 16:24:14 -0400 Received: by interlock.ans.net id AA22717 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Jun 1994 16:07:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Jun 1994 16:07:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Jun 1994 16:07:13 -0400 Date: Thu, 16 Jun 1994 16:07:09 -0400 From: jfjr@mbunix.mitre.org (Freedman) Message-Id: <199406162007.QAA13753@mbunix.mitre.org> Posted-From: The MITRE Corporation, Bedford, MA To: ipsec@ans.net Subject: swIPe vulnerabilities Cc: hgg@mbunix.mitre.org, jtw@linus.mitre.org, mbmg@beethoven.mitre.org In regards to S. Bellovin's swIPe comments: We have modified our swIPe implementation slightly by adding host filtering. Once swIPe is turned on - the ifconfigs and ioctls have been issued - any packets from a designated swIPed partner that are not swIPed are rejected. This is a few lines of code, mainly in ip_input. We also have a protoype key manager using Diffie-Hellman key exchange. This is done "out-of-band" over raw IPIP sockets. We have not yet included any third party certification. We believe that tieing swIPe processing to routing tables makes swIPe as vulnerable as the routing tables. Consider, HostA and HostB are swIPe end points. Packets from A intended for B are routed through the sw* interface and thus swIPed. HostC is a bad guy and, by playing interesting games with routing protocols, is able to cause changes in A's routing tables such that packets from A intended for B *bypass* the sw* interface and go out in the clear. B will reject such packets(assuming the host filtering described above is implemented) since they are from A, a swIPed host, and are not swIPed. The attack will fail on a full duplex TCP/IP channel wouldn't work. However,for UDP style, one way, communication this attack works fine. There should be some guarantee that packets intended for a swIPe host will undergo swIPe processing. As things stand now, with swIPe processing tightly bound to routing tables this is not the case. J. Freedman, J. T. Wittbold M. Michnikov From ipsec-request@ans.net Thu Jun 16 07:35:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18249 (5.65c/IDA-1.4.4 for ); Thu, 16 Jun 1994 17:54:02 -0400 Received: by interlock.ans.net id AA24327 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Jun 1994 17:34:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 16 Jun 1994 17:34:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 16 Jun 1994 17:34:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Jun 1994 17:34:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Jun 1994 17:34:17 -0400 Date: Thu, 16 Jun 94 14:35:01 PDT From: ashar@miraj.firstperson.com (Ashar Aziz) Message-Id: <9406162135.AA16862@miraj.Eng.Sun.COM> To: ipsec@ans.net Subject: SKIP (a key-management proposal) I have a key-management proposal (SKIP) that I would like to present to this group. I believe that this key-management proposal has many advantages for use in conjunction with a session-less and stateless protocol like IP (or CLNP or SIPP). Unfortunately, the proposal is not yet in the form an Internet-Draft, for which I apologize. However, I am hoping that there is enough information in the included draft overview to convey the basic ideas of the proposal. The proposed protocol format is simply a placeholder for conveying what sort of information needs to be present in the protocol that uses this kind of key-management. Something like swIPe could also be used, provided swIPe can accomodate the notion of a session-less key-management system, such as the one proposed here. (I am not sure if the existing swIPe protocol can do this, and this is one of the reasons I am presenting this proposal earlier than I was planning on. Perhaps the swIPe folks can tell me if this sort of key-management can be accommodated by their protocol). The section on management of certificates (section 4) is purely exploratory at the moment. It could be easily modified, without affecting the basic key-management algorithm. (CRLs are not mentioned, but they are obviously part of a certificate based infrastructure). The main advantage of this proposal is its stateless nature, and the use of a zero-message key-management protocol. It combines the advantages of a public-key certificate infrastructure (scalability, robustness etc.) with the advantages of shared key cryptography (speed, small block sizes etc.). Please comment. Ashar. ----------------Begin Draft Overview of SKIP--------------------- Simple Key-Management For Internet Protocols (SKIP) Draft 0.1 Ashar Aziz (ashar.aziz@Eng.Sun.Com) 6/16/94 Sun Microsystems Laboratories, Inc. Abstract There are occasions where it is advantageous to put authenticity and privacy features at the network layer. The vast majority of the privacy and authentication protocols in the literature deal with session oriented key- management schemes. However, many of the commonly used network layer protocols (e.g IP) are session- less datagram oriented protocols. We describe a key-management scheme that is particularly well suited for use in conjunction with a session-less datagram protocol like IP and some of its re- placement candidates like CLNP and SIPP. We also describe an ap- plication of this scheme in the context of Internet multicasting protocols. 1.0 Overview Any kind of scalable and robust key- management scheme that needs to scale to the number of nodes possible in the Internet needs to be based on an underlying public-key certificate based infras- tructure. This is the direction that, e.g, the key-management scheme for secure Internet e-mail, Privacy Enhanced Mail or PEM [1] , is taking. The certificates used by PEM are RSA public key certificates. Use of RSA public key certificates also enable the establishment of an authenticated session key [2,3]. (By an RSA public key certi- ficate, what is meant here is that the key being certified is an RSA public key.) One way to obtain authenticity and privacy at a datagram layer like IP is to use RSA public key certificates. (In the following description we use the term IP, whereas this can be any connec- tionless datagram protocol like CLNP or SIPP). There are two ways RSA certificates can be used to provide au- thenticity and privacy for a datagram protocol. The first way is to use out-of-band establishment of an authenticated session key, using one of several session key establishment protocols. This session key can then be used to encrypt IP data traffic. Such a scheme has the disadvantage of establishing and maintaining a pseudo session state on top of a session-less protocol. The IP source would need to first communicate with the IP destination in order to acquire this session key. Also, as and when the session key needs to be changed, the IP source and the IP destination need to communicate again in order to make this happen. Each such communication involves the use of a computationally expensive public-key operation. This communica- tion requirement is particularly ill-suited to a datagram proto- col like IP, which doesn't even require the receiving side to be up in order to send packets to it. Of course, in order to estab- lish and change negotiated session keys, the other side has to be up to negotiate or re-negotiate the session key. The second way an RSA certificate can be used is to do in-band signalling of the packet encryption key, where the packet encryp- tion key is encrypted in the recipient's public key. This is the way, e.g, PEM does message encryption. Although this avoids the session state establishment requirement, and also does not re- quire the two parties to communicate in order to set up and change packet encryption keys, this scheme has the disadvantage of having to carry the packet encryption key encrypted in the recipient's public key in every packet. Since an RSA encrypted key would minimally need to be 64 bytes, and can be 128 bytes, this scheme incurs the overhead of 64- 128 bytes of keying information in every packet. (As time progresses, the RSA block size would need to be closer to 128 bytes simply for security reasons.) Also, as and when the packet encryption key changes, a public key operation would need to be performed in order to recover the new packet encryption key. Thus both the protocol and computational overhead of such a scheme is high. Use of Diffie-Hellman (DH) public-key certificates [4] can avoid the pseudo session state establishment and the communications re- quirement between the two ends in order to acquire and change packet encrypting keys. Furthermore, this scheme does not incur the overhead of carrying 64-128 bytes of keying information in every packet. This kind of key-management scheme is better suited to protocols like IP, because it doesn't even require the remote side to be up in order to establish and change packet encrypting keys. This scheme is described in more detail below. 2.0 Simple Key-Management for Internet Procotols (SKIP) We stipulate that each IP based source and destination has a Diffie-Hellman public key. This public-key is distributed in the form of a certificate. The certificate can be signed using either an RSA or DSA signature algorithm. (We call such a certificate a Diffie-Hellman certificate, because the public value that is cer- tified is a Diffie-Hellman public value.) How the certificates are managed is described in more detail later. Thus each IP source or destination I has a secret value i, and computes a public value a**i mod p. Each pair of IP source and des- tination I and J can acquire a shared secret a**ij mod p. They can acquire this shared secret without actually having to communi- cate, as long as the public key of each IP node is known to all the other IP nodes. Local caching of DH certificates can elim- inate the constant need for a directory service. We use this computable shared secret as a key-encrypting-key to provide for IP packet based authentication and encryption. Thus we call a**ij mod p the long-term secret, and derive from it a key Kij. Kij is used as the key for a shared-key cryptosystem (SKCS) like DES or RC2. An important point here is that Kij is an impli- cit pair-wise shared secret. It does not need to be sent in every packet or negotiated out-of-band. Simply by examining the source of an IP packet, the destination IP node can compute this shared secret Kij. Kij is derived from aij mod p by taking the low order key-size bits of aij mod p. Since a**ij mod p is minimally going to be 512 bits and for greater security is going to be 1024 bits or higher, we can always derive enough bits for use as Kij which is a key for a SKCS. SKCS key sizes are typically in the range of 40-172 bits. We use Kij to encrypt a transient key, which we call Kp. Kp is then used to encrypt an IP packet or collection of packets. This is done in order to limit the actual amount of data in the long- term key. Since we would like to keep the long-term key for a re- latively long period of time, say one or two years, we dont en- crypt the actual IP data traffic in key Kij. Instead we only en- crypt transient keys in this long-term key, and use the transient keys to encrypt IP data traffic. This limits the amount of data encrypted in the long-term key to a relatively small amount even over a long period of time, like one year. Thus the first time an IP source I, which has a secret value i, needs to communicate with IP destination J, which has a secret value j, it computes the shared secret aij mod p. It can then dervive from this shared secret the long-term key Kij. IP source I then generates a random key Kp and encrypts this key using Kij. It encrypts the IP packet (header and data) in key Kp. It sends the encrypted IP packet, the encrypted key Kp, encapsulated in an outer IP header with the same source and destination addresses, and therefore the outgoing packet looks like, IP header with destination addresses I and J, protocol type SKIP_ENCRYPTED IP data , SKCS Algorithm Identifier and key size for Kij (1 byte) SKCS Algorithm Identifier and key size for Kp (1 byte) Kp encrypted in Kij (8-16 bytes) Message Indicator (8 bytes) Encrypted IP Hdr and Data portion. In order to prepare this packet for emission on the outbound side of IP node I, no communication was necessary with IP node J. Also, since Kij is used as the key for a SKCS, the length of en- crypted key Kp is padded up to the block size of a shared-key ci- pher (typically 8 bytes), as opposed to the block size of a public-key cipher (typically 64-128 bytes), which would have been the case if RSA certificates had been used in conjunction with in-band signalling of the packet encryption key. When IP node J receives this packet, it also computes the shared secret Kij and caches it for later use. Using Kij it obtains Kp, and using Kp it obtains the original IP packet, which it then delivers to the appropriate place which is either a local tran- sport entity or another outbound interface. The Message Indicator (MI) is a field that is needed to preserve the statelessness of the protocol. If a single key is used in order to encrypt multiple packets, (which is highly desirable since changing the key on a per packet basis constitutes too much overhead) then the packets need to be decryptable regardless of lost or out-of-order packets. The message indicator field serves this purpose. The actual content of the MI field is dependent on the choice of SKCS used for Kp and its operating mode. If Kp refers to a block cipher (e.g DES) operating in Cipher-Block- Chaining (CBC) mode, then the MI for the first packet encrypted in key Kp is the Ini- tialization Vector (IV). For subsequent packets, the MI is the last blocksize-bits of ciphertext of the last (in transmit order) packet. For DES or RC2 this would be last 64 bits of the last packet. For stream ciphers like RC4, the MI is simply the count of bytes that have already been encrypted in key Kp (and can be 64 bits also). If the source IP node (I in this case) decides to change the packet encryption key Kp, the receiving IP node can discover this fact without having to perform a public-key operation. It uses the cached value Kij to decrypt the encrypted packet key Kp, and this is a shared-key cryptosystem operation. Thus, without re- quiring communication between trasnsmitting and receiving ends, and without necessitating the use of a public-key operation, the packet encrypting key can be changed by the transmitting side. Since DH certififcates are used, the nodes themselves have no public-key signature algorithm. This is not a major problem, since signing on a per-packet basis using a public- key cryp- tosystem is too cumbersome in any case. The integrity of the packets is determined in a pairwise fasion using a SKCS. In order to keep the amount of data encrypted in any given key to be less than 232 (assuming a 64-bit block cipher) at T1 speeds of 1.5 Mbits/sec, the packet encryption key will need to change roughly every six hours. This results in the amount of key ma- terial encrypted in the long-term key in a years to be roughly 24K bytes, well under the 232 limit that would necessitate chang- ing the long-term key more frequently than a year. 2.1 Integrity-Only Protection SKIP may be used to provide for packet integrity in the absence of packet confidentiality. This can be done by computing a message-digest over the header and data portions which need to be integrity protected, and encrypting this message-digest directly using key Kij. Since the message-digest is a small amount of in- formation, it is not necessary to use a two-level keying struc- ture to encrypt the message-digests. The protocol field in the IP header will identify whether the message is SKIP_ENCRYPTED (as in Section 2.0) or SKIP_AUTHENTICATED. In case it is SKIP_AUTHENTICATED, the SKIP protocol header will contain algorithm identifiers for the hash algorithms and the Kij encryption algorithm (1 byte each), followed by the encrypted message-digest (8-20 bytes). 2.2 Playback Considerations This key-management scheme does not provide for any level of playback protection for the datagrams themselves. Most of the transport protocols deal with playbacks at the datagram layer anyway. For example, TCP does sequencing of IP packets. Therefore it isn't necessary to provide for this functionality at the da- tagram layer. If playback protection is important for a given application, then it needs to be built on top of the secure datagram protocol. Since the key-management itself is a zero- message protocol, it isn't meaningful to talk about replay attacks on the key- management algorithm itself. 2.3 Intruder in the middle attacks Unauthenticated Diffie-Hellman is susceptible to an intruder in the middle attack. To overcome this, authenticated Diffie- Hell- man schemes have been proposed, that include a signature opera- tion with the parties' private signature keys. SKIP is not susceptible to intruder in the middle types of at- tacks. This is because the Diffie-Hellman public parameters are long- term and certified. Intruder in the middle attacks on Diffie-Hellman assume that the parties cannot determine who the public Diffie-Hellman values belong to. Diffie- Hellman certifi- cates eliminate this possibility, without requiring any exchange of messages between the two parties. 2.4 Storage of Cached Keys Since the Kij values need to be cached for efficiency, reasonable safeguards need to be taken to protect these keys. One possible way to do this is to provide a hardware device to compute, store and perform operations using these keys. This dev- ice can ensure that there are no interfaces to extract the key from the device. 2.5 Manual Keying As an interim measure, in the absence of certification hiear- chies, nodes may wish to employ manually exchanged keying infor- mation. To handle such cases, the pair key Kij can be the key that is manually set up. Since manual re-keying is a slow and awkward process, it still makes sense to use the two level keying structure, and encrypt the packet encryption keys Kp using the manually setup pair keys Kij. This has the same benefit as before, namely it avoids over- exposing the pair key which is advantageous to maintain over re- latively long periods of time. This is particularly true for high-speed network links, where it is easy to encrypt large amounts of data over a short period of time. 3.0 Considerations for Datagram Multicast Protocols It is possible to use this kind of scheme in conjunction with da- tagram multicasting protocols like IP (or IPng) multicast [5]. However, this will require key-management awareness in the estab- lishment and joining process of multicast groups. This would work as follows. The notion of a group owner needs to exist. When secure multicasting to multicast address M is re- quired, a group membership creation primitive will need to estab- lish the secret value, and provide the public value. So, for mul- ticast address M, a randomly generated secret value m is created by the group owner and the public value am mod p is computed. Also associated with each group address M is a membership list of addresses that are allowed to transmit and receive encrypted mul- ticast datagrams to and from group address M. The public value is distributed securely to the nodes that wish to transmit to multicast address M. This is done by using the pairwise secure datagram protocol described in section 2 above. Thus nodes wishing to transmit to group address M acquire the public value am mod p from the group owner in a secured datagram from the group owner to the transmitting nodes. This value is distributed in the form of a certificate that is "signed" (using a SKCS) in the long-term pair-wise shared secret. This allows the group creation primitive to establish lifetimes for the transient secret value m and its corresponding public value. Nodes wishing to receive encrypted datagrams sent to multicast address M need to acquire the secret value m. This is done by sending the request to join primitive to the group owner. If the requesting node's address is part of the group's receive member- ship, then the group owner will send the secret value m, and the associated public value certificate in an encrypted packet, again using the pairwise secure protocol described in Section 2 above. Transmitting node I wishing to send to group address M will use the value aim mod p to derive the key Kim. Transmitting nodes don't need to know the secret value m; all they need to know is the group public value am mod p, and knowing their own secret value i can compute the shared secret aim mod p from which they derive Kim. Kim is then used to encrypt the packet encrypting key Kp. Since the receiving nodes know the group secret m, and the public value ai mod p they can also compute Kim, and thereby de- crypt the packet. An advantage of this scheme is that only the keying information is distributed in a pairwise fashion. The actual encrypted data packet is sent using the standard multicast delivery mechanisms, thereby allowing the same sort of network bandwidth efficiency that is expected of a network layer multicast protocol when operating over subnetworks which also support multicasting (like ethernet, FDDI etc). How the identity of the group owner is established and communi- cated to the participating nodes is left to the application layer. However, this also needs to be done in a secure fashion, otherwise the underlying key- management facility can be defeat- ed. The scalability of this scheme is intended to be limited to a moderate number of nodes, and not an extremely large number of nodes. This is not a major limitation, because there is an obvi- ous tradeoff between keeping a value secret and having it be widely distributed. 4.0 Management of DH certificates Since the nodes' public DH values are communicated in the form of certificates, the same sort of multi-tier certification structure that is being deployed for PEM [6] and also by the European PASS- WORD project can be used. Namely, there can be a Top Level Certi- fying Authority(TLCA) which may well be the same the Internet Policy Registration Authority (IPRA), Policy Certifying Authori- ties (PCAs) at the second tier and organizational CAs below that. In addition to the identity certificates, which are what are part of PEM certificate infrastructure, we also need additional au- thorization certificates, in order to properly track the owner- ship of IP addresses. Since we would like to directly use IP ad- dresses in the DH certificates, we cannot use the name subordina- tion principles alone (as e.g used by PEM) in order to determine if a particular CA has the authority to bind a particular IP ad- dress to a DH public value. We can still use the X.509/PEM certificate format, since the sub- ject Distinguished Name (DN) in the certificate can be the ascii decimal representation of an IP (or IPng) address. Since the nodes only have DH public keys, which have no signature capability, the nodes are themselves unable to issue certifi- cates. The node certificates are issued by organizational CAs which have jurisdiction over the range of IP addresses that are being certified. The PCAs will have to perform suitable checks (in line with the advertised policy of that PCA) to confirm that the organization which has jurisdiction over a range of addresses is issued a certificate giving it the authority to certify the DH values of individual nodes with those addresses. This authority will be delegated in the form of a authorization certificate signed by the PCA. For the purposes of authorization, the CA's Distinguished Name (DN) will be bound to the range of IP ad- dresses over which it has jurisdiction. The CA has either an RSA or DSA certificate issued by the PCA. An authorization certificate will also contain information about whether the CA to whom authority is being delegated can sub- delegate that authority. The CA which has delegatable authority over a range of IP addresses can delegate authority over part of the range to a subordinate CA, by signing another authorization certificate using its own private key. If the authority is non- delegatable, then the CA cannot delegate authority for that range of addresses. The range of IP addresses are identified in the certificate in the form of a list of IP address prefix, length pairs. 5.0 Conclusions We have described a scheme, Simple Key- Management for Internet Protocols (SKIP) that is particularly well suited to connection- less datagram protocols like IP and its replacement candidates like CLNP and SIPP. Both the protocol and computational overheads of this scheme are relatively low. In-band signalled keys incur the length overhead of the block size of a shared-key cipher. Also, setting and changing packet encrypting keys involves only a shared-key cipher operation. Yet the scheme has the scalability and robustness of a public- key certificate based infrastructure. A major advantage of this scheme is that establishing and chang- ing packet encrypting keys requires no communication between sending and receiving nodes and no establishment of a pseudo ses- sion state between the two sides is required. In many ways the key-management scheme here has structural simi- larities with the scheme used by PEM [1]. Both use the concept of an inter-change key (in our case that is the pair key Kij) and data encrypting keys (the packet encryption keys Kp). By using the implicit shared secret property of long-term DH public values, and treating the resulting keys as keys for a SKCS, we have reduced the protocol overhead substantially as compared to the overhead of PEM when used in conjunction with an asymmetric key- management system. We have also described how this scheme may be used in conjunction with datagram multicast protocols, allowing a single encrypted datagram to be multicast to all the receiving nodes. References [1] Internet PEM RFCs 1421-1424 [2] A Aziz, W Diffie, "Privacy and Authentication for Wire- less LANs", IEEE Personal Communications, Feb 1994. [3] W. Diffie, M. Wiener, P. Oorschot, "Authentication and Authenticated Key Exchanges.", in Designs Codes and Cryptography, Kluwer Academic Publishers, 1991. [4] W. Diffie, M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory [5] S. Deering, "IP Multicast", Ref needed [6] S. Kent, "Certificate Based Key Management," RFC 1422 for PEM From ipsec-request@ans.net Fri Jun 17 02:31:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13093 (5.65c/IDA-1.4.4 for ); Thu, 16 Jun 1994 23:13:46 -0400 Received: by interlock.ans.net id AA11244 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Jun 1994 22:31:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Jun 1994 22:31:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Jun 1994 22:31:00 -0400 Date: Thu, 16 Jun 1994 19:31:00 -0700 From: Phil Karn Message-Id: <199406170231.TAA21370@servo.qualcomm.com> To: kent@BBN.COM Cc: perry@imsi.com, ipsec@ans.net In-Reply-To: <199406151511.AA05483@interlock.ans.net> (message from Steve Kent on Wed, 15 Jun 94 10:59:28 -0400) Subject: Re: Granularity of authentication in swIPe Steve, I fully agree that the SAID is used to select previously negotiated options on a host-pair basis. So given that you can negotiate at key exchange time a much wider range of possible options than may be needed at any moment is it really necessary to have such a large SAID field? Can you show examples of situations where more than O(256) such associations are really necessary? Because the SAID is one of the few items in the IPSEC header that really does have to have a standard format (since it's used to index the stuff that is negotiable on a host-pair basis) it's important that we find a format that can satisfy everybody if we're going to have an interoperable standard. I doubt that most of my applications (the wireless type, anyway) will need more than one or two SAID values at any moment, and given the cost of my links I *really* don't want to spend even an extra byte of overhead unless I have to. But if you really want more than 1 byte, then I don't see much of an alternative to a variable length field, even though that will make the high-speed guys complain. Comments? Phil From ipsec-request@ans.net Fri Jun 17 02:48:11 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07545 (5.65c/IDA-1.4.4 for ); Thu, 16 Jun 1994 23:28:33 -0400 Received: by interlock.ans.net id AA08267 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Jun 1994 22:48:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Jun 1994 22:48:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Jun 1994 22:48:38 -0400 Date: Thu, 16 Jun 1994 19:48:11 -0700 From: Phil Karn Message-Id: <199406170248.TAA21401@servo.qualcomm.com> To: perry@imsi.com Cc: mleech@bnr.ca, ipsec@ans.net In-Reply-To: <9406142129.AA21251@snark.imsi.com> (perry@imsi.com) Subject: Re: Granularity of authentication in swIPe >Of course it is bound to the IP address, just as a TCP port number >makes sense only in the context of an IP address. There isn't any way >to get around this -- networks connect computers, not people. That This is a crucial point, one that's been kicking around for some time. I keep coming back to the position that in just about every modern operating system I know of, the kernel (or its logical equivalent) where the networking code resides has complete access to every one of its applications. That is, there's little to be gained by moving a cryptographic security mechanism with all its keys up to the application since a corrupt kernel can still get at them anyway. That said, the other major function of a kernel (protecting applications from each other) isn't really provided in a UNIX style networking environment, aside from the primitive and inadequate BSD mechanism of allowing only root processes to bind to raw IP "ports" and to low-numbered TCP and UDP ports. Perhaps what we need for SwIPe or its successor are new mechanisms in the UNIX kernel to manage access to the host-pair security associations maintained in the kernel. E.g., there might be a capability list that specifies which SAIDs may be used by which processes. SAIDs created with a particular application-provided key would by default be usable only by the process that created them (and provided the crypto keys). Other processes on the same machine would have access to the SAID only if the creating process were to grant it. Of course, with the trend toward more and more single-user UNIX systems, the historical importance of the kernel protecting mututally hostile processes from each other becomes less important all the time. Comments? Phil From ipsec-request@ans.net Fri Jun 17 03:15:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13150 (5.65c/IDA-1.4.4 for ); Thu, 16 Jun 1994 23:46:11 -0400 Received: by interlock.ans.net id AA38968 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Jun 1994 23:15:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Jun 1994 23:15:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Jun 1994 23:15:40 -0400 Date: Thu, 16 Jun 1994 20:15:42 -0700 From: Phil Karn Message-Id: <199406170315.UAA21424@servo.qualcomm.com> To: smb@research.att.com Cc: perry@imsi.com, kent@BBN.COM, ipsec@ans.net In-Reply-To: <199406150011.AA29826@interlock.ans.net> (smb@research.att.com) Subject: Re: Granularity of authentication in swIPe >I haven't had a chance to unpack the Usenix disk yet; as I recall, though, >swIPe has a one-byte keyid, which is unacceptable to me. It also has a >packet sequence number, which is a rather dubious construct that needs >a *lot* of debate, at the very least. The sequence number idea has already had a lot of debate. I guess it needs more. Since I was the one who originally proposed the sequence number feature, I guess I should try to defend it. First of all, the term "sequence number" is slightly misleading, because there is NO attempt to use it to provide in-sequence delivery. The intent was solely to help provide "at most once" IP datagram delivery in the presence of hostile replay attacks during the lifetime of a single SAID. My original motivation for this was as follows: Most ciphers that operate on packets require some sort of nonce (e.g., an IV) to ensure that identical packets encrypt differently. Although the IV could be part of the cipher-specific encapsulation, it seemed like a general enough feature to consider making it part of the standard IPSEC header. And if you make the IV a standard part of the IPSEC header, then you can make it do double duty in suppressing duplicates. This is much more convenient if the IV is a sequence number, but in theory it doesn't have to be. It just makes the bookkeeping easier. Not to say that the bookkeeping would actually *be* easy. If you assume that most packets arrive in order and are not lost (a fairly reasonable, though not universally valid assumption) then a data structure like that kept in a netnews .newsrc file could work well. But the only general mechanism would be a bitmap large enough to cover all of the packets to be sent during the lifetime of a single SAID. But the mechanism doesn't have to be totally bulletproof to still be useful. Since you only have to suppress duplicates for the life of the SAID, so you can always bound the bookkeeping by just creating a new SAID and blowing away the old one. You might even decide to do this automatically if you seem to be under a denial-of-service attack. So my question to the list is this: is there any kind of concensus around my first point, which is that the concept of a crypto-seeding IV is universal enough to warrant becoming part of the standard IPSEC header, where it can then possibly be used to do other things as a side benefit, like replay suppression? Phil From ipsec-request@ans.net Fri Jun 17 03:28:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05021 (5.65c/IDA-1.4.4 for ); Thu, 16 Jun 1994 23:54:14 -0400 Received: by interlock.ans.net id AA08388 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 16 Jun 1994 23:29:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Jun 1994 23:29:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Jun 1994 23:29:10 -0400 Date: Thu, 16 Jun 1994 20:28:59 -0700 From: Phil Karn Message-Id: <199406170328.UAA21435@servo.qualcomm.com> To: brian@lloyd.com Cc: ipsec@ans.net In-Reply-To: (brian@lloyd.com) Subject: Re: Expired swIPe >I thought that Phil Karn had done an implementation in his KA9Q package. >Would someone please correct me if this is an erronious impression. I have something that is conceptually very similar to SwIPe in KA9Q, although I have not released it because it is still quite messy. SwIPe originated as a joint project of mab, ji and myself. Mab and ji would concentrate on the BSD environment while I prototyped an independent version under KA9Q NOS to gain interoperability experience. However, due to other job tasks and distractions and my physical remoteness from NY/NJ I just haven't invested the time and effort in working with mab and ji that the project warrants. I.e., they deserve all the credit for the current release. But I'm getting involved again, mainly in the key management area now that RSAREF 2.0 is out and includes Diffie-Hellman key exchange. Want a list of a dozen strong 1024-bit primes, generated by yours truly, suitable as Diffie-Hellman moduli? They're really *good* primes, fresh out of the box, never used. :-) Phil From ipsec-request@ans.net Fri Jun 17 15:55:29 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04335 (5.65c/IDA-1.4.4 for ); Fri, 17 Jun 1994 12:46:46 -0400 Received: by interlock.ans.net id AA43907 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 17 Jun 1994 12:08:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 17 Jun 1994 12:08:07 -0400 Message-Id: <199406171608.AA42611@interlock.ans.net> To: Phil Karn Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Thu, 16 Jun 94 19:31:00 -0700. <199406170231.TAA21370@servo.qualcomm.com> Date: Fri, 17 Jun 94 11:55:29 -0400 From: Steve Kent Phil, The scenarios I envision that might require lots of SAIDs are ones in which IPSP is implemented at one routers for large organizations. An organization may elect to assign a different SAID for each (ultimate) source-destination address pair. But SAIDs must be unique on a S/D basis between the IPSP implementation points, in this case the routers. Thus there could be a need for many SAIDs between a pair of IPSP-capable routers. If the hosts behind the routers are allowed to ask for finer granularity associations, e.g., per TCP connection, then the number could grow even more. Steve From ipsec-request@ans.net Fri Jun 17 16:15:13 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05383 (5.65c/IDA-1.4.4 for ); Fri, 17 Jun 1994 12:52:09 -0400 Received: by interlock.ans.net id AA18890 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 17 Jun 1994 12:18:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 17 Jun 1994 12:18:35 -0400 Message-Id: <199406171618.AA37574@interlock.ans.net> To: Phil Karn Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Thu, 16 Jun 94 20:15:42 -0700. <199406170315.UAA21424@servo.qualcomm.com> Date: Fri, 17 Jun 94 12:15:13 -0400 From: Steve Kent Phil, The motivation you cite for using an IV/sequence number was the major reason I was not enamored of the proposal originally. In some contexts per-packet IVs might have to be random or have some other structure that would make for poor sequence numbers. I think it would be better to keep the two concepts separate. My motivation for the sequence numbers is more denial-of-service oriented, although a side effect is to counter attacks with other possible goals. As for managing the sequence numbers, you're right that it may not be easy to do it efficiently given occasional out-of-order arrivals. But, as you observed, most packets do arrive in sequence, so you might just keep track of the last sequentially validated sequence number, plus a small bit map or sorted list of sequence numbers to track packets in a region where there are gaps. By negotiating the size of the window at association establishment time, the receiver bounds the size of the bit map or list. Steve From ipsec-request@ans.net Fri Jun 17 16:38:48 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05619 (5.65c/IDA-1.4.4 for ); Fri, 17 Jun 1994 13:21:37 -0400 Received: by interlock.ans.net id AA36525 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 17 Jun 1994 12:49:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 17 Jun 1994 12:49:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 17 Jun 1994 12:49:43 -0400 Message-Id: <199406171638.KAA06797@misc.glarp.com> To: Phil Karn Cc: kent@bbn.com, perry@imsi.com, ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of "Thu, 16 Jun 1994 19:31:00 PDT." <199406170231.TAA21370@servo.qualcomm.com> Date: Fri, 17 Jun 1994 10:38:48 -0600 From: Brad Huntting > I fully agree that the SAID is used to select previously negotiated > options on a host-pair basis. So given that you can negotiate at key > exchange time a much wider range of possible options than may be > needed at any moment is it really necessary to have such a large SAID > field? Can you show examples of situations where more than O(256) > such associations are really necessary? In some applications one SAID per "user" does not seem unreasonable. Suppose for example, I have a select group of users on machine X that need to access services behind my firewall F. Unfortunately, X is also crawling with users who _dont_ need and shouldn't be given access to resources behind F. Let's say F uses swIPe to enforce it's access policy. A requirement of the policy is that access must be granted/denied on a per user basis (not uncommon). So it makes some sense to integrate key exchange with user authentication and create one (or more?) SAID for each user. The alternative to using per user key exchange and per user SAIDs would be to use one SAID for all X<->F communications. But then I'd have to rely on something like identd to identify individual users on X, or rely on X itself to screen which users can and can't use the X<->F tunnel. Neither of these is acceptable. For one thing, X may employ weaker authentication controls than what I consider to be acceptable (e.g. 8 character reusable passwords). Also, I dont want to futz around with X specific naming details like usernames or uid's for my access control lists on F; after all, these things are not under my control. Lastly, there's no way I'm going to trust someone else to maintain an access control list for determining who can use this X<->F tunnel. Even if I trust the admin of X, it's not her responsibility to safeguard my network, and so it's unreasonable to make her maintain my ACL's. It's not hard to argue that machine X needs to be trusted regardless, since it's kernel will be managing all security associations. But the only time I need to trust it is when one of my authorized users is running an application that uses the X<->F swIPe tunnel. If the authentication elements for the X<->F swIPe tunnel are only available when someone is using the tunnel there is much less risk of the tunnel being subverted. Now suppose one of these authorized users sits down in front of a machine Z that she feels is trustworthy. Trustworthy or not, my firewall has never talked to Z before, so there may be little or no common ground for a host based key exchange. If my key exchange is based on per user authentication, then my roaming user will have no problem establishing a swIPe tunnel between Z and F even though the two machines have never spoken before. brad From ipsec-request@ans.net Fri Jun 17 17:47:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13381 (5.65c/IDA-1.4.4 for ); Fri, 17 Jun 1994 14:27:07 -0400 Received: by interlock.ans.net id AA15534 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 17 Jun 1994 13:49:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 17 Jun 1994 13:49:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 17 Jun 1994 13:49:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 17 Jun 1994 13:49:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 17 Jun 1994 13:49:47 -0400 Message-Id: <9406171747.AA02569@snark.imsi.com> To: Steve Kent Cc: Phil Karn , ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of "Fri, 17 Jun 1994 11:55:29 EDT." <199406171608.AA42611@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 17 Jun 1994 13:47:10 -0400 From: "Perry E. Metzger" Steve Kent says: > The scenarios I envision that might require lots of SAIDs are > ones in which IPSP is implemented at one routers for large > organizations. An organization may elect to assign a different SAID > for each (ultimate) source-destination address pair. But SAIDs must > be unique on a S/D basis between the IPSP implementation points, in > this case the routers. Thus there could be a need for many SAIDs > between a pair of IPSP-capable routers. If the hosts behind the > routers are allowed to ask for finer granularity associations, e.g., > per TCP connection, then the number could grow even more. Steve; From a traffic analysis point of view, wouldn't it be a mistake to leak information on endpoints by assigning each a SAID? This could lead to a situation in which one could notice characteristics of the traffic associated with each SAID, eventually using that information to identify the source and then use that as a tool to attack the individual encryption scheme, or use the knowledge of the traffic levels iself in some manner. I can easily envision doing this -- just as a starting example, one could determine whether a pair were communicating via TCP by noting the slow start and Van J. algorithms in progress, or by deliberately corrupting a packet and noting whether there was apparent retransmission. You have more experience with this. Can you really think of an instance in which one would really want to simply repackage each host pair SAID rather than encrypting the whole link under a single policy, which would seem to leak less data? Is it something that would actually be desirable? Perry From ipsec-request@ans.net Fri Jun 17 19:08:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04329 (5.65c/IDA-1.4.4 for ); Fri, 17 Jun 1994 15:46:14 -0400 Received: by interlock.ans.net id AA37994 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 17 Jun 1994 15:08:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 17 Jun 1994 15:08:42 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 17 Jun 1994 15:08:42 -0400 Date: Fri, 17 Jun 1994 12:08:43 -0700 From: Phil Karn Message-Id: <199406171908.MAA26935@servo.qualcomm.com> To: kent@BBN.COM Cc: ipsec@ans.net In-Reply-To: <199406171618.JAA09551@qualcomm.com> (message from Steve Kent on Fri, 17 Jun 94 12:15:13 -0400) Subject: Re: Granularity of authentication in swIPe >the major reason I was not enamored of the proposal originally. In >some contexts per-packet IVs might have to be random or have some >other structure that would make for poor sequence numbers. I think it I'd be interested in some examples. I can't think of an algorithm or encryption mode where sequential numbers couldn't serve as IVs, but my experience is probably more limited than yours. I have considered only block ciphers with CBC-like modes (e.g., DES and IDEA) and key stream generators (like keyed MD5) and sequential numbers seem appropriate as IVs for both. Indeed, unique IVs are absolutely essential for a keystream generator to avoid generating the same key stream twice. Using sequential numbers is one way to ensure uniqueness. Of course you have to be careful when you lose this sequential state, but in the present protocol I don't see a problem as long as you also blow away and reestablish the SAID and keys from truly random data whenever this happens. Phil From ipsec-request@ans.net Fri Jun 17 19:26:27 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05113 (5.65c/IDA-1.4.4 for ); Fri, 17 Jun 1994 16:09:35 -0400 Received: by interlock.ans.net id AA24771 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 17 Jun 1994 15:34:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 17 Jun 1994 15:34:24 -0400 Message-Id: <199406171934.AA41151@interlock.ans.net> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Fri, 17 Jun 94 13:47:10 -0400. <9406171747.AA02569@snark.imsi.com> Date: Fri, 17 Jun 94 15:26:27 -0400 From: Steve Kent Perry, It is true that using fine-grained SAIDs does reveal more traffic analysis info. However, different users of IPSP may have different motivations for their use of SAIDs and traffic analysis may be low on their list of concerns. I certainly hope that the algorithms we use are sufficiently good that the additional info provided by fine-grained SAIDs would not be a concern. So, while I agree that one big, fat pipe between two sites has advantages from a T/A perspective, it may have disadvantages from other perspectives. If we want IPSP to be flexible in this regard, we have to provide for a large SAID space. If we narrow down how SAIDs will be used, and restrict the use to flavors that will not generate a demand for large numbers of SAIDs, then we can live with a smaller field. Steve From ipsec-request@ans.net Fri Jun 17 20:10:11 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13548 (5.65c/IDA-1.4.4 for ); Fri, 17 Jun 1994 16:57:41 -0400 Received: by interlock.ans.net id AA25343 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 17 Jun 1994 16:18:05 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 17 Jun 1994 16:18:05 -0400 Message-Id: <199406172018.AA30714@interlock.ans.net> To: Phil Karn Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Fri, 17 Jun 94 12:08:43 -0700. <199406171908.MAA26935@servo.qualcomm.com> Date: Fri, 17 Jun 94 16:10:11 -0400 From: Steve Kent Phil, As Ted Ts'o pointed out in a private message, the use of the LEAF with SKIPJACK is a good example where an "IV" cannot be just a sequence number. Certainly you wouldn't want IPSP to not be compatible with FIPS 185 :-)! SKIPJACK wasn't the example I had in mind, but it is representative of crypto hardware that insists on generating the IV itself, to minimize the possibility of repeating and IV already used under a given key. Steve From ipsec-request@ans.net Fri Jun 17 14:20:23 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13225 (5.65c/IDA-1.4.4 for ); Fri, 17 Jun 1994 18:52:22 -0400 Received: by interlock.ans.net id AA44172 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 17 Jun 1994 18:20:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 17 Jun 1994 18:20:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 17 Jun 1994 18:20:36 -0400 Date: Fri, 17 Jun 94 18:20:23 EDT From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Message-Id: <9406172220.AA08321@tsx-11.MIT.EDU> To: Steve Kent Cc: Phil Karn , ipsec@ans.net In-Reply-To: Steve Kent's message of Fri, 17 Jun 94 16:10:11 -0400, <199406172018.AA30714@interlock.ans.net> Subject: Re: Granularity of authentication in swIPe Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Fri, 17 Jun 94 16:10:11 -0400 From: Steve Kent Phil, As Ted Ts'o pointed out in a private message, the use of the LEAF with SKIPJACK is a good example where an "IV" cannot be just a sequence number. Certainly you wouldn't want IPSP to not be compatible with FIPS 185 :-)! SKIPJACK wasn't the example I had in mind, but it is representative of crypto hardware that insists on generating the IV itself, to minimize the possibility of repeating and IV already used under a given key. Disclaimer --- I didn't say that this would be a good reason to allow for non-random IV in IPSP --- I just asked Steve, somewhat tongue in cheek, whether this was the "structured IV" that he was thinking about. :-) The sad fact of the matter is that even if FIPS 185 isn't a good reason to allow for non-random IV's, my guess is that it's not the only form of classified encryption hardware that requires users to use a machine generated IV, and we probably should allow for them in our design. Although some might consider it a feature if we designed a protocol which precluded the use of FIPS 185, I don't think we can get away with it this time.... - Ted From ipsec-request@ans.net Sat Jun 18 21:00:04 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13426 (5.65c/IDA-1.4.4 for ); Sat, 18 Jun 1994 14:12:51 -0400 Received: by interlock.ans.net id AA42808 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 18 Jun 1994 14:02:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 18 Jun 1994 14:02:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 18 Jun 1994 14:02:54 -0400 Date: Sat, 18 Jun 1994 21:00:04 +0000 (O) From: NTG@vrit01.eg Subject: ^^^ Meaning of swIPe^^^ To: ipsec@ans.net Message-Id: <01HDP976Q9CY001U8X@FRCU.EUN.EG> X-Vms-To: FRCU::IN%"ipsec@ans.net" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Dear sir, Currently I started reading the swIPe protocol. Really I see it is easy and powerful. I am in the begining. I follow the comments of the subscribers but I want to know what swIPe stands for. for example IP stands for Internet Protocol, TCP Transport Control Protocol,...etc What swIPe stands for..? Thank you in advance Eng. Waleed Hosny 112 pyramids st. Giza - Egypt Electronic Research Institute ntg@ritsec.com.eg From ipsec-request@ans.net Mon Jun 20 11:54:11 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07905 (5.65c/IDA-1.4.4 for ); Mon, 20 Jun 1994 08:06:28 -0400 Received: by interlock.ans.net id AA42695 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 20 Jun 1994 07:54:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 20 Jun 1994 07:54:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 20 Jun 1994 07:54:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 20 Jun 1994 07:54:30 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 20 Jun 1994 07:54:30 -0400 Message-Id: <9406201154.AA04993@snark.imsi.com> To: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Cc: Steve Kent , Phil Karn , ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of "Fri, 17 Jun 1994 18:20:23 EDT." <9406172220.AA08321@tsx-11.MIT.EDU> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 20 Jun 1994 07:54:11 -0400 From: "Perry E. Metzger" Theodore Ts'o says: > As Ted Ts'o pointed out in a private message, the use of the > LEAF with SKIPJACK is a good example where an "IV" cannot be just a > sequence number. Certainly you wouldn't want IPSP to not be > compatible with FIPS 185 :-)! SKIPJACK wasn't the example I had in > mind, but it is representative of crypto hardware that insists on > generating the IV itself, to minimize the possibility of repeating > and IV already used under a given key. > [...] > The sad fact of the matter is that even if FIPS 185 isn't a good reason > to allow for non-random IV's, my guess is that it's not the only form of > classified encryption hardware that requires users to use a machine > generated IV, and we probably should allow for them in our design. I'll point out that the sequence number need not be used as the IV -- its entirely possible to get away with transmitting the IV in another manner for such encryption algorithms. Remember that swIPe itself doesn't specify how such things must be done -- it can change from encryption algorithm to encryption algorithm. In particular, with an EES implementation (not something I'd use, but hey, the government is going to want them) we could assume that the IV gets exchanged with the LEAF at key setup time and that the sequence number could be used as a sort of supplementary IV... Perry From ipsec-request@ans.net Tue Jun 21 05:28:27 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11954 (5.65c/IDA-1.4.4 for ); Tue, 21 Jun 1994 05:28:27 -0400 Received: by interlock.ans.net id AA38203 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Jun 1994 05:16:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Jun 1994 05:16:26 -0400 Message-Id: <199406210916.AA44599@interlock.ans.net> Date: 21 Jun 94 10:07:00 WET From: "Tim Dean" Subject: A few thoughts on IPSP To: "ipsec" (Forgive an interloper sticking in my twopence worth, but I couldn't stay silent any longer...) I have just reviewed swIPe - both the Internet Draft and accompanying paper on security under Unix. First, as an aside, it seems to give ISO's Network Layer Security Protocol (NLSP) a pretty bad press, and I don't fully understand the criticisms. ("... NLSP implicitly imposes a specific model of trust and policy; this manifests itself in the form of unwieldy features and a multiplicity of options." These sentences seem contradictory: it is NLSP's attempt to *avoid* being policy specific which results in such a wide range of options and features). That said, having just implemented NLSP with other people here, I feel there are a few nice features in it which may be useful in trying to define an IP security protocol. As a general statement, the IPSP should, like NLSP, be made `future-proof' where possible: an eye should be firmly kept on accommodating possible changes to TCP and/or IP, and also sup- porting new security environments in end systems/LANs (e.g. MLS systems, better firewalls between users, evolvement of methods for signalling security services between the Network Layer and the application). More specifically (I'm not trying to endorse NLSP here, but pointing out a few features which may be useful in defining an IPSP): 1) The IPSP should (like NLSP) be completely independent of the underlying network pro- tocols, routing, and other network specifics. The advantage of this is that it is not reliant on a datagram arriving on a specific port or address to determine how to process it; this means that network topology and network addresses can change and the Security Association can stay intact. (The Security Association ID in the NLSP header gives the reference to the ap- propriate information.) The swIPe draft, (forgive me if I've misunderstood it) seems to use the IP addresses below it to determine how to process datagrams. 2) The IPSP should (like NLSP) provide SAs with a choice of security services to its `us- ers' at a finer level of granularity than simple source/dest IP addresses below it; swIPe (ditto previous caveat) seems not to do this. This is important for two reasons. Firstly, when it is operating as a gateway to a protected network, different users may require different security services for their traffic. Secondly, (probably more importantly), security management - key management and access control management - almost certainly will require different services to `normal' user traffic. E.g. a key management application may do its own encryp- tion and require a complete bypass of network security functions; or it may require a `higher' level of protection (e.g. `stronger' crypto-algorithm) than normal user traffic; the important point is that the security layer should be flexible and not place constraints on its users which will be hard to fix in the future. 3) I've not been following the SAID space discussions too closely, but does the NLSP way of doing things help at all... (maybe this is already what's been agreed?) In NLSP the SAID is different for each direction of communication: each side tells its peer on SA setup what value it requires for communication with it. That way, each host can manage its SAID space efficiently and can (for example) allocate the next SAID in sequence for the next host which wishes to communicate with it. Schemes where SAIDs are agreed bilaterally seem to waste half the bits. Hope these few thoughts help a bit. Tim Dean Rm L110, DRA-Malvern Open Distributed Systems St Andrew's Road Software Engineering and CIS Technology Dept Malvern Defence Research Agency Worcestershire UK Tel: +44-684-894239 Fax: +44-684-896113 E-mail: Dean@hydra.dra.hmg.gb From ipsec-request@ans.net Wed Jun 22 13:53:24 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13364 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 10:10:31 -0400 Received: by interlock.ans.net id AA22063 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 09:53:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Jun 1994 09:53:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 09:53:35 -0400 Date: Wed, 22 Jun 1994 09:53:24 -0400 From: jfjr@mbunix.mitre.org (Freedman) Message-Id: <199406221353.JAA02898@mbunix.mitre.org> Posted-From: The MITRE Corporation, Bedford, MA To: ipsec@ans.net Subject: swIPe comments In regards to S. Bellovin's swIPe comments: We have modified our swIPe implementation slightly by adding host filtering. Once swIPe is turned on - the ifconfigs and ioctls have been issued - any packets from a designated swIPed partner that are not swIPed are rejected. This is a few lines of code, mainly in ip_input. We also have a protoype key manager using Diffie-Hellman key exchange. This is done "out-of-band" over raw IPIP sockets. We have not yet included any third party certification. We believe that tieing swIPe processing to routing tables makes swIPe as vulnerable as the routing tables. Consider, HostA and HostB are swIPed end points. Packets from A intended for B are routed through the sw* interface and thus swIPed. HostC is a bad guy and, by playing interesting games with routing protocols, is able to cause changes in A's routing tables such that packets from A intended for B *bypass* the sw* interface and go out in the clear. B will reject such packets(assuming the host filtering described above is implemented) since they are from A, a swIPed host, and are not swIPed. The attack will fail on a full duplex TCP/IP channel. However,for UDP style, one way, communication this attack works fine. There should be some guarantee that packets intended for a swIPe host will undergo swIPe processing. As things stand now, with swIPe processing tightly bound to routing tables this is not the case. From ipsec-request@ans.net Wed Jun 22 13:49:05 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14144 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 10:14:30 -0400 Received: by interlock.ans.net id AA39018 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 09:58:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 09:58:23 -0400 Message-Id: <199406221358.AA19302@interlock.ans.net> To: Theodore Ts'o Cc: ipsec@ans.net, kent@BBN.COM Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Fri, 17 Jun 94 18:20:23 -0400. <9406172220.AA08321@tsx-11.MIT.EDU> Date: Wed, 22 Jun 94 09:49:05 -0400 From: Steve Kent Ted, I noted that your message was somewhat "tongue in cheek." I didn't say that you suggested support for LEAF was a good motivation for allowing random or structured IVs, but rather that you cited the LEAF as good example of an IV that is incompatible with a sequence number approach to IVs. Steve From ipsec-request@ans.net Wed Jun 22 13:56:57 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05445 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 10:14:33 -0400 Received: by interlock.ans.net id AA43889 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 09:58:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 09:58:39 -0400 Message-Id: <199406221358.AA19309@interlock.ans.net> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Mon, 20 Jun 94 07:54:11 -0400. <9406201154.AA04993@snark.imsi.com> Date: Wed, 22 Jun 94 09:56:57 -0400 From: Steve Kent Perry, I think the best approach is to let sequence numbers be sequence numbers, and not try to load other requirements on them. As you observed, different encryption algorithms and modes of use have different requirements for IVs and IPSP should be algorithm independent. Steve From ipsec-request@ans.net Wed Jun 22 14:57:16 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15786 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 11:15:56 -0400 Received: by interlock.ans.net id AA50668 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 10:57:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 22 Jun 1994 10:57:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Jun 1994 10:57:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Jun 1994 10:57:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 10:57:36 -0400 Message-Id: <9406221457.AA02772@snark.imsi.com> To: Steve Kent Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of "Wed, 22 Jun 1994 09:56:57 EDT." <199406221433.KAA20740@wintermute.imsi.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 22 Jun 1994 10:57:16 -0400 From: "Perry E. Metzger" Steve Kent says: > I think the best approach is to let sequence numbers be > sequence numbers, and not try to load other requirements on them. As > you observed, different encryption algorithms and modes of use have > different requirements for IVs and IPSP should be algorithm independent. That might be reasonable at some times, and not the most efficient strategy at others. I'd say that since the contents of a swIPe packet are basically opaque it is up to the people standardizing the use of any particular cipher with swIPe and not a proper part of swIPe per se. After all, to an outside observer, there is no way to know what cipher, IV, or anything else is in use with a particular policy. I will agree, however, that there will certainly be instances in which a sequence number is not a reasonable IV. Perry From ipsec-request@ans.net Wed Jun 22 15:20:57 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15286 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 11:47:27 -0400 Received: by interlock.ans.net id AA55951 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 11:30:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 11:30:50 -0400 Message-Id: <199406221530.AA19595@interlock.ans.net> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Wed, 22 Jun 94 10:57:16 -0400. <9406221457.AA02772@snark.imsi.com> Date: Wed, 22 Jun 94 11:20:57 -0400 From: Steve Kent Perry, The most efficient approach to solving a problem is almost never the most general one as well. I think you aer saying that an IV field should not be an explicit part of IPSP. I agree that one can make the presence or absence of an IV a function of the encryption algorithm being used and that's a reasonable approach. One can not provide an explicit IV field, but rather declare that an IV, if present, must be prepended to the ciphertext portion of the packet. That approach may reduce copying and it makes the size and any structure of the IV is not visible to any IPSP software. This is a nice, object-orneited approach that should make it easy to use different algorithms with IPSP. However, if one wants to save space in the header by reusing the sequence number as the IV, this is in conflcit with the approach described above. Rather, the IPSP would have to pass the sequence number field to the crypto software as an IV and that would require that IPSP "know" that the sequence number was being used as an IV by some algorithms. That strikes me as not conducive to a modular IPSP design, and thus I am arguing against it. Steve From ipsec-request@ans.net Wed Jun 22 11:09:54 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05479 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 15:22:51 -0400 Received: by interlock.ans.net id AA28538 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 15:10:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Jun 1994 15:10:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 15:10:11 -0400 Date: Wed, 22 Jun 94 15:09:54 EDT From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Message-Id: <9406221909.AA20862@tsx-11.MIT.EDU> To: Steve Kent Cc: perry@imsi.com, ipsec@ans.net In-Reply-To: Steve Kent's message of Wed, 22 Jun 94 11:20:57 -0400, <199406221530.AA19595@interlock.ans.net> Subject: Re: Granularity of authentication in swIPe Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Wed, 22 Jun 94 11:20:57 -0400 From: Steve Kent However, if one wants to save space in the header by reusing the sequence number as the IV, this is in conflcit with the approach described above. Rather, the IPSP would have to pass the sequence number field to the crypto software as an IV and that would require that IPSP "know" that the sequence number was being used as an IV by some algorithms. That strikes me as not conducive to a modular IPSP design, and thus I am arguing against it. It depends on how you look at it. If IPSP always passes a pointer of the header structure to the crypto software along with the ciphertext portion of the packet, the IPSP layer need not "know" anything about what, if anything, some particular crypto layer might use from the header portion of the packet. It does has the downside of making it harder to reuse that interface crypto layer for some other non-IPSP layer on top --- but I'm not convinced that that level of modularity is really all that worthwhile. - Ted From ipsec-request@ans.net Wed Jun 22 19:42:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05624 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 16:03:20 -0400 Received: by interlock.ans.net id AA06376 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 15:51:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 15:51:28 -0400 Message-Id: <199406221951.AA25316@interlock.ans.net> To: Theodore Ts'o Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Wed, 22 Jun 94 15:09:54 -0400. <9406221909.AA20862@tsx-11.MIT.EDU> Date: Wed, 22 Jun 94 15:42:00 -0400 From: Steve Kent Ted, You're right, if you want to require that the crypto interface parse the IPSP header, then IPSP treat the use of a sequence number as IV uniformly. Your view is that the associated modulariy doesn't seem to be worhtwhile; my view is that the proposed space-saving hack doesn't seem to be worth violating modularity. Steve From ipsec-request@ans.net Wed Jun 22 12:07:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15475 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 16:18:05 -0400 Received: by interlock.ans.net id AA21231 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 16:08:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Jun 1994 16:08:02 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 16:08:02 -0400 Date: Wed, 22 Jun 94 16:07:53 EDT From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Message-Id: <9406222007.AA22023@tsx-11.MIT.EDU> To: Steve Kent Cc: Theodore Ts'o , ipsec@ans.net In-Reply-To: Steve Kent's message of Wed, 22 Jun 94 15:42:00 -0400, <9406221951.AA14663@MIT.EDU> Subject: Re: Granularity of authentication in swIPe Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Wed, 22 Jun 94 15:42:00 -0400 From: Steve Kent You're right, if you want to require that the crypto interface parse the IPSP header, then IPSP treat the use of a sequence number as IV uniformly. Your view is that the associated modulariy doesn't seem to be worhtwhile; my view is that the proposed space-saving hack doesn't seem to be worth violating modularity. It doesn't need to *parse* the IPSP header --- the IPSP layer can merely pass the parsed header in a structure to the crypto routine. Some crypto routines may use the header information; and some crypto routines won't. Presumably, systems where actual crypto is performed by a Top Secret magic mystical black box which self-destructs using thermite if you look at it the wrong way, may not use the header information. But at this point, we're talking about implementation details of each particular crypto system. I don't see a terrible modularity violation --- certainly it's no worse than what say, what CSLIP does. - Ted From ipsec-request@ans.net Wed Jun 22 20:47:32 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14045 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 16:58:09 -0400 Received: by interlock.ans.net id AA13850 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 16:47:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 22 Jun 1994 16:47:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Jun 1994 16:47:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Jun 1994 16:47:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 16:47:55 -0400 Message-Id: <9406222047.AA03677@snark.imsi.com> To: Steve Kent Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of "Wed, 22 Jun 1994 15:42:00 EDT." <199406221951.AA25316@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 22 Jun 1994 16:47:32 -0400 From: "Perry E. Metzger" Steve Kent says: > You're right, if you want to require that the crypto interface > parse the IPSP header, then IPSP treat the use of a sequence number as > IV uniformly. Your view is that the associated modulariy doesn't seem > to be worhtwhile; my view is that the proposed space-saving hack > doesn't seem to be worth violating modularity. Just a note: the decent TCP/IP implementations I know of seem to routinely violate modularity for performance. Perry From ipsec-request@ans.net Wed Jun 22 16:59:49 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14050 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 16:59:49 -0400 Received: by interlock.ans.net id AA21113 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 16:51:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Jun 1994 16:51:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Jun 1994 16:51:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 16:51:31 -0400 Date: Wed, 22 Jun 94 13:19:09 From: "Housley, Russ" Encoding: 3090 Text Message-Id: <9405227723.AA772316349@uu0892.spyrus.com> To: ipsec@ans.net Subject: Fwd: Security architectures, anyone? Subject: Security architectures, anyone? Author: shirey@mitre.org (Robert W. Shirey) at internet Date: 6/22/94 12:01 PM PLEASE FORWARD THIS MESSAGE TO OTHER LISTS THAT CONCERN WITH NETWORK AND INFORMATION SYSTEM ARCHITECTURE AND SECURITY TOPICS. The Privacy and Security Research Group (PSRG) of the Internet Research Task Force (IRTF) is drafting an Internet Security Architecture in cooperation with the Internet Engineering Task Force (IETF) and other contributors in the Internet community. This Architecture is intended to be a guide, openly available as an RFC, for designing and implementing protocols for use in the Internet. The *Internet* is the system of interconnected computer networks that share the protocol suite and the name and address spaces that are specified by the Internet Architecture Board (IAB) of the Internet Society [RFC1600, RFC1340]. The suite is named *the Internet Protocol Suite* (IPS). In this context, *security architecture* means a plan and set of principles for establishing and maintaining features and mechanisms that protect against interruption and loss to packet-switched network elements, the communication services they provide, and the data they contain and carry. The document is intended primarily for people who design and standardize Internet protocols. Protocol designers can use this document as a guide for selecting and incorporating security features. We further envision that the Internet Engineering Steering Group (IESG) will use the principles stated herein to evaluate and guide the development of new Internet standards in the IETF [RFC1602, RFC1603]. It has been suggested that the term "Architecture" can be very confusing and have many meanings, that there is no methodology or consistent manner in which security architectures are developed. It has been further suggested that a second document is needed to aid system security engineers in the development of system security architectures. To do this, system architectures must first be discussed generally, with or without security, including both end systems and the networks that connect them. As grist for this mill, we are looking to collect: 1. Definitions of "architecture", "system architecture", "information system architecture", "security architecture", etc. 2. Books (particularly textbooks), articles, or other descriptions of the content of architectures, methods for defining and developing them, etc. 3. Taxonomies for system architectures the different kinds of views they can take: abstract vs. concrete, near-term vs. far-term, etc. 4. Examples: publications that claim to present a generic system architecture or a system security architecture. Please send the information to me at one of the addresses shown below. Regards, -Rob- Robert W. Shirey SHIREY@MITRE.ORG tel 703.883.7210, sec 703.883.5749, fax 703.883.1397 Info. Security Div., The MITRE Corp., Mail Stop Z231 7525 Colshire Drive, McLean, Virginia 22102-3481 USA From ipsec-request@ans.net Wed Jun 22 20:46:24 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13340 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 17:00:52 -0400 Received: by interlock.ans.net id AA14178 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 16:50:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 16:50:53 -0400 Message-Id: <199406222050.AA18782@interlock.ans.net> To: Theodore Ts'o Cc: ipsec@ans.net, kent@BBN.COM Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Wed, 22 Jun 94 16:07:53 -0400. <9406222007.AA22023@tsx-11.MIT.EDU> Date: Wed, 22 Jun 94 16:46:24 -0400 From: Steve Kent Ted, If you pass a pointer to the IPSP header to a crypto module, then that module must be able to look through the IPSP header to locate the beginning of the encrypted data, at the least. If you want to make use of the "sequence number as IV hack," then the crypto module has to locate the sequence number and the beginning of the encrypted data. Both of these are examples of what I meant by parsing the IPSP header. That's in contrast to passing a pointer to the beginning of the encrypted data to the crypto module, and letting it be independent of the IPSP header format. I agree that you can add a layer of indirection to this processing to handle the IPSP header parsing between the mainline IPSP routine and the crypto module, but that does strike me as not so clean. Perhaps another way to look at this is to note that using a sequence number as IV may require the sequence number to be much larger than otherwise would be required. Does this mean that an IPSP implementation must be able to do arithmetic on this large field, or do we send a more reasonable size sequence number and zero fill it on the left to make the requisite IV size, or what? I'm just not convinced that this "dual use" approach to sequence numbers is a good idea. Steve From ipsec-request@ans.net Wed Jun 22 17:00:56 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14888 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 17:00:56 -0400 Received: by interlock.ans.net id AA04749 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 16:52:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Jun 1994 16:52:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Jun 1994 16:52:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 16:52:14 -0400 Date: Wed, 22 Jun 94 13:19:11 From: "Housley, Russ" Encoding: 952 Text Message-Id: <9405227723.AA772316351@uu0892.spyrus.com> To: kent@BBN.COM, tytso@ATHENA.MIT.EDU (Theodore Ts'o) Cc: perry@imsi.com, ipsec@ans.net Subject: Re[2]: Granularity of authentication in swIPe Ted: You said: It depends on how you look at it. If IPSP always passes a pointer of the header structure to the crypto software along with the ciphertext portion of the packet, the IPSP layer need not "know" anything about what, if anything, some particular crypto layer might use from the header portion of the packet. It does has the downside of making it harder to reuse that interface crypto layer for some other non-IPSP layer on top --- but I'm not convinced that that level of modularity is really all that worthwhile. Boy, do I disagree. Most cryptographic libraries do not include parsers for protocol headers. Rather, the protocol engine parses the header, and then it call on the cryptographic library to encrypt, decrypt, etc. I just do not see cryptography as a "layer." Rather, I see a security protocol as a "layer" that uses cryptographic modules. Russ From ipsec-request@ans.net Wed Jun 22 20:51:16 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13970 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 17:10:11 -0400 Received: by interlock.ans.net id AA04639 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 17:01:33 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 17:01:33 -0400 Message-Id: <199406222101.AA57627@interlock.ans.net> To: Theodore Ts'o Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Wed, 22 Jun 94 16:07:53 -0400. <9406222007.AA22023@tsx-11.MIT.EDU> Date: Wed, 22 Jun 94 16:51:16 -0400 From: Steve Kent Ted, I misread your message. I see that you suggested that IPSP parse the header and pass a data structure to the crypto module with the parsed components, from which the crypto module can then select what ever it needs. That makes my comments on the burden of parsing not quite correct. As you observed, it just means that the crypto module can't be a generic one, but rather a layer of indirection is needed if an underlying generic crypto module is employed. That observation is consistent with the comments I made. Steve From ipsec-request@ans.net Wed Jun 22 20:58:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14995 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 17:10:11 -0400 Received: by interlock.ans.net id AA14118 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 17:01:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 17:01:52 -0400 Message-Id: <199406222101.AA57634@interlock.ans.net> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Wed, 22 Jun 94 16:47:32 -0400. <9406222047.AA03677@snark.imsi.com> Date: Wed, 22 Jun 94 16:58:10 -0400 From: Steve Kent Perry, TCP/IP doesn't have the diversity of options envisioned for IPSP. You don't get to negotiate the TCP checksum or the sequence numer size for example. We have a negotiation for encryption and integrity algorithms, sequence numbers (and their size?), and all this after we have performed an as-yet-unspecified key management protocol. In comparison, TCP is pretty well fixed and thus subject to quite a bit of optimization. IP is more variable because of IP options, but many implementations do an extremely poor job of dealing with IP options, some to the point of crashing! Steve From ipsec-request@ans.net Wed Jun 22 22:51:03 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15653 (5.65c/IDA-1.4.4 for ); Wed, 22 Jun 1994 19:03:12 -0400 Received: by interlock.ans.net id AA19530 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 22 Jun 1994 18:51:18 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 22 Jun 1994 18:51:18 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 22 Jun 1994 18:51:18 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 22 Jun 1994 18:51:18 -0400 Date: Wed, 22 Jun 1994 15:51:03 -0700 From: Hilarie Orman Message-Id: <199406222251.PAA12088@baskerville.CS.Arizona.EDU> To: housley@spyrus.com Cc: tytso@ATHENA.MIT.EDU, kent@BBN.COM, ipsec@ans.net, perry@imsi.com In-Reply-To: Your message <9405227723.AA772316351@uu0892.spyrus.com> Subject: Re: Re[2]: Granularity of authentication in swIPe Work that we are doing here uses crypto protocol layers. Each algorithm is wrapped in a protocol structure with optional hooks for parsing headers and doing key lookups, etc. These layers can be combined into protocol graphs that provide complex services, such as Kerberos or IPSP with DH key management. The basic protocols come in a small set of "shapes", and new algorithms can be added as protocol layers with little difficulty. Hilarie Orman From ipsec-request@ans.net Thu Jun 23 15:08:13 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AB01677 (5.65c/IDA-1.4.4 for ); Thu, 23 Jun 1994 15:08:13 -0400 Received: by interlock.ans.net id AA32931 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Jun 1994 14:55:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 23 Jun 1994 14:55:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Jun 1994 14:55:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Jun 1994 14:55:26 -0400 Date: Thu, 23 Jun 94 11:26:17 From: "Housley, Russ" Encoding: 616 Text Message-Id: <9405237723.AA772395977@uu0892.spyrus.com> To: Phil Karn Cc: ipsec@ans.net Subject: Re[2]: Granularity of authentication in swIPe Phil: I see you contradicting yourself. Perhaps I am misunderstanding you. On one hand, you say that you want to keep the SAID small. You suggest 16 bits. On the other hand, you want add sequence numbers for a faciltiy which you claim is not "bulletproof." Also, I think that the SAID structure must support IP broadcast and IP multicast. For this reason, I want a larger SAID (say, 32 bits for compatabiltiy with the IEEE 802.10 Secure Data Exchange and Key Management Protocol). Management of broadcast and multicast keys within the Internet will require a large pool of SAIDs. Russ From ipsec-request@ans.net Thu Jun 23 20:14:35 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15865 (5.65c/IDA-1.4.4 for ); Thu, 23 Jun 1994 16:29:05 -0400 Received: by interlock.ans.net id AA13198 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Jun 1994 16:14:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 23 Jun 1994 16:14:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 23 Jun 1994 16:14:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Jun 1994 16:14:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Jun 1994 16:14:57 -0400 Message-Id: <9406232014.AA05265@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: Re[2]: Granularity of authentication in swIPe In-Reply-To: Your message of "Thu, 23 Jun 1994 11:26:17." <9405237723.AA772395977@uu0892.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 23 Jun 1994 16:14:35 -0400 From: "Perry E. Metzger" "Housley, Russ" says: > I see you contradicting yourself. Perhaps I am misunderstanding you. > > On one hand, you say that you want to keep the SAID small. You suggest 16 > bits. On the other hand, you want add sequence numbers for a faciltiy > which you claim is not "bulletproof." Why is this a contradiction? I don't understand. Could you explain your point at more length? > Also, I think that the SAID structure must support IP broadcast and IP > multicast. For this reason, I want a larger SAID (say, 32 bits for > compatabiltiy with the IEEE 802.10 Secure Data Exchange and Key Management > Protocol). Management of broadcast and multicast keys within the Internet > will require a large pool of SAIDs. I'm not sure that this is a problem. swIPe policies are associated with address pairs, and broadcast addresses and multicast addresses are parts of address pairs just as normal ones are. I doubt that a given single host might have more than 64000 simultaneous keys in use with a given multicast or broadcast address. I think that Steve Kent's argument that a pair of tunnel hosts might want to allocate a policy for each underlying encapsulated policy is a big stronger than this rationale for larger policy identifier fields. Perry BTW, is "spyrus.com" the same Spyrus that makes the SCSI based reader for Tessera cards? From ipsec-request@ans.net Thu Jun 23 21:31:59 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01761 (5.65c/IDA-1.4.4 for ); Thu, 23 Jun 1994 17:40:29 -0400 Received: by interlock.ans.net id AA42157 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Jun 1994 17:32:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Jun 1994 17:32:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Jun 1994 17:32:24 -0400 Date: Thu, 23 Jun 1994 14:31:59 -0700 From: Phil Karn Message-Id: <199406232131.OAA16499@servo.qualcomm.com> To: jfjr@mbunix.mitre.org Cc: ipsec@ans.net In-Reply-To: <199406221353.JAA02898@mbunix.mitre.org> (jfjr@mbunix.mitre.org) Subject: Re: swIPe comments > We have modified our swIPe implementation slightly by adding host >filtering. Once swIPe is turned on - the ifconfigs and ioctls have >been issued - any packets from a designated swIPed partner that are >not swIPed are rejected. This is a few lines of code, mainly in ip_input. What happens if the remote peer crashes and loses its swIPe state? How can you reestablish the security association if you block all non-swIPed packets? I've been giving this particular problem a LOT of thought. Your protocol can allow for crashed hosts, but it's easy to leave yourself open to simple denial-of-service attacks if you're not careful. BTW, by a "simple" denial of service attack I mean the class of attacks that could be mounted by anyone anywhere on the Internet by using false IP source addresses WITHOUT subverting Internet routing or having physical access to some particular Internet path (e.g., between two legitimate security peers). Although everyone knows that it's impossible to preclude ALL denial of service attacks on the Internet, the "simple" class is *so* easy to do that I think any protocol we design ought to take them into account. Phil From ipsec-request@ans.net Thu Jun 23 21:39:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14958 (5.65c/IDA-1.4.4 for ); Thu, 23 Jun 1994 17:50:51 -0400 Received: by interlock.ans.net id AA44020 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Jun 1994 17:39:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Jun 1994 17:39:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Jun 1994 17:39:03 -0400 Date: Thu, 23 Jun 1994 14:39:01 -0700 From: Phil Karn Message-Id: <199406232139.OAA16505@servo.qualcomm.com> To: kent@BBN.COM Cc: perry@imsi.com, ipsec@ans.net In-Reply-To: <199406221358.AA19309@interlock.ans.net> (message from Steve Kent on Wed, 22 Jun 94 09:56:57 -0400) Subject: Re: Granularity of authentication in swIPe > I think the best approach is to let sequence numbers be >sequence numbers, and not try to load other requirements on them. As >you observed, different encryption algorithms and modes of use have >different requirements for IVs and IPSP should be algorithm independent. Steve, I think there may be some confusion about the meaning of an "IV". Part of my problem is not knowing exactly how they work in Skipjack implementations. But isn't it true that Skipjack itself is a 64-bit block cipher just like DES for which all the usual DES modes of operation are usable, including CBC? Seems to me that if I were so stupid as to actually want to use Skipjack for IP packet encryption, I could program the chip to operate in ECB mode and do my own cipher block chaining in software. In this case the IPSEC sequence field automatically acts as an IV. Now if my understanding is correct that it takes 50ms to initialize the IV in a Capstone chip just so I can have it do CBC in hardware, then I couldn't handle more than 20 packets per second, which is pretty abysmal. Phil From ipsec-request@ans.net Thu Jun 23 22:53:18 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07824 (5.65c/IDA-1.4.4 for ); Thu, 23 Jun 1994 19:13:00 -0400 Received: by interlock.ans.net id AA27969 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Jun 1994 19:02:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Jun 1994 19:02:54 -0400 Message-Id: <199406232302.AA16189@interlock.ans.net> To: Phil Karn Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Thu, 23 Jun 94 14:39:01 -0700. <199406232139.OAA16505@servo.qualcomm.com> Date: Thu, 23 Jun 94 18:53:18 -0400 From: Steve Kent Phil, I don't want to posit the need for random IVs solely on a need to support SKIPJACK and the LEAF; they merely provide an example of a cryptosystem where the IV function could not be satisfied by a sequence number. However, to address your specific question, Matt Blaze pointed out that one could use SKIPJACK on the Tessera card in ECB mode, where an IV is not really needed, and externally perform the operations to implement CBC mode. In that context, one could use a sequence number as an IV. As for performance, the current Tessera cards are best viewed as prototypes and the production versions will probably show better performance due to improvements in card firmware and driver software, a natural result of experience. Thus, in the long run, I would expect performance to be better for CBC mode implememented on the card, vs. an externally implemented version. Steve From ipsec-request@ans.net Thu Jun 23 23:56:17 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07790 (5.65c/IDA-1.4.4 for ); Thu, 23 Jun 1994 20:01:50 -0400 Received: by interlock.ans.net id AA21962 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Jun 1994 19:54:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Jun 1994 19:54:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Jun 1994 19:54:13 -0400 Message-Id: <199406232353.AA28428@vax.darpa.mil> X-Sender: stjohns@vax.darpa.mil Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jun 1994 19:56:17 -0400 To: Steve Kent , Phil Karn From: stjohns@ARPA.MIL (Michael StJohns) Subject: Re: Granularity of authentication in swIPe Cc: ipsec@ans.net At 18:53 6/23/94 -0400, Steve Kent wrote: >Phil, > > I don't want to posit the need for random IVs solely on a need >to support SKIPJACK and the LEAF; they merely provide an example of a >cryptosystem where the IV function could not be satisfied by a >sequence number. However, to address your specific question, Matt >Blaze pointed out that one could use SKIPJACK on the Tessera card in >ECB mode, where an IV is not really needed, and externally perform the >operations to implement CBC mode. In that context, one could use a >sequence number as an IV. As for performance, the current Tessera >cards are best viewed as prototypes and the production versions will >probably show better performance due to improvements in card firmware >and driver software, a natural result of experience. Thus, in the >long run, I would expect performance to be better for CBC mode >implememented on the card, vs. an externally implemented version. > >Steve Steve - correct me if I'm wrong, but won't the TESSERA cards refuse to encrypt anything without the exchange of an IV containing a valid LEAF? Or is ECB an exception? Thanks - Mike From ipsec-request@ans.net Thu Jun 23 16:35:47 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04343 (5.65c/IDA-1.4.4 for ); Thu, 23 Jun 1994 20:44:45 -0400 Received: by interlock.ans.net id AA23600 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Jun 1994 20:36:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Jun 1994 20:36:46 -0400 Message-Id: <199406240036.AA28972@interlock.ans.net> From: smb@research.att.com Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Jun 1994 20:36:46 -0400 To: stjohns@ARPA.MIL (Michael StJohns) Cc: Steve Kent , Phil Karn , ipsec@ans.net Subject: Re: Granularity of authentication in swIPe Date: Thu, 23 Jun 94 20:35:47 EDT Steve - correct me if I'm wrong, but won't the TESSERA cards refuse to encrypt anything without the exchange of an IV containing a valid LEAF? Or is ECB an exception? ECB is indeed an exception. But with the prototype card, it's slow, about 40 ms. And I doubt they have much incentive to speed that part up... From ipsec-request@ans.net Thu Jun 23 10:43:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13315 (5.65c/IDA-1.4.4 for ); Thu, 23 Jun 1994 20:50:21 -0400 Received: by interlock.ans.net id AA39025 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 23 Jun 1994 20:43:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 23 Jun 1994 20:43:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 23 Jun 1994 20:43:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Jun 1994 20:43:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Jun 1994 20:43:03 -0400 Date: Thu, 23 Jun 94 17:43:43 PDT From: ashar@miraj.firstperson.com (Ashar Aziz) Message-Id: <9406240043.AA21052@miraj.Eng.Sun.COM> To: kent@BBN.COM, karn@qualcomm.com Subject: Re: Granularity of authentication in swIPe Cc: perry@imsi.com, ipsec@ans.net >From: Phil Karn >From ipsec-request@ans.net Thu Jun 23 14:53:41 1994 >Seems to me that if I were so stupid as to actually want to use >Skipjack for IP packet encryption, I could program the chip to operate >in ECB mode and do my own cipher block chaining in software. In this case >the IPSEC sequence field automatically acts as an IV. > >Now if my understanding is correct that it takes 50ms to initialize >the IV in a Capstone chip just so I can have it do CBC in hardware, >then I couldn't handle more than 20 packets per second, which is >pretty abysmal. Is there any reason why one couldn't perfom CBC across packets, by using the last block-size bits of the last encrypted packet as the "IV" for the next? Instead of generating a new pseudo-random IV for every packet? This way, if packets came in sequence, there would be no need to re-load the IV into the crypto hardware. Only if packets came out of sequence would this need to be done. Assuming, of course, that the crypto hardware allows this sort of streaming of input data; namely load (key, iv), decrypt pkt, decrypt pkt, etc. Ashar. From ipsec-request@ans.net Fri Jun 24 12:18:16 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06359 (5.65c/IDA-1.4.4 for ); Fri, 24 Jun 1994 08:27:00 -0400 Received: by interlock.ans.net id AA04740 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Jun 1994 08:18:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Jun 1994 08:18:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Jun 1994 08:18:24 -0400 Date: Fri, 24 Jun 1994 08:18:16 -0400 From: jfjr@mbunix.mitre.org (Freedman) Message-Id: <199406241218.IAA27602@mbunix.mitre.org> Posted-From: The MITRE Corporation, Bedford, MA To: karn@qualcomm.com Cc: ipsec@ans.net In-Reply-To: Phil Karn's message of Thu, 23 Jun 1994 14:31:59 -0700 <199406232131.OAA16499@servo.qualcomm.com> Subject: swIPe comments >> We have modified our swIPe implementation slightly by adding host >>filtering. Once swIPe is turned on - the ifconfigs and ioctls have >>been issued - any packets from a designated swIPed partner that are >>not swIPed are rejected. This is a few lines of code, mainly in ip_input. >What happens if the remote peer crashes and loses its swIPe state? How >can you reestablish the security association if you block all non-swIPed >packets? In our version, when the crashed peer comes up and tries to communicate with the uncrashed swIPe partner, it notices that it doesn't have keys and begins a key negotion process which is done over IPIP (swIPe). From ipsec-request@ans.net Fri Jun 24 10:19:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11944 (5.65c/IDA-1.4.4 for ); Fri, 24 Jun 1994 10:19:28 -0400 Received: by interlock.ans.net id AA28889 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Jun 1994 10:10:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Jun 1994 10:10:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Jun 1994 10:10:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Jun 1994 10:10:07 -0400 Date: Fri, 24 Jun 94 06:43:54 From: "Housley, Russ" Encoding: 1537 Text Message-Id: <9405247724.AA772465434@uu0892.spyrus.com> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re[4]: Granularity of authentication in swIPe Perry: In a previous messag, I said: > I see you contradicting yourself. Perhaps I am misunderstanding you. > > On one hand, you say that you want to keep the SAID small. You suggest 16 > bits. On the other hand, you want add sequence numbers for a faciltiy > which you claim is not "bulletproof." And, you asked me to expand on my question. I'll try. On one hand, Phil argues for minimal overhead. Then, on the other hand, Phil argues that the overhead associated with sequence numbers is acceptable even though the mechanism provided is not "bulletproof." I think that the group has come to concensus that the IV cannot double as a sequence number in all cases. Thus, if we are going to support sequence numbers as a mechanism, the IPSP must allow both the sequence number and an IV. So, is Phil advocating a security protocol with minimum overhead or a security protocol with lots of features and more overhead. Perhaps he wants a middle ground solution where a mimimum overhead core feature set is supplemented by optional, higher overhead features. If the middle ground solution is being proposed, I missed it. Russ P.S. You also asked: > BTW, is "spyrus.com" the same Spyrus that makes the SCSI based > reader for Tessera cards? Yes. We make a SCSI PCMCIA Card Adapter. It is often used with TESSERA, but it can be used with any PCMCIA card. We also make other security products, including a PCMCIA Crypto Card that does DES, RC4, RSA, D-H, MD2 and MD5. From ipsec-request@ans.net Fri Jun 24 20:08:13 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07577 (5.65c/IDA-1.4.4 for ); Fri, 24 Jun 1994 15:54:15 -0400 Received: by interlock.ans.net id AA04629 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Jun 1994 15:38:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Jun 1994 15:38:47 -0400 Return-Path: shirey@mitre.org Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Jun 1994 15:38:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Jun 1994 15:38:47 -0400 Message-Id: <9406241909.AA10686@smiley.mitre.org.sit> X-Sender: shirey@smiley.mitre.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Jun 1994 15:08:13 -0500 To: Phil Karn From: shirey@mitre.org (Robert W. Shirey) Subject: Re: swIPe comments Cc: ipsec@ans.net, jfjr@mbunix.mitre.org, saag@tis.com, psrg@tis.com Phil (and everyone else), It would be nice to see a (initially simple) taxonomy of denial-of-service attacks -- beginning with your definition of "simple", and going on to ?? -- for inclusion in the draft Internet Security Architecture and to otherwise organize security discussions in the IETF, etc. The classifications should be, like Phil's definition below, in terms of Internet (infrastructure) resources needed by (and/or affected by) the attack. Any contributions gratefully accepted. -Rob- At 2:31 PM 6/23/94 -0700, Phil Karn wrote: >> We have modified our swIPe implementation slightly by adding host >>filtering. Once swIPe is turned on - the ifconfigs and ioctls have >>been issued - any packets from a designated swIPed partner that are >>not swIPed are rejected. This is a few lines of code, mainly in ip_input. > >What happens if the remote peer crashes and loses its swIPe state? How >can you reestablish the security association if you block all non-swIPed >packets? > >I've been giving this particular problem a LOT of thought. Your >protocol can allow for crashed hosts, but it's easy to leave yourself >open to simple denial-of-service attacks if you're not careful. > >BTW, by a "simple" denial of service attack I mean the class of >attacks that could be mounted by anyone anywhere on the Internet by >using false IP source addresses WITHOUT subverting Internet routing or >having physical access to some particular Internet path (e.g., between >two legitimate security peers). > >Although everyone knows that it's impossible to preclude ALL denial of >service attacks on the Internet, the "simple" class is *so* easy to do >that I think any protocol we design ought to take them into account. > >Phil From ipsec-request@ans.net Fri Jun 24 22:37:33 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13968 (5.65c/IDA-1.4.4 for ); Fri, 24 Jun 1994 18:56:02 -0400 Received: by interlock.ans.net id AA41012 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Jun 1994 18:45:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Jun 1994 18:45:23 -0400 Message-Id: <199406242245.AA09520@interlock.ans.net> To: Michael StJohns Cc: ipsec@ans.net, kent@BBN.COM Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Thu, 23 Jun 94 19:56:17 -0400. <199406232353.AA28428@vax.darpa.mil> Date: Fri, 24 Jun 94 18:37:33 -0400 From: Steve Kent Mike, Matt Blaze's paper showed how to circumvent the need to transmit a LEAF for ECB mode, taking advantage of the fact that this mode doesn't need an IV in the first place. So, while "normal" use of the Tessera card for decryption would require receipt of a LEAF from the other communicating party, one can circumvent that procedure. Steve From ipsec-request@ans.net Fri Jun 24 22:41:15 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15762 (5.65c/IDA-1.4.4 for ); Fri, 24 Jun 1994 18:56:03 -0400 Received: by interlock.ans.net id AA23610 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Jun 1994 18:45:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Jun 1994 18:45:26 -0400 Message-Id: <199406242245.AA12342@interlock.ans.net> To: Ashar Aziz Cc: ipsec@ans.net Subject: Re: Granularity of authentication in swIPe In-Reply-To: Your message of Thu, 23 Jun 94 17:43:43 -0700. <9406240043.AA21052@miraj.Eng.Sun.COM> Date: Fri, 24 Jun 94 18:41:15 -0400 From: Steve Kent Ashar, The ability to use the last block as an IV varies depending on the crypto interface. Some implementations allow it, others don't. You don't want to hold up a packet waiting for the requisite precursors to arrive, since that would violate IP and would kill applications like packet voice and video. So, if you don't carry an IV on each packet, you run the risk that out of order arrival and/or packet loss will cause problems. Steve From ipsec-request@ans.net Fri Jun 24 22:45:16 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07072 (5.65c/IDA-1.4.4 for ); Fri, 24 Jun 1994 18:56:55 -0400 Received: by interlock.ans.net id AA15425 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Jun 1994 18:45:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Jun 1994 18:45:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Jun 1994 18:45:52 -0400 Date: Fri, 24 Jun 1994 15:45:16 -0700 From: Phil Karn Message-Id: <199406242245.PAA26055@servo.qualcomm.com> To: shirey@mitre.org Cc: ipsec@ans.net, jfjr@mbunix.mitre.org, saag@tis.com, psrg@tis.com In-Reply-To: <9406241909.AA10686@smiley.mitre.org.sit> (shirey@mitre.org) Subject: Re: swIPe comments Sounds like a worthy project to me. I can probably come up with the scenarios, but I'm not particularly good at naming them. Phil From ipsec-request@ans.net Fri Jun 24 22:59:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14130 (5.65c/IDA-1.4.4 for ); Fri, 24 Jun 1994 19:08:13 -0400 Received: by interlock.ans.net id AA47816 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Jun 1994 18:58:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Jun 1994 18:58:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Jun 1994 18:58:54 -0400 Date: Fri, 24 Jun 1994 15:59:01 -0700 From: Phil Karn Message-Id: <199406242259.PAA26113@servo.qualcomm.com> To: housley@spyrus.com Cc: ipsec@ans.net In-Reply-To: <9405237723.AA772395977@uu0892.spyrus.com> (housley@spyrus.com) Subject: Re: Re[2]: Granularity of authentication in swIPe >On one hand, you say that you want to keep the SAID small. You suggest 16 >bits. On the other hand, you want add sequence numbers for a faciltiy >which you claim is not "bulletproof." The SAID is an especially sensitive issue with me since it has to be in every packet. On the other hand, the use of sequence numbers could be negotiated on a per-SAID basis, which makes them less objectionable -- you can turn them off if you want. My sequence numbers are currently only 16 bits. The idea is that you'd probably rekey before this wraps around (assuming a dynamic key management protocol). I am not trying to solve every conceivable problem with IPSP. That's how things like OSI come about. The Internet approach has always been to try first to solve 95% of the problems with only 5% of the effort. Then after we get some real world experience we can decide if the remaining 5% are worth solving, or whether they are even real or not. Phil From ipsec-request@ans.net Sat Jun 25 00:04:12 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07584 (5.65c/IDA-1.4.4 for ); Fri, 24 Jun 1994 20:18:33 -0400 Received: by interlock.ans.net id AA07346 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Jun 1994 20:04:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Jun 1994 20:04:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Jun 1994 20:04:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Jun 1994 20:04:28 -0400 Date: Fri, 24 Jun 1994 17:04:12 -0700 From: Hilarie Orman Message-Id: <199406250004.RAA00822@baskerville.CS.Arizona.EDU> To: karn@qualcomm.com Cc: ipsec@ans.net In-Reply-To: Your message <199406242259.PAA26113@servo.qualcomm.com> Subject: Re: Re[2]: Granularity of authentication in swIPe One can easily send 16K packets in about the same amount of time that rekeying takes with Diffie-Hellman. Is this a desirable balance? From ipsec-request@ans.net Fri Jun 24 10:25:09 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15380 (5.65c/IDA-1.4.4 for ); Fri, 24 Jun 1994 20:33:33 -0400 Received: by interlock.ans.net id AA07285 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Jun 1994 20:24:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 24 Jun 1994 20:24:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Jun 1994 20:24:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Jun 1994 20:24:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Jun 1994 20:24:20 -0400 Date: Fri, 24 Jun 94 17:25:09 PDT From: ashar@miraj.firstperson.com (Ashar Aziz) Message-Id: <9406250025.AA00774@miraj.Eng.Sun.COM> To: ashar@miraj.firstperson.com, kent@BBN.COM Subject: Re: Granularity of authentication in swIPe Cc: ipsec@ans.net >From kent@BBN.COM Fri Jun 24 15:46:51 1994 >Ashar, > > The ability to use the last block as an IV varies depending on >the crypto interface. Some implementations allow it, others don't. >You don't want to hold up a packet waiting for the requisite >precursors to arrive, since that would violate IP and would kill >applications like packet voice and video. I didn't intend the decrypt routines to ever wait for pre-requisite packets to arrive. >So, if you don't carry >an IV on each packet, you run the risk that out of order arrival >and/or packet loss will cause problems. What I meant was that the last block would be in the "IV" field and carried in every subsequent packet after the first one (until rekey time anyway). If the packets arrived in sequence (and the crypto hw supported streaming of data) there would be no need to reload the IV. This would be the fast path and, assuming orderly delivery, be the common case as well. If not, then you are no worse than sending a new IV in every packet. If packets are lost or out of order, simply load the last block (carried in the IV field) as the new "IV" for the packet. This is what you have to do with a new IV in every packet approach anyway. Given how CBC works, the packet should decrypt properly, no? There is enough information ine every packet to have it be decryptable independently, since CBC doesn't keep more state than the last block. Am I missing something? Ashar. From ipsec-request@ans.net Sat Jun 25 00:20:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04124 (5.65c/IDA-1.4.4 for ); Fri, 24 Jun 1994 20:33:54 -0400 Received: by interlock.ans.net id AA13137 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Jun 1994 20:20:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Jun 1994 20:20:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Jun 1994 20:20:16 -0400 Date: Fri, 24 Jun 1994 17:20:10 -0700 From: Phil Karn Message-Id: <199406250020.RAA26333@servo.qualcomm.com> To: housley@spyrus.com Cc: ipsec@ans.net In-Reply-To: <9405237723.AA772395977@uu0892.spyrus.com> (housley@spyrus.com) Subject: Re: Re[2]: Granularity of authentication in swIPe >Also, I think that the SAID structure must support IP broadcast and IP >multicast. For this reason, I want a larger SAID (say, 32 bits for >compatabiltiy with the IEEE 802.10 Secure Data Exchange and Key Management >Protocol). Management of broadcast and multicast keys within the Internet >will require a large pool of SAIDs. As I think Perry already said, SAIDs logically include the IP addresses. They're just like TCP sockets - each connection is uniquely identified by the concatentation of the IP addresses and port numbers, which means you need many fewer port numbers than you otherwise would if everything was identified solely by port number. As an aside I just don't see any easy way to support multicast in IPSP that doesn't require a public key operation for each packet. Much of the utility of IPSP comes from setting up a session key using a fairly expensive key exchange protocol that is run only once for some fairly large number of packets. But I don't see any easy way to do this for multicast. I can see putting in hooks for multicast, but it's hard to see how they could be really useful given the current costs of even a public RSA operation. Phil From ipsec-request@ans.net Sat Jun 25 00:49:57 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15469 (5.65c/IDA-1.4.4 for ); Fri, 24 Jun 1994 20:57:21 -0400 Received: by interlock.ans.net id AA52005 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Jun 1994 20:49:59 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Jun 1994 20:49:59 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Jun 1994 20:49:59 -0400 Date: Fri, 24 Jun 1994 17:49:57 -0700 From: Phil Karn Message-Id: <199406250049.RAA26404@servo.qualcomm.com> To: ho@cs.arizona.edu Cc: ipsec@ans.net In-Reply-To: <199406250004.RAA00822@baskerville.CS.Arizona.EDU> (message from Hilarie Orman on Fri, 24 Jun 1994 17:04:12 -0700) Subject: Re: Re[2]: Granularity of authentication in swIPe >One can easily send 16K packets in about the same amount of time that >rekeying takes with Diffie-Hellman. Is this a desirable balance? Uh, doesn't this kind of figure depend on the particular ratio of link speed to CPU speed? Phil From ipsec-request@ans.net Sat Jun 25 03:14:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05106 (5.65c/IDA-1.4.4 for ); Fri, 24 Jun 1994 23:24:32 -0400 Received: by interlock.ans.net id AA08801 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 24 Jun 1994 23:15:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 24 Jun 1994 23:15:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 24 Jun 1994 23:15:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 24 Jun 1994 23:15:03 -0400 Date: Fri, 24 Jun 1994 20:14:53 -0700 From: Hilarie Orman Message-Id: <199406250314.UAA08973@baskerville.CS.Arizona.EDU> To: karn@qualcomm.com Cc: ipsec@ans.net In-Reply-To: Your message <199406250049.RAA26404@servo.qualcomm.com> Subject: Re: Re[2]: Granularity of authentication in swIPe >>One can easily send 16K packets in about the same amount of time that >>rekeying takes with Diffie-Hellman. Is this a desirable balance? > Uh, doesn't this kind of figure depend on the particular ratio of link > speed to CPU speed? Of course. Scanning back through this discussion I see that Steve Kent has already mentioned that the sequence number field should be larger or the size negotiable. Occam's protocols don't negotiate or have options. It would seem desirable to eliminate the the sequence number or make it a fixed (large) size. Anticipating the continued increases in both network and processor speeds has to be part of the process if it is to satisfy 95% of the needs by the time the standard is finished. From ipsec-request@ans.net Mon Jun 27 14:06:45 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA11804 (5.65c/IDA-1.4.4 for ); Mon, 27 Jun 1994 10:26:19 -0400 Received: by interlock.ans.net id AA51990 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Jun 1994 10:10:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Jun 1994 10:10:53 -0400 Message-Id: <199406271410.AA29714@interlock.ans.net> To: Phil Karn Cc: ipsec@ans.net Subject: Re: Re[2]: Granularity of authentication in swIPe In-Reply-To: Your message of Fri, 24 Jun 94 17:20:10 -0700. <199406250020.RAA26333@servo.qualcomm.com> Date: Mon, 27 Jun 94 10:06:45 -0400 From: Steve Kent Phil, I realize that the swIPe model calls for the ultimate source and destination addresses to be part of the SAID, but that is not the general model for SAIDs. By including the S/D address in the SAID, one imposes some limitations on policies for key menagement granularity. That's why I have not assumed any use of addresses in conjunction with the SAID, as additional qualifiers. Steve From ipsec-request@ans.net Mon Jun 27 07:57:35 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06187 (5.65c/IDA-1.4.4 for ); Mon, 27 Jun 1994 12:16:06 -0400 Received: by interlock.ans.net id AA41177 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 27 Jun 1994 11:56:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 27 Jun 1994 11:56:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Jun 1994 11:56:39 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Jun 1994 11:56:39 -0400 Date: Mon, 27 Jun 94 11:57:35 EDT From: wcb@cert.org Message-Id: <9406271557.AA10657@sphynx.cert.org> To: karn@qualcomm.com, shirey@mitre.org Subject: Re: swIPe comments Cc: ipsec@ans.net, jfjr@mbunix.mitre.org, saag@tis.com, psrg@tis.com > Phil (and everyone else), > > It would be nice to see a (initially simple) taxonomy of denial-of-service > attacks -- beginning with your definition of "simple", and going on to ?? > -- for inclusion in the draft Internet Security Architecture and to > otherwise organize security discussions in the IETF, etc. The > classifications should be, like Phil's definition below, in terms of > Internet (infrastructure) resources needed by (and/or affected by) the > attack. > > Any contributions gratefully accepted. > rob, attack strategy taxonomies are extremely difficult and expensive to develop and maintain, at any state of usefulness. they become obsolete very quickly, and as a result i would not recommend including such a taxonomy in a document like the Internet Security Architecture draft. what is the focus of the denial-of-service taxonomy that you are proposing? is it just swIPe, or are you interested in developing a taxonomy for the internet's architecture. carter Carter Bullard CERT Coordination Center Phone (412) 268-6238 Software Engineering Institute 24 hr (412) 268-7090 Carnegie Mellon University Email wcb@cert.org cert@cert.org Pittsburgh, PA 15213-3890 From ipsec-request@ans.net Tue Jun 28 01:48:52 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04265 (5.65c/IDA-1.4.4 for ); Tue, 28 Jun 1994 01:48:52 -0400 Received: by interlock.ans.net id AA10714 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 28 Jun 1994 01:36:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 28 Jun 1994 01:36:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 28 Jun 1994 01:36:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 28 Jun 1994 01:36:45 -0400 Date: Mon, 27 Jun 94 21:42:04 From: "Housley, Russ" Encoding: 1494 Text Message-Id: <9405277727.AA772778524@uu0892.spyrus.com> To: Phil Karn Cc: ipsec@ans.net Subject: Re[4]: Granularity of authentication in swIPe Phil: Thanks for clarifying your position. I think that I understand it. > The SAID is an especially sensitive issue with me since it has to be > in every packet. On the other hand, the use of sequence numbers could > be negotiated on a per-SAID basis, which makes them less objectionable > -- you can turn them off if you want. My concern is that the SAID must be big enough to deal with broadcast and multicast keys in the entire Internet. More and more applications take advantage of multicast, and I expect that trend to continue. While the volume of broadcast and multicast traffic may not catch up to the volume of pairwise traffic, the IPSP must offer protection for it in a straightforward manner. > I am not trying to solve every conceivable problem with IPSP. That's > how things like OSI come about. The Internet approach has always been > to try first to solve 95% of the problems with only 5% of the > effort. Then after we get some real world experience we can decide if > the remaining 5% are worth solving, or whether they are even real or not. I like the Internet engineering methodology, especially the part that require two independent, interoperable implementations before a protocol can be called a standard. I just happen to think that protecting broadcast and multicast traffic is part of the 95% (not part of the 5%). That said, let's argue about protocols and mechanisms, not standards development methodology. Russ From ipsec-request@ans.net Tue Jun 28 01:51:34 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15294 (5.65c/IDA-1.4.4 for ); Tue, 28 Jun 1994 01:51:34 -0400 Received: by interlock.ans.net id AA13280 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 28 Jun 1994 01:36:56 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 28 Jun 1994 01:36:56 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 28 Jun 1994 01:36:56 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 28 Jun 1994 01:36:56 -0400 Date: Mon, 27 Jun 94 21:42:06 From: "Housley, Russ" Encoding: 1578 Text Message-Id: <9405277727.AA772778526@uu0892.spyrus.com> To: Phil Karn Cc: ipsec@ans.net Subject: Re[4]: Granularity of authentication in swIPe Phil: >>Also, I think that the SAID structure must support IP broadcast and IP >>multicast. For this reason, I want a larger SAID (say, 32 bits for >>compatabiltiy with the IEEE 802.10 Secure Data Exchange and Key Management >>Protocol). Management of broadcast and multicast keys within the Internet >>will require a large pool of SAIDs. > >As I think Perry already said, SAIDs logically include the IP >addresses. They're just like TCP sockets - each connection is >uniquely identified by the concatentation of the IP addresses and >port numbers, which means you need many fewer port numbers than you >otherwise would if everything was identified solely by port number. I disagree. In pairwise communications, this might be true, but in multicast it is not true. I see multicast support like this: When an IPSP implementation comes up, it contacts a key server to obtain the SAIDs and keys for the multicast groups for which it is a member. The transfer of keys from the key server to the IPSP implementation could be protected in a pairwise key formed using D-H, or it could be protected in a pairwise key that was manually distributed, or it could be protected in a pairwise key form Kerberos. The key server would be charged with access control to the multicast keys. It would not distribute them to IPSP implementation that were not part of the multicast group. Without the key server for multicast, I agree, you end up doing public key operations on IP datagrams. And, I don't like this solution either. Russ From ipsec-request@ans.net Mon Jun 27 22:22:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13155 (5.65c/IDA-1.4.4 for ); Tue, 28 Jun 1994 18:53:55 -0400 Received: by interlock.ans.net id AA14905 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 28 Jun 1994 18:27:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 28 Jun 1994 18:27:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 28 Jun 1994 18:27:43 -0400 Date: Mon, 27 Jun 1994 22:22:42 +0000 (O) From: NTG@vrit01.eg Subject: *** Help to get Kerberos S/W *** To: ipsec@ans.net Message-Id: <01HE1WUZMOG20000AJ@FRCU.EUN.EG> X-Vms-To: FRCU::IN%"ipsec@ans.net" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Dear sir, I am Eng. Waleed Hosny from Egypt. Currently I prepare for getting the master degree in computers networking. My research point handles the securing of the IP packets, i.e. the security at the network layer for the routed packets. I will try to use the kerberos authentication services in my implementation. Would you please help me by directing me to the location of the Kerberos S/W (For Unix & DOS). I need the name of the site that I can make FTP to get the Kerberos and the directory name. If there is a DOS version it will be better. Thank you in advance for your help. I am waiting for your help Eng. Waleed Hosny NTG@VRIT01.EG NTG@RITSEC.COM.EG ERI@FRCU.EUN.EG 112 Pyrmaids Street - Giza - Egypt 202 383 0728 From ipsec-request@ans.net Wed Jun 29 11:53:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13112 (5.65c/IDA-1.4.4 for ); Wed, 29 Jun 1994 16:12:06 -0400 Received: by interlock.ans.net id AA28837 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 29 Jun 1994 15:56:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 29 Jun 1994 15:56:50 -0400 Message-Id: <199406291956.AA28833@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 29 Jun 1994 15:56:50 -0400 Date: Wed, 29 Jun 94 15:53:01 EDT From: "Mark H. Linehan (8-863-7860)" X-Addr: H3-B16 IBM Research Hawthorne, NY To: ipsec@ans.net Subject: IPSEC Review Paper Reply-To: LINEHAN@watson.ibm.com I've written a paper that describes and compares various proposals for providing security functions at the IP layer. These proposals include SP3 and I-NLSP swIPe the encryption and authentication options of SIPP PIPS The paper is available by anonymous ftp from software.watson.ibm.com in the file pub/tjw.reports/ipsec_review.ps. Comments to this mailing list or to me at linehan@watson.ibm.com. From ipsec-request@ans.net Wed Jun 29 22:12:29 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15041 (5.65c/IDA-1.4.4 for ); Wed, 29 Jun 1994 18:23:43 -0400 Received: by interlock.ans.net id AA38246 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 29 Jun 1994 18:12:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 29 Jun 1994 18:12:35 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 29 Jun 1994 18:12:35 -0400 Message-Id: <199406292212.AA15174@interlock.reston.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 29 Jun 1994 18:12:35 -0400 Date: Wed, 29 Jun 1994 18:12:29 -0400 From: king@reston.ans.net (Greg King) To: ipsec@ans.net, LINEHAN@watson.ibm.com Subject: Re: IPSEC Review Paper Mark, On page 17, you point out that its not clear how the current swIPe implementation handles fragmentation. Its not clear to me that it does. At least on input. Perry? Greg From ipsec-request@ans.net Wed Jun 29 12:07:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04108 (5.65c/IDA-1.4.4 for ); Wed, 29 Jun 1994 22:27:35 -0400 Received: by interlock.ans.net id AA06684 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 29 Jun 1994 22:09:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 29 Jun 1994 22:09:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 29 Jun 1994 22:09:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 29 Jun 1994 22:09:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 29 Jun 1994 22:09:11 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 29 Jun 1994 22:09:11 -0400 Message-Id: <00112.2855761894.21458@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Wed, 29 Jun 1994 19:07:01 MST Subject: IPSEC Toronto Meeting Reply to: IPSEC Toronto Meeting The IPSEC Working Group will be meeting in Toronto. Note below in the draft agenda that we are scheduled for two meeting times. DRAFT Agenda of the Thirtieth IETF - as of 6/24/94 (July 25-29, 1994) WEDNESDAY, July 27, 1994 0800-0900 Working Group Workshop 0830-0900 Continental Breakfast 0900-0930 Technical Presentations 0930-1200 Morning Sessions Break 1330-1530 Afternoon Sessions I SEC IP Security WG - Network Layer Encryption (ipsec) (Paul Lambert/Motorola and Jim Zmuda/Spyrus) FRIDAY, July 29, 1994 0830-0900 Continental Breakfast 0900-1200 Morning Sessions SEC IP Security WG - Key Management (ipsec) (Paul Lambert/Motorola and Jim Zmuda/Spyrus) Your comments on an IPSEC agenda for Toronto are solicited. There have been several volunteers for presentations at the meeting. We could use a few more. We could use a swIPe champion on the agenda (Wed.). Please drop me a note if you would like to be on the agenda. Also, should we have another demonstration of implementations? Thanks in advance for your comments, Paul