From ipsec-request@ans.net Mon Oct 2 04:59:13 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12936 (5.65c/IDA-1.4.4 for ); Mon, 2 Oct 1995 01:13:46 -0400 Received: by interlock.ans.net id AA03010 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 2 Oct 1995 01:05:31 -0400 Message-Id: <199510020505.AA03010@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 2 Oct 1995 01:05:31 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 2 Oct 1995 01:05:31 -0400 Date: Mon, 2 Oct 95 04:59:13 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: final formats? As I mentioned last week, I'd like to come to closure on the packet formats, so that we can go on to discussing the actual text, examples, and implementation notes later. There has been one comment that they'd like to have no anonymity in one direction, while having it in the other. I cannot see how this enhances security, and it overly complicates the protocol. Are other folks generally comfortable with the Photuris messages? Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Mon Oct 2 04:42:11 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17289 (5.65c/IDA-1.4.4 for ); Mon, 2 Oct 1995 01:13:46 -0400 Received: by interlock.ans.net id AA26294 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 2 Oct 1995 01:05:26 -0400 Message-Id: <199510020505.AA26294@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 2 Oct 1995 01:05:26 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 2 Oct 1995 01:05:26 -0400 Date: Mon, 2 Oct 95 04:42:11 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: 3DES keys > From: Hilarie Orman > The title of the thread is 3DES keys. That's 112 bits * 2 = 224 bits of > exponent. > Yes, we have gone rather far afield. I asked a simple question about generating 3DES keys, and we ended up talking about relative strengths of all kinds of keys. Right now, I'd like to concentrate of the correctness of the Photuris mechanisms, rather than adding better implementation notes. Could someone post the location of the paper or argument which says that 3DES with 2 keys is no better than DES? Are 3 keys any better? What is the current analysis? Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Mon Oct 2 04:50:15 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16778 (5.65c/IDA-1.4.4 for ); Mon, 2 Oct 1995 01:13:46 -0400 Received: by interlock.ans.net id AA85692 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 2 Oct 1995 01:05:29 -0400 Message-Id: <199510020505.AA85692@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 2 Oct 1995 01:05:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 2 Oct 1995 01:05:29 -0400 Date: Mon, 2 Oct 95 04:50:15 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: lengths and strengths > From: Hilarie Orman > > As to elliptic curves, 155 bits of length or 155 bits of strength? > > That's 155/2 bits of strength. > Hmmm, that's only good enough for DES and/or MD5, not 3DES and/or SHA. Do you have any stronger groups we could use instead? > elliptic curves becomes more pronounced as the *length* of the shared > secret (the modulus) increases. We found the break-even point to be > 512 bits for mod p vs. 155 bits for EC. If you use 1024 bit or 2048 > bit mod p systems, the corresponding EC's are much more efficient. > Let's use the corresponding EC's then, please. We aren't even using 512 bit moduli for ModExp. > > > As for the upper bits, the attacker has read the Photuris spec and > > > knows that small exponents are recommended for efficiency. > > > > > Hmmm, have to think about that. Actually, I think it was the number of > > 1 bits.... Maybe we could still have very large exponents. > > This is actually an interesting suggestion, but it probably doesn't win. > You can get 64-bits of strength by dispersing 19 bits at random in 1024. > This makes one part of the DH computation very fast, but it slows down the > other substantially. > Which half? I'm only concerned about the speed of shared-secret generation, not public key computation (precomputed in background). Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Mon Oct 2 17:59:04 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12994 (5.65c/IDA-1.4.4 for ); Mon, 2 Oct 1995 14:08:34 -0400 Received: by interlock.ans.net id AA24166 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 2 Oct 1995 13:59:22 -0400 Message-Id: <199510021759.AA24166@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 2 Oct 1995 13:59:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 2 Oct 1995 13:59:22 -0400 From: David_A Wagner Subject: Re: 3DES keys To: bsimpson@morningstar.com (William Allen Simpson) Date: Mon, 2 Oct 1995 10:59:04 -0700 (PDT) Cc: ipsec@ans.net In-Reply-To: <199509300238.AA82218@interlock.ans.net> from "William Allen Simpson" at Sep 30, 95 02:23:08 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1579 > > In Photuris, all the keys are generated by hashing from the > shared-secret. Assume the shared-secret length is 128-bits, and its > strength is therefore 64-bits. But given MD5, its 128-bit length > birthday attack is also 64-bit strength. > > So, I don't understand why one would use more than 128 bits for the > length of the shared-secret. Why would the conservative advice be 256 > bit length? > I don't see how MD5's collision resistance is relevant here. MD5 is being used mainly as a one-way mixing function to make its output appear uniformly distributed. Anyhow, the length of the input to MD5 isn't an interesting quantity: it's the strength (the effective entropy) that matters. If the input to MD5 can be guessed with 2^64 operations, the output can also be guessed with 2^64 operations. This is insufficient for (e.g.) IDEA. That explains the advice that (conservatively) you want 128 bits of entropy in the shared secret (which is input to MD5): because (conservatively) you want 128 bits of entropy in the IDEA key. Now for discrete-log based key exchange algorithms, 128 bits of entropy in the shared secret corresponds to a length of 256 bits. But again, the *length* of the shared secret isn't the fundamental quantity: the *strength* of the shared secret is the important value; then you derive the required length by an algorithm-dependent process. (The relative relationship between length & strength depends on the key exchange algorithm, while the absolute required strength depends on the underlying symmetric-key encryption algorithm.) From ipsec-request@ans.net Mon Oct 2 18:08:04 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17867 (5.65c/IDA-1.4.4 for ); Mon, 2 Oct 1995 14:13:38 -0400 Received: by interlock.ans.net id AA47089 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 2 Oct 1995 14:08:16 -0400 Message-Id: <199510021808.AA47089@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 2 Oct 1995 14:08:16 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 2 Oct 1995 14:08:16 -0400 From: David_A Wagner Subject: Re: 3DES keys To: bsimpson@morningstar.com (William Allen Simpson) Date: Mon, 2 Oct 1995 11:08:04 -0700 (PDT) Cc: ipsec@ans.net In-Reply-To: <199510020505.AA26294@interlock.ans.net> from "William Allen Simpson" at Oct 2, 95 04:42:11 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1223 > > Could someone post the location of the paper or argument which says that > 3DES with 2 keys is no better than DES? Are 3 keys any better? What is > the current analysis? > I'm not aware of any paper which says ``two-key 3DES is no stronger than DES''. If you know of any, I'd love to hear of it. There are two papers which have described attacks on two-key 3DES which don't apply to three-key 3DES. You get to decide whether they worry you; certainly they're not practical right now. The first paper was (I think) by Hellman; he described an attack on two-key 3DES which needs 2^56 chosen plaintexts. He called this a certificational weakness. Unfortunately, I can't seem to find the reference for this right now.. A more recent known plaintext attack was described by Wiener & van Oorschot. Here's a reference: @InProceedings{OorschotWi91, author = "P. C. van Oorschot and M. J. Wiener", year = "1991", title = "A Known-plaintext attack on two-key triple encryption", booktitle = "Advances in Cryptology --- Eurocrypt '90", editor = "I. B. Damg{\aa}rd", pages = "318--325", publisher = "Springer-Verlag", address = "Berlin", } From ipsec-request@ans.net Tue Oct 3 01:41:06 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12969 (5.65c/IDA-1.4.4 for ); Mon, 2 Oct 1995 21:52:42 -0400 Received: by interlock.ans.net id AA80884 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 2 Oct 1995 21:41:12 -0400 Message-Id: <199510030141.AA80884@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 2 Oct 1995 21:41:12 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 2 Oct 1995 21:41:12 -0400 X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: "William Allen Simpson" Cc: ipsec@ans.net Subject: Re: 3DES keys In-Reply-To: Your message of "Mon, 02 Oct 1995 04:42:11 GMT." <199510020505.AA26294@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 02 Oct 1995 21:41:06 -0400 From: "Perry E. Metzger" "William Allen Simpson" writes: > Could someone post the location of the paper or argument which says that > 3DES with 2 keys is no better than DES? Are 3 keys any better? What is > the current analysis? Two n bit keys in multiple encryption schemes give you somewhat less than an effective 2n key bit key length, whereas three keys actually give you an effective 2n bit key length. See the discussion in Schneier's book on crypto -- I think its in chapter 8. Perry From ipsec-request@ans.net Tue Oct 3 02:21:39 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18045 (5.65c/IDA-1.4.4 for ); Mon, 2 Oct 1995 23:29:18 -0400 Received: by interlock.ans.net id AA39414 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 2 Oct 1995 23:17:47 -0400 Message-Id: <199510030317.AA39414@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 2 Oct 1995 23:17:47 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 2 Oct 1995 23:17:47 -0400 Date: Tue, 3 Oct 95 02:21:39 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: 3DES keys > From: "Perry E. Metzger" > Two n bit keys in multiple encryption schemes give you somewhat less > than an effective 2n key bit key length, whereas three keys actually > give you an effective 2n bit key length. See the discussion in > Schneier's book on crypto -- I think its in chapter 8. > I've read it Perry. Hilary said this years' Crypto had a session showing that 2 key 3DES was no better than DES. I'm asking for the details, or some refutation. And I have asked twice: what folks have implemented 3DES in hardware, so we can make a sensible decision on how to generate the keys? I consider software more maleable than hardware. If no one speaks up, it will be clear that nobody important has done anything in hardware, and what I write on the topic will be acceptable and final. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Tue Oct 3 05:49:07 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15555 (5.65c/IDA-1.4.4 for ); Tue, 3 Oct 1995 02:04:35 -0400 Received: by interlock.ans.net id AA31005 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 3 Oct 1995 01:49:14 -0400 Message-Id: <199510030549.AA31005@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 3 Oct 1995 01:49:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 3 Oct 1995 01:49:14 -0400 X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: "William Allen Simpson" Cc: ipsec@ans.net Subject: Re: 3DES keys In-Reply-To: Your message of "Tue, 03 Oct 1995 02:21:39 GMT." <199510030317.AA39414@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 03 Oct 1995 01:49:07 -0400 From: "Perry E. Metzger" "William Allen Simpson" writes: > > From: "Perry E. Metzger" > > Two n bit keys in multiple encryption schemes give you somewhat less > > than an effective 2n key bit key length, whereas three keys actually > > give you an effective 2n bit key length. See the discussion in > > Schneier's book on crypto -- I think its in chapter 8. > > > I've read it Perry. Hilary said this years' Crypto had a session showing > that 2 key 3DES was no better than DES. I'm asking for the details, or > some refutation. Either way I feel more comfortable with generating the extra few bytes of keying material and going with separate keys -- in the long run we are going to be switching to longer key lengths in new block cyphers anyway, and its pretty clear that three keys are strictly more secure (if only marginally so). > And I have asked twice: what folks have implemented 3DES in hardware, so > we can make a sensible decision on how to generate the keys? There are a bunch of 3DES hardware implementations -- what do you need to know specifically? Perry From ipsec-request@ans.net Tue Oct 3 06:20:25 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17174 (5.65c/IDA-1.4.4 for ); Tue, 3 Oct 1995 02:36:15 -0400 Received: by interlock.ans.net id AA81970 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 3 Oct 1995 02:20:42 -0400 Message-Id: <199510030620.AA81970@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 3 Oct 1995 02:20:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 3 Oct 1995 02:20:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 3 Oct 1995 02:20:42 -0400 Date: Mon, 2 Oct 1995 23:20:25 -0700 (MST) From: Bob Wilmes To: William Allen Simpson Cc: ipsec@ans.net Subject: Re: 3DES keys In-Reply-To: <199510030317.AA39414@interlock.ans.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In William Stalling's recent book on PGP mail, he makes the reference to the 2 key 3DES being better than using a single key 3 DES, because of the susceptability of the single key 3DES to a "middle fork attack." (I believe this is the correct phrase, but I don't have the actual book available to check). Regarding key generation for DES, I believe there are several references in the literature regarding DES keys which if choosen, result in cipher text that is the same as the original plain text. A key generation scheme should check for these possibilities. ------------------------------------------------------------------------ = Bob Wilmes = bwilmes@primenet.com = Phoenix/Scottsdale, Arizona, USA = ------------------------------------------------------------------------ On Tue, 3 Oct 1995, William Allen Simpson wrote: > > From: "Perry E. Metzger" > > Two n bit keys in multiple encryption schemes give you somewhat less > > than an effective 2n key bit key length, whereas three keys actually > > give you an effective 2n bit key length. See the discussion in > > Schneier's book on crypto -- I think its in chapter 8. > > > I've read it Perry. Hilary said this years' Crypto had a session showing > that 2 key 3DES was no better than DES. I'm asking for the details, or > some refutation. > > And I have asked twice: what folks have implemented 3DES in hardware, so > we can make a sensible decision on how to generate the keys? > > I consider software more maleable than hardware. If no one speaks up, > it will be clear that nobody important has done anything in hardware, > and what I write on the topic will be acceptable and final. > > Bill.Simpson@um.cc.umich.edu > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > From ipsec-request@ans.net Tue Oct 3 12:24:58 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18051 (5.65c/IDA-1.4.4 for ); Tue, 3 Oct 1995 09:08:50 -0400 Received: by interlock.ans.net id AA50878 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 3 Oct 1995 09:02:51 -0400 Message-Id: <199510031302.AA50878@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 3 Oct 1995 09:02:51 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 3 Oct 1995 09:02:51 -0400 Date: Tue, 3 Oct 95 12:24:58 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: 3DES keys > From: "Perry E. Metzger" > Either way I feel more comfortable with generating the extra few bytes > of keying material and going with separate keys -- in the long run we > are going to be switching to longer key lengths in new block cyphers > anyway, and its pretty clear that three keys are strictly more secure > (if only marginally so). > > > And I have asked twice: what folks have implemented 3DES in hardware, so > > we can make a sensible decision on how to generate the keys? > > There are a bunch of 3DES hardware implementations -- what do you need > to know specifically? > Thank you for offering to do the research, Perry. Who are the vendors? What keying requirements do the products have? If we specify 3 keys for 3DES, will all the products handle it? Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Tue Oct 3 13:11:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18119 (5.65c/IDA-1.4.4 for ); Tue, 3 Oct 1995 17:16:56 -0400 Received: by interlock.ans.net id AA67432 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 3 Oct 1995 17:11:32 -0400 Message-Id: <199510032111.AA67432@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 3 Oct 1995 17:11:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 3 Oct 1995 17:11:32 -0400 Date: Tue, 3 Oct 95 17:11:26 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipsec@ans.net Subject: ESP/AH interoperability We (NRL) have done basic interoperability testing with Morningstar, the only other implementer to respond to our public requests for interoperability testing, and we do interoperate with DES-CBC ESP and MD5 AH over IPv4. We interoperated fine. This was not interoperability stress testing, just basic interoperability testing. I think there will be a need for more formal ESP/AH interoperability testing this winter/spring. As far as I know, NRL has the only working ESP/AH for IPv6 at this time. If anyone else has one and is ready to test, please drop me an email. Thanks, Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Tue Oct 3 21:32:27 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04321 (5.65c/IDA-1.4.4 for ); Tue, 3 Oct 1995 17:35:51 -0400 Received: by interlock.ans.net id AA59297 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 3 Oct 1995 17:32:38 -0400 Message-Id: <199510032132.AA59297@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 3 Oct 1995 17:32:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 3 Oct 1995 17:32:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 3 Oct 1995 17:32:38 -0400 Date: Tue, 3 Oct 1995 14:32:27 -0700 From: Hilarie Orman To: bsimpson@morningstar.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199510020505.AA85692@interlock.ans.net> Subject: Re: lengths and strengths >> You can get 64-bits of strength by dispersing 19 bits at random in 1024. >> This makes one part of the DH computation very fast, but it slows down the >> other substantially. > > Which half? I'm only concerned about the speed of shared-secret > generation, not public key computation (precomputed in background). It's the shared secret part that gets slower -- QED by Murphy's :-) From ipsec-request@ans.net Wed Oct 4 03:08:13 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12717 (5.65c/IDA-1.4.4 for ); Tue, 3 Oct 1995 23:12:30 -0400 Received: by interlock.ans.net id AA61683 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 3 Oct 1995 23:08:18 -0400 Message-Id: <199510040308.AA61683@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 3 Oct 1995 23:08:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 3 Oct 1995 23:08:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 3 Oct 1995 23:08:18 -0400 Date: Tue, 3 Oct 1995 20:08:13 -0700 From: Hilarie Orman To: bsimpson@morningstar.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199510020505.AA26294@interlock.ans.net> Subject: Re: 3DES keys RSA Labs, http://www.rsa.com/rsalabs/cryptobytes/spring95/news.htm: Modes involving single-DES instead of triple-DES as a primitive, such as encrypting three times with single-DES in cipher block chaining mode, have been shown by Eli Biham in the past year to be potentially no stronger than single-DES against certain attacks. Encrypting with triple-DES in cipher block chaining mode is not vulnerable to those attacks. A handout at the Crypto 95 rump session by Thomas Jones (peace@acm.org) refers to Kaliski's 1994 tech report on combined DES modes, which might only be available to subscribers of RSA Labs tech reports. The handout also refers to Bihams's attack, giving an Asiacrypt '94 reference and the proceedings, to be published by Springer. The "triple-DES in cipher block chaining mode" method, if I understand it correctly, is subject to a dictionary attack of somewhat less than 2^64 space complexity, depending on your attack scenario. This mode was described earlier this year in this mailing list by Ashar Aziz and John Ioannides. The two attacks motivated Jones to suggest several alternative combined DES modes that carry more internal state and are resistant to known forms of attack. It is arguable that neither attack is practical. However, one might take it to mean that the strength of the systems is far less than the number of key bits would indicate. In that case, why bother generating lots of keying material? About 76 bits would be the maximum needed. From ipsec-request@ans.net Thu Oct 5 18:17:35 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15462 (5.65c/IDA-1.4.4 for ); Thu, 5 Oct 1995 18:15:38 -0400 Received: by interlock.ans.net id AA58017 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 5 Oct 1995 18:07:50 -0400 Message-Id: <199510052207.AA58017@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 5 Oct 1995 18:07:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 5 Oct 1995 18:07:50 -0400 Date: Thu, 5 Oct 95 18:17:35 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Photuris Chapter 1 Well, we've gotten quiet around here, and there seem to be no more packet format questions. I've gotten encouraged that interoperable MD5/DES are coming along, and want to finalize Photuris. Besides, Phil's going on a trip, and so I'd like to have some consensus when he gets back. So, look hard at Chapter 1, see if it fits well with the whole, and has enough terminology to be understood by inexperienced implementors. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Fri Oct 6 16:16:20 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18423 (5.65c/IDA-1.4.4 for ); Fri, 6 Oct 1995 11:57:16 -0400 Received: by interlock.ans.net id AA40192 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 6 Oct 1995 11:45:44 -0400 Message-Id: <199510061545.AA40192@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 6 Oct 1995 11:45:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 6 Oct 1995 11:45:44 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Oct 1995 17:16:20 +0100 To: ieeetcpc@ccvm.sunysb.ed, utheorynt@vm1.nodak.edu, orcs-l@osuvm1.bitnet, tccc@cs.umass.edu, cellular@dfv.rwth-aachen.edu, performance@tay1.dec.com, glynn@leland.stanford.edu, modern-heuristics@uk.ac.mailbase, ietf-announce@cnri.reston.va.us, mobile-ip@tadpole.com, dbworld@cs.wisc.edu, end2end-interest@isi.edu, f-troup@aurora.cis.upenn.edu, rem-conf-request@es.net, cost237-transport@comp.lancs.ac.uk, reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net, sigmedia@bellcore.com, www-security@ns2.Rutgers.EDU, ipsec@ans.net, dns-security@tis.com, mobile-ip@tadpole.com, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, cnom@meatro.bellcore.com, globecom@signet.com.sig, ietf@isi.edu, elf@cs.washington.edu, g_f_wetzel@att.com From: bernardi@tce.ing.uniroma1.it (Paolo Bernardi) Subject: Wireless Networks Journal - CFP Herebelow it follows the call for papers for a special issue of Wireless Networks Journal. I would be very grateful if you could diffuse it according your distribution list. Thank you for your kind attention. Call for Papers WIRELESS NETWORKS JOURNAL Baltzer Science Publishers Special Issue "Exposure Hazards and Health Protection in Personal Communication Services" Scope: The rapid diffusion of electronic and telecommunication equipments and systems emitting electromagnetic waves has brought into focus the problems of electromagnetic pollution of the environment and the possible adverse health effects on human beings. In particular, over the past decade there has been a significant increase in the use of hand-held cellular telephones. Because of the proximity of the transmitting antenna to the user's head, great concerns have arose about the potential risks to human health. The problem has been made even more acute by the impending development of wireless data services and wide-band wireless local area networks. Many national and international standard organizations, governmental bodies, and health authorities have issued or are considering approval of standards, recommendations, or legistative actions to protect the public from excessive exposures. In the meantime, scientists and manufacturers are contemplating new design techniques that may reduce the exposure. The aim of this special issue is to highlight problems which are presently under consideration and to present recent progress in this area of research, with particular emphasis on scientific studies used to define exposure limits. Possible topics include, but are not limited to: Biological effects (in vitro and in vivo): - CW fields - modulated fields Dosimetry: - source characterization - electric and magnetic properties of biological materials - experiments and numerical models Epidemiology Interaction mechanisms: - at subcellular, cellular, single organ, and physiological system level Standards and Safety Issues: - cellular phones - wireless data systems and services - wireless local-area networks - Video Display Units The authors should send 4 copies of their paper to one of the Guest Editors by February 1, 1996. The following time-table shall be followed: Manuscript Submission: Deadline: February 1, 1996 Final Manuscript Submission after Revision: Deadline: July 1, 1996 Expected Publication Date: xx, xx, xx Guest Editors: Prof. Paolo Bernardi Department of Electronic Engineering Universita' di Roma "La Sapienza" Via Eudossiana 18, 00184 Roma, ITALY Tel. +39 6 4458 5 855 Fax +39 6 4742647 e-mail: bernardi@tce.ing.uniroma1.it Prof. James C. Lin The University of Illinois at Chicago College of Engineering (M/C 154) 851 South Morgan Street Chicago, Illinois 60607 - 7053 tel: +312 413 1052 fax: +312 413 0024 e-mail: u45339@uicvm.uic.edu Prof. Paolo Bernardi Department of Electronic Engineering Universita' di Roma "La Sapienza" Via Eudossiana 18, 00184 Roma ITALY Tel. +39 6 4458 5 855 Fax +39 6 4742647 E-mail bernardi@tce.ing.uniroma1.it From ipsec-request@ans.net Fri Oct 6 20:30:40 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12929 (5.65c/IDA-1.4.4 for ); Fri, 6 Oct 1995 16:39:04 -0400 Received: by interlock.ans.net id AA25639 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 6 Oct 1995 16:35:36 -0400 Message-Id: <199510062035.AA25639@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 6 Oct 1995 16:35:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 6 Oct 1995 16:35:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 6 Oct 1995 16:35:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 6 Oct 1995 16:35:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 6 Oct 1995 16:35:36 -0400 Date: Fri, 6 Oct 1995 16:30:40 -0400 From: pau@watson.ibm.com (Pau-Chen Cheng) To: bsimpson@morningstar.com Subject: Re: Photuris Chapter 1 Cc: ipsec@ans.net Bill, a question : If during the signature exchange phase, the signature msg indicates that DES and MD5 are used for the security association and a session key is computed. How to determine if this session key is used for DES, MD5 or both ? Thank you. Regards, Pau-Chen From ipsec-request@ans.net Fri Oct 6 14:51:29 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12930 (5.65c/IDA-1.4.4 for ); Fri, 6 Oct 1995 18:56:56 -0400 Received: by interlock.ans.net id AA66762 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 6 Oct 1995 18:51:47 -0400 Message-Id: <199510062251.AA66762@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 6 Oct 1995 18:51:47 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 6 Oct 1995 18:51:47 -0400 Date: Fri, 6 Oct 95 18:51:29 EDT From: hugo@watson.ibm.com To: karn@qualcomm.com, bsimpson@morningstar.com, ipsec@ans.net Subject: Photuris Security Bill wants to finalize Photuris. Me too. However, Photuris is still an *insecure* protocol as defined. (It also contains several ambiguiites and lacks some basic -IMHO- functionality but that's a subject for another message). I have raised more than 6 months ago several issues related to Photuris security holes for which I never got a response from the editors. Needless to say, these comments were never reflected in the protocol. I have brought up these issues several times in these months both in the list, and personally (in Danvers) with the editors. I know that Phil is very busy with other stuff, and I can't blame him for that (I am busy too). However, this cannot be a justification to have a buggy key management protocol for IP. I am appending a message I sent to this WG list on June 12th on these issues. I'd like to know how the editors dealt with these comments; I cannot imagine they just ignored them, that's too much irresponsibility especially with those comments that touch the basic security of the scheme. Points (1), (2), and (5) in the attached message are the most critical for security. (As for (5) the comment now applies to the "Change_Message" in pg 24 of draft 03). In partricular can you please let me know: About (1): do you have a requiremnet that the signature transform hides the contents of the signed information? This is not written in the document, and is *not* the property of signatures in general. For example RSA signature without hashing reveals all of its contents which in this case include the shared-secret (as an example, hashing may not be applied if the total information length is less than the RSA modulus length, a perfectly possible case when the DH is based on 155-bit Elliptic Curve). About (2): I am willing to explain more on this if you are receptive to the need of change in the protocol. In particular, MAC-ing as I suggest solves both the shared-secret leakage problem of (1), and prevents the [DOW92] attacks that motivated the signing of K. About (5): If you believe that a previous (possibly broken) SPI cannot be replayed please explain that to me. In addition: the way keys are derived for data-transforms (e.g., DES-CBC, MD5) from a session key as described in the draft (Appendix B) is unacceptable as already posted in this list (i.e., re-use of same bits for DES-CBC and MD5). I have many other comments on the draft that I will send in next days. However, the above seem to be the most critical for security. Hugo Appended (historical) message: > Date: Mon, 12 Jun 95 20:40:43 EDT > From: hugo at watson.ibm.com > To: KARN@QUALCOMM.COM > Cc: IPSEC@ans.net > Subject: Status of Photuris > > Phil, > > Stockholm is approaching and we have not heard about the > developments with Photuris since Danvers. I would like to know the status > of the following important issues on which I have had objections and/or > recommendations. > > 1) The DH key (or "session key" SK) must not be signed. Signing SK is > unnecessary and, even worst, it is insecure. (See my note of April 12) > > 2) Encryption of the signature messages is needed for privacy (anonymity). > However, it is *not* the right solution for proving possession of the DH key. > (The latter is needed to avoid some of the attacks described in the > Diffie-Van Oorschot-Wiener paper). > A right (and necessary!) solution is to have, in addition of the > signature, a MAC (message authentication code, e.g., key-ed MD5) keyed > with the DH key and applied to the same information that the signature > is applied to (or to the signature itself). In particular, > the MAC must be mandated even if the signature is encrypted for privacy > (notice that this is a change relative to the original STS protocol). > (See my note of April 12). > > 3) A fast re-key mechanism is to be provided for key refreshment based on > symmetric key techniques (as opposed to DH and/or PK techniques). This > is to be done by refreshing the key by means similar to those implied in the > draft (page 20). However, the necessary nonces for freshness > guarantee should be provided explicitly (e.g., by replacing the DH-exponent > fields of the DH-exchange message with a fresh nonce). SAID's are not to be > used for this purpose. Cookies can be used (since cookies must be > unpredictable by definition), however, I would still recommend using special > purpose nonces, to avoid the double functionality of cookies against denial > of service attacks and nonces (in particular, cookies may be unncessary if > the parties already share a previous key since then verifying a MAC is very > fast, actually as fast as generating a cookie). > One simple and secure solution to this fast re-key is presented in the > IKMP draft (Usenix conference version also available); this solution is > compatible with the basic Photuris format. > (See exchange of notes with Phil at end of March). > > 4) The protocol should support a DH exchange that is authenticated by means > of a previously shared key between the parties. This provides for a secure > solution in many important scenarios, including the cases of > * parties with manually installed long-lived master keys, > * parties that get a common key from a key distribution center (a la > Kerberos), or > * parties that use a previously shared DH key for refresh via a new > DH exchange. > In these cases, signatures can be replaced MAC w hich is beneficial > both for efficiency and privacy. > For the purpose of this exchange the basic DH flows of Photuris remain > unchanged except that > a) signature is omitted > b) the MAC field is used to authenticate the information that is > otherwise signed, but the MAC is computed using the previously shared key > (e.g., the shared Kerberos key, etc). > [This is a basic functionality provided by my "Photuris variant" but which > is easily adaptable to the basic Photuris. This was described and discussed > with Phil in Danvers] > > 5) The non-interactive key refreshment in page 26 of the draft (re-key message) > needs to be eliminated. If there is a good reason to keep it, it needs > to be re-designed to avoid replay attacks (e.g., via a shared counter). > The way it is designed now it is vulnerable to replay and then insecure. > > > Hugo > > PS: Hope this time a revised draft will be available well before Stockholm. > > From ipsec-request@ans.net Fri Oct 6 23:17:22 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17613 (5.65c/IDA-1.4.4 for ); Fri, 6 Oct 1995 19:20:58 -0400 Received: by interlock.ans.net id AA28744 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 6 Oct 1995 19:17:29 -0400 Message-Id: <199510062317.AA28744@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 6 Oct 1995 19:17:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 6 Oct 1995 19:17:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 6 Oct 1995 19:17:29 -0400 Date: Fri, 6 Oct 1995 16:17:22 -0700 From: Hilarie Orman To: bsimpson@morningstar.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199510052207.AA58017@interlock.ans.net> Subject: Re: Photuris Chapter 1 How about omitting the cookies and message type from the anonymity algorithm? Makes processing a bit more uniform and avoids encrypting known plaintext. The architecture document implies that the mode is part of the security association, but Photuris seems oblivious to this. Perhaps I'm missing something, but I think the recipient of an ESP message cannot know, without checking the full security association, whether a full IP datagram or only the payload is contained in the protected region. Shouldn't Photuris have a field for specifying mode? A forward reference from the 5.2 mention of "Anonymity Choice specified cryptographic hash" to appendix B.2 would be helpful. Or else an explanation of this when the Anonymity Choice is first introduced. Otherwise, the term causes breathless astonishment on first encounter (aka "huh?"). I know that you appreciate good writing, so you would probably be annoyed to read this construction had it arisen from another author: This message is required to be encrypted using the Anonymity-Choice indicated in the Key_Response. The chosen algorithm does not need to provide integrity, ... Instead you might prefer This message must be encrypted using ... The chosen algorithm need not provide integrity, ... From ipsec-request@ans.net Sat Oct 7 15:04:16 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16674 (5.65c/IDA-1.4.4 for ); Sat, 7 Oct 1995 15:12:07 -0400 Received: by interlock.ans.net id AA46764 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 7 Oct 1995 15:06:15 -0400 Message-Id: <199510071906.AA46764@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 7 Oct 1995 15:06:15 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 7 Oct 1995 15:06:15 -0400 Date: Sat, 7 Oct 95 15:04:16 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris Security > Date: Fri, 6 Oct 95 18:51:29 EDT > From: hugo@watson.ibm.com > To: karn@qualcomm.com, bsimpson@MorningStar.Com, ipsec@ans.net > I remind Hugo that Phil and I are both on the ipsec list, and really don't need multiple copies of a message to bring it to our attention. Also, I asked for comments on Chapter 1. You are outside the scope of the discussion at this point. There will be a "last call" from the IESG where you are certainly welcome to raise whatever issues that you wish on the overall document. > I have many other comments on the draft that I will send in next days. Please don't, unless they are explicit language improvements, which is the current discussion. Note the excellent recent comments by Hilary. > However, Photuris is still an *insecure* protocol as defined. > ... > I am appending a message I sent to this WG list on June 12th on these issues. > I'd like to know how the editors dealt with these comments; > I cannot imagine they just ignored them, that's too much irresponsibility > especially with those comments that touch the basic security of the scheme. > Actually, because there was so little substance, it would have been irresponsible to pay _any_ credence what-so-ever to the plaints. I was asked _not_ to respond (by more than one person). Moreover, although I cannot speak for Phil, I was so turned off by your incessant rants that I stopped working on Photuris for several months. I have recently been encouraged by the results of widespread implementation efforts. I am doing my best to address the issues raised by these implementors, so that they also are encouraged and satisfied and work together. However, the IETF Standards Process requests that we certify that we have addressed even insignificant objections. When your earlier messages were sent, we were only asking for Experimental status, and could safely ignore you. Unfortunately, the WG chairs seem to want to progress this as a Proposed Standard instead. Therefore, I will attempt to review these few items, under the assumption that this will satisfy your curiousity as to _why_ we ignored them. I have rearranged them more logically, in the order discussed in the actual Photuris document. Nota Bene, for the rest of the folks: this is a direct and personal response, which may be offensive to some, although I have attempted to keep the sarcasm to a minimum. You have been warned. ---- > > (See my note of April 12) This was interspersed throughout the message. Actually, I prefer to _again_ ignore your note of April 12, since it has so many inaccuracies with respect to Photuris, including its derivation and the use of its fields. Particularly, you seem to suffer from the delusion that Photuris is based on STS, and interpret Photuris features as STS features. This is not correct. We did not learn of STS until Van Oorschot faxed a copy to Karn in March 95. Another example is the reference to failure with respect to certain unnamed stream cyphers, which are nowhere discussed in Photuris. It would be helpful if, in the future, you did not make up attacks based on material which is not in the document. ---- > > 4) The protocol should support a DH exchange that is authenticated by means > > of a previously shared key between the parties. This provides for a secure > > solution in many important scenarios, ... It would be very helpful if you actually _read_ Photuris, and paid more attention to the other messages on the IP Sec mailing list. This is already required to be supported by Photuris. This is the only currently implemented authentication technique. Other techniques such as RSA (PKCS, PGP, X.509) are optional, because of patent and export restrictions. But, they have been reserved and are described elsewhere in great detail. The ability to dynamically select which signature method is used has long been a fundamental principle of Photuris. > > For the purpose of this exchange the basic DH flows of Photuris remain > > unchanged except that > > a) signature is omitted > > b) the MAC field is used to authenticate the information that is > > otherwise signed, but the MAC is computed using the previously shared key > > (e.g., the shared Kerberos key, etc). This is some unusual use of the word "signature", which is not that same as I am given to understand in either the English language or cryptography. The Signature_Message always has a Signature field. This field can indeed contain any form of authentication. But the basic specification requires that it contain a MD5 hash. There is no separate "MAC field", as referenced above. ---- > > 1) The DH key (or "session key" SK) must not be signed. Signing SK is > > unnecessary and, even worst, it is insecure. (See my note of April 12) > > Early drafts (include -01 which you were so vehemently against) did not discuss which fields were signed. They did not mention signing the shared-secret (computed by the D-H exchange). Indeed, the shared-secret was not signed in Karn's early implementation. Only the public values were signed. However, Van Oorschot (as I remember) later noted that an authentication-only version of the protocol was possible if we signed the shared-secret. Since an authentication-only version of the protocol is desirable in amateur radio networks, that is what we have selected. Only the authentication-only signature form (using MD5) is described in the base Photuris document. It is clearly indicated as "required to be supported". You have not explained to my satisfaction why signing the fields as described in Photuris in any way "leaks" information about the computed shared-secret or the trailing secret-key used for MD5 (see Appendix B). > About (1): do you have a requiremnet that the signature transform hides the > contents of the signed information? This is not written in the document, > and is *not* the property of signatures in general. Then, it should not be surprising that it is not written in the document. > For example RSA signature without hashing reveals all of its contents which > in this case include the shared-secret Perhaps you make a nice publication record out of reiterating the obvious, but it does not belong in Photuris. > (as an example, hashing may not be applied if the total information length > is less than the RSA modulus length, a perfectly possible case when the > DH is based on 155-bit Elliptic Curve). > It would be helpful if, in the future, you did not make up attacks based on material which is not in the document. ---- > > 2) Encryption of the signature messages is needed for privacy (anonymity). > > However, it is *not* the right solution for proving possession of the DH key. I can find no reference in Photuris (any draft) where _optional_ encryption of the exchange is used for the _requirement_ of proving possession of the D-H shared-secret. > > (The latter is needed to avoid some of the attacks described in the > > Diffie-Van Oorschot-Wiener paper). > > ... > > (notice that this is a change relative to the original STS protocol). > > (See my note of April 12). > > Again, you have mistaken Photuris for a derivation of STS. Photuris has never had this putative STS failing. It would be helpful if, in the future, you did not make up attacks based on material which is not in the document. > About (2): I am willing to explain more on this if you are receptive to the > need of change in the protocol. You have not yet given any reason for a change in the protocol. ---- > > 3) A fast re-key mechanism is to be provided for key refreshment based on > > symmetric key techniques (as opposed to DH and/or PK techniques). This > > is to be done by refreshing the key by means similar to those implied in the > > draft (page 20). This feature was not in the original Photuris drafts, but was added at the repeated request of _many_ members of the WG. I do not understand what you mean by "implied in the draft". Upon reviewing page 20 of draft -01 (now page 22 of draft -03), the section is clearly labeled "Session-Key Computation", and clearly and completely describes the derivation of session keys. > > However, the necessary nonces for freshness > > guarantee should be provided explicitly (e.g., by replacing the DH-exponent > > fields of the DH-exchange message with a fresh nonce). Exchanging _new_ public-values is already an option. "Either party may initiate an exchange at any time." [page 6]. However, the alternative Change_Message does not exchange the public values. This results in fewer messages, and avoids overloading the public-value fields with other "nonce" fields (which I find preposterous). > > SAID's are not to be > > used for this purpose. You have not yet described any cryptographic weakness with the approach. Until you can, please don't tell me or anyone else what may "be used"! The SPI _is_ currently used. It is guaranteed to be unique to the party generating it over the lifetime of the shared-secret, is recommended to be generated randomly, and is "fresh" in every known cryptographic sense. Oh yeah, and we avoid the IBM patents, too.... > > Cookies can be used (since cookies must be > > unpredictable by definition), You are incorrect. The cookies of subsequent exchanges are _not_ required to change in the Responder direction. Indeed, there is explicit mention of rapid calculation when the public-values are the same. > > however, I would still recommend using special > > purpose nonces, to avoid the double functionality of cookies against denial > > of service attacks and nonces (in particular, cookies may be unncessary if > > the parties already share a previous key since then verifying a MAC is very > > fast, actually as fast as generating a cookie). Since the parties already share a previous D-H shared secret, this is already used. Using a previous session-key instead would be a _SERIOUS_ security flaw, as it would not ensure Perfect Forward Secrecy. The cookies are _not_ used as nonces, and therefore not subject to such "double functionality". ---- > > 5) The non-interactive key refreshment in page 26 of the draft (re-key message) > > needs to be eliminated. If there is a good reason to keep it, it needs > > to be re-designed to avoid replay attacks (e.g., via a shared counter). > > The way it is designed now it is vulnerable to replay and then insecure. > > This seems very much to be the same issue as (3), except you now want to eliminate the message altogether. You have not yet described any cryptographic weakness with the approach. > About (5): If you believe that a previous (possibly broken) SPI cannot > be replayed please explain that to me. > It is not a matter of belief. This is one of the reasons that protection of Perfect Forward Secrecy (which you have tried to "optionally" eliminate in your "variants") is so important. The session-keys are dependent on the D-H shared secret, the signatures, the cookies and the SPI. The shared-secret and cookies are in turn dependent on the Photuris session. The signatures are dependent on the Photuris session _and_ the long term certificates or secret keys. Once any of the above have changed, the SPI cannot possibly be replayed. ---- > In addition: the way keys are derived for data-transforms (e.g., DES-CBC, > MD5) from a session key as described in the draft (Appendix B) is unacceptable > as already posted in this list To date, there has been no posting to this list which describes a cryptographic weakness in the derivation of the session key for either DES-CBC or MD5. Your "proof by assertion" is not acceptable to me. > (i.e., re-use of same bits for > DES-CBC and MD5). > This "potential weakness" has been discussed from time to time, but no _actual_ interaction between DES-CBC and MD5 has been described in the literature to my knowledge. Perhaps you could be more explicit? While the same SPI and session-key _may_ be used for both ESP and AH, it is not required. See [page 10]: Typically, an encryption method is chosen for the primary attribute of the SPI, and an authentication method is later added for the same SPI, or as an additional separate SPI. In any case, since this is a potential limitation of both manual and automatic key generation, its discussion belongs in the Security Architecture. Perhaps you should raise this theoretical issue again when that document goes to Draft Standard. Moreover, this is less likely with Photuris than with manual key management. Photuris is quite capable of rapid SPI session-ley generation, as noted earlier, and will not need to "re-use" keys. ---- Sat, 7 Oct 95 18:58:08 GMT By the clock, I have now wasted over 3 hours of a nice Saturday morning and part of an afternoon replying to this message. I could have been doing many other things, such as actually editing drafts or working on code, or just plain enjoying the day. I refuse to expend more time on this particular individual. Certainly not when he merely repeats previously posted messages, that were roundly ignored by everyone the first time! Perhaps again in 3 months.... Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sat Oct 7 19:24:11 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15574 (5.65c/IDA-1.4.4 for ); Sat, 7 Oct 1995 16:15:15 -0400 Received: by interlock.ans.net id AA77014 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 7 Oct 1995 16:11:53 -0400 Message-Id: <199510072011.AA77014@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 7 Oct 1995 16:11:53 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 7 Oct 1995 16:11:53 -0400 Date: Sat, 7 Oct 95 19:24:11 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris Chapter 1 > From: Hilarie Orman > How about omitting the cookies and message type from the anonymity > algorithm? Makes processing a bit more uniform and avoids encrypting > known plaintext. > I had thought I'd already done this. Where did I miss some text? Anonymity Choice When selected as an Anonymity-Choice, its anonymity session-key uses the most significant 64-bits of MD5 generated material. The least significant bit of each octet is ignored (parity). The 64-bit Initialization Vector (IV) is set to the Type, LifeTime, and Security-Parameter-Index fields. Encryption begins with the next field, and continues to the end of the data indicated by the UDP Length. > The architecture document implies that the mode is part of the > security association, but Photuris seems oblivious to this. Perhaps > I'm missing something, but I think the recipient of an ESP message > cannot know, without checking the full security association, whether a > full IP datagram or only the payload is contained in the protected > region. Shouldn't Photuris have a field for specifying mode? > Hmmm, I always thought of "mode" as CBC, not tunneling. I think that the recipient of an ESP message can _easily_ tell whether a full IP datagram or just another header (such as TCP) is next, by using the Payload Type! I even mentioned payload type 4 for IP! [RFC-1829] Are you saying that we need another attribute to negotiate whether the data is tunneled? Anyone else need this? > A forward reference from the 5.2 mention of "Anonymity Choice specified > cryptographic hash" to appendix B.2 would be helpful. Or else an explanation > of this when the Anonymity Choice is first introduced. Otherwise, the > term causes breathless astonishment on first encounter (aka "huh?"). > Good idea! Done. Both places. > I know that you appreciate good writing, so you would probably be annoyed > to read this construction had it arisen from another author: > > This message is required to be encrypted using the Anonymity-Choice > indicated in the Key_Response. The chosen algorithm does not need to > provide integrity, ... > > Instead you might prefer > > This message must be encrypted using ... The chosen algorithm need not > provide integrity, ... > Thanks, always appreciate actual text suggestions. Sometimes, I even use them verbatim. ;-) The fact that you are commenting so far along (Chapter 5) is evidence that you already are happy with Chapter 1, so I'll move the process along. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sat Oct 7 20:13:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15595 (5.65c/IDA-1.4.4 for ); Sat, 7 Oct 1995 16:26:59 -0400 Received: by interlock.ans.net id AA76836 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 7 Oct 1995 16:24:20 -0400 Message-Id: <199510072024.AA76836@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 7 Oct 1995 16:24:20 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 7 Oct 1995 16:24:20 -0400 Date: Sat, 7 Oct 95 20:13:43 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Photuris Chapters 1 to 4 Since folks seem to not focus on a single chapter at a time, and are finding the most editorial comment in #5 or later, how about we cover only 1 through 4 in the next day or so, and then get down to the nitty gritty of 5, 6, 7? And, I've had a number of items sent to me personally, rather than the list. Could we keep it on the list, so that the little changes don't surprise anyone? Other than minor definitions, the major suggestion is that the clogging description is too much too soon. I could move some of the little arrow pictures up to the introduction. Normally, I try to define the names of things before using them, but people seem to like the diagram sooner. Oh, and it's OK to tell the list you _like_ something, too. ;-) How else are we to gauge consensus? Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Mon Oct 9 00:03:24 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12096 (5.65c/IDA-1.4.4 for ); Sun, 8 Oct 1995 20:08:18 -0400 Received: by interlock.ans.net id AA18713 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 8 Oct 1995 20:03:33 -0400 Message-Id: <199510090003.AA18713@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 8 Oct 1995 20:03:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 8 Oct 1995 20:03:33 -0400 From: David_A Wagner Subject: major areas needing work To: ipsec@ans.net Date: Sun, 8 Oct 1995 17:03:24 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 485 I'd like to know what critical IPSEC projects still need work done. In other words, what does IP security need to move forward that we're still lacking? I need a medium-sized (200+ hours) project for an operating systems class, and I'd like to spend it on something useful. If the working group is searching for a volunteer to implement some piece of IPSEC, please let me know. (Or if anybody has any suggestions or wish lists outside of IPSEC, I'd love to hear from you!) Thanks! From ipsec-request@ans.net Mon Oct 9 02:27:38 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17746 (5.65c/IDA-1.4.4 for ); Sun, 8 Oct 1995 22:32:10 -0400 Received: by interlock.ans.net id AA49719 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 8 Oct 1995 22:28:24 -0400 Message-Id: <199510090228.AA49719@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 8 Oct 1995 22:28:24 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 8 Oct 1995 22:28:24 -0400 Date: Sun, 8 Oct 1995 22:27:38 -0400 (EDT) From: Scott Bradner To: ipsec@ans.net Subject: Re: Photuris Security Bill, I've got some general comments on the Photuris draft and a number of specific suggestion for wording changes. Where the wording changes are to clarify and do not involve any question of meaning I will send them to you directly. I'll make the more general comments here. As you and I have talked about a number of times, I am a fan of description, reason and context. The IETF documents that are most often cited to me as a "good" standards are the host requirements documents. In particular, the inclusion of a section of discussion about specific topics is seen to be very helpful in understanding not only why something was suggested but also why something else was not. Many of the reasons that particular paths were chosen have been made clear on the mailing lists but that information will not be generally available to someone reading the final standard a few years from now. (Note, I think the Implementation notes are a *very* good thing to have.) In addition I think that a paragraph of overview can be very helpful in setting the context in which the details of a protocol are defined. I would like to have IETF standards be easily readable and understandable by a range of people, from students to implementers. With the above in mind, I'd like to make a number of specific suggestions. move sections 1.2 and 1.3 later into the document, they are quite confusing to encounter before understanding just what the protocol is. add an introductory part to section 2 describing, in prose, what the protocol is providing to the user and the process it uses to do so. in section 2.2 - include the reason that the cookies are 16 octets long (rather than some other length) sec 2.3 - paragraph 2 - I'm confused by "such as moduli" sec 3.1, 3.2, 4.1 4.2, 5, 6.1, and 6.5 - add a paragraph at the start saying what each procedure or message is for (a general comment, I think it is better to say for reserved fields "unused, MUST be set to zero when transmitted and MUST be ignored when received" ) (oops - I've gone past the chapt 5 boundary, more later) Thanks Scott From ipsec-request@ans.net Mon Oct 9 04:36:14 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17817 (5.65c/IDA-1.4.4 for ); Mon, 9 Oct 1995 01:04:10 -0400 Received: by interlock.ans.net id AA56783 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 9 Oct 1995 01:00:41 -0400 Message-Id: <199510090500.AA56783@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 9 Oct 1995 01:00:41 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 9 Oct 1995 01:00:41 -0400 Date: Mon, 9 Oct 95 04:36:14 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: major areas needing work > From: David_A Wagner > I need a medium-sized (200+ hours) project for an operating systems > class, and I'd like to spend it on something useful. If the working > group is searching for a volunteer to implement some piece of IPSEC, > please let me know. (Or if anybody has any suggestions or wish lists > outside of IPSEC, I'd love to hear from you!) > Is anyone working on AH-MD5 and ESP-DES-CBC for Linux? I think that would be very useful, and the kind of thing a class project could do. And of course, Photuris for Linux.... Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Mon Oct 9 15:08:22 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12232 (5.65c/IDA-1.4.4 for ); Mon, 9 Oct 1995 11:37:33 -0400 Received: by interlock.ans.net id AA59466 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 9 Oct 1995 11:30:09 -0400 Message-Id: <199510091530.AA59466@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 9 Oct 1995 11:30:09 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 9 Oct 1995 11:30:09 -0400 Date: Mon, 9 Oct 95 15:08:22 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Photuris-04 I have submitted an internet-draft incorporating many of Hilary and Scott suggestions. Those which want an early copy can get it from ftp.morningstar.com:pub/I-Net/photuris-04b.txt I mostly just reorganized text sections, added a couple of definitions, and Hilary's length versus strength text. Also, the various nits that have been noticed so far are fixed. I also changed the key calculations somewhat, appending the shared-key. While there is no possibility of an appending attack, I figured, "what the heck, it may be more secure against cryptanalysis in the case that someday someone may figure out how to unroll MD5." Particularly as those leading 1024-bit shared-secrets just happen to fall on a 512-bit MD5 hash boundary. And, as requested, I added a 2048-bit modulus. I'm still waiting for a stronger elliptic curve. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Mon Oct 9 16:11:27 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12085 (5.65c/IDA-1.4.4 for ); Mon, 9 Oct 1995 12:19:32 -0400 Received: by interlock.ans.net id AA08616 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 9 Oct 1995 12:14:15 -0400 Message-Id: <199510091614.AA08616@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 9 Oct 1995 12:14:15 -0400 From: Ran Atkinson Date: Mon, 9 Oct 1995 12:11:27 -0400 Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: ipsec@ans.net Subject: IPsec mailing list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rja@bodhi.cs.nrl.navy.mil [co-chair hat on] The IPsec WG mailing list is open to any and all discussion on the IETF's IP Security proposals. While Bill's efforts to herd and focus the discussion of Photuris might be useful, people ought not feel inhibited from posting topics that are outside the scope of what Bill views as current if the poster really believes it is important. [co-chair hat off, begin personal comments] Now I don't know about other folks, but I find Hugo's most recent notes on Photuris to be impenetrable. It would be MUCH more useful if it were made a stand-alone note based on the most recent online version of Photuris, provided specific cites to the parts of that draft that are being objected to, and ecxplained the particulars on how to exploit any claimed vulnerabilities. If the complaints are editorial (that is, relating mostly to wording or clarity), then it would be more useful to propose specific revised text (as others already have been doing). Those folks who provided me with specific text changes tothe ESP/AH drafts (e.g. Hilarie Orman) generally found that those changes were taken before the RFCs were published. This is simply because it is MUCH easier as an editor to make specific changes than to figure out which part of the current text is confusing and how to make it less confusing. Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Mon Oct 9 18:15:36 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15408 (5.65c/IDA-1.4.4 for ); Mon, 9 Oct 1995 14:26:32 -0400 Received: by interlock.ans.net id AA38566 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 9 Oct 1995 14:15:42 -0400 Message-Id: <199510091815.AA38566@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 9 Oct 1995 14:15:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 9 Oct 1995 14:15:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 9 Oct 1995 14:15:42 -0400 Date: Mon, 9 Oct 1995 11:15:36 -0700 From: Hilarie Orman To: rja@bodhi.cs.nrl.navy.mil Cc: ipsec@ans.net In-Reply-To: Yourmessage <199510091614.AA08616@interlock.ans.net> Subject: Re: IPsec mailing list I don't see any reason that Change_Message's (6.1) cannot be replayed, and this could could be used as a denial of service mechanism. The Change_Message's have mutated significantly since Hugo's original comments, but I think his observation that there is no replay prevention is valid. Imagine A sending two change messages for the same SPI to B. Each message changes the validity-choice method to a different algorithm. E replays the first message, and now A and B are out of sync. Actually, if one of the messages is lost, it would seem that similar trouble would result. From ipsec-request@ans.net Mon Oct 9 19:25:58 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18506 (5.65c/IDA-1.4.4 for ); Mon, 9 Oct 1995 14:37:22 -0400 Received: by interlock.ans.net id AA69704 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 9 Oct 1995 14:28:19 -0400 Message-Id: <199510091828.AA69704@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 9 Oct 1995 14:28:19 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 9 Oct 1995 14:28:19 -0400 To: William Allen Simpson Cc: ipsec@ans.net Subject: Re: major areas needing work In-Reply-To: Your message of "Mon, 09 Oct 1995 04:36:14 GMT." <199510090500.AA56783@interlock.ans.net> Date: Mon, 09 Oct 1995 14:25:58 -0500 From: Craig Metz In message <199510090500.AA56783@interlock.ans.net>, "William Allen Simpson" wr ites: >Is anyone working on AH-MD5 and ESP-DES-CBC for Linux? I think that >would be very useful, and the kind of thing a class project could do. > >And of course, Photuris for Linux.... I am sort-of-working on this, where sort-of-working means that I do not have as much time lately to spend on actual code as I would like. Of course, being able to play divide-and-conquer would make this happen faster. -Craig From ipsec-request@ans.net Mon Oct 9 19:32:24 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18675 (5.65c/IDA-1.4.4 for ); Mon, 9 Oct 1995 15:49:38 -0400 Received: by interlock.ans.net id AA93457 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 9 Oct 1995 15:39:36 -0400 Message-Id: <199510091939.AA93457@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 9 Oct 1995 15:39:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 9 Oct 1995 15:39:36 -0400 Organization: To: "William Allen Simpson" Cc: ipsec@ans.net Subject: Re: major areas needing work In-Reply-To: Your message of "Mon, 09 Oct 1995 04:36:14 GMT." <199510090500.AA56783@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <21234.813267144.1@forthnet.gr> Date: Mon, 09 Oct 1995 21:32:24 +0200 From: "Angelos D. Keromytis" In message <199510090500.AA56783@interlock.ans.net>, "William Allen Simpson" wr ites: >And of course, Photuris for Linux.... > I'll probably port Photuris to a few architectures when i have a final version (BSD, SunOS, AIX, Linux come to mind). -Angelos From ipsec-request@ans.net Mon Oct 9 20:39:25 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16776 (5.65c/IDA-1.4.4 for ); Mon, 9 Oct 1995 16:49:40 -0400 Received: by interlock.ans.net id AA89183 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 9 Oct 1995 16:39:36 -0400 Message-Id: <199510092039.AA89183@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 9 Oct 1995 16:39:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 9 Oct 1995 16:39:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 9 Oct 1995 16:39:36 -0400 Date: Mon, 9 Oct 1995 13:39:25 -0700 From: Hilarie Orman To: bsimpson@morningstar.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199510091530.AA59466@interlock.ans.net> Subject: Re: Photuris-04 The 155 bit EC is virtually the same strength as the 1024 bit mod p system, so there's no need for another EC in that range. We are looking into getting a slightly larger EC to match the strength of 2048 bit mod p systems, will send parameters when they are available. From ipsec-request@ans.net Mon Oct 9 20:57:19 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12242 (5.65c/IDA-1.4.4 for ); Mon, 9 Oct 1995 17:07:01 -0400 Received: by interlock.ans.net id AA93375 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 9 Oct 1995 16:57:28 -0400 Message-Id: <199510092057.AA93375@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 9 Oct 1995 16:57:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 9 Oct 1995 16:57:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 9 Oct 1995 16:57:28 -0400 X-Mailer: exmh version 1.6.2 7/18/95 To: Hilarie Orman Cc: rja@bodhi.cs.nrl.navy.mil, ipsec@ans.net Subject: Re: IPsec mailing list In-Reply-To: ho's message of Mon, 09 Oct 1995 11:15:36 -0700. <199510091815.AA38566@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 09 Oct 1995 16:57:19 -0400 From: Bill Sommerfeld -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii I don't see any reason that Change_Message's (6.1) cannot be replayed, and this could could be used as a denial of service mechanism. The Change_Message's have mutated significantly since Hugo's original comments, but I think his observation that there is no replay prevention is valid. There's enough support in the protocol for replay detection if some restrictions are made on SPI reuse. Some sort of timestamp or sequence number would reduce the amount of storage needed to provide replay protection, but it's not really necessary. I think the "change" message is misnamed, since it either creates a new SPI, or deletes an existing one. I'm not going to suggest edits to change that, however.... The draft doesn't explicitly disallow modifying an existing SPI, but it doesn't specifically allow it, either. I don't see how one could change arbitrary SPI attributes reliably, since packets sent using the SPI could be reordered around the change request. The fix is relatively simple: - limit the lifetime of the shared secret, and require that photuris remember the existance of all SPI's created using the shared secret until the shared secret expires. - -- Here's my suggested additions to the spec; there's admittedly some redundancy here, but I don't think it's excessive. [these should go into section 5.4]: The shared secret, and any SPIs created using it, must be destroyed once the initial SPI, created here, expires. [These should go into section 6.4 implementation guidelines]: Change_Message packets must not be allowed to *modify* already existing SPI's, or to resurrect SPI's which have been deleted. If an otherwise-valid change_message is received which would produce an SPI which would live beyond the expiration time of the shared secret, the new SPI must be silently adjusted to expire when the shared secret expires. To prevent resurrection of already-used SPI's, implementations MUST remember, but mark as unusable, deleted or expired SPIs until the shared secret used to create them also expires. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBMHmMqlpj/0M1dMJ/AQEkHQP9Gt+9c4046ACcvzZxfP0m39S25B5zDVhE ukp3WqRC7RlHCkHo4tf9IR7aL5UXR+y2K/oecpVH0tyQ3G+EywIn630LvvOqU3l6 YelJzN8hueDS0dJ3Gd4ZgrQ4JJlNkLUEGtEL4mJzd4n44PxMT6l8IHYlzzpUER0K QD7lFVAFrDM= =dMo5 -----END PGP SIGNATURE----- From ipsec-request@ans.net Mon Oct 9 21:10:33 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18207 (5.65c/IDA-1.4.4 for ); Mon, 9 Oct 1995 17:59:28 -0400 Received: by interlock.ans.net id AA99000 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 9 Oct 1995 17:49:38 -0400 Message-Id: <199510092149.AA99000@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 9 Oct 1995 17:49:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 9 Oct 1995 17:49:38 -0400 Date: Mon, 9 Oct 95 21:10:33 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Modify feature of Change_Message > From: Hilarie Orman > Imagine A sending two change messages for the same SPI to B. Each > message changes the validity-choice method to a different algorithm. > E replays the first message, and now A and B are out of sync. > Actually, if one of the messages is lost, it would seem that similar > trouble would result. > The Validity-Choice is pertinent only to that single Change_Message. Every Change_Message carries a Validity-Choice. It has no relation to any SPI. So, it is not possible to get out of sync: Validity-Choice variable. A cryptographic hash function is selected from the peer's list of supported Attributes, and used to provide message integrity. ---- Attribute-Choices variable. A list of one or more attributes for the Security Association, selected from the list of Attributes sent by the peer. Instead, let us assume that you _meant_ two different authentication or encryption Attribute-Choices for the same SPI. This is not expressly illegal, although it boggles the mind. The whole purpose of having multiple SPI values is to establish such _different_ Security Associations. Indeed, it would appear at first examination that a replay would be possible in that improbably bad implementation. However, the length of time that such a replay can occur is limited by a second feature, which is fundamental to Photuris. The public-values are changing on a regular basis. When the public-value changes, the cookies will no longer match at that party, and the Photuris exchange will begin again from the cookie exchange. Ran and NSA asked for the ability to modify attributes on the fly. Thus, it is a recent addition to Photuris. If they don't give a better reason for needing the facility, I would be happy to restrict it again to adding/deleting entire SPIs. Or, if they would like, we could restrict it to only certain attributes, which are individually specified. So far, there is only one that has been mentioned as a candidate for modification -- Sensitivity Label. BTW, as the modify feature is relatively new, that old crufty message for which you became apologist could not have been refering to it. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Mon Oct 9 21:08:11 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12065 (5.65c/IDA-1.4.4 for ); Mon, 9 Oct 1995 17:59:28 -0400 Received: by interlock.ans.net id AA48564 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 9 Oct 1995 17:49:36 -0400 Message-Id: <199510092149.AA48564@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 9 Oct 1995 17:49:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 9 Oct 1995 17:49:36 -0400 Date: Mon, 9 Oct 95 21:08:11 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris-04 > From: Hilarie Orman > The 155 bit EC is virtually the same strength as the 1024 bit mod p > system, so there's no need for another EC in that range. I don't understand. The 1024 bit mod p has a maximum strength of 1024. You told us before that 155 EC has a strength of 155/2 bits. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Tue Oct 10 08:37:35 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15476 (5.65c/IDA-1.4.4 for ); Tue, 10 Oct 1995 04:52:21 -0400 Received: by interlock.ans.net id AA08823 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 10 Oct 1995 04:38:59 -0400 Message-Id: <199510100838.AA08823@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 10 Oct 1995 04:38:59 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 10 Oct 1995 04:38:59 -0400 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 10 Oct 1995 04:38:59 -0400 Subject: Comments on draft-ietf-ipsec-skip-02 To: ipsec@ans.net Date: Tue, 10 Oct 1995 09:37:35 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 51499 Hello Ashar, Everybody, I have read the newest SKIP draft, and have some comments, suggestions, critics and so on to make. Buried in all the comments are some small but substantial proposed changes to the protocol. Please tell me if any comment of mine is unclear, or if I need to justify it more. If you want me to, I can incorporate some of the proposed changes into the document myself. Understand me well: I like this draft, and think it is a good evolution of the first draft. But there are some severe shortcomings (certificate discovery protocol, sequencing, 'S' 'R' 'N' 'C' bits, assigned numbers, ambiguities) which need to be fixed. As all this is open and published information, discussing it should be no threat to ITAR. If you adapt some of the suggested changes, I suggest to turn out a new revision of the draft until end of october, so we can use november to implement this stuff. Friendly greetings, Germano Caronni | Simple Key-Management For Internet Protocols (SKIP) | | I have added my comments, opinions and suggestions on lines without '|', | CONTENTS In the contents section, several line numbers are not aligned. Do you happen to work with 'FrameMaker' ? ;-) | - i - At the end of the first and second page of the table of contents a ^L is missing. |1. Overview |There are two ways authenticated RSA public keys can be used to provide ^^^ It is not easy to find the second way - one has to read carefully. |authenticity and privacy for a datagram protocol, such as IP. The first |is to use out-of-band establishment of an authenticated session key, |using one of several session key establishment protocols prior to |communication [2,3] , the second one is the inband transmission of the authenticated session key. How about explicitly referencing inband establishment at this point, and point to later discussion. Perhaps even separate subchapters would be useful. |This session key is then used to |encrypt/authenticate IP data traffic. Separate subchapters would also allow for better partitioning of the arguments. The following 8 paragraphs mix some lines of reasoning which make no smoth reading out of it. I would suggest to separate the issues of - - context-free vs session-context (recovery, load balancing) - - DH keyexchange vs RSA (amount of per-packet data) more strongly. Perhaps you can leave out some argumentation simply by pointing to section 1.6 ? The draft contains a lot of reasoning and motivations. When re-reading it I tentatively clipped out all subjects not needed to define a standard for SKIP which let the document shrink somewhat. Is it really needed to give this high amount of 'motivation' and explanative material in the definition of a standard? I fully understand the need for it, to let people assess the value of this standard, but I would rather prefer to see this stuff in an informative annex, than in the document itself. I prefer short documents to long ones ;-) [[ Yes - it is really needed. Please disregard all future rantings about it in the comments. ]] |1.1 Simple Key-Management for Internet Protocols | |We stipulate that each IP based source and destination shall have an |authenticated Diffie-Hellman public key. This public key may be |distributed in numerous ways. One mechanism (described here) is by the |use of X.509/PEM certificate format [6]. Other mechanisms, for example, |PGP certificates, secure DNS resource records, and related issues such |as various trust models are detailed in an adjunct Internet-Draft. Hmm. Is there a reference to this draft? |Examples of principals in the network are IP nodes, or users. In the |discussion below we focus on IP nodes, although a straightforward |extrapolation to user oriented keying is possible and is further |described later. I suggest referring to section 1.8. The 'extrapolation' itself is not given, it is only shown that the mean exist to make it possible. I would write ...user oriented keying is possible. The protocol parts allowing this are described in section 1.8. I assume this would/could happen such that the SKIP daemon contacts an other appropriate user-level process (or external hardware) to get Kij (or the currently valid form of it). Another way would be that a user-process may setsockopt() a Kij (or Kp??) which causes the kernel to allocate a node ID for this socket, and cache node-id and Kij. I guess we do not want to elaborate on such topics at this point in time? |Thus each IP source or destination I has a secret value i, and a public |value g^i mod p. Similarly, IP node J has a secret value j and a public |value g^j mod p. There is a very! sharp break between the two above chapters. The 'thus' and the non-definition of i leads me to believe that a chapter is missing? Who assigns 'i'? |(SKCS) like DES, RC2, IDEA, and such. Since Kij is used for key- |encryption, it is not practical to use a stream cipher for this purpose. ...encryption, one MUST NOT use a stream cipher... |Kij is derived from g^ij mod p by taking the low order key-size bits of |g^ij mod p. Since g^ij mod p should minimally be 512 bits and for |greater security should be 1024 bits or more, 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-256 bits. I would change this to define what happens if there are not enough bits for use as Kij. I can easily go and use RC5 with 2048 keying bits. I suggest ALWAYS using the method described in 1.11 -- see there. | |The important point here is that Kij is an implicit pairwise shared key. |It does not need to be sent in ANY packet or negotiated out-of-band. The |destination IP node can compute this shared key (Kij) by simply knowing |the source IP node's authenticated public key. Because this key is |implicit, and is used as a MMMMaaaasssstttteeeerrrr kkkkeeeeyyyy,,,, its length can be made as long as Oops. Junk. (backspaces) |use. (In order to do this, if it did not already possess I's |authenticated DH public key, it may have to obtain this from the local |directory service.) And check the authenticity! |Since the authenticated public keys are Diffie-Hellman public keys, the |nodes themselves have no public-key signature algorithm. This is not a need |problem, since signing on a per-packet basis using a public-key |cryptosystem is too cumbersome. The integrity of the packets is |determined using a symmetrically keyed Message Authentication Code |(MAC). We do not provide sender/receiver non-repudiation in authentication. Perhaps this should be stated somewhere near 1.7.4 I really would like to see this but it can be done with an appropriate (and expensive) AH. Again - this is quite a long discussion, not all of it is relevant to the realisation of SKIP. Only to the evaluation ;-) |1.3 Zero-Message Master Key Update Algorithm | |counter value n is only incremented and never decremented. It is used to |prevent re-use of compromised traffic authentication keys as well as to [--------------] (delete) |provide coarse-grain playback protection of data traffic. In the event | |Recommended time units/counter update frequency and the agreed upon |start time is specified later in the document. ... in section 6.3. I have mixed feelings about n. I certainly helps to prevent coarse grain replay attacks. (And we need to use it for keying purposes - otherwise it would be without effect in the encryption-only scenario) I do not like the implicit master keys, but I see no alternative. |Once the counter has moved forward, and after a short grace period to |allow traffic in transit to be received, packets encrypted with the help |of counter values earlier than n MUST be rejected. Assume the following denial-of-service attack: Using the NTP protocol I forward the time of a host to a high value. Then communication will be impossible. (Latest when I stop influencing the clock) Other issue. Should 'n' be stored on disk or other permanent storage? Or is it sufficient to always recaluclate n from the actual time? |1.3.1 Zero Message Master key Update with Diffie-Hellman Clever ;-) |1.3.2 Zero Message Master Key update with Manual Keying | |As before, n can be computed as the difference between an agreed upon |start time (specified later in this document) and the current time. |Then, the n'th master key is generated using the following function: | |Kijn = h(Kij, n, 1) | h(Kij, n, 0) | |where h() is a pseudo-random, one-way hash function, for example, MD5 |[13]. For this version of SKIP, the one-way function MUST be MD5. The |"|" represents concatenation. The low order bits of this operation are |used for Kijn. Well, what exactly do you mean by Kij,n,1 ? I would write Kijn = h(Kij | n | 1) | h(Kij | n | 0) where '|' means concatenation, and the high-order bits are on the right side. Again you might need to define the amount of bits used? |1.4 Independence from Cryptographic Algorithms | |a prime field, that can be used to provide the same public key agreement |property are constructions that employ elliptic curves over finite |fields and schemes that utilize exponentiation using composite moduli. Literature References, perhaps? |Essentially, all aspects of the key-management protocol described above |can be generalized to public and private values of the public key |agreement type. This includes the master key update algorithm described |in the previous section. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv > >We describe this using an abstract description of a public key agreement >system as follows. We define Public_Key_Agree() as a cryptographic >function that takes two inputs, one public and one private to generate a >mutually shared secret. We let secret_i and public_i refer to the >private and public values respectively of principal I, and secret_j and >public_j refer to the private and public values respectively of >principal J. The pairwise mutually shared secret between I and J is >denoted shared_secret_ij. The master key Kij is derived from the >shared_secret_ij by taking the low-order keysize bits of >shared_secret_ij. > >A public key agreement function is then defined as: > >shared_secret_ij = Public_Key_Agree(secret_i, public_j) > = Public_Key_Agree(secret_j, public_i) > >Having described a key agreement algorithm in the abstract form given >above, the master key update algorithm described in the specific context >of classic Diffie-Hellman above can be specified using the same form in >a manner independent of the cryptographic construction as follows, > >shared_secret_ijn = Public_Key_Agree(n, shared_secret_ij) > >Kijn is derived from shared_secret_ijn. As before, from an >implementation perspective, it may be faster to utilize the (n-1)th >value of the shared secret in order to compute the n'th value of the >shared secret. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The bracketed section above is - IMHO - completely unneeded and of no interest for this draft. There is no need defining a terminology which is not used. Place this in a draft dealing with alternative algorithms for gaining Kij! SKIP should _not_ care how the shared secret could be derived, but define one mandatory menthod (d-h). |The public key agreement algorithm is specified by the algorithm |identifier used to identify the public key in the public key certificate |or equivalent mechanism (e.g. secure DNS). | |1.5 Storage of Cryptographic Keys | |One possible way to do this is to utilize a hardware device to compute, |store and perform operations using these keys. This device can ensure |that there are no interfaces to extract the keys from the device. Such |devices can be in the form of tamper-proof smart cards, PCMCIA devices, |and so on. Where can I buy it? ;-)) |1.6 SKIP for High Availability and Load Balancing |1.7 Attacks that the protocol guards against Interesting. But for evaluation purposes only. |1.7.1 Intruder in the Middle Attacks 'Man in the Middle' is the terminology I know. But never mind... |1.7.2 Known Key Attacks |If the in-band traffic keys Kp used for packet authentication are ever |compromised, then the master key update algorithm described above |precludes the re-use of compromised keys to send forged traffic. In a coarse-grained fashion! Otherwise use sequencing. Which reminds me: What happened to sequencing??!! I rather liked it being in the SKIP header - as no other means for it was available, and it is algorithm independant. Do I correctly assume that you expect AH/ESP transforms to come up with sequencing? And then, will it be an issue of authentication or of encryption. Or both? Sigh... Another dozen transforms looming on the horizon. |This is because even if a particular traffic key Kp is compromised, this |does not tell an attacker anything about the current implicit key Kijn, |and therefore the attacker would not be able to compute the encryption |of Kp in Kijn. Without knowing the encryption of Kp under the Kijn, an |attacker cannot re-use past compromised keys Kp to any advantage. Wrong semantic. This particular Kp is already available. Should be ...the encryption of differing Kp's in Kijn or this compromised Kp in future different Kijn's... A replay attack is still possible in a limited window of opportunity, before n changes. |Also, knowing any number of past keys Kp does not help an attacker learn |any other Kp, since knowing any number of Kp keys does not allow an |attacker to learn Kijn. Knowing or even choosing Kp keys, and using that |to learn Kijn is equivalent to a known or chosen plain-text attack on |Kijn, and that should be infeasible even given a very large number of |known/chosen Kp keys as long as the key-encryption algorithm is immune |to a chosen text attack, which will always be the case. Thus SKIP is ^known/choosen ^^^^^^^^^^^^^^^^^ |immune to known or chosen key attacks of this variety. DES has been shown to be vulnerable to such attack (2^41). 'which will always be the case' is a dangerous wording... |1.7.3 Anti-Clogging Defense | |An attacker may attempt to mount a denial-of-service attack on a node |implementing SKIP, by trying to force it to perform an unacceptably high |number of computationally expensive operations, e.g. the Diffie-Hellman |computation. ... or seeking in a stream cipher! |In order to prevent denial-of-service attacks on the SKIP scheme |described above, a recommended solution is to pre-compute and cache |master keys Kij, based either on usage patterns of the machine or |through administrative action. In case a clogging attack occurs, the IP |node will still be able to communicate with the set of machines for |which it has pre-computed master keys, it will simply stop computing new |master keys. This allows business as usual activities to carry on, even |while a clogging attack occurs, since there are no computationally |expensive (e.g. public key) operations required to key or re-key with an |IP node once the master key Kij has been computed. Interesting strategy. |The keys belonging to administrator's SHOULD always be in the pre- [-] |compute cache used to prevent this form of denial-of-service attack. |This allows the administrator to securely add more nodes to the pre- |compute cache, even during a clogging attack. A side issue: The usage of may/should/may-not vs SHOULD/MAY/MUST should be carefully checked throughout the document. Different styles are visible. |1.7.4 Non-Goal: Perfect Forward Secrecy | |Although perfect forward secrecy as described in [3], is a desirable and |appealing goal for a key-distribution protocol, there are no known |practical and scalable techniques for achieving perfect forward secrecy Do you know a non-scalable but practical technique? I honestly do not know any practical technique. if you do - please tell me. |for a stateless message based protocol. Here a message based protocol is |contrasted with a stateful session based protocol. Common examples of Hmm. I get the feeling you really have mixed two papers in this draft. A 'statelessness-ratio' and a technical description of skip. sigh. |message based protocols include secure e-mail protocols such as PEM and |PGP. There are no known techniques for providing perfect forward secrecy |of encrypted data for these message based protocols. I tend to disagree. Might be possible when strict sequencing is implied, and bilateral state is kept. I will check, and perhaps write about it later. |above, vastly complicating (or making impossible) highly available and |load-balanced protected IP configurations. Perfect forward secrecy can be achieved when user-level keying is used, and appropriate protocols are employed on that level... Here, just before section 1.8, a newline is missing. |Master Key-IDs effectively decouple the identification of a master key |for purposes of key lookup and access control from issues of network |topology, routing and IP addressing. As one example, this allows IP adresses. |The length of the Master Key ID is implicit in the choice of the NSID. |There are two possible lengths, 32 bits and 128 bits. A 32 bit name |space identifier may be used to identify, e.g., IPv4 addresses. A 128 |bit identifier may be used to refer to an IPv6 address. | |The 128-bit Master Key-ID format also allows many different name spaces |(up to 256) to be used with SKIP, by letting the Master Key-ID be the |message digest of the name in its native name space. Examples of name or |identifier spaces that can be accommodated in this manner are DNS names, |ISO Distinguished Names, U.S. Social Security numbers, Credit Card |numbers, Bank Account numbers etc. I would suggest keeping the length of IDs subject to the NSID value. Additionally it is not clear whether all other NSID types than IPv4 require 128 bit. I see at least one application where 64 bits are sufficient, but 32 are not. I would write '... There are two commonly used lengths, 32 bits and 128 bits...' And I would replace 'The 128-bit Master Key-ID format also...' with 'The usage of NSIDs also allows many...' -- why should I be bound to 128 bit when using a NSID? |Although some of these name spaces have associated privacy concerns |(e.g. social security numbers, credit card numbers etc.), these |sensitive values would not actually be disclosed, since message-digests |are one-way functions. Commonly used message digests have a 128-bit |output, and this provides a compact and private way of carrying this |identification information in a packet header. I strongly disagree. Common credit card numbers contain 16 digits, where the first four digits contain a country code. I can precompute all hashes, and would thus be able to recover the credit card number. This need to be mentioned. The name space has to be made such that precomputation is infeasible, if the values are sensitive. |It is also possible for this identifier to be the message digest of the |public key of a principal, since some principals may wish to be known by |their public keys alone. If the public key is used as an identification |mechanism, it simplifies the distribution of authenticated public keys, Good idea. Have you ever thought if it is possible to construct DH values from RSA public/secret keys? if it is possible, users could use their PGP keys to establish a 'security association' by using them as input to a DH calculation. I will have to think about it... |Principals in the network will need to be able to reverse lookup a |certificate (or equivalent information) using the Master Key ID. There Are we obsoleting Kerberos? Hmm.... |If the "N" bit is zero, i.e. there are no name space identifiers |present, the Master Key-ID is a 32 bit identifier for SKIP encapsulated |in IPv4 and a 128 bit identifier for SKIP in encapsulated in IPv6. In |this case, the Master Key-IDs default to IPv4 and IPv6 addresses |respectively. Suggestion: Do NOT use a 'N' bit, but use the value of the two NSID fields directly. (e.g. value == 0 -> no corresponding node-id field present! I deem this important, because you are running out of toggle-bits. I am sure that the value assigned to NSID in this draft can still be changed to reflect the modified behaviour. Thus we would also save the 'S' and the 'R' bit. It is of equal cost to directly check the NSID fields. |a semi-permanent identifier ^strange word. What do you actually mean? |To illustrate one possible user, this decoupling allows, nodes to move [-] [-] |around on the network, and come in from dynamically assigned IP |addresses (using, for example, the DHCP protocol) and still have access ^reference? |control and Diffie-Hellman public key lookup occur based on the semi- |permanent Master Key-IDs. Again the semi-permanence. |If the "S" bit is set, the sender Master Key-ID MUST be used for lookups |and the source IP address MUST NOT be used. If the "R" bit is set, the |receiver Master Key-ID MUST be used for authenticated public key lookups |and the destination IP address MUST NOT be used. If source NSID is non-zero, the sender Master Key-ID MUST be used for lookups and the source IP address MUST NOT be used. If the destination NSID is non-zero, the receiver... |Some commonly used name spaces have been assigned NSIDs. These are |described in the "Assigned Numbers" section below. More name spaces will |be registered through IANA. "assigned numbers" section 5.3 |1.8.1 The SKIP Header | |SKIP Header | | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Clear IP Header protocol = SKIP... (typically 20-bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Ver |C|S|R|N| Source NSID | Dest NSID |NEXT HEADER | 1 2 3 4 1 2 3 4 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 x x x x I strongly suggest NOT having the four bits marked with 'x' but using the corresponding byte-fields instead. (This would allow to re-introduce sequencing, if wanted!) |Following the NSID bytes in the SKIP header, the NEXT HEADER field is |used to indicate which protocol follows the SKIP header. This field will |usually indicate ESP or AH. But the NEXT HEADER may be any protocol |which requires keying material. Examples of protocols other than AH/ESP |that may use SKIP are given below. Well, it even could be IP, for encapsulation purposes. What happens if neither encryption nor authentication are present? Does Kp get dropped? |The input to the key encryption algorithm is padded with a random fill |up to a multiple of the block size of the key-encryption algorithm. The Where is the padding applied. Low-order bits or high-order bits? I suggest high-order bits. |length of Kp is derived from knowledge of the encryption/MAC algorithms. |The low order key-length bits of the decrypted output are used as Kp. Ah. I see. |The Kp Alg and MAC Alg specify algorithms used by the interior protocol I suggest changing the name of the field 'Kp Alg' to 'Crypt Alg', as both fields depend on Kp. |not an absolute, however. For instance, it is possible to have a Kp |algorithm which provides encryption and MAC computation. This is further |described in a later section. ...in section 1.11.2. |The Comp Alg field specifies the algorithm that was used to compress |packets prior to encryption/authentication. This field is only used when |the "C" bit is set. Drop the C bit. Just rely on the Comp Alg field. As you do with encryption and MAC computation, and I suggest doing it with Node-IDs too. |The values for the algorithm fields will be described later in this |document. ...in section 5.4. sigh. I suggest adding the algorithms '0' in 5.4, for defining 'no ecnryption/MAC performed. Same for compression. |The field "Kp encrypted in Kij" is the ... Explain again that the length of Kp is variable, and depends on the MAC/crypt algorithm? |The sender Master Key-ID field contains the Master Key-ID of the sender. |This field is only present if the "S" bit has been set. ...if the source NSID is set. |The receiver Master Key-ID field contains the Key-ID of the intended |receiver. This field is only present if the "R" bit has been set. ...if the destination NSID is set. |1.8.2 The relative order of compression, encryption and authentication | |The protocol allows three potential transforms to be performed, namely |compression, encryption and authentication. The order in which these |transforms are performed is very important. It is desirable for |encryption to follow compression, because encrypted data is not |(generally) compressible. Authentication must follow encryption and/or ^usually not! |compression because it is unknown whether transforming a MAC using |either encryption or compression results in a valid MAC. I do not understand. You think it possible that an encrypted MAC will match an encrypted plaintext, over which it was originally computed? Hmm. Would be interesting to work out the properties such a MAC computation AND/OR encryption would need to have. It surely does not exist as of now ;-) |Received packets will naturally be transformed using the reverse order. [---------] |specific transform. The packet key Kp is used as a key to compute a MAC |using, for example, Keyed MD5. The MAC is inserted into the encapsulated See further below. in 1.9.1 perhaps add a reference to the new SHA RFC, which appeared some weeks ago, as alternative to keyed-MD5. |1.9.2 Scope of MAC computation | |The only fields that are non-zero for the purposes of the MAC |computation in the 20-byte outer IP header are: 1) 4-bit IP version |number, 2) 16-bit ID field, 3) the two 32-bit source and destination IP |addresses, and 4) the 8-bit protocol field. All other fields of the 20- |byte IP header are treated as zero. Isn't this a disagreement to: |All IP options other than IPSO are ignored for the purposes of the MAC |computation. The intent is to ignore any fields that may potentially be |changed in transit by routers. Does this mean that IPSO MUST be 0 on the receiving side, or what? Please elaborate... |1.10 SKIP for Encryption | |When SKIP is used to supply keying material for encryption only, the Kp |algorithm indicates packet encryption algorithm. Kp will be used as a |key to the Kp algorithm. The Kp algorithm will be mapped to standard |transforms such as RFC 1829. These transforms will also contain |information such as Initialization Vectors or Message Indicators. Where is this mapping to std. transfroms defined? |1.10.1 SKIP with ESP | | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Clear IP Header protocol = SKIP... (typically 20-bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Ver |C|S|R|N| Source NSID | Dest NSID |NEXT HEADER=ESP| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Counter n | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Kij Alg | Kp Alg | RESERVED | COMP Alg | 1 2 3 4 5 6 7 1 2 3 4 5 6 7 please check the width of these fields in the different graphics. |value SKIP_SPI. The SKIP_SPI value is specified later in this document. in section [guess] 5.2 |1.11 SKIP for Packet Encryption and Authentication | |Packets may be both encrypted and authenticated. An important issue when |performing both authentication and encryption is key separation. Namely, |the authentication and encryption keys MUST be different. This allows, |for example, encryption keys to be short (possibly to satisfy export |control laws) while keeping the authentication key as long as necessary. |Furthermore, it MUST be infeasible to derive either one of the |authentication key or the encryption key, should one of them be |compromised. Why?? Please explain. I see that there is a problem, if Kp can be recovered, and that the recovery is made more difficult when the two alg's use differnt representations of Kp. But why is it _important_ ? |This is accomplished as follows. The Kp that is decrypted from the |packet header is not used directly to encrypt/decrypt or authenticate |the packet. Rather, it is used to derive two separate keys named E_kp |and A_kp, where A_kp is used as the authentication key and E_kp is used |as the encryption key. E_kp and A_kp are related to the Kp decrypted |from the packet header as follows: | |E_kp = h(Kp, 1, Kp) | h(Kp, 0, Kp) |A_kp = h(Kp, 3, Kp) | h(Kp, 2, Kp) As above, the "," operator needs to be defined. Also the width of 0..3 needs to be defined. See comments about 'Kijn and manual keying' above. Incidentally, why are you using Kp|0|Kp, and not simply Kp|0 ?? I do not think it makes things more secure. I am not sure whether this makes sense, but I tend to propose that we always use the output of the key separation process. So nobody would have to decide when to use Kp directly, and when to use E_kp, A_kp instead. This is not important. Comments? |When using MD5, the function specified above provides a total of 256 |bits, which is a sufficient number of key bits for the expected |encryption and authentication algorithms that will be used with SKIP. What will you do if it is not sufficient? Redesign SKIP? |A SKIP implementation will know when to perform the key separation |procedure specified above by presence of non-zero values in both the Kp |Alg identifier and the MAC Alg identifier. This indicates that both |encryption and authentication are taking place, and therefore separate |keys need to be computed. Hmm. What happens if MAC Alg. is non-zero, but no AH header follos? What happens if it is zero, and an AH header follows. Have you somewhere explicitly defined the significance of MAC alg being 0, or Kp alg being 0? |The other important issue when performing both authentication and |encryption is the order of the two operations. For sending, SKIP |compliant implementations MUST first encrypt the packet using E_kp as |the encryption key, and then compute the MAC over the encrypted packet |and invariant clear header fields using A_kp as the authentication key. Isn't this a reiteration of section 1.8.2 ? |Any protocol which uses both authentication and encryption MUST use this |key separation algorithm. When performing encryption without |authentication, or authentication without encryption, then key bits are MUST be |directly derived from Kp, without using the key separation functions |described above. |1.11.1 SKIP with AH and ESP | |SKIP combines naturally with AH and ESP. The Next protocol field in the ^^^^^^^^^ ;-)))) |The following is an example of SKIP with AH and ESP. In Addition, the |use of Master Key-ID's is also demonstrated. Key-IDs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Kij Alg | Kp Alg | MAC ALG | COMP Alg | again, check alignment of fields. |All 32-bit quantities are transmitted in network order. This I would state somewhere earlier, or make it a global definition, near to the introduction!! |1.11.2 SKIP with combined ESP transforms | |For ESP transforms which combine encryption and authentication (for ^both |instance: Keyed MD5 with DES-CBC), only an ESP header is needed. The Kp |algorithm in the SKIP header will indicate the transform and A_kp would |be used for authentication and the E_kp (as discussed in a previous |section) would be used for encryption. | |Since a SKIP implementation has to unambiguously distinguish between |when authentication and encryption are both being taking place in order |to perform key separation, the MAC field MUST contain the same algorithm |identifier as the Kp algorithm identifier. Since this algorithm |identifier will indicate a combined encryption/authentication transform |for ESP, setting both fields to non-zero values unambiguously indicates |that both encryption and authentication are taking place. Well. Now this gets weird. The semantics of Kp alg (suggested: Crypt alg) and MAC alg are somewhat convoluted. Don't you think that a combined transform would itself provide the key-separation process? I understand that otherwise this coupling of the two algorithm fields (and the numbering spaces) is the only practical solution to handle such combined transforms. But usually, if a MAC alg is defined, I would demand to see an AH header... |1.12 Generic use of SKIP header | |In particular it is possible to pass SKIP in the payload of of a TCP/UDP [--] |packet. This allows the key-management and encryption/authentication to |be performed in the application protocol (above TCP/UDP), and there may |be times where it is advantageous to do so. We are linking network layer with application layer here. Is this wise? (Note: I like it, as I like the user-initiated, or per-socket keying; but is it a smart thing to do?) AH always needs the IP header to check integrity. Does this combine with an application layer authentication? |2.1 Transient Multicast Groups | |Furthermore, in order to distribute multicast keying material, the |notion of a group owner needs to exist. How the identity of the group |owner is established and communicated 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 can be defeated. Does this imply user-level keying of SKIP? |encrypted packet, using the pairwise secure protocol described in |Section 1 above. ... using SKIP as described in section 1. |requests/response messages. The request is sent to TCP/UDP port # 2000. 2000 is a bad choice. This is the most commonly used port for experiments etc. As it is the first x000 number accessible to everybody. How about using something like 17530/17531 ? |The first field specifies the version of this protocol, which is 1. It |is followed by the actual IP multicast address for which the GIK is |being requested. The request packet that is sent must have the minimal |enhancement of source-origin authentication, which is accomplished using |the AH protocol. The user level would not need to care about this, would it? As we are using SKIP below, this would have to be implied. |The group owner's response is an encrypted packet |containing the GIK Kg. The response is sent to TCP/UDP port # 2001 at |the requester's unicast IP address. The packet format is as follows, and |as before, it defines the data-portion of a TCP or UDP packet. Nice. Small and complete. I like it. |key-change policy. There are two ways of specifying key-change policy. |One is in terms of elapsed time since last key-change. This is specified Perhaps state that you are talking about key change of Kp, not Kijn ? |Transmitting nodes to group address M will randomly generate packet |encryption keys Kp, and encrypt these keys using Kg. The packet |structure is similar to the structure used for encrypted unicast SKIP |packets, except that the packet keys Kp are not encrypted in the |pairwise keys Kijn, but instead are encrypted using the GIK Kg. An ...Kg, analogous to manual keying as described... . | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Clear IP Header protocol = SKIP... (typically 20-bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Ver |C|S|R|N| Source NSID | Dest NSID |NEXT HEADER | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Counter n=1 (unused) | Why????!!! This might be used to convolute Kg. (I know, you can do the same with expiration of Kg, and requiring it to be fetched again.) Perhaps this issue should be discussed. And why is it set to 1, and not to 0 ? ;-) There is a small little arrow at the left side of the image. Any significance? |An implementation of this protocol will use the destination IP multicast |address to lookup the GIK Kg. Hmm. You have not yet implemented it. (-:C Take care your cache is large enough (and uses LRU) when handling a multicast group. Otherwise you SKIP implementation will run into problems if somebody does not follow the Kp change schedule. (see experiments in Atlanta where a bilateral SKIP already flooded (and blocked) your chache. |the group. This can be extremely frequent, e.g. once every few seconds |even with very large multicast groups, because there is no extra |communications overhead for updating packet encryption keys. Again. Remember the cache size. |Second, since all the packet encryption keys are randomly generated, and |hence different, there is no problem in using stream-ciphers with |multicast. Perhaps we could note the synchronisation problems with stream ciphers, as observed in Atlanta. I will discuss this in a later mail. |2.2 SKIP for Broadcast/Permanent Multicast Groups | |GIKn = h(GIK, n, 1) | h(GIK, n, 0) sigh. again the ',' operator. |This use of SKIP to supply keys for non AH/ESP protocols is intended to |be illustrative, and not exclusive. Other protocols can similarly be exhaustive? |The Algorithm discovery ICMP message: | | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | TYPE=SKIP_ICMP| CODE | CHECKSUM | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | nKij | nKp | nmac | ncomp | MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Current Time | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | n update Frequency (in seconds) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Expected n | Isn't this tightly coupled to 'current time'? Might be redundant? | 7 6 5 4 3 2 1 0 | +-+-+-+-+-+-+-+-+ | |I|P|M|C|N| res | | +-+-+-+-+-+-+-+-+ | bits 0-2 are reserved and should be set to 0. MUST/SHOULD | |The ICMP type field SKIP_ICMP is specified later in this document. | |The time field, Current Time, is set to the system's concept of current |time in seconds since 0h Jan 1, 1900. This is identical to the Integer ^ UTC |portion of the NTP timestamp. and will work until about 2036. Have you ever thought about augmenting NTP by authentication using SKIP. This would secure the usage of 'n' for hosts using NTP. See RFC1305, appendix C. |The nKij, nKp, nmac and ncomp fields should be filled in with the number nMAC |of Kij, Kp, MAC and Compression algorithms the system supports, |respectively. | |A host may force an ICMP message by sending a SKIP packet to the remote |host with either the Kij or Kp algorithms set to zero. The compression |algorithm may be set to 0 as well, but only if the "C" bit has been set. See my suggested changes above, and forget about the 'C' bit. Directly use the comrepssion alg. field. Kp algorithms = 0 actually makes sense. I suggest forcing ICMP messages only with Kij alg = 0. |The DHPublicKey gets encapsulated as the BIT STRING in |SubjectPublicKeyInfo of an X.509 certificate in the obvious manner. The ^^^^^^^? |certificate and CRL encoding is the same as in RFC 1422. CRLs will be |used with SKIP in the usual manner, in line with each site's ^^^^^? |certificate/CRL management policies. |4.3 Certificate Discovery Protocol |algorithm for choosing a particular certificate (essentially a Diffie- |Hellman public value) when more than one exist is described later. ...is described in section 4.4 ? |All certificate discovery protocol communication use the User Datagram |Protocol (UDP). The initiator binds to port skip-cert-send (6456) and |sends a certificate request to port skip-cert-recv (6455). The |responder binds to port cert-recv-port and sends the response to port |cert-send-port. Two separate ports are used to allow for multiple 2 ports but 4 names?! |certificate requests to be made without waiting for the response to be |received, (that means, one port is used to simply send requests out and |the other port is used to receive responses). A simple cache of the |Master Key-ID and the IP address to which the request was sent is all |that is required to manage outstanding certificate requests. If I receive a SKIP packet containg an IP-v4 Master-ID and a source IP address, and I try to do certificate discovery, to whom do I send my UDP packet? Why using 2 ports? If one process allocated both ports, as is suggested byt the menioning of the cache, then one port is sufficent. Same applies to ports in multicast scenario above. |Implementation detail: Considering that a node may be pre-configured to |allow only encrypted communication with any other node, a certificate |request would be rejected. It is suggested that the two ports (cert- |send-port and cert-recv-port) be treated as a "by-pass" channel for |encryption. As only certificates requests are satisfied on these ports |the window for vulnerability is limited. Again we have a break of the layering. This would suggest SKIP implementations where you can choose which ports are to be protected, and which not. Which I like ;-) |The certificate discovery packet: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | VERSION | ACTION | STATUS |NUMBER-OF-CERTS| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ACTION indicates the type of message. Possible values are: |1 (Request) - request for remote parties certificate(s). |2 (Reply) - response to a certificate request. You need no second port, when you distinguish requests from replies! |NUMBER-OF-CERTS - if 0 then no certificates are present in the message | and the message is simply a request for all certificates | for the specified Master Key-ID or a response where the | STATUS octet indicates an error. Suggestion: Use more than 8 bit for this value. There are no space limitations demanding us to save 3 bytes. I know, more than 256 certificates are highly improbable in UDP packets <64k , but why limit oneself... |Note that this allows for the initiator to not only request for all |certificates for a particular Key-ID but can also send in the same |message all the certificates it has. As certificates have the subjects for a certain master-ID. How about allowing for multiple master-IDs ? We have a collsion of terminology here: Key-ID vs Master-ID ? |identity (i.e. specifies the certificate owner), this information does |not have to be sent to other party. ^the | |Master Key-ID - this is a 32 bit or a 128 bit identifier as described | in the section on Master Key-IDs. Hmm. How do I know if it is 32bit or 128 bit? Why only the two values? Redesign. Include NSID! ...and it is section 1.8. |CERT-TYPE specifies the certificate type of the certificate that is to |follow. see 5.4 for values. |CERTIFICATE - the actual certificate. | | |The Certificate Discovery Protocol allows certificate requests to be |made to any arbitrary IP-node. This feature allows the initiator to send |requests to, say, an IP-node which is acting as a DNS or NFS server (and |hence would have many certificates stored in its local certificate |database). How about defining when the authenticity of a certificate is to be chacked, and what happens if it is not authentic? I just remeber that RFC1825 contains some MUSTs concerning logging of authentication failures... Are we RFC1825 compliant in SKIP? Or should we ask for a change of RFC1825? I deem it stupid to enforce logging. This is up to the admin to decide. |5.3 Name Space Identifier (NSID) Assignments | |Some of the name spaces that may be used with SKIP are assigned |identifiers here. Other name space identifiers will be assigned by IANA. | NSID Value Name Space Master Key ID length | 0 IPv4 Address Space 32-bits I suggest using 0 as implicitly meaning the actual IP adress of the packet | 1 POSIX/XOPEN User Ids 32-bits | 2 IPv6 Address Space 128-bits | 3 MD5 of DNS Names 128-bits | 4 MD5 of ISO DN ASN.1 encoding 128-bits | 5 MD5 of U.S. Social Security # 128-bits | 6 MD5 of Credit Card # 128-bits | 7 MD5 of Principal's Public Key 128-bits | 8 MD5 of RFC-822 Mailbox Address 128-bits | 9 MD5 of Bank Account # 128-bits | 10 MD5 of NIS Name 128-bits | | |Only the IPv4 and IPv6 address spaces are used without transformation |using MD5. All other names are hashed into 128-bits from their native |name space encoding mechanism using the MD5 message digest algorithm. See earlier discussion of weakness! By the way: What happens if two different values hash to the same digest, and the database sees this collision? |5.4 Assigned Algorithm Numbers | |Key-Encryption Algorithms (Kij Alg) 0 Invalid |1 DES-CBC (IV = 0, random fill upto multiple of 64-bits) MANDATORY |2 3 key Triple DES-EDE-CBC (IV = 0, random fill upto multiple of 64-bits) |3 IDEA-CBC (IV = 0, random fill upto multiple of 64-bits) 10 Simple Crypt What about using the same numbers as for Kp (or Crypt) Alg ? What about RC2, RC5? |Traffic Encryption Algorithms (Kp Alg) | 0 Not encrypted, no Kp present if no MAC Alg defined. |1 DES-CBC (64-bit IV, padding ESP transform RFC 1829) 1 DES-CBC (RFC 1829) MANDATORY |2 40-bit RC2-CBC (64-bit IV, PKCS # 5 padding algorithm) why not the one in PKCS #7 ? |3 40-bit RC4 (64-bit byte offset Message Indicator) |4 128-bit RC4 (64-bit byte offset Message Indicator) ESP formats need to be defined! |5 2 key (k1, k2, k1) Triple DES (EDE-CBC) (64-bit IV, padding according to PKCS #7, FIPS 81) |6 3 key (k1, k2, k3) Triple DES (EDE-CBC) (64-bit IV, padding according to PKCS #7, FIPS 81) |7 IDEA-CBC (64-bit IV, padding according to PKCS #7, FIPS 81) |8 DES-CBC (64-bit IV, padding according to PKCS #7, FIPS 81) Do wee need these two?? Very redundant! 10 Simple Crypt What about RC2, RC5 ? What about RFC1851? |MAC Algorithms (MAC Alg) | 0 Not authenticated, no Kp present if no Crypt Alg defined. |1 128-bit Keyed MD5 (RFC 1828) MANDATORY |2 DES-CBC MAC where defined? 3 SHA (RFC1852) ?? |Compression Algorithms (Comp Alg) | 0 No compression used | Currently Unassigned | |Certificate Type (Cert Type) ^Format | |1 X.509 |2 PGP |3 Secure DNS How about defining an ASCII interchange format, which is human-readable and needs no binary encoding. Printable, Mailable, etc. ? Just print out numbers.... (No authentication needed, just transfer of g,p,public value) |characters. It is best to utilize as many different sources of random |information as possible. Our suggestion for generation of in-kernel random data is to use vmstat netstat etc. data, and use this to key RC4, which then delivers 'Random' bytes. Comments? |The traffic encryption/authentication key SHOULD be updated for every 10 |Mbytes of protected traffic, or once every 2 minutes, which ever one |results in a more frequent update policy. Perhaps discuss problem of resynchronizing stream ciphers, because of out-of-seekrange offsets? I do not remember having read anywhere that the IV of a streamcipher drops back to zero when Kp changes. Where do we place this, in the RC4 or whatever draft? |The start time for computing "n" is 0h Jan 1, 1995. The time units of n ^UTC Yet another starting point ;-) |are hours since this start time. Therefore the "n" counter is |incremented once every hour. | |Symbolically, n is computed locally as | |local n = (current time) - (start time) normalized to hours ^^^ without rounding, perhaps use 'truncated' or 'granularity of' | |check this against the value of n in the received SKIP header. If they |do not differ by more than 1, the packet is accepted. If they differ by Define the window to be +/- 1 hour. |Note that this doesn't require the use of fine-grain synchronized clocks |or a secure clock synchronization protocol. Nodes should by default have |clocks synchronized within an hour of each other. If they are not |synchronized even in this coarse-grain manner, then validating |certificates and CRLs becomes problematic. Is there a way to switch off Zero-Message Master Key Update? I would say yes, simply by setting 'n' to 0. This should be stated in the draft. It depends on policy if such packets may be accepted or not. |Two sets of values are specified here. One uses a 1024 bit modulus (p). |The other uses a 512 bit modulus. These values were computed using the |BSAFE library from RSA Data Security, Inc. The 512 bit modulus is |defined for interoperability with exportable implementations due to US |export control regulations. Exactly how did you generate them? As mentioned in IETF Stockholm by Schiller, it would be wiese to do this in a public forum, using lots of random noise, as available on any conference ;-) =========== That's it. Germano -- <...cookie space for rent...> Germano Caronni caronni@tik.ee.ethz.ch http://www.tik.ee.ethz.ch/~caronni PGP-Key-ID:7B7AE5E1 gec@acm.org 997C6DC4AF930A5D2D5D6AEAA196C33B From ipsec-request@ans.net Tue Oct 10 07:25:27 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17601 (5.65c/IDA-1.4.4 for ); Tue, 10 Oct 1995 07:25:27 -0400 Received: by interlock.ans.net id AA25055 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 10 Oct 1995 07:19:28 -0400 Message-Id: <199510101119.AA25055@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 10 Oct 1995 07:19:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 10 Oct 1995 07:19:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 10 Oct 1995 07:19:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 10 Oct 1995 07:19:28 -0400 Date: Tue, 10 Oct 95 13:14:17 IDT From: Sara Bitan Subject: Photuris 03 To: IPSEC , William Allen Simpson X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hello Bill! While implementing Photuris I've found some possible inconsistency in the draft. Section 2.3 "Exchange Scheme" states: "Selection among several different schemes is needed to enable experimental and proprietary extensions without affecting the basic protocol. The Initiator of the exchange specifies a list of the ^^^^^^^^^ schemes supported, and the Responder chooses one which it ^^^^^^^^^ supports. " However, the detailed protocol description states that Offered-Schemes are offered by the *Responder* in the Cookie_Response message (section 3.2) and the Scheme-Choice is returned by the *Initiator* in the Key_Request message (section 4.1). Thanks, Sara From ipsec-request@ans.net Tue Oct 10 14:27:23 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16712 (5.65c/IDA-1.4.4 for ); Tue, 10 Oct 1995 10:39:15 -0400 Received: by interlock.ans.net id AA50085 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 10 Oct 1995 10:32:38 -0400 Message-Id: <199510101432.AA50085@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 10 Oct 1995 10:32:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 10 Oct 1995 10:32:38 -0400 Date: Tue, 10 Oct 95 14:27:23 GMT From: "William Allen Simpson" To: IPSEC Subject: Re: Photuris 03 > From: Sara Bitan > "Selection among several different schemes is needed to enable > experimental and proprietary extensions without affecting the basic > protocol. The Initiator of the exchange specifies a list of the > ^^^^^^^^^ > schemes supported, and the Responder chooses one which it > ^^^^^^^^^ > supports. " > Yes, that was left over text from -02. It was fixed in -04. Thanks. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Tue Oct 10 21:10:16 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16823 (5.65c/IDA-1.4.4 for ); Tue, 10 Oct 1995 17:08:26 -0400 Received: by interlock.ans.net id AA22098 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 10 Oct 1995 17:01:27 -0400 Message-Id: <199510102101.AA22098@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 10 Oct 1995 17:01:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 10 Oct 1995 17:01:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 10 Oct 1995 17:01:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 10 Oct 1995 17:01:27 -0400 Date: Tue, 10 Oct 1995 14:10:16 -0700 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net, caronni@tik.ee.ethz.ch Subject: Re: Comments on draft-ietf-ipsec-skip-02 X-Sun-Charset: US-ASCII Germano, Thanks for your detailed and thoughtful comments. I will send a detailed reply a little bit later, given the extensive nature of your comments. On a related note, many people are privately e-mailing me comments and questions. Please cc the ipsec mailing list on your comments/questions. This is a work item of the ipsec WG, and a group discussion is more useful than private one-on-one discussions. Thanks, Ashar. From ipsec-request@ans.net Wed Oct 11 13:23:09 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18601 (5.65c/IDA-1.4.4 for ); Wed, 11 Oct 1995 09:45:43 -0400 Received: by interlock.ans.net id AA22306 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 11 Oct 1995 09:36:40 -0400 Message-Id: <199510111336.AA22306@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 11 Oct 1995 09:36:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 11 Oct 1995 09:36:40 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-photuris-04.txt Date: Wed, 11 Oct 95 09:23:09 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Photuris Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-photuris-04.txt Pages : 51 Date : 10/10/1995 Photuris [Firefly] is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-photuris-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-04.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-photuris-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951010101909.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-photuris-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-photuris-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951010101909.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Wed Oct 11 07:51:17 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12216 (5.65c/IDA-1.4.4 for ); Wed, 11 Oct 1995 12:00:50 -0400 Received: by interlock.ans.net id AA84240 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 11 Oct 1995 11:53:02 -0400 Message-Id: <199510111553.AA84240@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 11 Oct 1995 11:53:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 11 Oct 1995 11:53:02 -0400 Date: Wed, 11 Oct 95 11:51:17 EDT From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: Security Problems in Photuris #1 In spite of the attempt of Bill to discredit me and my findings about security holes in Photuris, the issues I brought up are serious and substantial. They apply to Photuris draft 03 (referred to as Photuris.03 in the sequel) and several of them were identified long ago (>6 months) and no action was taken. I consider this situation unacceptable: can we afford defining an insecure key management protocol for IP??? I will try to elaborate on these issues in a few messages to this list. Ran Atkinson referred to my last note as "impenetrable" and I can't but agree with him. To understand these issues one needs much more background on these problems than I have provided to the list. I mainly intended my last note to the editors of Photuris whom I expect to be more knowledgeable of the subtle issues involved here, and with whom I had the opportunity to discuss some of the issues in the past. I hoped that by having the editors taking care of these changes, my life, and yours, would be easier, and our convergence to a secure protocol faster. Since this is not happening I will try to be more explicit about the Photuris problems. All the issues that I'll mention are related to Photuris.03 (except if otherwise noted). The problems fall in different categories, and have varying effect on the security. Some of these categories are (I will elaborate on the particular examples in the upcoming messages): (1) insecure mechanisms. For example, the allowed use of digital signatures to be applied to secret information, or the derivation of keys for DES-CBC and keyed-MD5. (2) insufficient mechanisms. For example, missing defenses against replay for the Change_Message, or the proposed solution to fast re-key. (3) language problems. Usually, missing or insufficient specification of cryptographic requirements or functionality. The specifications for the certificate field in the signature message is an example. As a general remark: I will point out to problems, and will suggest solutions. I am not contributing text at this time since this would increase too much my wasted time if the editors oppose these changes. In case they are receptive to the need for change I may try to contribute text as well. *An important point to stress*: none of the changes I propose require any radical modification to the protocol, or to ongoing implementations of the protocol, they are simple to do and are fundamental to the security of the protocol. I hope people will read this, and give their feedback (in favor or against the required changes) to the list. Waiting for a "last call" to deal with the basic security of the protocol would be irresponsible. Also from my part. We need to give time to other people (in particular, other cryptographers) to scrutinize these security solutions as well. TO BE CONTINUED Hugo From ipsec-request@ans.net Wed Oct 11 10:48:23 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12072 (5.65c/IDA-1.4.4 for ); Wed, 11 Oct 1995 15:04:03 -0400 Received: by interlock.ans.net id AA69269 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 11 Oct 1995 14:53:12 -0400 Message-Id: <199510111853.AA69269@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 11 Oct 1995 14:53:12 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 11 Oct 1995 14:53:12 -0400 Date: Wed, 11 Oct 95 14:48:23 EDT From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: Security problems in Photuris #2 Summary of this message: I claim that the security of Photuris needs to be guaranteed not only based on its default transforms, but for any replacement of these transforms by other secure algorithms. The current definition of Photuris does not satisfy this criterion. As an example, use of plain RSA signature as the signature attribute in the protocol discloses the exchanged DH key. [Whoever consider this not to be a serious and practical security bug, please let us know.] Protocol security and Algorithm independence ******************************************** Photuris is intended to be algorithm independent. To me this means that the protocol with the defined default algorithms is secure, but also that substituting any default algorithm by another that has the same required security functionality, e.g., encryption, signature, would result in a secure implementation of the protocol. For example, any specifications-conformant implementation of Photuris that uses a sound digital signature algorithm as its "signature attribute" (as well as other secure algorithms for the other attributes) must result in a secure key-exchange protocol. If the use of a particular, secure (i.e., computationally unforgeable) signature method results in an insecure implementation of Photuris then the protocol, as defined, is *insecure*. In such a case we can either * change the protocol, or * explicitly specify the extra requirements from the function (e.g., "a signature-attribute is a signature function that is infeasible to forge *and also* protects the secrecy of the signed information.") The first option is generally preferable if it does not add unnecessary complexity to the protocol (the second option increases the chances of a mistaken implementation, and reduces the number of useful algorithms). Some of my claims about Photuris insecurity fall under the above understanding of algorithm independence. Namely, I show that for particular choices of signature or encryption algorithms the resultant Photuris realization is insecure. The algorithms used in my examples are well-known and secure, still their use makes Photuris insecure. This does not contradict in any way that there exist certain signature and encryption algorithms for which Photuris is secure. It is not enough that *there exist* secure conformant implementations of Photuris, it must be that *all* conformant implementations are secure. In addition, I warn about accepting the security of a protocol only based on the fact that all the *known* examples of algorithms that realize a given attribute happen to have some extra feature. For example, cryptographic hash functions are designed with the goal of being "collision-resistant", ie. to guarantee infeasibility of finding collisions. If we need the algorithm to provide some extra feature, e.g., that the output of the function does not leak any information on its input, or that the output is unpredictable (or pseudorandom), then these properties need to be explicitely specified. The following is an example of a security failure in Photuris, related to the above algorithm-independence issue. Problems with the signature message *********************************** Section 5.3 specifies the information on which the signature is verified (which in turn defines the information on which the signature is computed) > 5.3. Verification > > The two parties now verify the signatures received. The indicated > Signature-Choice is calculated over the following concatenated > values: > > + the computed shared-secret, + [other fields] Clearly, any signature-choice that has the property of *not hiding* the contents of the signed information will leak information on the shared-secret (ie., the DH key). And there is *no requirement* (in the Photuris document, or elsewhere in the literature) that a signature scheme should hide the information contents. Moreover, we also have a handy example of such a signature: plain RSA (without hashing). If you see an RSA signature computed directly on a piece of data D then the public verification process of that signatures consists of *recovering D*. In this case, the whole shared-secret has leaked! (Notice that if one uses a 1024 RSA modulus and works for the DH exchange over a 155-bit fields then the whole signed information fits in 1024 bits, as required for such a plain RSA signature). Bill answered to this security bug by saying that the current default signature-choice which is MD5-based does not suffer of that problem. [This is right if we assume that MD5 with an appended secret key (which is the default signature-choice in Photuris) does not leak information on its input (a property that is not guaranteed by cryptographic or collision resistant hash functions).] However, even if this mechanism is secure it does not guarantee the security of Photuris when using other signature transforms. And the above RSA example shows that, indeed, there are natural signatures that would reveal the whole shared-secret. How to fix the above "sign the shared-secret" bug? One solution is to fix the "language": specify that only signature-attributes that cryptographically hide the signed information are acceptable. Or just leave "signatures" to mean what they traditionally mean (ie., unforgeability), and add an explicit mechanism that takes care of the required additional aspects. I vote for the second way. In the next message I will present the solution I suggest. Hugo From ipsec-request@ans.net Wed Oct 11 22:46:08 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15387 (5.65c/IDA-1.4.4 for ); Wed, 11 Oct 1995 18:54:16 -0400 Received: by interlock.ans.net id AA68124 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 11 Oct 1995 18:46:38 -0400 Message-Id: <199510112246.AA68124@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 11 Oct 1995 18:46:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 11 Oct 1995 18:46:38 -0400 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 11 Oct 1995 18:46:38 -0400 Subject: ENskip 0.14 available To: skip@tik.ee.ethz.ch (SKIP Software), skip-info@tik.ee.ethz.ch, ipsec@ans.net, iialan@iifeak.swan.ac.uk Date: Wed, 11 Oct 1995 23:46:08 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 1872 -----BEGIN PGP SIGNED MESSAGE----- Hello everybody, the SKIP interoperability work done in Atlanta has lead to a new (slightly improved) version of ENskip. The pre-alpha source code release 0.14 for IRIX, NetBSD, Nextstep and Solaris (for this verision only Solaris has been tested, the others should work nevertheless) is available as: ftp://www.tik.ee.ethz.ch/pub/packages/skip/ENskip-0.14pa.tgz Currently only the old draft skip-00 is implemented. We expect to add DH calculation soon, and will switch to the new draft in the next few months. Friendly greetings, Germano Excerpt from the README: ======================================================================== This is ENskip, pre-alpha 0.10. ENskip is a security module for the TCP/IP stack. It provides encryption, authentication and sequencing of packets on the IP layer between two or more machines. For more information on the SKIP protocol, see the Internet Draft draft-ietf-ipsec-aziz-skip-00.txt and following. You might also want to check http://skip.incog.com for information about the background, the protocol itself and future directions of it. ENskip is pre-alpha. If you are not absolutely sure what this is all about, you might want to read the draft, and perhaps reconsider using this package. No bug-fixes, installation help or any other support is granted. If you have any suggestions, comments or contributions to make ENskip work better, mail to skip@tik.ee.ethz.ch. Enjoy! M. Hauber and Ch. Schneider G. Caronni ======================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHxJLLH8jId7euXhAQFC9gP8DxQiB3C0n/SPNtsAm6mPDPKtOi/zdJXl EP2N15y468+Y9C62P51uToxzBicDIgDGW8tYdljoe3a/3gNvRNPkC1ItIHEB7TQ+ xUGE6wKTKdQMyOFyiwF5AolAWTgZjEIQzndw7iO4ya/jBb+w9i08JmF4QorNbwiT SgBrVLPRXFE= =/yZy -----END PGP SIGNATURE----- From ipsec-request@ans.net Thu Oct 12 00:51:30 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17015 (5.65c/IDA-1.4.4 for ); Wed, 11 Oct 1995 21:47:04 -0400 Received: by interlock.ans.net id AA03817 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 11 Oct 1995 21:39:25 -0400 Message-Id: <199510120139.AA03817@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 11 Oct 1995 21:39:25 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 11 Oct 1995 21:39:25 -0400 Date: Thu, 12 Oct 95 00:51:30 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Security problems in Photuris #2 > From: hugo@watson.ibm.com > > Summary of this message: I claim that the security of Photuris > needs to be guaranteed not only based on its default transforms, > but for any replacement of these transforms by other secure algorithms. I dispute your claim. You did not specify the scope of "secure". This statement would require that a zero-knowledge proof of a Hamiltonian cycle (to pick something randomly from Schneier) would be an appropriate algorithm for Photuris. > The current definition of Photuris does not satisfy this criterion. > As an example, use of plain RSA signature as the signature attribute > in the protocol discloses the exchanged DH key. I cannot find _anywhere_ in our documents where a "plain" RSA signature is mentioned, let alone used. Plain RSA alone is not secure for digital signatures over any hidden text. And it is "just plain inefficient"! The forms of signatures specified are currently DNS-SIG, DSS, MD2, MD4, MD5, PGP, PKCS, SHA, and X.509. MD5 is required. The others are not specified in the base document, but have been split off to an extensions document. Therefore, I refuse to discuss their details until the base is complete. > Photuris is intended to be algorithm independent. No, it is not. Only a few, well chosen, algorithms are specified. Anything else would destroy interoperability and burden the implementor. Protocol designers are expected to have both knowledge and common sense. Implementors are expected to follow the specification. Bad assumptions lead to a bogus argument. 'Nuff said. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Oct 11 17:44:36 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16768 (5.65c/IDA-1.4.4 for ); Wed, 11 Oct 1995 21:50:52 -0400 Received: by interlock.ans.net id AA55092 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 11 Oct 1995 21:46:23 -0400 Message-Id: <199510120146.AA55092@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 11 Oct 1995 21:46:23 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 11 Oct 1995 21:46:23 -0400 Date: Wed, 11 Oct 95 21:44:36 EDT From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: Security Problems in Photuris #3 Summary of this message: The issue of this note is how to fix the signature message of Photuris.03 in order to avoid the security holes discussed in my previous notes (mainly, the signing of the shared-secret) as well as the lack of clear specifications for the Certificate field as discussed below. I start by a lengthy discussion of the subtle cryptographic issues behind the protocol, and then present a solution based on this discussion. The length of the present note does not represent the complexity of the solution but the complexity of its rationale. The Photuris changes required by this solution are minimal (both in terms of specifications and implementation). The solution can be read in sections "The signature message using Digital Signatures" and "The pre-shared key signature option", below. How to sign in the Signature_Message ************************************ To really understand this solution and the real problems it comes to solve (which are more involved than the sole issue of signing or not the shared-secret), one needs a good understanding of the cryptographic subtleties surrounding this protocol. I will make an attempt to explain some of the issues here, though a complete treatment of this would require an even more detailed discussion. Notice that the way I presented the Photuris signature bug is by explaining that information on the shared-secret can be leaked by a signature. One could wonder why, in the first place, is the shared-secret signed. A (partial) answer is that: * the signature message in Photuris has dual cryptographic functionality * It serves to (1) authenticate the DH exponents (2) to prove possession of the shared-secret (ie. DH key) by the parties, and to bind this shared-secret to the identity of the parties. The first item is mandatory to prevent traditional man-in-the-middle attacks aga The second is far more subtle and its need was pointed out in the (excellent) paper on the STS protocol (that paper is referenced as [DOW92] in Photuris, and is a must to read to understand the issues discussed here). It turns out that without (2) the protocol would be insecure. I elaborate on this after the following note. [Note on STS vs Photuris: STS and Photuris are different protocols as a whole. However, they have a lot in common and many of the cryptographic aspects of STS are applicable to Photuris. This allows us to apply (where relevant) the lessons learned from the STS protocol to Photuris. I note that the issues discussed in this message apply to Photuris.03, and may or may not apply to STS.] To see the need to involve the shared-secret into the authentication of the protocol, let's take Photuris.03 as defined but remove the shared-secret from the signed information. We assume for simplicity that no anonymity-encryption is in place (such encryption is optional in Photuris). An attacker, Eve, can now act between A and B (which represent Initiator and Responder, respectively) as follows. Eve leaves all the Photuris messages flowing between A and B unchanged except that she replaces two fields in A's signature message: she replaces A's certificate by her own, and changes the signature field to Eve's signature. Since all information being signed is public Eve can easily do that. The result of such an attack is that Eve does not know the shared secret, however while A believes to have exchanged the key with B, B believes to have exchanged it with Eve. The actual effects of such an attack depend on the particular scenario where the protocol is run; see [DOW92] for an example of possible consequences. The abstract problem behind this attack is the lack of cryptographic binding between the identities of the parties and the shared-secret. There are several possible fixes to this problem. The idea is that any party, say Eve, that does not know the shared-secret (i.e. the DH key) should not be able to trick B to believe that he (B) was communicating with Eve. The STS protocol uses encryption of the signature message under the DH key to avoid this problem. I have observed that encryption, in general, is not a good enough protection here. [In particular, if a stream cipher mode of encryption is being used I can present two weaknesses of this solution (this applies even for ideal one-time pad encryption), other modes of encryption may suffer of similar weaknesses as well. I will not elaborate on this here.] For Photuris this means that even if encryption of the signature_message is used for anonymity, this encryption does not solve the above problem. Photuris.03 uses the signing of the shared-secret to solve the above impersonation problem. This is a tricky solution. Reason 1: As pointed out before, if the signature does not provide secrecy of the signed information then the shared-secret (or information about it) can be disclosed. Reason 2: Even if a signature with secrecy protection is used but the identity of the signer is *not* included in the signature, the protocol becomes insecure. To see the latter, consider the example of a signature performed with RSA and MD5 hashing. In this case, Eve doesn't need to find the shared-secret in order to replace A's signature with her own. She just uses A's public key to recover the hashed information, and then sign it herself (no need to know the shared-secret)! By including the identity of the signer in the signed information this problem is solved. (The need to sign the identity of the signer may seem counter-intuitive -- why wouldn't be the use of a private key enough? -- but essential for security here.) Therefore, we have learned that we need to (1) sign the DH exponents (2) prove that the parties know the shared secret (DH key) (3) bind the identity of the signer to the shared-secret. Notice that Photuris.03 provides this binding through the inclusion of the Certificate field in the signature. What the current draft fails to make clear is the mandatory need to *always* include the identity of the signer in the certificate field (current language in Photuris.03, implies that an implementation could not include a certificate at all, and then, in particular, no identity into the signature). This issue is further clarified below. Given all this background on these subtle protocol issues, and Photuris deficiencies in addressing them, here is my proposed solution. For concreteness, I first present the solution assuming the use of a public key-based digital signature, later I will show the solution for the case of parties that have a previously-shared key (e.g., a manually installed master key, a Kerberos key, etc), and use this key to authenticate the DH exchange. As we'll see, the solution to the second is a "particular case" of the former. The signature message using Digital Signatures: ********************************************** Most of the signature-message is unchanged from the specification in Photuris.03. The changes are in the signature-choice, the signature computation, and the certificate specification. The Signature-Choice variable will specify the following attributes (1) Digital signature algorithm (e.g., RSA, DSS), and a corresponding certificate method (e.g., X.509, DNS, PGP, private formats, etc). (2) a keyed MAC algorithm (e.g. keyed-MD5 a la RFC-1829, envelope SHA, DES-CBC-MAC, etc.). [(1) is identical to what Photuris.03 specifies; (2) is an additional specification here] The Certificate MUST include at a minimum the identity of the signer, and may include additional information binding the public key of that signer with the identity (as in traditional certificates). [This is different than what's specified by Photuris.03 in the sense that we add the "MUST requirement" that the Certificate field includes at a minimum the identity. This mandatory inclusion is not clear in Photuris.03 which states > Certificate variable precision number. When the Signature- > Choice indicates a certification method, such as > X.509, PGP or DNS-SIG, the certificate is included. > > The content is outside the scope of this > specification. Although the field is depicted as > 32-bit aligned for convenience, the size may be > shorter or longer, as indicated by its integral Size > field. For example, an implementation that does not use regular certificates, but just uses the sender's IP address to retrieve the public key of the sender (from a local data base, a directory, etc), may interpret the above specification as saying that in such a case the certificate field may not be included at all. This would be insecure; instead, the IP address on which the public key search is based must be included in that field.] The signature field is computed by (1) key the MAC function using the computed shared-secret (the MAC function is as specified by the Signature-Choice variable); apply this keyed MAC to the information as stated in Photuris.03 with the exception of the shared-secret, namely, MAC the information: + the Offered-Schemes, + the SPI Owner (receiver) Exchange-Value, + the SPI User (sender) Exchange-Value, + the SPI Owner (receiver) Offered-Attributes, + the SPI User (sender) Offered-Attributes, + the Type, LifeTime and SPI, + the Certificate + the contents of the remainder of the message following the Certificate. [Notice that I erased the phrase "(which may be specially handled)" appearing in Photuris.03 after "the Certificate" in the above list. I do not understand what does it mean. By the requirement that the certificate field must contain the identity of the sender we guarantee that the MAC computation includes this identity] Note: I would like to eventually change the structure of the above list (e.g., put the Offer-Attributes at the end, have all the message signed instead of parts of it, etc.), but this is a secondary issue and would distract us from the more essential issues. (2) Apply the Digital Signature, as specified by the Signature-choice variable, using the sender's private-key and computed on the result of the MAC computation described in (1). The pre-shared key signature option *********************************** An important scenario to support is that of communicating parties that share a key before the execution of the Photuris key-exchange. We call this key a pre-shared key. This pre-shared key could have been shared via a previous execution of Photuris, or it can be a manually installed key -- e.g., between a user's laptop and the user's workstation --, or via Kerberos distribution, and so on. In such a case the parties may use the pre-shared key to authenticate the DH exchange, thus avoiding the need and cost of the digital signature. The above solution to the Signature_Message will work in this case by performing the MAC computation as explained above but with the key to the MAC being the pre-shared key (instead of the shared-secret). The digital signature computation is omitted. Notice that in this case the sender needs to specify the pre-shared key in use. This can be done by including a "pointer" to this key (e.g., an SPI, a key-identifier, etc.) in the certificate. Issues: ****** * how long should signature-choice be to include the specification of the MAC function (are 16 bits still enough?) * need to provide attribute codes (or types) to be used as signature-choice when a pre-shared key is used for authentication (namely, these codes would specify a MAC function, and the omission of a digital signature). Implementations need to be careful in this case to use the specified pre-shared key for keying the MAC, and not using the shared-secret for that purpose. * Another subtle issue for future treatment: since MAC functions are not guaranteed by definition not to leak (partial) information on their keys, one should not use the shared-secret directly to key the MAC but a key derived from the shared-secret; alternatively, one can use the Key-Generator function as a MAC. Since all the issue of deriving keys from the shared-secret is not well resolved in Photuris.03, I'll leave this issue for future discussion. * Non-repudiation (if you are not a real crypto fun, skip this): the solution of signing a MAC value contradicts the traditional property of non-repudiation provided by digital signatures. If such non-repudiation would be a requirement for Photuris, my solution wouldn't be acceptable. [The point is that for some MAC functions (e.g., DES-MAC) the party knowing the MAC key can find different messages mapping to the same MAC value and then could argue that its peer signed a different stream of information than it really did.] I find this perfectly acceptable for Photuris: Not only should non-repudiation be a non-goal of Photuris; ideally, complete repudiability of communication should have been a property of key-exchange for IP. I explained this privacy-related issues in the past (related to my "Photuris variant"). If non-repudiation had to be provided then some slight modifications of the above solution could achieve that (e.g., hash with a collision resistant function before MAC-ing, or use a collision-resistant MAC; MAC-ing a signature instead of signing the MAC is another possibility, however it requires an extra field and accomodates less naturally the pre-shared key case). Hugo From ipsec-request@ans.net Thu Oct 12 21:11:49 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16993 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 03:38:15 -0400 Received: by interlock.ans.net id AA03681 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 03:26:56 -0400 Message-Id: <199510120726.AA03681@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 12 Oct 1995 03:26:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 03:26:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 03:26:56 -0400 Date: Fri, 13 Oct 95 03:11:49 CST From: liny@liny.csie.nctu.edu.tw (lin) To: ipsec@ans.net Subject: please post The ACM/Baltzer Wireless Networks Journal announces a special issue on Personal Communications Scope: Personal communications provide communication services anywhere, anytime, with anybody, and in any form. To implement the personal communications concepts, extremely sophisticated systems which integrate many diverse technologies are required. This special focuses on the research and development of advanced PCS technologies. Original contributions related to the following topics are solicited: - Small scale mobility (handover) management - Channel allocation algorithms - Large scale mobility (roaming) management - Privacy and authentication - Multi-tier system - PCS database reliability - Intelligent networks for PCS - PCS data applications - PCS backbone architecture (e.g., ATM) - Local wireless network - Wireless multimedia - Mobile IP - Modeling of PCS (measurement, analysis, and simulation) Authors are invited to submit postscript files of their papers to liny@csie.nctu.edu.tw or submit 6 copies of their papers to Professor Yi-Bing Lin, Dept. Comp. Sci. & Info. Engr., National Chiao Tung University, Hsinchu, Taiwan, R.O.C. Papers should not exceed twenty double spaced pages in length, excluding figures and diagrams. Submission deadline: April 15, 1996 Acceptance notification: July 30, 1996 Final manuscript due: October 30, 1996 Guest editors: Yi-Bing Lin Dept. Comp. Sci. & Info. Engr. National Chiao Tung University Hsinchu, Taiwan, R.O.C. Russell T. Hsing Bellcore MRE 2M199 445 South St. Morristown, NJ 07960 trh@thumper.bellcore.com From ipsec-request@ans.net Thu Oct 12 13:27:25 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17488 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 09:38:07 -0400 Received: by interlock.ans.net id AA68201 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 09:27:29 -0400 Message-Id: <199510121327.AA68201@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 12 Oct 1995 09:27:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 09:27:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 09:27:29 -0400 To: Hilarie Orman Cc: ipsec@ans.net Subject: Re: 3DES keys In-Reply-To: Your message of "Tue, 03 Oct 1995 20:08:13 EDT." <199510040308.AA61683@interlock.ans.net> Date: Thu, 12 Oct 1995 09:27:25 -0400 From: "Donald E. Eastlake 3rd" I suppose people like 3DES becasue the financial community is headed that way and there is hardware for it. But if I wanted something stronger than DES but keeping the measly 64 bit block size, I think I'd go for D-I-D. You take 128 bits of key, DES with the top 64 (ignoring parity), IDEA the output with them all, then DES with the bottom 64 (ignoring parity). Then you can CBC around the whole thing. Donald From: Hilarie Orman To: bsimpson@morningstar.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199510020505.AA26294@interlock.ans.net> }RSA Labs, http://www.rsa.com/rsalabs/cryptobytes/spring95/news.htm: } } Modes involving single-DES instead of triple-DES as a primitive, such } as encrypting three times with single-DES in cipher block chaining } mode, have been shown by Eli Biham in the past year to be potentially } no stronger than single-DES against certain attacks. Encrypting with } triple-DES in cipher block chaining mode is not vulnerable to those } attacks. } }... } From ipsec-request@ans.net Thu Oct 12 14:44:09 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12270 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 11:04:33 -0400 Received: by interlock.ans.net id AA43932 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 10:51:50 -0400 Message-Id: <199510121451.AA43932@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 10:51:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 10:51:50 -0400 Date: Thu, 12 Oct 95 14:44:09 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Photuris generality Because the generality of Photuris has apparently lead to the misconception that it is applicable to every current and future cryptographic mechanism, I have added the following Design Notes: Although attributes offer great flexibility, only a few well-chosen algorithms are specified. This provides opportunity for intensive review by the cryptographic community, reduces implementation complexity, and improves potential for interoperability. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Thu Oct 12 06:06:02 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17467 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 11:25:58 -0400 Received: by interlock.ans.net id AA92681 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 11:08:07 -0400 Message-Id: <199510121508.AA92681@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 11:08:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 11:08:07 -0400 Date: Thu, 12 Oct 95 10:06:02 EDT From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: Security problems in Photuris #2 Ref: Your note of Thu, 12 Oct 95 00:51:30 GMT (attached) Here are my answers to Bill's message. The moral is: We need a robust and secure Photuris for many years to come. Let's do it right. The mechanisms I propose pay no extra penalty relative to what is in Photuris today and they increase security and robustness. Let's not wait to last minute to do changes because I want my own proposals scrutinized by others. > > > From: hugo@watson.ibm.com > > > > Summary of this message: I claim that the security of Photuris > > needs to be guaranteed not only based on its default transforms, > > but for any replacement of these transforms by other secure algorithms. > > I dispute your claim. You did not specify the scope of "secure". I wish the Photuris draft would have specified this scope. It would make the whole specification clearer and more robust. I was not trying to get too much into specifications. But, I believe it is clear from the rest of my original message that the security of an algorithm is relative to the functionality it gives. For example, a signature algorithm provides for authentication and unforgeability AND NOT FOR SECRECY. > > This statement would require that a zero-knowledge proof of a > Hamiltonian cycle (to pick something randomly from Schneier) would be an > appropriate algorithm for Photuris. If you read my message it says To me this means that the protocol with the defined default algorithms is secure, but also that substituting any default algorithm by another that has the same required security functionality, e.g., encryption, signature, would result in a secure implementation of the protocol. Notice the words "same required security functionality"; a zero-knowledge proof of Hamiltonian cycle is a beautiful protocol but no one has claimed it achieves any of the functionalities required by Photuris, like signature, encryption, authentication, etc. > > > The current definition of Photuris does not satisfy this criterion. > > As an example, use of plain RSA signature as the signature attribute > > in the protocol discloses the exchanged DH key. > > I cannot find _anywhere_ in our documents where a "plain" RSA signature Plain RSA is not explicitely specified in Photuris. I gave it as a natural, easy to understand, example of a signature function that does not hide the signed text. The basic point is: digital signatures do not hide text by definition (or requirement). Hiding the text may (or may not) be achieved as a "side effect" of particular mechanisms like hashing. But even hashing, in general, does *not* guarantee the hiding of text. We are not even sure about this property for the current natural candidates like MD5. We definitely cannot guarantee that property for each of the algorithm that with time people will want to use with Photuris. On the other hand, Photuris is "plain insecure" if this secrecy property is not provided by the signature attribute. Photuris has to be robust enough to remain secure for long time, even when algorithms change (and they will!) because of efficiency or security reasons!!!! > is mentioned, let alone used. Plain RSA alone is not secure for digital > signatures over any hidden text. And it is "just plain inefficient"! I don't want to discuss the merits of plain RSA. I am not proposing (or recommending) using this mode of RSA. It is just a very natural, practical example. (And if efficiency is your issue, then let me remark that it is *more* efficient if the signed text is no longer than the RSA modulus, as the case of Photuris with 155-bit elliptic curve) > > The forms of signatures specified are currently DNS-SIG, DSS, MD2, MD4, > MD5, PGP, PKCS, SHA, and X.509. MD5 is required. The others are not > specified in the base document, but have been split off to an extensions > document. Therefore, I refuse to discuss their details until the base > is complete. > > > > Photuris is intended to be algorithm independent. > > No, it is not. HUH?! I thought Photuris follows the decisions of the IPSEC WG. Let me cite from RFC1825 " Security Architecture for IP": This section describes some of the design objectives of this security architecture and its component mechanisms. The primary objective of this work is to ensure that IPv4 and IPv6 will have solid cryptographic security mechanisms available to users who desire security. These mechanisms are designed to avoid adverse impacts on Internet users who do not employ these security mechanisms for their traffic. These mechanisms are intended to be algorithm-independent so that the cryptographic algorithms can be altered without affecting the other parts of the implementation. These security mechanisms should be useful in enforcing a variety of security policies. Standard default algorithms (keyed MD5, DES CBC) are specified to ensure interoperability in the global Internet. Let me highlight this part from the above citation: ************************************************************************* * These mechanisms are intended to be algorithm-independent so that the * * cryptographic algorithms can be altered without affecting the other * * parts of the implementation. * ************************************************************************* And just to be clear about the point I made above, let me repeat it Photuris has to be robust enough to remain secure for long time, even when algorithms change because of efficiency or security reasons !!!! > Only a few, well chosen, algorithms are specified. For immediate interoperability purpose this is perfect. But please give guidance to the future implementor/user on how to decide on "well chosen" algorithms. > > Anything else would destroy interoperability and burden the implementor. > > Protocol designers are expected to have both knowledge and common sense. Well, at least an issue where we are in complete agreement!!! > > Implementors are expected to follow the specification. Again we are in agreement. This is *exactly* why I am so concerned about the current specifications > > Bad assumptions lead to a bogus argument. > > 'Nuff said. > > Bill.Simpson@um.cc.umich.edu > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Bill, please. We are wasting time here. Let's go on. Stubborn defiance will not help us. And Phil, where are you???????? Hugo From ipsec-request@ans.net Thu Oct 12 16:37:46 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15468 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 13:26:21 -0400 Received: by interlock.ans.net id AA78484 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 13:11:45 -0400 Message-Id: <199510121711.AA78484@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 13:11:45 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 13:11:45 -0400 Date: Thu, 12 Oct 95 16:37:46 GMT From: "William Allen Simpson" To: IPSEC@ans.net Subject: Re: Security problems in Photuris #2 > From: hugo@watson.ibm.com > I was not trying to get > too much into specifications. But, I believe it is clear from the rest > of my original message that the security of an algorithm is relative to the > functionality it gives. > On the other hand, I am _only_ interested in specifications. The latter sentence is not obvious. What relation? What does it add to the specification? (and where would it be put?) > Notice the words "same required security functionality"; a zero-knowledge > proof of Hamiltonian cycle is a beautiful protocol but no one has claimed it > achieves any of the functionalities required by Photuris, like signature, > encryption, authentication, etc. > Actually, in our terms, it is _not_ a protocol, it is an algorithm. > I don't want to discuss the merits of plain RSA. I am not proposing (or > recommending) using this mode of RSA. It is just a very natural, practical > example. What you have done is specified a "straw man". You admit that it has none of the functionalities required by the Photuris protocol. Since Photuris does not recommend its use, and you are unwilling to recommend its use, why have you wasted our time? > (And if efficiency is your issue, then let me remark that it > is *more* efficient if the signed text is no longer than the RSA modulus, > as the case of Photuris with 155-bit elliptic curve) > Another inapplicable "straw man", since Photuris clearly indicates that the signed text includes more than the shared-secret. > Bill, please. We are wasting time here. Let's go on. Stubborn defiance will > not help us. > You are correct. You are wasting our time. Stubborn disputation of irrelevancies will not help us. > And Phil, where are you???????? > Surely, if he finds a point that is interesting, he will answer it. Why do you continue to insist on badgering everyone to answer you? Well, I've had enough. Let's go on. Does anyone else have something useful to add to Photuris? Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Thu Oct 12 17:37:21 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17038 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 13:46:14 -0400 Received: by interlock.ans.net id AA78390 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 13:37:33 -0400 Message-Id: <199510121737.AA78390@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 13:37:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 13:37:33 -0400 From: David A Wagner Subject: Re: Security problems in Photuris #2 To: bsimpson@morningstar.com (William Allen Simpson) Date: Thu, 12 Oct 1995 10:37:21 -0700 (PDT) Cc: ipsec@ans.net In-Reply-To: <199510120139.AA03817@interlock.ans.net> from "William Allen Simpson" at Oct 12, 95 00:51:30 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 564 > Plain RSA alone is not secure for digital > signatures over any hidden text. > > Photuris is intended to be algorithm independent. > > No, it is not. Only a few, well chosen, algorithms are specified. > Bad assumptions lead to a bogus argument. I propose a simple compromise: document the assumptions. Since Bill keeps asking for text contributions, here's one: ``Photuris signature transforms must hide their input. A signature transform which leaks information about its input is unsuitable for use in Photuris.'' From ipsec-request@ans.net Thu Oct 12 18:02:28 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17891 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 14:10:30 -0400 Received: by interlock.ans.net id AA92671 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 14:02:52 -0400 Message-Id: <199510121802.AA92671@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 14:02:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 14:02:52 -0400 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: bsimpson@morningstar.com Cc: IPSEC@ans.net Subject: Re: Security problems in Photuris #2 In-Reply-To: Your message of "Thu, 12 Oct 1995 10:06:02 EDT." <199510121508.AA92681@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 12 Oct 1995 14:02:28 -0400 From: "Perry E. Metzger" hugo@watson.ibm.com writes: > Here are my answers to Bill's message. > The moral is: > > We need a robust and secure Photuris for many years to come. > Let's do it right. > The mechanisms I propose pay no extra penalty relative to what is > in Photuris today and they increase security and robustness. > Let's not wait to last minute to do changes because I want my own > proposals scrutinized by others. I'd like to say that I think Hugo's comments ought to be seriously discussed. As he says, they don't produce any extra penalty, so if they give us potential added flexibility and strength we ought to consider them seriously. Given that we have no installed base to remain compatible with, its worth talking about at the very least. Perry From ipsec-request@ans.net Thu Oct 12 10:10:32 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17430 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 14:50:31 -0400 Received: by interlock.ans.net id AA03536 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 14:41:51 -0400 Message-Id: <199510121841.AA03536@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 14:41:51 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 14:41:51 -0400 Date: Thu, 12 Oct 95 14:10:32 EDT From: hugo@watson.ibm.com To: daw@CS.Berkeley.EDU Cc: ipsec@ans.net Subject: Security problems in Photuris #2 Ref: Your note of Thu, 12 Oct 1995 10:37:21 -0700 (PDT) (attached) > > I propose a simple compromise: document the assumptions. > > Since Bill keeps asking for text contributions, here's one: > > ``Photuris signature transforms must hide their input. > A signature transform which leaks information about > its input is unsuitable for use in Photuris.'' This is not a compromise. This is the absolute minimum required for the current Photuris design. As I said in my messages, language changes can help here. But why not to get a better, less restrictive design that does not require (inflexible) assumptions from a signature transform as above? The additional MAC operation I am asking for before applying the digital signature cannot be a reason not to go to a better, more robust design. Anyway, don't forget another "mandatory" language change regarding the Signature-Message. A Photuris implementation MUST sign the identity of the signer (this is unrelated to the issue of whether the signature provides secrecy or not). This can be accomplished by specifying that the Certificate field MUST always be present and, at least, include the signer's identity. Or, any other way to ensure that this identity is included in the signature (and known to the verifier). See my "Security problems in PHoturis #3" for a rationale about mandatory signing of identity. Hugo From ipsec-request@ans.net Thu Oct 12 19:25:28 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12960 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 15:31:35 -0400 Received: by interlock.ans.net id AA36573 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 15:25:39 -0400 Message-Id: <199510121925.AA36573@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 12 Oct 1995 15:25:39 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 15:25:39 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 15:25:39 -0400 X-Mailer: exmh version 1.6.2 7/18/95 To: David A Wagner Cc: bsimpson@morningstar.com (William Allen Simpson), ipsec@ans.net Subject: Re: Security problems in Photuris #2 In-Reply-To: daw's message of Thu, 12 Oct 1995 10:37:21 -0700. <199510121737.AA78390@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 12 Oct 1995 15:25:28 -0400 From: Bill Sommerfeld -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii I propose a simple compromise: document the assumptions. I was thinking the same thing.. Since Bill keeps asking for text contributions, here's one: ``Photuris signature transforms must hide their input. A signature transform which leaks information about its input is unsuitable for use in Photuris.'' Hmm. How about the following, which includes some rationale text.. "Since the shared secret is included in the value to be signed, Photuris signature transforms must not leak information about any part of their input. An example of an unsuitable signature transform would be RSA of the raw signature value." The following text may also help: "Because the shared secret is found at both the beginning and the end of the input to the signature transform, and all specified signature transforms hash their input and then sign the hash, one may look at this process as the signature of a keyed hash of the remaining fields, with the shared secret as the key." BTW, the same issue also applies to the verification of change messages in section 6.4; the validity_choice algorithm also must not leak info about the shared secret. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBMH1rpVpj/0M1dMJ/AQEHbwP9F/DLG7ET7Psi3I0X3gcioj4Jbkk/9hdp v1L/4jbWMDjUq3/Ptq2ORS9UFfkMqU9Vyzd83nYIfX6ANlxD7F1JILL8Z17DYacd nHQIDPJcXTD+JejS4Flfk3D3t7hw9rt9lkiZqy6uF2Z1wtnzD8dl3At2EGaPM0kU mdTlHkrOWj4= =t2gz -----END PGP SIGNATURE----- From ipsec-request@ans.net Thu Oct 12 19:06:41 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18372 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 15:45:25 -0400 Received: by interlock.ans.net id AA17642 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 15:39:55 -0400 Message-Id: <199510121939.AA17642@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 15:39:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 15:39:55 -0400 Date: Thu, 12 Oct 95 19:06:41 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Photuris Chapters 5 to 7 I have one more review promised me by tomorrow for 1-4. I think I'm ready to take comments on Chapters 5 through 7, while I get the new draft done over the weekend. Also, there is a minor item that folks ought to note. Originally, Photuris was intended to be published as Experimental. The WG Chairs decided that they wanted official WG review for possible Proposed Standard publication. Indeed, WG review effected some significant changes, which were suggested by implementors. In this case, adding AH and ESP on the same ports in the middle of the Photuris exchange worked fine on one platform, but was difficult on a couple of others. And so, we reorganized the messages and added explicit Privacy and Validity fields. Wide implementation experience on multiple platforms is often very helpful. But that's also true of Experimental, and would likely have happened in the normal course of events. However, most of the feedback _on_ this list has been one very verbose naysayer. Unless other members of the WG indicate to the Chairs that they desire to see this published as a Standards' Track protocol, I am quite content to stay with Experimental. For one thing, I won't have the extra grief, and publication can be that much sooner. So, while you ponder the wording of 5-7, also indicate whether you wish this published as Experimental or Proposed Standard. Thanks. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Thu Oct 12 19:46:49 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17108 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 15:52:06 -0400 Received: by interlock.ans.net id AA04176 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 15:49:37 -0400 Message-Id: <199510121949.AA04176@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 15:49:37 -0400 From: Ran Atkinson Date: Thu, 12 Oct 1995 15:46:49 -0400 Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: ipsec@ans.net Subject: Updated AH code fragment available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rja@bodhi.cs.nrl.navy.mil I've finally updated the example online AH code fragment at ftp://ftp.nrl.navy.mil/pub/ security/ipsec/ipsec-ah-fragment.c to reflect the version of AH that we included with the "alpha-quality" release of the NRL IPv6/IPsec software distribution for 4.4-Lite BSD. This implements the Simpson/Metz/Atkinson compromise on what to include with AH and is known to interoperate with Morningstar's AH implementation over IPv4. Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Thu Oct 12 08:47:51 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15494 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 18:51:58 -0400 Received: by interlock.ans.net id AA70189 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 18:48:08 -0400 Message-Id: <199510122248.AA70189@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 18:48:08 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 18:48:08 -0400 Date: Thu, 12 Oct 95 15:47:51 PDT From: rogaway@cs.ucdavis.edu (Phil Rogaway) To: bsimpson@morningstar.com, ipsec@ans.net Subject: Re: Photuris generality > Because the generality of Photuris has apparently lead to the > misconception that it is applicable to every current and future > cryptographic mechanism, I have added the following Design Notes: > > Although attributes offer great flexibility, only a few > well-chosen algorithms are specified. This provides opportunity > for intensive review by the cryptographic community, reduces > implementation complexity, and improves potential for > interoperability. > > Bill.Simpson@um.cc.umich.edu Bill -- The above is completely off the mark. What cryptographers want and expect of a protocol like Photuris is that it works under the assumption that each of its primitives is instantiated to meet the (standard) definition of the goal of that primitive. You certainly don't have that in Photruis. Adding some sort of proviso like the one you suggest isn't going to do anything to solve this problem. You do not facilitate analysis by saying that Photuris is only required to work when its primitives are drawn from a certain concrete set of possibilities; exactly the opposite-- you render cryptographic analysis impossible. Phil From ipsec-request@ans.net Thu Oct 12 15:54:57 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17680 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 20:03:03 -0400 Received: by interlock.ans.net id AA27359 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 19:55:04 -0400 Message-Id: <199510122355.AA27359@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 12 Oct 1995 19:55:04 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 19:55:04 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 19:55:04 -0400 Date: Thu, 12 Oct 95 19:54:57 EDT To: ipsec@ans.net Subject: Photuris terminology I agree with Hugo Krawczyk's concern that the use of the term "Signature" (as in section 5, "Signature Exchange") is somewhat misleading, and introduces some risk. The difficulty can be removed by slightly changing the protocol (Hugo's proposal), or adding some clarifying language. The danger, as he points out, is that the term "signature" generally refers only to a quantity computed from the message and the private key that can only be computed by someone possessing the private key, while being capable of being verified by anyone holding the corresponding public key. ***************************************************************** *** There is nothing in this notion of "signature" that means *** *** that the message can not be derived from the signature. *** ***************************************************************** Indeed, I believe that the CCITT standards distinguish explicitly between "signature schemes with message recovery" and "signature schemes without message recovery". Furthermore, it IS important that the signature scheme used not have the "message recovery" property, since part of what is signed is the computed shared-secret. At the minimum, this requirement should be noted in the document. Otherwise, there is a risk that the list of approved "signature schemes" might be inadvertently expanded in the future to include one that had message recovery. (Not by anyone currently involved in the proposal, but by some future caretaker...) I would suggest adding language of the following form somewhere (such as on the top of page 23): The Signature-Choice method must specify a signature method that does not have "message recovery": it should not be feasible to compute the message from the signature. (More specifically, it should not be feasible to compute any of the bits of the message from the signature.) This property is required of the signature method to prevent an adversary from computing the computed shared-secret from the signature. The signature methods specified in Appendix B are believed to be satisfactory from this point of view. Also, any signature scheme that signs a cryptographic hash of the message should be satisfactory. Ronald L. Rivest From ipsec-request@ans.net Fri Oct 13 00:12:35 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17022 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 20:55:08 -0400 Received: by interlock.ans.net id AA47480 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 20:48:20 -0400 Message-Id: <199510130048.AA47480@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 20:48:20 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 20:48:20 -0400 Date: Fri, 13 Oct 95 00:12:35 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: text contribution > To: David A Wagner > From: Bill Sommerfeld > I propose a simple compromise: document the assumptions. > > I was thinking the same thing.. > > Since Bill keeps asking for text contributions, here's one: > Thank you, David and Bill, for sensible suggestions. Of course, this is generally true of every encryption and authentication algorithm -- it should not leak its key. We could repeat this text in virtually every part of the draft, and in every other security document as well. Hopefully, you are not proposing such silliness. Although it is restating the obvious, at your request I have added something of the sort in the Security Considerations section: In general, where the shared-secret or session-keys are involved in any calculation, the algorithms selected should not reveal information about the secret, either directly or indirectly. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Thu Oct 12 18:54:23 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17014 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 23:03:37 -0400 Received: by interlock.ans.net id AA85996 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 22:54:28 -0400 Message-Id: <199510130254.AA85996@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 12 Oct 1995 22:54:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 22:54:28 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 22:54:28 -0400 Date: Thu, 12 Oct 95 22:54:23 EDT To: ipsec@ans.net Subject: Photuris Page 22: It is not described anywhere what the recipient is supposed to do with the "LifeTime" variable in the Signature_Message. If this is not used by the recipient, it should be omitted. (Presumably it should documented what is to be done with this by the recipient.) From ipsec-request@ans.net Thu Oct 12 18:54:53 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17781 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 23:03:37 -0400 Received: by interlock.ans.net id AA85490 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 22:54:59 -0400 Message-Id: <199510130254.AA85490@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 12 Oct 1995 22:54:59 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 22:54:59 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 22:54:59 -0400 Date: Thu, 12 Oct 95 22:54:53 EDT To: ipsec@ans.net Subject: Photuris Page 24, section 5.2, second paragraph: "The fields protected are described for each method." I don't see where these descriptions are, and I don't see why they should differ for different "methods." More explanation is needed here. From ipsec-request@ans.net Thu Oct 12 18:55:24 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12926 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 23:03:56 -0400 Received: by interlock.ans.net id AA72444 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 22:55:35 -0400 Message-Id: <199510130255.AA72444@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 12 Oct 1995 22:55:35 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 22:55:35 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 22:55:35 -0400 Date: Thu, 12 Oct 95 22:55:24 EDT To: ipsec@ans.net Subject: Photuris Page 43: It is not specified what the lengths are of the "Type" and "Length" fields themselves. Are these supposed to be single bytes, or to be inferred from the figure, or what? From ipsec-request@ans.net Thu Oct 12 18:55:53 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15491 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 23:04:13 -0400 Received: by interlock.ans.net id AA49162 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 22:56:01 -0400 Message-Id: <199510130256.AA49162@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 12 Oct 1995 22:56:01 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 22:56:01 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 22:56:01 -0400 Date: Thu, 12 Oct 95 22:55:53 EDT To: ipsec@ans.net Subject: Photuris Page 17 (Initiator-Offered-Attributes) Page 20 (Responder-Offered-Attributes) It is not clear exactly what is intended by "three or more" Security Parameter Attributes. Is the number three somewhat arbitrary, or is there some rationale (like maybe I'm supposed to choose one encryption algorithm, one authentication algorithm, and one signature algorithm at least)? If the number is just arbitrary, it would help to say so. From ipsec-request@ans.net Thu Oct 12 18:57:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17800 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 23:04:50 -0400 Received: by interlock.ans.net id AA74530 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 22:57:52 -0400 Message-Id: <199510130257.AA74530@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 12 Oct 1995 22:57:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 22:57:52 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 22:57:52 -0400 Date: Thu, 12 Oct 95 22:57:43 EDT To: ipsec@ans.net Subject: Photuris Page 24: Is padding required even if encryption is not specfied? Page 24, line 7: "size of the Padding field" --> "size of the Padding field in octets" From ipsec-request@ans.net Fri Oct 13 00:59:58 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12237 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 23:22:20 -0400 Received: by interlock.ans.net id AA76508 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 23:08:25 -0400 Message-Id: <199510130308.AA76508@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 23:08:25 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 23:08:25 -0400 Date: Fri, 13 Oct 95 00:59:58 GMT From: "William Allen Simpson" To: rivest@theory.lcs.mit.edu (Ron Rivest) Cc: ipsec@ans.net Subject: Re: Photuris terminology Thank you for taking the time to read the draft. Are there any other cryptographic flaws or misunderstandings that you have found? Are you actually on this list? Or did Hugo "appeal to authority" again? > From: rivest@theory.lcs.mit.edu (Ron Rivest) > I agree with Hugo Krawczyk's concern that the use of the term > "Signature" (as in section 5, "Signature Exchange") is somewhat > misleading, and introduces some risk. The difficulty can be removed > by slightly changing the protocol (Hugo's proposal), or adding some > clarifying language. > > The danger, as he points out, is that the term "signature" generally > refers only to a quantity computed from the message and the private > key that can only be computed by someone possessing the private key, > while being capable of being verified by anyone holding the > corresponding public key. > ***************************************************************** > *** There is nothing in this notion of "signature" that means *** > *** that the message can not be derived from the signature. *** > ***************************************************************** It always helps when communicating persons are speaking the same language. Of course, we have had the same problem with other parts of Hugo's messages. For example, he calls things "protocols", when we would call them "algorithms". Our protocols require a specific instantiation. He refuses to condescend to discuss such mere "specifications". That is not the definition used in Photuris. Photuris relies instead on the definition from [Schneier, p 36] (which Photuris references): "That bit string attached to the document when signed ... will be called the digital signature, or just the signature." This definition is _much_ more useful. Particularly as the current Photuris draft does not require use of public/private key pairs! I understand that with your involvement in public-key algorithms you might see signatures only in the light of public and private keys. However, the default required by Photuris specifies MD5 as the signature algorithm. A long-term authentication secret is used instead of a public/private key-pair. The excised text indicated by ellipses are the following words: "(in the above example, the one-way hash of the document encrypted with the private key)" Note that even the Schneier examples use a one-way hash with private keys! > Indeed, I believe that the CCITT standards distinguish explicitly between > "signature schemes with message recovery" and "signature schemes without > message recovery". > It has always amazed me what the ITU is willing to "standardize". > Furthermore, it IS important that the signature scheme used not have > the "message recovery" property, since part of what is signed is the > computed shared-secret. > Yes, but this is "obvious", even to non-cryptographers. As I noted in another message, not revealing the secret when you use it in _any_ transform is a rather fundamental and well-known principle. This applies to authentication, encryption, and key generation, as well as the signature. Photuris makes no attempt to be a "pure" cryptographers' thesis. Such a thesis would run to hundreds of pages. Instead, Photuris is a protocol specification which can be implemented by non-cryptographers. It selects from a few _useful_ tools. The usefulness of the tools is determined in advance. > At the minimum, this requirement should be noted in the document. Otherwise, > there is a risk that the list of approved "signature schemes" might be > inadvertently expanded in the future to include one that had message recovery. > (Not by anyone currently involved in the proposal, but by some future > caretaker...) > That presumes that "caretaking" occurs in a vacuum. Surely, when someone attempted to standardize something that silly, then the ever vigilant Hugo would leap at the opportunity to correct them! And of course, a malicious caretaker could simply _remove_ any such text as you herein propose. So nothing is gained.... > I would suggest adding language of the following form somewhere (such as > on the top of page 23): > I will again note that it is not my intention to reiterate the properties required for "good" cryptographic hashes, encryption methods, or any other algorithm. We are tool users, and it is outside the scope of the document to conduct an analysis of the tools. There are plenty of other sources and continuing research in the field. And all of the tools selected for signatures already have the property that the message _cannot_ be derived from the signature. However, at your august request (and of two others in the working group), I will incorporate something akin to this in the Security Considerations: The signature method must not allow "message recovery", to prevent determination of the shared-secret or any long-term distributed secret-key (where applicable). More specifically, it should not be feasible to compute any of the bits of the authenticated message from the signature. In general, where a secret (such as the shared-secret or session-keys) is involved in any calculation, the algorithms selected should not reveal information about the secret, either directly or indirectly. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Fri Oct 13 02:53:56 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17874 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 23:23:21 -0400 Received: by interlock.ans.net id AA74712 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 23:08:25 -0400 Message-Id: <199510130308.AA74712@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 23:08:25 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 23:08:25 -0400 Date: Fri, 13 Oct 95 02:53:56 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris generality > From: rogaway@cs.ucdavis.edu (Phil Rogaway) > What cryptographers want and expect of a protocol like Photuris is > that it works under the assumption that each of its primitives > is instantiated to meet the (standard) definition of the goal of that > primitive. Primitives? > You do not facilitate analysis > by saying that Photuris is only required to work when its > primitives are drawn from a certain concrete set of possibilities; > exactly the opposite-- you render cryptographic analysis impossible. > Thank you, thank you! It gladdens my heart to hear that self-described cryptographers find that analysis is impossible! I was worried that there would be some subtle flaw that would facilitate cryptanalysis. Now that you have assured us that it is not possible, that makes Photuris the only protocol that has ever come to perfection! Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Thu Oct 12 19:09:15 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17367 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 23:23:41 -0400 Received: by interlock.ans.net id AA47590 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 23:09:23 -0400 Message-Id: <199510130309.AA47590@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 12 Oct 1995 23:09:23 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 23:09:23 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 23:09:23 -0400 Date: Thu, 12 Oct 95 23:09:15 EDT To: ipsec@ans.net Subject: Photuris Page 23, Key Generator Choice: It is not clear to me how to take the output of the Key Generator Choice and use it as a session key. Do I use the the first bits or the last bits, or what? (For example, the discussion of MD5 on pages 44-45 only says that when MD5 is chosen as the Key Generator Choice, it generates 128 bits of keying material. It does not say how to pick a subset of those bits for an algorithm that might need fewer than 128 key bits, nor does it describe what to do if the algorithm needs more (for example, RC5 takes a variable-length key as input, and could easily make use of more than 128 key bits.) From ipsec-request@ans.net Thu Oct 12 19:28:11 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17403 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 23:44:43 -0400 Received: by interlock.ans.net id AA52457 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 23:28:18 -0400 Message-Id: <199510130328.AA52457@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 12 Oct 1995 23:28:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 23:28:18 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 23:28:18 -0400 Date: Thu, 12 Oct 95 23:28:11 EDT To: ipsec@ans.net Subject: Photuris Page 23: Signature: The sentence "Although the field is depicted as 32-bit aligned for convenience, the size may be shorter or longer, as indicated by its integral Size field." appears here and several other places, and is confusing to me. The first clause talks about alignment, and the second clause talks about length. It would be clearer to talk about these separately, as in: "The field may be any integral number of octets in length, as indicated by its Size field. It does not need to have any particular alignment (the 32-bit alignment shown in the figure is merely for convenience in the illustration)." From ipsec-request@ans.net Thu Oct 12 19:40:40 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12816 (5.65c/IDA-1.4.4 for ); Thu, 12 Oct 1995 23:54:39 -0400 Received: by interlock.ans.net id AA26008 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 12 Oct 1995 23:40:46 -0400 Message-Id: <199510130340.AA26008@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 12 Oct 1995 23:40:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 12 Oct 1995 23:40:46 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 12 Oct 1995 23:40:46 -0400 Date: Thu, 12 Oct 95 23:40:40 EDT To: ipsec@ans.net Subject: Photuris Page 25: "accept only those users found there" --> "accept only those users whose certificates are found there". Page 32: Is the error code 3 supposed to be used as well if the certificate fails to verify (as opposed to the certificate being OK, but the signature failing)? Probably another error code would be better... From ipsec-request@ans.net Thu Oct 12 20:11:38 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18848 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 00:27:05 -0400 Received: by interlock.ans.net id AA49203 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 00:11:46 -0400 Message-Id: <199510130411.AA49203@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 13 Oct 1995 00:11:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 00:11:46 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 00:11:46 -0400 Date: Fri, 13 Oct 95 00:11:38 EDT To: ipsec@ans.net Subject: Photuris Page 9: What is the length of the "Type" field (in this and the other message types)? Also: There is no explicit "version number" in the header anywhere, which makes me nervous. Is the "Reserved" field (which is present in all but the Cookie_Request) intended for this purpose? If so, perhaps it should be called "Version_Number" instead of "Reserved". If not, perhaps a "Version_Number" field should be added. From ipsec-request@ans.net Thu Oct 12 20:05:39 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12202 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 00:31:27 -0400 Received: by interlock.ans.net id AA28332 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 00:18:37 -0400 Message-Id: <199510130418.AA28332@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 13 Oct 1995 00:18:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 00:18:37 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 00:18:37 -0400 Date: Fri, 13 Oct 95 00:05:39 EDT To: ipsec@ans.net Subject: Photuris Page 22 and page 32: Is an Error_Message sent if a Signature_Message is received with an invalid Signature-Choice or an invalid Key-Generator-Choice? If so, what error code is to be used? Ron Rivest From ipsec-request@ans.net Thu Oct 12 20:25:16 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18889 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 00:40:30 -0400 Received: by interlock.ans.net id AA87611 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 00:25:22 -0400 Message-Id: <199510130425.AA87611@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 13 Oct 1995 00:25:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 00:25:22 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 00:25:22 -0400 Date: Fri, 13 Oct 95 00:25:16 EDT To: ipsec@ans.net Subject: Photuris Page 11: Section 2.5 Variable Precision Numbers It seems possible that a variable-precision number could have a size of 0 octets. Indeed, many of the examples given have exactly that (e.g. the Validity-Choice field on pages 27--28 are shown as 16-bits, which must be a size of 0). Yet the value of such a quantity is undefined. Is it 0? Ron Rivest From ipsec-request@ans.net Thu Oct 12 20:33:46 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12251 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 00:46:26 -0400 Received: by interlock.ans.net id AA74635 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 00:33:52 -0400 Message-Id: <199510130433.AA74635@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 13 Oct 1995 00:33:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 00:33:52 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 00:33:52 -0400 Date: Fri, 13 Oct 95 00:33:46 EDT To: ipsec@ans.net Subject: Photuris Page 11: Section 2.5 (Variable-Precision Numbers) You might also leave an "escape" for longer numbers. I always worry about fixed upper bounds on the lengths of things. In the case of Photuris, for example, a single such variable-length number is supposed to be able to contain a certificate chain. When everyone is done throwing everything they think they want in the certificates (e.g. explicit statements of certification policies translated into all languages), certificates might be a lot bigger than we expect, and we might overrun this limit with a long certificate chain. (I hope not, but I see no reason to needlessly restrict this here...) There are lots of standard techniques for handling such things (presumably ASN.1 DER has one such technique), or you could do something ad-hoc (reserve 0xFFFF to mean that the length is in the next four bytes, followed by the value, etc..) From ipsec-request@ans.net Thu Oct 12 20:44:48 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12285 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 01:00:59 -0400 Received: by interlock.ans.net id AA71157 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 00:44:54 -0400 Message-Id: <199510130444.AA71157@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 13 Oct 1995 00:44:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 00:44:54 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 00:44:54 -0400 Date: Fri, 13 Oct 95 00:44:48 EDT To: ipsec@ans.net Subject: Photuris Page 10: [Size of cookies] The size of the cookies (16 octets) seems unnecessarily large. Why not 8 octets each? The chance that a random cookie will satisfy the recipient is then only 2^{-64}. From an engineering point of view, it seems that the cookie length is about right when the probability of a random cookie being accepted is about the same as the ratio of the cookie computation time to the exchange-value computation time. The only penalty we really pay for bogus cookies being accepted is the possible extra computation time for computing the exchange value; with the condition I gave this is on the order of the cookie computation time (in terms of expected value). This argument is perhaps not correct if the adversary can detect when he has success; but this I don't see how to do unless he uses his real IP address, which he is unlikely to do. Even then, if the recipient increments his secret value for computing cookies every so often, then the adversary can't keep pounding on a discovered cookie. 2^{-64} is really quite small... (If you think it is too big you should certainly never use DES, since its key is only 56 bits long...) From ipsec-request@ans.net Fri Oct 13 13:06:24 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17056 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 10:14:10 -0400 Received: by interlock.ans.net id AA68466 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 10:03:17 -0400 Message-Id: <199510131403.AA68466@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 10:03:17 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 10:03:17 -0400 Date: Fri, 13 Oct 95 13:06:24 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris Thank you for the detailed review. I have grouped these together for ease of processing: > From: rivest@theory.lcs.mit.edu (Ron Rivest) > Page 17 (Initiator-Offered-Attributes) > Page 20 (Responder-Offered-Attributes) > > It is not clear exactly what is intended by "three or more" > Security Parameter Attributes. Is the number three somewhat > arbitrary, or is there some rationale (like maybe I'm supposed to > choose one encryption algorithm, one authentication algorithm, and > one signature algorithm at least)? If the number is just arbitrary, > it would help to say so. > Actually, 3 is the minimal number of attributes which are required to be supported. Therefore, the list will always be 3 or more.... * * * * 5 MD5 * 17 DES-CBC, 32-bit IV * * 18 DES-CBC, 64-bit IV added "three (minimum required) or more" > Page 22: It is not described anywhere what the recipient is supposed to > do with the "LifeTime" variable in the Signature_Message. > If this is not used by the recipient, it should be omitted. > (Presumably it should documented what is to be done with this > by the recipient.) > Good idea. Actually, the LifeTime is first described under Expiration in Chapter 1, but an additional explicit section is useful in Security Parameters as well. Each SPI has an associated LifeTime, specified by the SPI owner (receiver). The SPI can also be deleted by the SPI Owner using the Change_Message. Once the SPI has expired or been deleted, the parties cease using the SPI, and purge the associated state. > Page 24, section 5.2, second paragraph: > > "The fields protected are described for each method." I don't > see where these descriptions are, and I don't see why they should > differ for different "methods." More explanation is needed here. > It currently says (see "Attribute List" Appendix). In the only described method thus far (DES-CBC), the IV and encrypted fields are 64-bit aligned. There may be methods in which the privacy can take place beginning at the LifeTime, or cover the SPI, for example. I wanted to leave this open as a possibility. How about: The fields protected, the length of the Padding (if any), and other details are described for each Anonymity-Choice method. A single non-negotiable key generation cryptographic hash is specified to create a special anonymity session-key. See the "Attribute List" Appendix for details. > Page 24: Is padding required even if encryption is not specfied? > Added: This field is always present, even though no Anonymity-Choice is specified or no Padding is required. > Page 24, line 7: "size of the Padding field" --> > "size of the Padding field in octets" > Fixed. > Page 43: It is not specified what the lengths are of the "Type" and "Length" > fields themselves. Are these supposed to be single bytes, or to > be inferred from the figure, or what? > Single bytes, inferred from the figure. (This is traditional RFC format, and each +-+ is one bit.) However, I see that I have not been consistent here, as some places the size is specified, and others it is not. Also, I have not been consistent in using words versus numbers, and capitalization. Fixed. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Fri Oct 13 07:04:29 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15392 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 11:12:37 -0400 Received: by interlock.ans.net id AA81064 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 11:04:34 -0400 Message-Id: <199510131504.AA81064@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 11:04:34 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 11:04:34 -0400 Date: Fri, 13 Oct 95 11:04:29 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipsec@ans.net Subject: Change message in Photuris I like the revised language proposed by Bill Sommerfeld regarding the "Change" message of Photuris. I think it greatly improves clarity and makes interoperability more likely. I hope Bill will take that text into the next Photuris draft. Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Fri Oct 13 07:01:50 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16677 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 11:12:38 -0400 Received: by interlock.ans.net id AA15217 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 11:01:55 -0400 Message-Id: <199510131501.AA15217@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 11:01:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 11:01:55 -0400 Date: Fri, 13 Oct 95 11:01:50 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipsec@ans.net Subject: Photuris & signatures 1. I really appreciate Hugo's providing more detailed explanation of his concerns. His latest efforts have been much more easily understood by me, at least. However, I'm inclined to say that the problem he sees with signatures is more of a "specification clarity" issue than a "fundamental flaw" in the protocol. 2. I think that David Wagner, Bill Sommerfeld, & Ron Rivest have all been extremely helpful here by providing proposed clarifying text. I like the language each has proposed. Because it includes a bit more rationale for the benefit of those not familiar with the cryptographic issues, perhaps the Rivest language should be added to the spec in an appropriate place. IMHO, Bill's more general rewording of those 3 clarification proposals is not sufficient because it is too generic and isn't blunt enough for lay people who aren't familiar with the issues. I would be greatly obliged if Bill would also take the Rivest language (verbatim) into the draft in an appropriate place. I also believe that the following clarifying sentence should be added at the very end of Section 1.0 (end of the paragraph just before the start of Section 1.1): "Not all digital signature algorithms are suitable for use with Photuris. This is discussed further in Section [which cite] of this document." [which cite] == whichever section the Rivest language is added into. 3. I think it would also be helpful if a definition of "Signature" or "Digital Signature" would be added to Section 1.1. This definition should NOT be a highly technical cryptographer's definition. Instead the definition should be one readable and understandable by network protocol implementers (since that is the intended audience of this document). 4. It is true that the theoretical cryptography community and the computer networking community do not share the same meaning for the term "protocol". The former uses "protocol" in a way that the latter would generally use "algorithm". Neither group is wrong, but perhaps it is helpful to remind folks of this. I don't find flames on this matter to be constructive. We all need to try to cooperate and work together here. :-) I'm still behind (due to other real work) in my study of the drafts (SKIP and Photuris) and also on the mailing list, but I'm trying to catch up soon. :-) Regards, Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Fri Oct 13 08:12:33 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16691 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 13:23:10 -0400 Received: by interlock.ans.net id AA12475 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 13:15:39 -0400 Message-Id: <199510131715.AA12475@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 13:15:39 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 13:15:39 -0400 Date: Fri, 13 Oct 95 12:12:33 EDT From: "Juan A. Garay ((914) 784-6852)" To: ipsec@ans.net Subject: Photuirs & signature - protocol vs. algorithm Ran Atkinson writes: > 4. > It is true that the theoretical cryptography community and the > computer networking community do not share the same meaning for the > term "protocol". The former uses "protocol" in a way that the latter > would generally use "algorithm". Neither group is wrong, but perhaps > it is helpful to remind folks of this. I don't find flames on this > matter to be constructive. We all need to try to cooperate and work > together here. :-) In a distributed, network environment, a protocol is (should be) a collection of algorithms, one for each participant. Cheers, Juan PS 'hope this comment doesn't place me (at least completely) in the theoretician camp! :-) From ipsec-request@ans.net Fri Oct 13 09:27:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12867 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 13:31:35 -0400 Received: by interlock.ans.net id AA53505 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 13:27:53 -0400 Message-Id: <199510131727.AA53505@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 13 Oct 1995 13:27:53 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 13:27:53 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 13:27:53 -0400 Date: Fri, 13 Oct 95 13:27:43 EDT To: ipsec@ans.net Subject: Photuris Terminology The Photuris document uses the words "signature" and "certificate" in ways that, to the cryptographic community, are misleading. In order to avoid confusion, these terminological abuses should at minimum be pointed out explicitly. Better, they should be replaced with more accurate terms. The problem arises in allowing MD5 (or any other hash algorithm) as a "Signature-Choice". If only public-key algorithms were permitted in Photuris as a "Signature-Choice", then there would be no problem. In the cryptographic community, the term "signature" is NEVER used to refer to a MAC (message authentication code). These concepts are always kept quite distinct. -- A signature is fundamentally a public-key notion: the signature for a message is created with the signer's private key, and verfied using the signer's public key. -- A message authentication code is a secret-key notion: the MAC for a message is computed by the sender using a secret that is shared with the receiver; the receiver verifies the MAC by recomputing it from the message and the shared secret. Using MD5 as a "Signature-Choice" results in a MAC, not a "signature". Allowing MD5 as a "Signature-Choice" is an unnecessary abuse of terminology. Note that I'm not arguing that one might not want to use MD5 here, but rather that it is improper and unnecessary to call this a "signature" method. ****************************************************************************** ** Since both techniques provide authentication, I would suggest the following ** changes in terminology: ** ** Signature-Choice --> Authentication-Choice ** Signature --> Authentication-Value ****************************************************************************** Similarly, the term "certificate" is used in the cryptographic community exclusively to denote a public-key certificate. An "email address" (as specified in the document, page 45, when MD5 is the Signature Choice), is not a "certificate". ****************************************************************************** ** I suggest the following change in terminology: ** ** Certificate --> Authentication-Descriptor ****************************************************************************** which could either be an email address or a public-key certification. We have enough confusion in this field without abusing standard terminology. Presumably this arose since the original work [DOW] only envisioned public-key signature methods, and then the use of MAC's was later added to Photuris. Ron Rivest From ipsec-request@ans.net Fri Oct 13 17:37:04 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19041 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 13:48:43 -0400 Received: by interlock.ans.net id AA40228 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 13:38:59 -0400 Message-Id: <199510131738.AA40228@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 13 Oct 1995 13:38:59 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 13:38:59 -0400 Date: Fri, 13 Oct 1995 10:37:04 -0700 From: touch@ISI.EDU Posted-Date: Fri, 13 Oct 1995 10:37:04 -0700 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 13:38:59 -0400 To: ipsec@ans.net, garay@watson.ibm.com Subject: Re: Photuirs & signature - protocol vs. algorithm > From: "Juan A. Garay ((914) 784-6852)" > Subject: Photuirs & signature - protocol vs. algorithm > > Ran Atkinson writes: > > > 4. > > It is true that the theoretical cryptography community and the > > computer networking community do not share the same meaning for the > > term "protocol". The former uses "protocol" in a way that the latter > > would generally use "algorithm". Neither group is wrong, but perhaps > > it is helpful to remind folks of this. I don't find flames on this > > matter to be constructive. We all need to try to cooperate and work > > together here. :-) > > In a distributed, network environment, a protocol is (should be) > a collection of algorithms, one for each participant. A protocol is the set of rules the set of distributed algorithms obey, i.e., the way they interact. It comes from the term for the rules of diplomatic interaction. Spec the rules, and the algorithms can be implemented independently. That's the whole point. Joe From ipsec-request@ans.net Fri Oct 13 09:42:17 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16742 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 13:48:51 -0400 Received: by interlock.ans.net id AA04971 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 13:42:24 -0400 Message-Id: <199510131742.AA04971@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 13:42:24 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 13:42:24 -0400 Date: Fri, 13 Oct 95 13:42:17 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipsec@ans.net Subject: algorithm-independent Hugo, The reference on "algorithm-independence" that you cite from RFC-1825 has been misconstrued by you. That reference only refers to ESP and AH, with which it is cross-dependent. As author of RFC-1825, I can say this authoritatively. I will attempt to recall the need to clarify that language when RFC-1825 next comes up for review, do feel free to remind me if I forget. To the best of my knowledge, the Photuris specification is not intended to be completely algorithm-independent (however, I'm still studing the Photuris draft and so I might be contradicted by some part of the Photuris spec I misread or haven't yet read). Photuris needs to be interpreted within the context of the Photuris drafts, IMHO. IMHO, if any IPsec key mgmt proposal were unable to distribute keys/SAs for use with ESP/AH, then there would be an architectural problem. I don't believe Photuris has such a problem. I haven't read the latest SKIP draft in detail, but if the changes to SKIP I anticipate were made in the current draft then SKIP no longer has that particular problem. Regards, Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Fri Oct 13 10:16:07 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19150 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 14:27:24 -0400 Received: by interlock.ans.net id AA74007 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 14:16:16 -0400 Message-Id: <199510131816.AA74007@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 13 Oct 1995 14:16:16 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 14:16:16 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 14:16:16 -0400 Date: Fri, 13 Oct 95 14:16:07 EDT To: ipsec@ans.net Subject: Photuris I'd like to raise another issue that is being swept under the rug, but which needs to be addressed by ipsec, and needs to be explicitly addressed by Photuris: ****************************************************************************** ** Who are the entities between whom a Security Association is established? ** ** How are they named? ** ****************************************************************************** IPSEC needs to provide EXPLICT answers to these questions. The Photuris spec needs to be based on these answers. This cannot be swept under the rug any longer. * On page 2 of the Photuris draft, it is said that the Security Association is established between "two nodes". What is a node??? (A machine with an IP address??) * On page 45 of the Photuris draft, it is specified that the Certificate (when MD5 is the `Signature Choice') is an "email address". Are we envisioning that the Security Association may link users? (I imagine that some would like the answer to be "yes".) Or was this intended merely to be an IP address? The problem: If I try to establish a Security Association with a specific user, or a specific process, on another machine, then I need some way to specify who I wish to talk to in my initial Key_Request. With Photuris as it is, the Responder is not identified by the Photuris initiator to any finer granularity than the IP address to which the Photuris packets are sent. If the intent is to support Security Associations between entities at some other level of granularity, then the initiator needs to be able to name who (or which process, whatever) at that IP address he desires to communicate with. ** The Key_Request message needs to be expanded to name the ** ** party with whom I wish to establish a Security Association, if this ** ** is to be identified in some way that is different or more specific ** ** than merely the IP address of the responder. ** As it stands, Photuris apparently only supports the establishment of Security Associations between entities named by IP addresses. Is this what is intended? From ipsec-request@ans.net Fri Oct 13 17:18:40 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16706 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 15:21:41 -0400 Received: by interlock.ans.net id AA40550 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 15:16:34 -0400 Message-Id: <199510131916.AA40550@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 15:16:34 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 15:16:34 -0400 Date: Fri, 13 Oct 95 17:18:40 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris Now to address the ones that came _after_ midnight.... > From: rivest@theory.lcs.mit.edu (Ron Rivest) > > Page 9: What is the length of the "Type" field (in this and the > other message types)? > one octet. Fixed. > Also: There is no explicit "version number" in the header anywhere, > which makes me nervous. Is the "Reserved" field (which is present > in all but the Cookie_Request) intended for this purpose? If so, > perhaps it should be called "Version_Number" instead of "Reserved". > If not, perhaps a "Version_Number" field should be added. > There are _two_ version numbers: 1) the major version number is the UDP port. A protocol that is truly different will need another port. 2) the minor version number is the Scheme. A protocol that differs only in small ways, such as moduli, will use a different scheme number. Also, this field was increased from 8 bits to 16 bits. NSA claims they are going to have thousands of variants, including some which don't have all the same steps after the cookie exchange. > Page 10: [Size of cookies] > > The size of the cookies (16 octets) seems unnecessarily large. > Why not 8 octets each? > Very simply, it's the output of MD5. Have to do all 128 bits of work, whether or not we use all of the bits. Meanwhile, the Photuris exchanges are so rare (every 10 minutes or so) that even on bandwidth constrained links, this size isn't very big. So, no real savings in terms of computation time or bandwidth, which are the important factors. > This argument is perhaps not correct if the adversary can detect > when he has success; but this I don't see how to do unless he uses > his real IP address, which he is unlikely to do. > Correct. Which is the second sentence in the design decision covers. ATM clouds. They claim to be gigabit speeds. The field also needs to be big enough to be improbable when 2^32 cookies a second can be tested. Even then, 8 bytes is probably enough, from a theoretical standpoint. > Even then, if the recipient increments his secret value for computing > cookies every so often, then the adversary can't keep pounding on a > discovered cookie. > Yes, and probably should change more often on the faster links. > 2^{-64} is really quite small... > > (If you think it is too big you should certainly never use DES, since > its key is only 56 bits long...) > Yeah, we all agree on that! > Page 11: Section 2.5 Variable Precision Numbers > > It seems possible that a variable-precision number could have > a size of 0 octets. Indeed, many of the examples given have > exactly that (e.g. the Validity-Choice field on pages 27--28 are > shown as 16-bits, which must be a size of 0). Yet the value > of such a quantity is undefined. Is it 0? > Yes. Fixed: A value of zero is represented by a Size of zero, and no value field. A value of one is represented by a Size of one, and no value field. However, you've mistaken the validity-choice field. That field is an attribute, which has a type-length format. The validity-choice is followed by the Verification, which is a separate variable precision number. If you look carefully, you will notice that the MD5 attribute is 16-bits, and the VPN Size is 16 bits, making the hash value align neatly on the next 32-bit boundary. (of course, this cannot be depended upon for other algorithms, but I did optimize for the defaults.) > You might also leave an "escape" for longer numbers. I always > worry about fixed upper bounds on the lengths of things. In the > case of Photuris, for example, a single such variable-length > number is supposed to be able to contain a certificate chain. > When everyone is done throwing everything they think they want > in the certificates (e.g. explicit statements of certification > policies translated into all languages), certificates might be > a lot bigger than we expect, and we might overrun this limit with > a long certificate chain. (I hope not, but I see no reason to > needlessly restrict this here...) > There is also a maximum size on the UDP packet of 16 bits. > There are lots of standard techniques for handling such things > (presumably ASN.1 DER has one such technique), or you could > do something ad-hoc (reserve 0xFFFF to mean that the length > is in the next four bytes, followed by the value, etc..) > True -- anybody have any preferences? Know off the top of their head what PGP does? X.509? > Page 23, Key Generator Choice: > > It is not clear to me how to take the output of the Key > Generator Choice and use it as a session key. Do I use the > the first bits or the last bits, or what? (For example, the > discussion of MD5 on pages 44-45 only says that when MD5 is > chosen as the Key Generator Choice, it generates 128 bits of > keying material. It does not say how to pick a subset of those > bits for an algorithm that might need fewer than 128 key bits, > nor does it describe what to do if the algorithm needs more > (for example, RC5 takes a variable-length key as input, and could > easily make use of more than 128 key bits.) > Correct. That's why _each_ algorithm which _uses_ a key specifies how it uses the bits. MD5: ... its SPI session-key uses the entire Key-Generator-Choice generated keying material. DES-CBC: ... its SPI session-key uses the most significant 64-bits of Key-Generator-Choice generated material. The least significant bit of each octet is ignored (parity). RC5 (in extensions draft): ... its SPI session-key uses the most significant Key-Size bits of Key-Generator-Choice generated material. > Page 23: Signature: > > "The field may be any integral number of octets in length, > as indicated by its Size field. It does not need to have > any particular alignment (the 32-bit alignment shown in > the figure is merely for convenience in the illustration)." > Thank you. Done. > Page 25: "accept only those users found there" --> > "accept only those users whose certificates are found there". > Done. > Page 32: Is the error code 3 supposed to be used as well if the > certificate fails to verify (as opposed to the certificate > being OK, but the signature failing)? Probably another error > code would be better... > Yes, as currently written. Why? Usually, you don't want to give out that kind of information.... Such as when a username is unrecognized, but the same error is given as if the password is invalid. > Page 22 and page 32: > > Is an Error_Message sent if a Signature_Message is received > with an invalid Signature-Choice or an invalid Key-Generator-Choice? > If so, what error code is to be used? > Nothing currently written. For other messages, either! How about a new error code #5 indicating invalid attribute choice? Or would it be better to just silently discard the bad message? Could be an attack where an invalid message is sent during an exchange to abort the exchange. Needs thought. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Fri Oct 13 19:24:10 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13053 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 16:26:27 -0400 Received: by interlock.ans.net id AA55807 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 16:19:39 -0400 Message-Id: <199510132019.AA55807@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 16:19:39 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 16:19:39 -0400 Date: Fri, 13 Oct 95 19:24:10 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Nodes and Users > From: rivest@theory.lcs.mit.edu (Ron Rivest) > IPSEC needs to provide EXPLICT answers to these questions. The Photuris > spec needs to be based on these answers. This cannot be swept under the > rug any longer. > No rug sweeping has been attempted, we have discussed this at length in the Security Architecture. > * On page 2 of the Photuris draft, it is said that the Security Association > is established between "two nodes". What is a node??? (A machine with > an IP address??) > A node is a standard well-known IP term for an entity with one or more interfaces. Interfaces have IP addresses. > * On page 45 of the Photuris draft, it is specified that the Certificate > (when MD5 is the `Signature Choice') is an "email address". Are we > envisioning that the Security Association may link users? (I imagine > that some would like the answer to be "yes".) Or was this intended > merely to be an IP address? > User oriented keying is a fundamental goal of IPSec. Again, RFC-1525. > The problem: > > If I try to establish a Security Association with a specific user, or > a specific process, on another machine, then I need some way to specify > who I wish to talk to in my initial Key_Request. > Nope. Process selection is done with the headers _inside_ AH or ESP. > With Photuris as it is, the Responder is not identified by the Photuris > initiator to any finer granularity than the IP address to which the > Photuris packets are sent. > Correct. Right up until the Signature exchange. But I already have language to this effect: To provide user-oriented keying, or create multiple Security Associations with different parameters, the sender can either initiate multiple Photuris exchanges, or send a Change_Message. The Destination MUST be capable of maintaining multiple Security Associations (SPI values) for each Source. It is the responsibility of the Source to internally segregate the different session-keys provided by the Destination. > If the intent is to support Security Associations between entities at > some other level of granularity, then the initiator needs to be able > to name who (or which process, whatever) at that IP address he desires > to communicate with. > We've talked about this, but currently the protocol only specifies who the SA is _from_. The initiator decides to start a Photuris exchange when: 1) it has a datagram which it wishes to send with privacy. 2) it has received an ICMP message from a destination which indicates a requirement for authentication. Other needs to initiate a Photuris exchange are likely to be a matter for considerable debate. (and thus have been left out) > As it stands, Photuris apparently only supports the establishment of > Security Associations between entities named by IP addresses. Is this > what is intended? > It establishes shared-secrets between a user and an IP address (in the case of a server). Of course, the two most likely scenarios are machine to machine (firewalls making virtual private networks), or user to user (one person, at least one CPU)! Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Fri Oct 13 23:17:40 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16738 (5.65c/IDA-1.4.4 for ); Fri, 13 Oct 1995 19:24:08 -0400 Received: by interlock.ans.net id AA25598 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 13 Oct 1995 19:17:50 -0400 Message-Id: <199510132317.AA25598@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 19:17:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 19:17:50 -0400 From: David A Wagner Subject: Re: Nodes and Users To: bsimpson@morningstar.com (William Allen Simpson) Date: Fri, 13 Oct 1995 16:17:40 -0700 (PDT) Cc: ipsec@ans.net In-Reply-To: <199510132019.AA55807@interlock.ans.net> from "William Allen Simpson" at Oct 13, 95 07:24:10 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 716 So this makes me realize I don't quite understand how user-level keying works with Photuris. If this is a stupid question, flame away... :-) Consider host H running two server processes (maybe under different userids). Process A says ``I'll accept any authenticated connection.'' Process B says ``I'll accept only connections with triple DES encryption and full MD5 MAC authentication.'' When a client contacts host H's Photuris port, how does the algorithm negotiation work? (Should H's OS use a greatest-common-denominator and insist that the client use triple DES with MD5 MAC?) If I understand correctly (and maybe I don't), H's Photuris can't know which server process the new SPI will be destined for... From ipsec-request@ans.net Sat Oct 14 00:32:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16918 (5.65c/IDA-1.4.4 for ); Sat, 14 Oct 1995 00:47:46 -0400 Received: by interlock.ans.net id AA39054 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 14 Oct 1995 00:42:35 -0400 Message-Id: <199510140442.AA39054@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 14 Oct 1995 00:42:35 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 14 Oct 1995 00:42:35 -0400 Date: Sat, 14 Oct 95 00:32:43 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris Terminology > From: rivest@theory.lcs.mit.edu (Ron Rivest) > ** Signature-Choice --> Authentication-Choice > ** Signature --> Authentication-Value > ** Certificate --> Authentication-Descriptor > Seems reasonable. But since we already use the term Authentication for the AH, a completely different methodology, I prefer to use another term, such as Identification. Fits well with the metaphor: privacy hides identification and attributes. I've renamed the phase to Identification, too. I've changed Anonymity to Privacy. BTW, this took three hours! (sigh) No real change to the protocol, just finding all the variants, leading a/an, etc. > We have enough confusion in this field without abusing standard terminology. > Presumably this arose since the original work [DOW] only envisioned > public-key signature methods, and then the use of MAC's was later added > to Photuris. > I seem to have to repeat this fairly regularly: we never heard of STS until this Spring. Not everyone reads obscure Dutch publications.... We do read widely distributed books with lots of code, and I suspect that Schneier definitions will overtake and become "standard terminology". Actually, the very first implementation used MD5 hashing. Phil is only now adding PGP certificates. For network folks, MACs are an entirely different beast (Media Access Control). And since network terms have a tendency to make it into the popular lexicon (including the term networking itself), I do hope your "MAC" goes away soon.... Actually, I hope both "MAC"s go away soon. "Link" is a much better term. Mac is a machine, short for Macintosh.... Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sat Oct 14 13:52:12 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17770 (5.65c/IDA-1.4.4 for ); Sat, 14 Oct 1995 11:47:36 -0400 Received: by interlock.ans.net id AA11814 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 14 Oct 1995 11:24:30 -0400 Message-Id: <199510141524.AA11814@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 14 Oct 1995 11:24:30 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 14 Oct 1995 11:24:30 -0400 Date: Sat, 14 Oct 95 13:52:12 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Session Management Ran advised me that I missed replying to this message earlier in the week. > Date: Mon, 09 Oct 1995 16:57:19 -0400 > From: Bill Sommerfeld > > There's enough support in the protocol for replay detection if some > restrictions are made on SPI reuse. Some sort of timestamp or sequence > number would reduce the amount of storage needed to provide replay > protection, but it's not really necessary. > Yes. > I think the "change" message is misnamed, since it either creates a > new SPI, or deletes an existing one. I'm not going to suggest edits > to change that, however.... > There previously were 2 messages (5 and 6) for Re_Key and Delete_Key, but I was convinced to combine them. Change_Key eventually became Change_Message, since it doesn't change the _key_ (and was confusing to some for that reason), it changes the accumulated state. For a short period of time (draft -03), it also allowed modification. However, there was not WG consensus that this was useful, and that was removed in -04. > The draft doesn't explicitly disallow modifying an existing SPI, but > it doesn't specifically allow it, either. I don't see how one could > change arbitrary SPI attributes reliably, since packets sent using the > SPI could be reordered around the change request. > I have added a section specifically disallowing modification. > The fix is relatively simple: > - limit the lifetime of the shared secret, and require that > photuris remember the existance of all SPI's created using the shared > secret until the shared secret expires. > This is already true. Obviously not clearly enough. Although I have quoted the sections in other messages, they are apparently too dispersed for folks to remember. Therefore, I have gathered many of them into a new section just before Multicast, called "Session Management". This also includes the user-oriented keying material which previously was an implementation note in the early protocol description section. > Here's my suggested additions to the spec; there's admittedly some redundancy > here, but I don't think it's excessive. > > [these should go into section 5.4]: > > The shared secret, and any SPIs created using it, must be > destroyed once the initial SPI, created here, expires. > This is wrong, the SPI can outlive the shared-secret. This is important to allow traffic to continue without interruption during new Photuris exchanges. > [These should go into section 6.4 implementation guidelines]: > > Change_Message packets must not be allowed to *modify* already > existing SPI's, or to resurrect SPI's which have been deleted. > Correct. > If an otherwise-valid change_message is received which would produce > an SPI which would live beyond the expiration time of the shared > secret, the new SPI must be silently adjusted to expire when the > shared secret expires. > No. It is computationally infeasible to recreate the shared-secret from the session-key. > To prevent resurrection of already-used SPI's, implementations MUST > remember, but mark as unusable, deleted or expired SPIs until the > shared secret used to create them also expires. > Yes. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sat Oct 14 16:21:03 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17355 (5.65c/IDA-1.4.4 for ); Sat, 14 Oct 1995 20:39:42 -0400 Received: by interlock.ans.net id AA88422 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 14 Oct 1995 20:21:09 -0400 Message-Id: <199510150021.AA88422@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sat, 14 Oct 1995 20:21:09 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 14 Oct 1995 20:21:09 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 14 Oct 1995 20:21:09 -0400 Date: Sat, 14 Oct 95 20:21:03 EDT To: ipsec@ans.net Subject: Photuris // Variable-Precision numbers I wrote in a previous note: > Page 11: Section 2.5 Variable Precision Numbers > > It seems possible that a variable-precision number could have > a size of 0 octets. Indeed, many of the examples given have > exactly that (e.g. the Validity-Choice field on pages 27--28 are > shown as 16-bits, which must be a size of 0). Yet the value > of such a quantity is undefined. Is it 0? > To which Bill Simpson replied: >Yes. Fixed: > > A value of zero is represented by a Size of zero, and no value field. > > A value of one is represented by a Size of one, and no value field. and now I'm confused. Representing a value of one by a Size of one, and no value field, is inconsistent with the purpose of the Size field, and rules out the possibility of having a Size field of one with a real value field of length one. (I am interpreting the Size field to mean the length of the Value field only; the 2 bytes of the Size field are not counted.) What you want is something like (bytes given in hex): Size Value Represents (decimal) 00 0 01 00 0 01 01 1 01 02 2 ... 01 FF 255 02 00 00 0 02 00 01 1 ... 02 FF FF 65535 and so on. Correct? From ipsec-request@ans.net Sat Oct 14 21:12:20 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16670 (5.65c/IDA-1.4.4 for ); Sat, 14 Oct 1995 21:12:20 -0400 Received: by interlock.ans.net id AA65595 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 14 Oct 1995 20:54:45 -0400 Message-Id: <199510150054.AA65595@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 14 Oct 1995 20:54:45 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 14 Oct 1995 20:54:45 -0400 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: "William Allen Simpson" Cc: ipsec@ans.net Subject: Re: Nodes and Users In-Reply-To: Your message of "Fri, 13 Oct 1995 19:24:10 GMT." <199510132019.AA55807@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 14 Oct 1995 20:54:33 -0400 From: "Perry E. Metzger" "William Allen Simpson" writes: > > From: rivest@theory.lcs.mit.edu (Ron Rivest) > > IPSEC needs to provide EXPLICT answers to these questions. The Photuris > > spec needs to be based on these answers. This cannot be swept under the > > rug any longer. > > > No rug sweeping has been attempted, we have discussed this at length in > the Security Architecture. Bill has expressed to me in private mail that he thinks that the question of certificates, certificate formats and naming can wait, but frankly I don't think it can because we don't have a usable system without it. Perry From ipsec-request@ans.net Sun Oct 15 02:23:19 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18710 (5.65c/IDA-1.4.4 for ); Sat, 14 Oct 1995 23:16:30 -0400 Received: by interlock.ans.net id AA92323 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 14 Oct 1995 22:58:46 -0400 Message-Id: <199510150258.AA92323@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 14 Oct 1995 22:58:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 14 Oct 1995 22:58:46 -0400 Date: Sun, 15 Oct 95 02:23:19 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris // Variable-Precision numbers As I said, I had to think about it some more. Sorry, should have gotten back to you on that, but here is what I actually wrote: Each variable precision number is composed of two parts. Size two or four octets. Number of significant bits used in the Value field. Always transmitted most significant octet first. A Size of zero has no Value field; value is zero. A Size of one has no Value field; value is one. When the most significant octet is in the range 0 through 254 (0xfe), the field is two octets. Both octets are used to indicate the size of the Value field. When the most significant octet is 255 (0xff), the field is four octets. The remaining three octets are used to indicate the size of the Value field. Value variable. The bits used are right justified and zero filled on octet boundaries; that is, any unused bits are in the most significant octet. Always transmitted most significant octet first. The shorter forms SHOULD NOT be used when the Size indicates a number of significant bits which happen to be zero. > From: rivest@theory.lcs.mit.edu (Ron Rivest) > Representing a value of one by a Size of one, and no value field, is > inconsistent with the purpose of the Size field, and rules out the > possibility of having a Size field of one with a real value field of length > one. (I am interpreting the Size field to mean the length of the Value > field only; the 2 bytes of the Size field are not counted.) > > What you want is something like (bytes given in hex): > > Size Value Represents (decimal) > 00 0 > 01 00 0 > 01 01 1 > 01 02 2 > ... > 01 FF 255 > 02 00 00 0 > 02 00 01 1 > ... > 02 FF FF 65535 > and so on. > > Correct? > Not quite, the Size is _bits_ not _bytes_: Size Value Represents (decimal) 0000 0 0001 1 0002 00 0 0002 01 1 0002 02 2 ... 0008 01 1 (8 significant bits) 0008 FF 255 0009 0001 1 (9 significant bits) ... ff223344 00...01 1 (many significant bits ;-) Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sun Oct 15 05:05:29 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19017 (5.65c/IDA-1.4.4 for ); Sun, 15 Oct 1995 01:45:23 -0400 Received: by interlock.ans.net id AA70227 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 15 Oct 1995 01:27:17 -0400 Message-Id: <199510150527.AA70227@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 15 Oct 1995 01:27:17 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 15 Oct 1995 01:27:17 -0400 Date: Sun, 15 Oct 95 05:05:29 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Nodes and Users > From: "Perry E. Metzger" > Bill has expressed to me in private mail that he thinks that the > question of certificates, certificate formats and naming can wait, but > frankly I don't think it can because we don't have a usable system > without it. > I firmly disagree. The _usable_ system is Photuris with names and secrets, using only MD5 and DES, which can leverage off the current installed base. This fills exactly the same needs as the AH and ESP base requirements. As an intermediate step, PGP certificates are likely to be used. Waiting for DNS-SIG, X.509 (3 versions), and other certificate distribution is not my idea of a usable system. Maybe in 2001. I am not in favor of holding up a mechanism that is _better_ than manually distributed names and secrets for session-keys, in order to argue the details of a more complicated long-term identification distribution mechanism. That is why the certificates are in a separate extensions document. It will probably be argued yet another year.... Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sun Oct 15 23:19:08 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12997 (5.65c/IDA-1.4.4 for ); Sun, 15 Oct 1995 19:27:41 -0400 Received: by interlock.ans.net id AA13197 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 15 Oct 1995 19:19:20 -0400 Message-Id: <199510152319.AA13197@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 15 Oct 1995 19:19:20 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 15 Oct 1995 19:19:20 -0400 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: "William Allen Simpson" Cc: ipsec@ans.net Subject: Re: Nodes and Users In-Reply-To: Your message of "Sun, 15 Oct 1995 05:05:29 GMT." <199510150527.AA70227@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sun, 15 Oct 1995 19:19:08 -0400 From: "Perry E. Metzger" "William Allen Simpson" writes: > > From: "Perry E. Metzger" > > Bill has expressed to me in private mail that he thinks that the > > question of certificates, certificate formats and naming can wait, but > > frankly I don't think it can because we don't have a usable system > > without it. > > > I firmly disagree. The _usable_ system is Photuris with names and > secrets, using only MD5 and DES, which can leverage off the current > installed base. This fills exactly the same needs as the AH and ESP > base requirements. > > As an intermediate step, PGP certificates are likely to be used. Thats fine, but we have to start looking in to how names and certificates can plug in. We can even build the architecture to be extensible so we don't have to make permanent decisions, but we have to make some. You have to be able to ask who it is you are talking to and have a meaningful answer or perfect forward secrecy means nothing. > Waiting for DNS-SIG, X.509 (3 versions), and other certificate > distribution is not my idea of a usable system. Maybe in 2001. I don't think X.509 is viable, but surely we are smart enough to come up with something that is viable. If we simply punt we don't have a real deployable system. Unlike some I don't think this is impossible for us to do and do quickly. However, it has to be done. Perry From ipsec-request@ans.net Mon Oct 16 10:59:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18894 (5.65c/IDA-1.4.4 for ); Mon, 16 Oct 1995 07:12:33 -0400 Received: by interlock.ans.net id AA33875 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 16 Oct 1995 07:05:44 -0400 Message-Id: <199510161105.AA33875@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 16 Oct 1995 07:05:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 16 Oct 1995 07:05:44 -0400 Date: Mon, 16 Oct 95 10:59:26 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: photuris-05c The latest Photuris draft may be found at ftp.morningstar.com: pub/I-Net/photuris-05c Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Mon Oct 16 14:44:37 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19084 (5.65c/IDA-1.4.4 for ); Mon, 16 Oct 1995 10:53:57 -0400 Received: by interlock.ans.net id AA34132 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 16 Oct 1995 10:46:08 -0400 Message-Id: <199510161446.AA34132@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 16 Oct 1995 10:46:08 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 16 Oct 1995 10:46:08 -0400 From: Saroj Bhandari Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 16 Oct 1995 10:46:08 -0400 Date: Mon, 16 Oct 1995 10:44:37 -0400 (EDT) To: ipsec@ans.net Subject: call for papers Cc: tony@eng.umd.edu Call for Papers Hybrid and Satellite Communication Networks A special issue to be published in WIRELESS NETWORKS published in cooperation with the ACM: Scope: As attention is focused today on wireless communications, a key component of the wireless connectivity fabric is often overlooked. Satellites represent a crucial element of the global information infrastructure and are experiencing a quiet technology revolution that will multiply their capabilities significantly. The recent launches of OLYMPUS in Europe and the ACTS in the United States have proven that on-board processing, bandwidth-on-demand, switchable spot-beams, and the use of the Ka-band can convert, until now, the passive "bent-pipe" reflectors to powerful, full-fledged network nodes. The satellite advantages of ubiquitous coverage, easy access, large bandwidth, immunity to terrestrial catastrophes, and relatively low-cost add up to make satellites indispensable as parts of the worldwide information highway. The much discussed personal communication systems that are currently under development, from Motorola's Iridium to the Teledesics bold constellation concept, demonstrate one aspect of the envisioned role of future satellite systems in the mobile communication area. The main technical bottlenecks that must be overcome to permit the seamless incorporation of satellites into modern hybrid networks and their transparent interoperability with terrestrial links (whether wireless or not) include: - The mismatch of bandwidth, error-rate, and propagation delay properties between satellite and terrestrial links. - The need for seamless network protocol operation - The differences among the multiple services anticipated by such networks in the emerging multimedia markets - The congestion, access, admission control, and bandwidth allocation problems - The cost of terminal manufacturing with dual (space/terrestrial) capabilities - The regulatory, standardization, pricing, and other commercial and business issues that impact the operation of such systems. Authors are invited to send 6 copies of their papers to the guest editor on subjects that relate to the above topics. Please list contact persons, addresses, phone, fax, and e-mail information on the front page of the paper. The following schedule will be followed: Manuscript submission: February 15, 1996 Acceptance notification: June 15, 1996 Final Manuscript Due: September 15, 1996 Publication Date: 4th quarter 1997 Guest Editor: Anthony Ephremides Dept. of Electrical Engineering University of Maryland College Park, MD 20742, USA From ipsec-request@ans.net Mon Oct 16 06:55:18 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17046 (5.65c/IDA-1.4.4 for ); Mon, 16 Oct 1995 10:56:55 -0400 Received: by interlock.ans.net id AA03550 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 16 Oct 1995 10:55:25 -0400 Message-Id: <199510161455.AA03550@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 16 Oct 1995 10:55:25 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 16 Oct 1995 10:55:25 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 16 Oct 1995 10:55:25 -0400 Date: Mon, 16 Oct 95 10:55:18 EDT To: ipsec@ans.net Subject: Photuris // Variable-Precision numbers I find the treatment of variable-precision numbers still confusing. The number of significant bits should be the number of bits you need to look at to determine the number. If the number of significant bits is t, then the numbers representable range from 0 to 2^{t}-1, inclusive. The problem is for the case t = 1. It is inconsistent to have no bits in the value field at all. For t=1, you should be able to represent either 0 or 1. Size Value Represents (decimal) 0000 0 0001 00 0 *** This is what you want 0001 01 1 *** This is what you want 0002 00 0 0002 01 1 0002 02 2 0002 03 3 0003 00 0 ... 0003 07 7 0004 00 0 ... and so on... ============================================================================== Return-Path: Date: Sun, 15 Oct 95 02:23:19 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris // Variable-Precision numbers As I said, I had to think about it some more. Sorry, should have gotten back to you on that, but here is what I actually wrote: Each variable precision number is composed of two parts. Size two or four octets. Number of significant bits used in the Value field. Always transmitted most significant octet first. A Size of zero has no Value field; value is zero. A Size of one has no Value field; value is one. When the most significant octet is in the range 0 through 254 (0xfe), the field is two octets. Both octets are used to indicate the size of the Value field. When the most significant octet is 255 (0xff), the field is four octets. The remaining three octets are used to indicate the size of the Value field. Value variable. The bits used are right justified and zero filled on octet boundaries; that is, any unused bits are in the most significant octet. Always transmitted most significant octet first. The shorter forms SHOULD NOT be used when the Size indicates a number of significant bits which happen to be zero. > From: rivest@theory.lcs.mit.edu (Ron Rivest) > Representing a value of one by a Size of one, and no value field, is > inconsistent with the purpose of the Size field, and rules out the > possibility of having a Size field of one with a real value field of length > one. (I am interpreting the Size field to mean the length of the Value > field only; the 2 bytes of the Size field are not counted.) > > What you want is something like (bytes given in hex): > > Size Value Represents (decimal) > 00 0 > 01 00 0 > 01 01 1 > 01 02 2 > ... > 01 FF 255 > 02 00 00 0 > 02 00 01 1 > ... > 02 FF FF 65535 > and so on. > > Correct? > Not quite, the Size is _bits_ not _bytes_: Size Value Represents (decimal) 0000 0 0001 1 0002 00 0 0002 01 1 0002 02 2 ... 0008 01 1 (8 significant bits) 0008 FF 255 0009 0001 1 (9 significant bits) ... ff223344 00...01 1 (many significant bits ;-) Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Mon Oct 16 20:11:56 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12244 (5.65c/IDA-1.4.4 for ); Mon, 16 Oct 1995 16:50:18 -0400 Received: by interlock.ans.net id AA51044 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 16 Oct 1995 16:37:16 -0400 Message-Id: <199510162037.AA51044@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 16 Oct 1995 16:37:16 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 16 Oct 1995 16:37:16 -0400 Date: Mon, 16 Oct 95 20:11:56 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris // Variable-Precision numbers > From: rivest@theory.lcs.mit.edu (Ron Rivest) > The problem is for the case t = 1. It is inconsistent to have no bits in the > value field at all. For t=1, you should be able to represent either 0 or 1. > Size Value Represents (decimal) > 0000 0 What in the world is a number with _no_ significant bits? > 0001 00 0 *** This is what you want > 0001 01 1 *** This is what you want What is the point of a number with 1 significant bit which is always 1? My answer to these rhetorical questions is: There is no such thing as a number with no significant bits. Therefore, we steal that number to make programming simpler. 0 means a number with one significant bit, which is 0. Rather than wasting space on a number with 1 significant bit, when half the possible values are already special cased, use the size field to special case that 1, meaning 1 significant bit of value 1. Oh, and this is all rather a waste of time arguing, since 0 and 1 aren't legal for exponents anyway. They are just very commonly used numbers. Never-the-less, I will try to make the wording clearer next time around. I presume that you like the 'ff' extension scheme? Good, thanks for the suggestion! And since we are down to little quibbles, I presume that you are happy with the fields hashed for the signature, session-keys, and others? Are there any serious cryptographic flaws in the messages? Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Tue Oct 17 00:20:24 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12722 (5.65c/IDA-1.4.4 for ); Mon, 16 Oct 1995 20:19:28 -0400 Received: by interlock.ans.net id AA03370 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 16 Oct 1995 20:11:42 -0400 Message-Id: <199510170011.AA03370@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 16 Oct 1995 20:11:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 16 Oct 1995 20:11:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 16 Oct 1995 20:11:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 16 Oct 1995 20:11:42 -0400 Date: Mon, 16 Oct 1995 17:20:24 -0700 From: ashar@osmosys.incog.com (Ashar Aziz) To: caronni@tik.ee.ethz.ch Subject: Re: comments on SKIP draft 02 Cc: ipsec@ans.net X-Sun-Charset: US-ASCII Germanno, I have updated the SKIP I-D with all of your suggested protocol modifications. Others also made similar suggestions, and this seemed like the right thing to do. I just mailed an updated I-D for publication. Please review this document first from a protocol point of view, and secondarily from an editorial perspective. It is important to get the protocol correct first, and perhaps add better organized text later. I am hoping that this current draft will be close enough from a protocol perspective to begin implementation efforts (so that we can all be done by December!). The editorial modifications that you requested can be done in parallel with implementation efforts. I am inclined to keep the text regarding motivation and rationale. I believe this helps in understanding the overall document. Re: sequencing. I have some thoughts on sequencing that I will write up as soon as I get the time. In particular, I believe it is possible to do this without writing a dozen new transforms. Regards, Ashar. From ipsec-request@ans.net Mon Oct 16 20:21:23 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12219 (5.65c/IDA-1.4.4 for ); Mon, 16 Oct 1995 20:21:23 -0400 Received: by interlock.ans.net id AA100205 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 16 Oct 1995 20:16:40 -0400 Message-Id: <199510170016.AA100205@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 16 Oct 1995 20:16:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 16 Oct 1995 20:16:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 16 Oct 1995 20:16:40 -0400 Date: Mon, 16 Oct 95 16:44:44 From: "Housley, Russ" Encoding: 291 Text To: IPSEC@ans.net, hugo@watson.ibm.com Subject: Re: Security problems in Photuris #2 Hugo: I agree. The key management protocol MUST support a wide family of algorithms. Many commercial and academic users will embrace RSA, but I suspect that government users will be strongly encourage (or even forced) to use DSS. Therefore, we need a flexible solution. Russ From ipsec-request@ans.net Tue Oct 17 01:50:31 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17316 (5.65c/IDA-1.4.4 for ); Mon, 16 Oct 1995 22:06:44 -0400 Received: by interlock.ans.net id AA41580 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 16 Oct 1995 22:01:58 -0400 Message-Id: <199510170201.AA41580@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 16 Oct 1995 22:01:58 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 16 Oct 1995 22:01:58 -0400 Date: Tue, 17 Oct 95 01:50:31 GMT From: "William Allen Simpson" To: rivest@theory.lcs.mit.edu (Ron Rivest) Cc: ipsec@ans.net Subject: Re: Photuris // Variable-Precision numbers I'm tossing this off without having read the list in half a day, so if this has already been resolved, you can ignore this message. Talking to a social science prof after choir, I was reminded about "missing data" from social science math packages like SPSS. So, how about the following: 0000 -- --- means "missing value" 0001 00 0 (one significant bit, as expected) 0001 01 1 Would that tickle the hearts of mathematicians out there? Better yet, is there some standard math package that we should follow (noting that this doesn't support signed numbers or anything fancy)? The above will work (mostly) with PGP coded numbers.... Still have to add code to check for the 255 expansion. Got to admit, this is not the kind of thing I expected to be arguing about! Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Mon Oct 16 18:09:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12974 (5.65c/IDA-1.4.4 for ); Mon, 16 Oct 1995 22:10:57 -0400 Received: by interlock.ans.net id AA47592 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 16 Oct 1995 22:09:35 -0400 Message-Id: <199510170209.AA47592@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 16 Oct 1995 22:09:35 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 16 Oct 1995 22:09:35 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 16 Oct 1995 22:09:35 -0400 Date: Mon, 16 Oct 95 22:09:26 EDT To: bsimpson@morningstar.com, ipsec@ans.net Subject: Photuris // Variable-Precision numbers I agree with Bill that this is quibbling over a real minor point, but I'll continue the debate just this once from a desire for mathematical cleanliness. Let S denote the value of the Size field and let V denote the value of the Value field, represented as an integer with very large precision: V = .....v_5 v_4 v_3 v_2 v_1 v_0 Then the answer we want can be represented as X, computed by the program: X = Sum_{0<=i Date: Mon, 16 Oct 95 20:11:56 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris // Variable-Precision numbers > From: rivest@theory.lcs.mit.edu (Ron Rivest) > The problem is for the case t = 1. It is inconsistent to have no bits in the > value field at all. For t=1, you should be able to represent either 0 or 1. > Size Value Represents (decimal) > 0000 0 What in the world is a number with _no_ significant bits? > 0001 00 0 *** This is what you want > 0001 01 1 *** This is what you want What is the point of a number with 1 significant bit which is always 1? My answer to these rhetorical questions is: There is no such thing as a number with no significant bits. Therefore, we steal that number to make programming simpler. 0 means a number with one significant bit, which is 0. Rather than wasting space on a number with 1 significant bit, when half the possible values are already special cased, use the size field to special case that 1, meaning 1 significant bit of value 1. Oh, and this is all rather a waste of time arguing, since 0 and 1 aren't legal for exponents anyway. They are just very commonly used numbers. Never-the-less, I will try to make the wording clearer next time around. I presume that you like the 'ff' extension scheme? Good, thanks for the suggestion! And since we are down to little quibbles, I presume that you are happy with the fields hashed for the signature, session-keys, and others? Are there any serious cryptographic flaws in the messages? Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Tue Oct 17 04:58:47 1995 Received: from ilold.ans.net (interlock.ans.net) by ftp.ans.net with SMTP id AA17801 (5.65c/IDA-1.4.4 for ); Tue, 17 Oct 1995 09:05:10 -0400 Received: by ilold.ans.net id AA38363 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 17 Oct 1995 08:58:52 -0400 Message-Id: <199510171258.AA38363@ilold.ans.net> Received: by ilold.ans.net (Protected-side Proxy Mail Agent-3); Tue, 17 Oct 1995 08:58:52 -0400 Received: by ilold.ans.net (Protected-side Proxy Mail Agent-2); Tue, 17 Oct 1995 08:58:52 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by ilold.ans.net (Protected-side Proxy Mail Agent-1); Tue, 17 Oct 1995 08:58:52 -0400 Date: Tue, 17 Oct 95 08:58:47 EDT To: ipsec@ans.net, naganand@ftp.com Subject: Photuris // Variable-Precision numbers v_0 is the least significant bit, so it has significance 2^0 = 1; the formula is correct as I wrote it, I believe... Ron Rivest ============================================================================== Return-Path: Date: Tue, 17 Oct 1995 08:55:26 -0400 X-Sender: naganand@mailserv-H.ftp.com Mime-Version: 1.0 To: rivest@theory.lcs.mit.edu (Ron Rivest) From: naganand@ftp.com (Naganand Doraswamy) Subject: Re: Photuris // Variable-Precision numbers Ron, Quick clarification on the formula you posted in IP security mailing list. > V = .....v_5 v_4 v_3 v_2 v_1 v_0 >Then the answer we want can be represented as X, computed by the program: > X = Sum_{0<=i); Tue, 17 Oct 1995 10:11:35 -0400 Received: by ilold.ans.net id AA71440 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 17 Oct 1995 10:06:26 -0400 Message-Id: <199510171406.AA71440@ilold.ans.net> Received: by ilold.ans.net (Protected-side Proxy Mail Agent-2); Tue, 17 Oct 1995 10:06:26 -0400 Received: by ilold.ans.net (Protected-side Proxy Mail Agent-1); Tue, 17 Oct 1995 10:06:26 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-photuris-05.txt Date: Tue, 17 Oct 95 09:48:41 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Photuris Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-photuris-05.txt Pages : 53 Date : 10/16/1995 Photuris [Firefly] is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-photuris-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-05.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-photuris-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951016142319.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-photuris-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-photuris-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951016142319.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Oct 17 18:46:37 1995 Received: from ilold.ans.net (interlock.ans.net) by ftp.ans.net with SMTP id AA15422 (5.65c/IDA-1.4.4 for ); Tue, 17 Oct 1995 14:50:52 -0400 Received: by ilold.ans.net id AA08412 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 17 Oct 1995 14:46:45 -0400 Message-Id: <199510171846.AA08412@ilold.ans.net> Received: by ilold.ans.net (Protected-side Proxy Mail Agent-3); Tue, 17 Oct 1995 14:46:45 -0400 Received: by ilold.ans.net (Protected-side Proxy Mail Agent-2); Tue, 17 Oct 1995 14:46:45 -0400 Received: by ilold.ans.net (Protected-side Proxy Mail Agent-1); Tue, 17 Oct 1995 14:46:45 -0400 Date: Tue, 17 Oct 1995 11:46:37 -0700 From: Hilarie Orman To: rivest@theory.lcs.mit.edu Cc: ipsec@ans.net, bsimpson@morningstar.com In-Reply-To: Yourmessage <199510170209.AA47592@interlock.ans.net> Subject: Re: Photuris // Variable-Precision numbers But Bill's scheme suggests X = if (S=0) then 0 else 2^(S-1) + Sum_{0<=i); Tue, 17 Oct 1995 19:41:45 -0400 Received: by interlock.ans.net id AA21932 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 17 Oct 1995 19:37:07 -0400 Message-Id: <199510172337.AA21932@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 17 Oct 1995 19:37:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 17 Oct 1995 19:37:07 -0400 Date: Tue, 17 Oct 95 22:35:39 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris // Variable-Precision numbers Looks like folks have found a new and exciting passtime -- analyzing the efficiency of bit storage techniques. The one that I wrote seemed closest to the code at hand. However, since there were some questions, which may or may not indicate actual implementation problems, I have inquired about a couple of packages which are related to the work at hand: 1) Gnu Math Package 2) PKCS 3) PGP GMP apparently uses arrays of longs. Not always the same longs on every platform. Using this as our external representation would make truly large packets, and need more specification. Not quite what we need. PKCS uses ASN.1 DER. I vaguely remember "assinine one" from poking at SNMP. It is more compact than the current design for very short numbers, 12.5% bigger for medium sized numbers, and is lost in the noise for very large numbers. It is difficult to parse (masking and shifting 7-bit quantities). But, since anybody using PKCS or X.509 will have ASN.1 parsing available, that's how the certificate field will be defined in those cases. PGP has a very nice simple representation. This looks close to what Karn used in the initial implementation. I guess that "Implementors" just pick simpler structures, or maybe it is just that both Karn and Zimmerman are named Phil, but this looks like they think somewhat alike. So, I am mangling the PGP representation to allow longer bit strings. Where simple things such as public-values and hashes are used, this is the notation: Size two, four, or eight octets. The number of significant bits used in the Value field. Always transmitted most significant octet first. Size zero has no Value field; there are no significant bits. This means "missing" or "null", and should not be confused with the value zero. When the most significant octet is in the range 0 through 254 (0xfe), the field is two octets. Both octets are used to indicate the size of the Value field, which ranges from 1 to 65,279 significant bits (in 1 to 8,160 octets). When the most significant octet is 255 (0xff), the field is four octets. The remaining three octets are added to 65,280 to indicate the size of the Value field, which is limited to 16,776,959 significant bits (in 2,097,120 octets). When the most significant two octets are 65,535 (0xffff), the field is eight octets. The remaining six octets are added to 16,776,960 to indicate the size of the Value field. This is vastly too long for anything in these messages, but is included for completeness. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Oct 18 01:18:43 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12947 (5.65c/IDA-1.4.4 for ); Tue, 17 Oct 1995 21:29:44 -0400 Received: by interlock.ans.net id AA22890 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 17 Oct 1995 21:24:32 -0400 Message-Id: <199510180124.AA22890@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 17 Oct 1995 21:24:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 17 Oct 1995 21:24:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 17 Oct 1995 21:24:32 -0400 From: alten@na.SJF.Novell.COM (Alex Alten) Subject: Re: Photuris // Variable-Precision numbers To: bsimpson@morningstar.com (William Allen Simpson) Date: Tue, 17 Oct 1995 18:18:43 -0700 (PDT) Cc: ipsec@ans.net In-Reply-To: <199510150258.AA92323@interlock.ans.net> from "William Allen Simpson" at Oct 15, 95 02:23:19 am X-Mailer: ELM [version 2.4 PL22] Original-Content-Type: text Content-Type: text/plain Content-Length: 558 May I suggest that you use ASN.1 encoding for the multiprecision integers? This is a standard that is in use (by SNMP) and has both commercial and public domain software libraries available. The only extra overhead is one leading byte for the data type field, otherwise it is the same thing as you and Ron are discussing, with a length field followed by the integer (data). - Alex -- Alexander I. Alten Alten@Na.Sjf.Novell.Com (408) 577-8224 Novell, Inc. Member of Technical Staff Mail Stop F1-42-D2 2180 Fortune Drive San Jose, CA 95131 USA From ipsec-request@ans.net Wed Oct 18 08:15:15 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19146 (5.65c/IDA-1.4.4 for ); Wed, 18 Oct 1995 04:20:18 -0400 Received: by interlock.ans.net id AA25933 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 18 Oct 1995 04:15:32 -0400 Message-Id: <199510180815.AA25933@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 18 Oct 1995 04:15:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 18 Oct 1995 04:15:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 18 Oct 1995 04:15:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 18 Oct 1995 04:15:32 -0400 To: alten@na.sjf.novell.com (Alex Alten) Cc: bsimpson@morningstar.com (William Allen Simpson), ipsec@ans.net Subject: Re: Photuris // Variable-Precision numbers In-Reply-To: Your message of Tue, 17 Oct 1995 18:18:43 -0700. <199510180124.AA22890@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <27054.814004114.1@grizzly.genua.de> Date: Wed, 18 Oct 1995 09:15:15 +0100 From: Bernhard Schneck In message <199510180124.AA22890@interlock.ans.net>you write: > > May I suggest that you use ASN.1 encoding for the multiprecision integers? > This is a standard that is in use (by SNMP) and has both commercial and > public domain software libraries available. The only extra overhead is > one leading byte for the data type field, otherwise it is the same thing > as you and Ron are discussing, with a length field followed by the integer > (data). With the following differences: - ASN.1 counts bytes in the size field, the Photuris draft counts bits - ASN.1 has signed integers, the Photuris draft uses unsigned - ASN.1 encoding rules can be a pain in to get right for some values (eg. 128 is encoded as 02 02 00 80, ie. it requires at least two bytes for the value) \Bernhard. From ipsec-request@ans.net Wed Oct 18 05:12:35 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16690 (5.65c/IDA-1.4.4 for ); Wed, 18 Oct 1995 09:18:34 -0400 Received: by interlock.ans.net id AA28454 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 18 Oct 1995 09:12:46 -0400 Message-Id: <199510181312.AA28454@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 18 Oct 1995 09:12:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 18 Oct 1995 09:12:46 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 18 Oct 1995 09:12:46 -0400 Date: Wed, 18 Oct 95 09:12:35 EDT To: ipsec@ans.net Subject: Photuris // entities I'm still confused about how the entities communicated are to be identified. Here is a specific concern, using the terminology of version 5 of the Photuris draft: When the Initiator initiates a connection, all he specifies regarding the identity of the desired responder is the IP address of the node he sends his Cookie_Request to. However, later on, he may receive an Identification_Message from the (purported) responder that has an Identification field that is, in the current draft, unconstrained. *** When is the Responder's Identification field (un)acceptable? *** For example, is an Identification from a specific user at the responder's site unacceptable? (I should think so, since the Initiator didn't -- and couldn't -- have requested communication with that specific user in his initial Cookie_Request or Exchange_Request.) I think that the protocol definition should define all possible error conditions, and specify what the appropriate actions are for the detector of the error. In this case, I think that the Photuris protocol is either "buggy" or "contains a gap in its specification". It is "buggy" if it the Initiator is supposed to accept ANY correct Identification and Verification information from the Responder. At the minimum, one would hope that there be a constraint that the identification specify either the node with the original IP address requested or a user at that node. It "contains a gap in its specification" if there is more than one Identification that is permissible for the Responder to send, but the Initiator may reasonably prefer one instead of the others. The gap is that the Initiator should be allowed to specify in his original request (the Exchange_Request, I suppose, or else the Cookie_Request) the identity or identities of the parties with whom he wishes to set up a Security Association. Ron Rivest From ipsec-request@ans.net Wed Oct 18 05:28:44 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18261 (5.65c/IDA-1.4.4 for ); Wed, 18 Oct 1995 09:38:41 -0400 Received: by interlock.ans.net id AA28645 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 18 Oct 1995 09:28:51 -0400 Message-Id: <199510181328.AA28645@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 18 Oct 1995 09:28:51 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 18 Oct 1995 09:28:51 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 18 Oct 1995 09:28:51 -0400 Date: Wed, 18 Oct 95 09:28:44 EDT To: ipsec@ans.net Subject: Photuris // entities Although my previous question was phrased from the point of view of the Initiator, the same question arises from the point of view of the Responder: When is the Initiator's Identification information unacceptable to the Responder? This seems likely to be a somewhat differennt question than the analogous version regarding the Responder's Identification information, and may have a different answer. In both cases, however, the protocol spec should make these answers explicit... Ron Rivest From ipsec-request@ans.net Wed Oct 18 13:25:56 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12729 (5.65c/IDA-1.4.4 for ); Wed, 18 Oct 1995 10:29:31 -0400 Received: by interlock.ans.net id AA29592 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 18 Oct 1995 10:18:41 -0400 Message-Id: <199510181418.AA29592@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 18 Oct 1995 10:18:41 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 18 Oct 1995 10:18:41 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-skip-03.txt Date: Wed, 18 Oct 95 09:25:56 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Simple Key-Management For Internet Protocols (SKIP) Author(s) : A. Aziz Filename : draft-ietf-ipsec-skip-03.txt Pages : 52 Date : 10/16/1995 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 (for example, IP and IPv6) 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 or IPv6. We also describe a simple extension of this protocol to provide scalable group key-management for Internet multicasting protocols. SKIP has been designed to work with the IP Security Protocols AH and ESP [8,9,10] which are specified for both IPv4 and IPv6. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-skip-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-skip-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951017105721.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951017105721.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Wed Oct 18 10:11:52 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16834 (5.65c/IDA-1.4.4 for ); Wed, 18 Oct 1995 14:16:11 -0400 Received: by interlock.ans.net id AA04873 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 18 Oct 1995 14:11:34 -0400 Message-Id: <199510181811.AA04873@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 18 Oct 1995 14:11:34 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 18 Oct 1995 14:11:34 -0400 Date: Wed, 18 Oct 95 14:11:52 EDT From: Robert Glenn To: ipsec@ans.net Subject: Questions on AH and ESP for IPv4 Cc: glenn@snad.ncsl.nist.gov Two issues follow, one dealing with fragmentation, the Authentication Header, and routers, the other dealing with the ESP Tunnel mode and TTLs. Page 2 of the RFC1826 says "Also, Path MTU Discovery MUST be used when intermediate authentication of the Authentication Header is desired and IPv4 is in use because with this method it is not possible to authenticate a fragment of a packet [MD90] [Kno93]". And Page 8 says "IPv4 Implementations SHOULD use Path MTU Discovery when the IP Authentication Header is being used [MD90]". There seems to be a minor ambiguity between pages 2 and 8, but my interpretation of this is that AH *hosts* SHOULD use PMTU and AH routers MUST use PMTU. I propose that the sentence on page 8 should be chopped and on page 2 it should read: "Also, Path MTU Discovery SHOULD be used in conjunction with the Authentication header in IPv4 hosts and MUST be used when intermediate authentication of the Authentication Header is desired in IPv4 routers because with this method it is not possible to authenticate a fragment of a packet [MD90] [Kno93]" It's a minor change, but I think it is less ambiguous. I don't have PMTU and of course my AH router code breaks when fragmentation begins. Also, this is an area that is inconsistant with the ESP spec. ESP would suffer the same problem, except there is the ESP Tunnel mode that solves the problem. Until PMTU is better deployed, would it be valuable to have either an AH Tunnel mode or a more generic IPSEC Tunnel mode? Next topic deals with the ESP Tunnel mode. On the clear IPv4 packet, what should the TTL be set to? My initial take was to set it to the value in the encrypted packet, but later decided to set it to MAXTTL and let the other end of the tunnel worry about the real TTL. It makes for some interesting observations when using traceroute. Also should this issue be mentioned in the spec. or is it just an implementation issue? Rob Glenn Rob.Glenn@nist.gov From ipsec-request@ans.net Wed Oct 18 19:14:53 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17014 (5.65c/IDA-1.4.4 for ); Wed, 18 Oct 1995 19:30:06 -0400 Received: by interlock.ans.net id AA12721 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 18 Oct 1995 19:26:43 -0400 Message-Id: <199510182326.AA12721@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 18 Oct 1995 19:26:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 18 Oct 1995 19:26:43 -0400 Date: Wed, 18 Oct 95 19:14:53 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Tunnel mode Cannot answer the other question, since I've always considered intermediate authentication impractical. > From: Robert Glenn > Next topic deals with the ESP Tunnel mode. On the clear IPv4 packet, > what should the TTL be set to? My initial take was to set it to the > value in the encrypted packet, but later decided to set it to MAXTTL > and let the other end of the tunnel worry about the real TTL. It makes > for some interesting observations when using traceroute. Also should > this issue be mentioned in the spec. or is it just an implementation > issue? > Try reading RFC-1853. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Thu Oct 19 01:17:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12133 (5.65c/IDA-1.4.4 for ); Wed, 18 Oct 1995 21:22:10 -0400 Received: by interlock.ans.net id AA14805 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 18 Oct 1995 21:17:39 -0400 Message-Id: <199510190117.AA14805@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 18 Oct 1995 21:17:39 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 18 Oct 1995 21:17:39 -0400 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 18 Oct 1995 21:17:39 -0400 Subject: Preliminary comment skip draft 03 To: ashar@osmosys.incog.com (Ashar Aziz) Date: Thu, 19 Oct 1995 02:17:26 +0100 (MET) Cc: ipsec@ans.net, skip-info@tik.ee.ethz.ch, skip@tik.ee.ethz.ch (SKIP Software), plattner@tik.ee.ethz.ch (Bernhard Plattner) X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 2051 Hello Ashar, all, I just received the new skip draft (03), and did one quick reading. I was pleased to see the changes and adaptions. (03) looks really close to 'IT' for me. I am mostly happy with it, only the certificate discovery seems botched. Assume I send a request for certificates partaining to a certain master Id, and want at the same time to provide some of my own certificates, and the corresponding master ID. The draft explicitly states that this is possible. But there is only one master ID field. Is there a master ID stored within each certificate? [Hmm. Might be.] Something there is ambigous, or perhaps plain wrong. Do you expect all future certificates to be shorter than 256 bytes? As indicated by CERT-LENGTH. And there are more things that I already mentioned in my comments to (02). I will do some careful reading in the next few days, and give you a more exhaustive reply by Monday or so. Friendly greetings, Germano infamous second thoughts: p.s. concerning the usage of stream ciphers: We saw in Atlanta that a cipher with speed comparable to RC4 is needed for encryption of live video. The draft mentions RC4 as possible 'Crypt Alg', but gives no references as how the following header is to be composed. Perhaps this, and the MI issue should be discussed somewhere? On the other hand I have been informed that there are legal issues with writing an RC4 transform draft. The same probably is true in this case. If yes, I just want to give the following input. It might allow us to synchronize implemenation efforts, without stumbling over ITAR and 'cleanroom': encrypted part +---------------+-----------------------+====+========================+ |32-bit SKIP SPI|64-bit MI network order|data|8bit next protocol field| +---------------+-----------------------+====+========================+ where MI is the number of bytes that were already encrypted with the current Kp. p.p.s RFC1851 (3DES) does not appear in (03). Why? See my comments to draft (02). From ipsec-request@ans.net Thu Oct 19 06:53:40 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18352 (5.65c/IDA-1.4.4 for ); Thu, 19 Oct 1995 03:57:58 -0400 Received: by interlock.ans.net id AA19276 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 19 Oct 1995 03:54:31 -0400 Message-Id: <199510190754.AA19276@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 19 Oct 1995 03:54:31 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 19 Oct 1995 03:54:31 -0400 Date: Thu, 19 Oct 95 06:53:40 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris // entities > From: rivest@theory.lcs.mit.edu (Ron Rivest) > I'm still confused about how the entities communicated are to be identified. > Here is a specific concern, using the terminology of version 5 of the > Photuris draft: > > When the Initiator initiates a connection, all he specifies > regarding the identity of the desired responder is the IP > address of the node he sends his Cookie_Request to. > > However, later on, he may receive an Identification_Message > from the (purported) responder that has an Identification field > that is, in the current draft, unconstrained. > > *** When is the Responder's Identification field (un)acceptable? *** > Current text reads: Early implementations may wish to keep their own trusted key databases, such as the Pretty Good Privacy web of trust, and accept only those users whose identification is found there. So, if either the Initiator or Responder isn't found in the database, that's a failure, and the Verification Failed Error_Message is sent. Eventually, with X.509 or DNS-SIG, if they aren't found in the external database, they would likewise fail. > For example, is an Identification from a specific user > at the responder's site unacceptable? (I should think so, since > the Initiator didn't -- and couldn't -- have requested communication > with that specific user in his initial Cookie_Request or > Exchange_Request.) > First of all, in most cases, this will be router (firewall) to router, or host to router, or single-user host to single-user host. In those cases, as to either Initiator or Responder, I would say that _any_ valid identity which correctly signs/MACs/whatever is good enough. In the MLS target scenario, the Responder isn't a "user", it is a "secure system". I don't know any incoming processes that are identified with "users". I don't think of FTP as a "user", even though it might run in user space, as it isn't individually controlled by a human being. So, the only possible "unauthorized" party would be the Initiator. Photuris merely handles the identity exchange, and successfully completes. Assuming the secure system has any degree of Access Control, it "knows" which Initiators are valid. The access control would be handled by higher layers -- for example, not allow Telnet but allow anonymous FTP. Current text reads: Each party implements local policy that determines what access, if any, is granted to the holder of a particular identity. And of course, in the Attributes section itself: Authentication policy is in the SPI Owner (receiver) direction. > I think that the protocol definition should define > all possible error conditions, and specify what the appropriate > actions are for the detector of the error. > I think that it does. It just has fewer error conditions than you seem to want, because it does _not_ handle Access Control. The appropriate action is already listed: If identity verification fails, the users are notified, an Error_Message is sent, and the Security Association is destroyed. > It is "buggy" if it the Initiator is supposed to accept ANY > correct Identification and Verification information from the > Responder. At the minimum, one would hope that there be a > constraint that the identification specify either the node with > the original IP address requested or a user at that node. > I think that will be very implementation dependent, and outside the scope of the specification. But we could list some more of the possibilities in the Appendix: - It could be a user@node.site, of course. - It could be the hostmaster@site, or hostmaster@node.site. In the Extensions draft: - It could be a DNS-SIG for the node or the site. - It could be a configured PGP key (already mentioned). - It could be many forms of X.509, and I'll leave the X.509 advocates to submit language. > It "contains a gap in its specification" if there is more than > one Identification that is permissible for the Responder to send, > but the Initiator may reasonably prefer one instead of the others. > The gap is that the Initiator should be allowed to specify in his > original request (the Exchange_Request, I suppose, or else the > Cookie_Request) the identity or identities of the parties with > whom he wishes to set up a Security Association. > I am totally against this. The list could have thousands or tens of thousands of identities and preferences. It would be an administrative and protocol nightmare. And would assist in defeating privacy. Any authentic Identification is as good as another for the purposes of preventing a man-in-middle attack. Access Control is outside the scope. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Thu Oct 19 11:19:19 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18833 (5.65c/IDA-1.4.4 for ); Thu, 19 Oct 1995 07:24:18 -0400 Received: by interlock.ans.net id AA20745 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 19 Oct 1995 07:19:24 -0400 Message-Id: <199510191119.AA20745@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 19 Oct 1995 07:19:24 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 19 Oct 1995 07:19:24 -0400 From: Karl Fox Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 19 Oct 1995 07:19:24 -0400 Date: Thu, 19 Oct 95 07:19:19 -0400 To: Robert Glenn Cc: ipsec@ans.net Subject: Questions on AH and ESP for IPv4 In-Reply-To: <199510181811.AA04873@interlock.ans.net> References: <199510181811.AA04873@interlock.ans.net> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Robert Glenn writes: > Page 2 of the RFC1826 says "Also, Path MTU Discovery MUST be used when > intermediate authentication of the Authentication Header is desired and > IPv4 is in use because with this method it is not possible to > authenticate a fragment of a packet [MD90] [Kno93]". ... > I propose that the sentence on page 8 should be chopped > and on page 2 it should read: "Also, Path MTU Discovery SHOULD be used > in conjunction with the Authentication header in IPv4 hosts and MUST be > used when intermediate authentication of the Authentication Header is > desired in IPv4 routers because with this method it is not possible to > authenticate a fragment of a packet [MD90] [Kno93]" Please don't make this change, as it would invalidate my implementation, which always encapsulates a packet to be authenticated in IP-in-IP (ip_p=4) before adding the AH. It doesn't need Path MTU Discovery, and it works just fine. > Until PMTU is better deployed, would it be valuable to have either > an AH Tunnel mode or a more generic IPSEC Tunnel mode? An AH tunnel mode does exist -- simply do as I described above. -- Karl Fox, servant of God, employee of Morning Star Technologies +1 800 558 7827 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 From ipsec-request@ans.net Thu Oct 19 04:33:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17716 (5.65c/IDA-1.4.4 for ); Thu, 19 Oct 1995 08:37:27 -0400 Received: by interlock.ans.net id AA22239 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 19 Oct 1995 08:33:07 -0400 Message-Id: <199510191233.AA22239@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 19 Oct 1995 08:33:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 19 Oct 1995 08:33:07 -0400 Date: Thu, 19 Oct 95 08:33:26 EDT From: Robert Glenn To: karl@MorningStar.Com Subject: Re: Questions on AH and ESP for IPv4 Cc: ipsec@ans.net Karl, The change I proposed was just a re-wording of what is already in RFC1826. It is not a change in semantics, unless my interpretation is incorrect. As for the AH Tunnel mode, it is not documented in the AH spec at all. Anyone who doesn't implement the generic IP-in-IP(RFC1853 - thanks Bill), would not be able to interoperate with your implementation. All I was asking was that RFC1826 should pay some lip service to using IP-in-IP for routers until PMTU is more a part of the Internet infrastructure. Rob G. Rob.Glenn@nist.gov From ipsec-request@ans.net Thu Oct 19 19:15:16 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17187 (5.65c/IDA-1.4.4 for ); Fri, 20 Oct 1995 02:48:50 -0400 Received: by interlock.ans.net id AA15137 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 20 Oct 1995 02:44:34 -0400 Message-Id: <199510200644.AA15137@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 20 Oct 1995 02:44:34 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 20 Oct 1995 02:44:34 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 20 Oct 1995 02:44:34 -0400 X-Mailer: exmh version 1.6.2 7/18/95 To: "William Allen Simpson" Cc: ipsec@ans.net Subject: Re: Photuris // entities In-Reply-To: bsimpson's message of Thu, 19 Oct 1995 06:53:40 +0000. <199510190754.AA19276@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 19 Oct 1995 15:15:16 -0400 From: Bill Sommerfeld -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii In the MLS target scenario, the Responder isn't a "user", it is a "secure system". I don't know any incoming processes that are identified with "users". I don't think of FTP as a "user", even though it might run in user space, as it isn't individually controlled by a human being. I think this is an unfortunately limited view of the possibilities. Kerberos allows you to have multiple distinct "server principals" on a server, each with a separate cryptographic identity. Sophisticated applications can and do pick which one they want to talk to. So, the only possible "unauthorized" party would be the Initiator. I don't think that's a reasonable assumption. 1) Consider user-oriented network services like X and Zephyr, where the "server"/"responder" is close to the user, and the "client"/"initiator" is off on a server machine. It's not common, but one can have multiple heads, and multiple X servers, on a single multi-user machine. 2) If a TCP connection is idle, no packets need to flow. If the active security association expires, *either* end might need or want to recreate it. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBMIajwVpj/0M1dMJ/AQHZqgP+Ltb7ePmze+8AfdZuT1FLqoXkRmUd3g7F ea7DOKN65PvDH+ZK7AJ7aQZOUxIds3xIXgybWZ+NiYemFAjkf/P0y0ME0it1RCgm pfGFVWOu6wloXXgj5lmWeSjbxnLtuGwODgA2GQ/HuFEBT0NE3tGVxtvg2yUJj6QR Bts/X2eiUbE= =DnrU -----END PGP SIGNATURE----- From ipsec-request@ans.net Fri Oct 20 08:47:15 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17766 (5.65c/IDA-1.4.4 for ); Fri, 20 Oct 1995 08:47:15 -0400 Received: by interlock.ans.net id AA18860 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 20 Oct 1995 08:42:09 -0400 Message-Id: <199510201242.AA18860@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 20 Oct 1995 08:42:09 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 20 Oct 1995 08:42:09 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 20 Oct 1995 08:42:09 -0400 Date: Fri, 20 Oct 95 05:09:29 From: "Housley, Russ" Encoding: 1104 Text To: ipsec@ans.net, "William Allen Simpson" Subject: Re: Modify feature of Change_Message From: "William Allen Simpson" > Ran and NSA asked for the ability to modify attributes on the fly. > Thus, it is a recent addition to Photuris. If they don't give a > better reason for needing the facility, I would be happy to restrict > it again to adding/deleting entire SPIs. > > Or, if they would like, we could restrict it to only certain > attributes, which are individually specified. So far, there is only > one that has been mentioned as a candidate for modification -- > Sensitivity Label. Bill, The IEEE 802.10 working group spent alot of time discussing the various options here. In the end, we decided that SAIDs (or SPIs in Photuris) are cheap, so the possibility of confusion about the attributes associated with any particular key should be avoided. Therefore, if in the lifetime of a key two different sets of attributes need to be associted with the key, then these are treated as separate security associations. It greatly simplifies the protocol state machine. I suggest that you follow a similar track. Russ From ipsec-request@ans.net Fri Oct 20 04:20:32 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16833 (5.65c/IDA-1.4.4 for ); Fri, 20 Oct 1995 09:25:05 -0400 Received: by interlock.ans.net id AA19335 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 20 Oct 1995 09:18:21 -0400 Message-Id: <199510201318.AA19335@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 20 Oct 1995 09:18:21 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 20 Oct 1995 09:18:21 -0400 From: bwhelan@netx.nei.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 20 Oct 1995 09:18:21 -0400 Date: Fri, 20 Oct 95 09:20:32 EST To: ipsec@ans.net Subject: subscribe Can anyone tell me how to get onto this mailing list? From ipsec-request@ans.net Fri Oct 20 17:46:56 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14987 (5.65c/IDA-1.4.4 for ); Fri, 20 Oct 1995 14:28:24 -0400 Received: by interlock.ans.net id AA27053 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 20 Oct 1995 14:23:13 -0400 Message-Id: <199510201823.AA27053@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 20 Oct 1995 14:23:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 20 Oct 1995 14:23:13 -0400 Date: Fri, 20 Oct 95 17:46:56 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris // entities > From: Bill Sommerfeld > In the MLS target scenario, the Responder isn't a "user", it is a > "secure system". I don't know any incoming processes that are > identified with "users". I don't think of FTP as a "user", even though > it might run in user space, as it isn't individually controlled by a > human being. > > I think this is an unfortunately limited view of the possibilities. > Kerberos allows you to have multiple distinct "server principals" on a > server, each with a separate cryptographic identity. > So does Photuris. There is no restriction of the number of Photuris exchanges that can be active at the same time. Indeed [p 5]: When both parties initiate Photuris exchanges concurrently, or one party initiates more than one Photuris exchange, the Initiator Cookies (and UDP Ports) keep the exchanges separate. This results in more than one initial SPI for each Destination. > Sophisticated applications can and do pick which one they want to talk > to. > Correct. As they can in Photuris. But that picking is not part of Photuris, it is part of the "security architecture". Even without Photuris, something somewhere has to choose among multiple SPIs for a given Destination, so that the correct one is used for the TCP/UDP Port pair connection that is running. > So, the only possible "unauthorized" party would be the Initiator. > > I don't think that's a reasonable assumption. > > 1) Consider user-oriented network services like X and Zephyr, where > the "server"/"responder" is close to the user, and the "client"/"initiator" > is off on a server machine. It's not common, but one can have multiple > heads, and multiple X servers, on a single multi-user machine. > So? What stops them from each starting a Photuris exchange? > 2) If a TCP connection is idle, no packets need to flow. > If the active security association expires, *either* end might > need or want to recreate it. > Certainly. But as is carefully defined, the encryption policy is in the sender direction, and the authentication policy is in the receiver direction. A sender which desires to send encrypted data will initiate a Photuris exchange. No problem there, unless it doesn't trust the kernel of the other node to deliver the encrypted data only to the intended "user", as indicated by the TCP/UDP port protected in the data. But in that case, you'd be insecure no matter what you did. A receiver which requires authentication will send an ICMP message when it receives an unauthenticated datagram, and the sender will initiate a Photuris exchange to authenticate itself. Again, no problem. I think this pretty well covers it all! Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Fri Oct 20 17:39:36 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10893 (5.65c/IDA-1.4.4 for ); Fri, 20 Oct 1995 14:28:25 -0400 Received: by interlock.ans.net id AA27047 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 20 Oct 1995 14:23:09 -0400 Message-Id: <199510201823.AA27047@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 20 Oct 1995 14:23:09 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 20 Oct 1995 14:23:09 -0400 Date: Fri, 20 Oct 95 17:39:36 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Modify feature of Change_Message > From: "Housley, Russ" > The IEEE 802.10 working group spent alot of time discussing the various > options here. In the end, we decided that SAIDs (or SPIs in Photuris) are > cheap, so the possibility of confusion about the attributes associated with > any particular key should be avoided. Therefore, if in the lifetime of a > key two different sets of attributes need to be associted with the key, > then these are treated as separate security associations. It greatly > simplifies the protocol state machine. I suggest that you follow a similar > track. > Thanks. I agree. Well said. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Fri Oct 20 22:34:24 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10838 (5.65c/IDA-1.4.4 for ); Fri, 20 Oct 1995 17:39:44 -0400 Received: by interlock.ans.net id AA03728 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 20 Oct 1995 17:35:00 -0400 Message-Id: <199510202135.AA03728@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 20 Oct 1995 17:35:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 20 Oct 1995 17:35:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 20 Oct 1995 17:35:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 20 Oct 1995 17:35:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 20 Oct 1995 17:35:00 -0400 From: perk@watson.ibm.com (Charlie Perkins) To: Robert Glenn Cc: karl@MorningStar.Com, ipsec@ans.net Subject: IP4-within-IP4 encapsulation In-Reply-To: (Your message of Thu, 19 Oct 95 08:33:26 EDT.) <199510191233.AA22239@interlock.ans.net> Date: Fri, 20 Oct 95 17:34:24 -0500 Much of Bill Simpson's work in RFC 1853 is also represented in an Internet Draft under development within the mobile-IP working group. If you are interested in looking over the draft, I would be happy to get comments about it. The effort of the mobile-IP working group is intended to be suitable for use with mobile-IP, but also keeping in mind the larger picture of general IP-within-IP encapsulation. The mobile-IP encapsulation draft is: draft-ietf-ip4inip4-01.txt and may be found at your favorite source for Internet Drafts. Comments may be submitted to mobile-ip@smallworks.com, or perhaps still mobile-ip@tadpole.com. The list is being moved tonight, so I'm not sure. Regards, Charles Perkins From ipsec-request@ans.net Fri Oct 20 18:02:01 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18811 (5.65c/IDA-1.4.4 for ); Fri, 20 Oct 1995 18:02:01 -0400 Received: by interlock.ans.net id AA04397 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 20 Oct 1995 17:57:37 -0400 Message-Id: <199510202157.AA04397@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 20 Oct 1995 17:57:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 20 Oct 1995 17:57:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 20 Oct 1995 17:57:37 -0400 Date: Fri, 20 Oct 95 14:31:14 From: "Housley, Russ" Encoding: 567 Text To: Germano Caronni Cc: ipsec@ans.net Subject: Re: Preliminary comment skip draft 03 Germano Caronni provided this diagram: encrypted part +---------------+-----------------------+====+========================+ |32-bit SKIP SPI|64-bit MI network order|data|8bit next protocol field| +---------------+-----------------------+====+========================+ where MI is the number of bytes that were already encrypted with the current Kp. Why do you want to limit the MI (a.k.a. IV) to the counter? A random number works fine too. Russ From ipsec-request@ans.net Fri Oct 20 22:06:38 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16820 (5.65c/IDA-1.4.4 for ); Fri, 20 Oct 1995 18:10:29 -0400 Received: by interlock.ans.net id AA04700 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 20 Oct 1995 18:08:20 -0400 Message-Id: <199510202208.AA04700@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 20 Oct 1995 18:08:20 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 20 Oct 1995 18:08:20 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 20 Oct 1995 18:08:20 -0400 X-Mailer: exmh version 1.6.2 7/18/95 To: "William Allen Simpson" Cc: ipsec@ans.net Subject: Re: Photuris // entities In-Reply-To: bsimpson's message of Fri, 20 Oct 1995 17:46:56 +0000. <199510201823.AA27053@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 20 Oct 1995 18:06:38 -0400 From: Bill Sommerfeld -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii So does Photuris. There is no restriction of the number of Photuris exchanges that can be active at the same time. Indeed [p 5]: When both parties initiate Photuris exchanges concurrently, or one party initiates more than one Photuris exchange, the Initiator Cookies (and UDP Ports) keep the exchanges separate. This results in more than one initial SPI for each Destination. But there is still no way for the Initiator to choose which principal on the Responder it wishes to communicate with. > So, the only possible "unauthorized" party would be the Initiator. > > I don't think that's a reasonable assumption. > > 1) Consider user-oriented network services like X and Zephyr, where > the "server"/"responder" is close to the user, and the "client"/"initiator " > is off on a server machine. It's not common, but one can have multiple > heads, and multiple X servers, on a single multi-user machine. > So? What stops them from each starting a Photuris exchange? That's not the issue, the issue is how an *initiator* can select which of several possible server identities it intends to send encrypted data to. You don't want to send something down an encrypted link unless you know who on the other end has the key! Certainly. But as is carefully defined, the encryption policy is in the sender direction, and the authentication policy is in the receiver direction. A sender which desires to send encrypted data will initiate a Photuris exchange. No problem there, unless it doesn't trust the kernel of the other node to deliver the encrypted data only to the intended "user", as indicated by the TCP/UDP port protected in the data. But in that case, you'd be insecure no matter what you did. Ok, so if I'm reading you correctly, you're implying that all encryption SPI's are set up in a "user->system" mode. There's a fundamental weakness in this, at least for UDP. [The vulnerability probably also exists for TCP, but may be harder to exploit.] Again, if I'm reading you correctly, if user A at host X wishes to have a two-way encrypted channel with user B at host Y, then you're suggesting that there will be two photuris exchanges (ouch -- that's 8 DH modular exponentiations before anyone gets to talk..), and the SPI's actually used will be A->Y B->X Now, if there's a second malicious user C at host Y, what's to stop C from noticing when B releases his UDP port, grabbing the port, replaying A's traffic, and thus receiving the encrypted data? Or do we have to mandate that transports not reuse ports within the longest SPI lifetime they allow? If, on the other hand, the SPI's were set up: A->B B->A then, on receipt of the A->B packet, Y would notice that B no longer owned the destination port, and drop the packet. Also, the cost of the setup is cut in half -- only 4 modular exp's instead of 8.. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBMIgda1pj/0M1dMJ/AQFQIwP9E62IHzjTDXP8Vk5+etkeO05yE1yDwJuV SazjdPzYWaKSfen727O351zwiGyIX9WxtAGgHoQF3Pt+M3242CXk0d8gueRwzkfj 9re7pcx/561+WGdhEgLwYxeLLKvW21YGMnLY1nBrksuxLOII05l++U2alosAd4oB R0FNvkLVhoI= =1Q/u -----END PGP SIGNATURE----- From ipsec-request@ans.net Fri Oct 20 16:44:32 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18925 (5.65c/IDA-1.4.4 for ); Fri, 20 Oct 1995 20:48:49 -0400 Received: by interlock.ans.net id AA08301 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 20 Oct 1995 20:45:13 -0400 Message-Id: <199510210045.AA08301@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 20 Oct 1995 20:45:13 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 20 Oct 1995 20:45:13 -0400 To: perry@piermont.com Cc: "William Allen Simpson" , ipsec@ans.net Subject: Re: Nodes and Users Date: Fri, 20 Oct 95 20:44:32 EDT "William Allen Simpson" writes: > > From: rivest@theory.lcs.mit.edu (Ron Rivest) > > IPSEC needs to provide EXPLICT answers to these questions. The Ph oturis > > spec needs to be based on these answers. This cannot be swept und er the > > rug any longer. > > > No rug sweeping has been attempted, we have discussed this at length in > the Security Architecture. Bill has expressed to me in private mail that he thinks that the question of certificates, certificate formats and naming can wait, but frankly I don't think it can because we don't have a usable system without it. I agree very strongly with Perry about this. I tried raising the issue a few months ago; it met with a resounding silence. We need to settle this immediately, if not sooner. It is, as far as I'm concerned, an absolute show-stopper -- without some resolution, I would vote against -- well, not precisely vote in the IETF, but you know what I mean -- Photuris, on those grounds alone. From ipsec-request@ans.net Sat Oct 21 00:56:04 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14596 (5.65c/IDA-1.4.4 for ); Fri, 20 Oct 1995 21:00:20 -0400 Received: by interlock.ans.net id AA08458 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 20 Oct 1995 20:57:52 -0400 Message-Id: <199510210057.AA08458@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 20 Oct 1995 20:57:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 20 Oct 1995 20:57:52 -0400 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Bill Sommerfeld Cc: "William Allen Simpson" , ipsec@ans.net Subject: Re: Photuris // entities In-Reply-To: Your message of "Fri, 20 Oct 1995 18:06:38 EDT." <199510202208.AA04700@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 Oct 1995 20:56:04 -0400 From: "Perry E. Metzger" Bill Sommerfeld writes: > But there is still no way for the Initiator to choose which principal > on the Responder it wishes to communicate with. This is true. I'm rather disturbed by it, and by the fact that we haven't even begun to address naming, which we need to set up in order to choose counterparties. Perry From ipsec-request@ans.net Sat Oct 21 13:05:38 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04126 (5.65c/IDA-1.4.4 for ); Sat, 21 Oct 1995 09:10:41 -0400 Received: by interlock.ans.net id AA15576 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 21 Oct 1995 09:05:45 -0400 Message-Id: <199510211305.AA15576@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sat, 21 Oct 1995 09:05:45 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 21 Oct 1995 09:05:45 -0400 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 21 Oct 1995 09:05:45 -0400 Subject: Re: Preliminary comment skip draft 03 To: housley@spyrus.com (Housley Russ) Date: Sat, 21 Oct 1995 14:05:38 +0100 (MET) Cc: ipsec@ans.net In-Reply-To: <199510202157.AA04397@interlock.ans.net> from "Housley, Russ" at Oct 20, 95 02:31:14 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 1309 Housley, Russ wrote: > Germano Caronni provided this diagram: > encrypted part > +---------------+-----------------------+====+========================+ > |32-bit SKIP SPI|64-bit MI network order|data|8bit next protocol field| > +---------------+-----------------------+====+========================+ > where MI is the number of bytes that were already encrypted with the > current Kp. > Why do you want to limit the MI (a.k.a. IV) to the counter? A random > number works fine too. Because I am talking about RC4, a stream cipher. Stream ciphers have the property that encryption of a (bit|byte|...) is position dependant, but usually does not depend on the data encrypted before. To use a stream cipher in IP, where packets may be reordered by the network, you have to know at which 'offset' of the stream this particular block has been encrypted. Then you can 'seek' (and cache states) in the stream upon receipt of the packet, and thus decrypt it. Additional care has to be taken about denial-of-service attacks asking you to seeek to say 2^63 in the stream, and about the need for resynchronisation, which could be done when scheduled keychanges occur. Do you agree? Friendly greetings, Germano From ipsec-request@ans.net Sun Oct 22 15:15:51 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04334 (5.65c/IDA-1.4.4 for ); Sun, 22 Oct 1995 11:51:52 -0400 Received: by interlock.ans.net id AA28011 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 22 Oct 1995 11:44:32 -0400 Message-Id: <199510221544.AA28011@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 22 Oct 1995 11:44:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 22 Oct 1995 11:44:32 -0400 Date: Sun, 22 Oct 95 15:15:51 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Nodes and Users > From: smb@research.att.com > Bill has expressed to me in private mail that he thinks that the > question of certificates, certificate formats and naming can wait, but > frankly I don't think it can because we don't have a usable system > without it. > > I agree very strongly with Perry about this. I tried raising the > issue a few months ago; it met with a resounding silence. We need > to settle this immediately, if not sooner. It is, as far as I'm > concerned, an absolute show-stopper -- without some resolution, I > would vote against -- well, not precisely vote in the IETF, but you > know what I mean -- Photuris, on those grounds alone. > I have responded to this thread several times. (The title is mine) Very good, then I am sure that the Chairs will count this as opposing Photuris submission as a Proposed Standard. If there is insufficient support, I will submit it as Experimental instead. Thank you. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sun Oct 22 14:28:49 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15600 (5.65c/IDA-1.4.4 for ); Sun, 22 Oct 1995 11:51:52 -0400 Received: by interlock.ans.net id AA28005 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 22 Oct 1995 11:44:28 -0400 Message-Id: <199510221544.AA28005@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 22 Oct 1995 11:44:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 22 Oct 1995 11:44:28 -0400 Date: Sun, 22 Oct 95 14:28:49 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris // entities > From: Bill Sommerfeld > That's not the issue, the issue is how an *initiator* can select which > of several possible server identities it intends to send encrypted > data to. You don't want to send something down an encrypted link > unless you know who on the other end has the key! > First of all, as I've pointed many times before, this nothing to so with the most common use of Photuris. This is _only_ for MLS workstations. Second, as already stated, it is the responsibility of the sender (whether that sender was the Initiator or Responder), to select among the identities with which it _has_ an association. These implementation details are certainly outside the scope of Photuris. We are _not_ specifying APIs here. Third, by the time the Initiator sends any data, it does in fact _know_ whom it is sending the data. The signing/verification has been completed. > But as is carefully defined, the encryption policy is in the sender > direction, and the authentication policy is in the receiver direction. > > A sender which desires to send encrypted data will initiate a Photuris > exchange. No problem there, unless it doesn't trust the kernel of the > other node to deliver the encrypted data only to the intended "user", as > indicated by the TCP/UDP port protected in the data. But in that case, > you'd be insecure no matter what you did. > > Ok, so if I'm reading you correctly, you're implying that all > encryption SPI's are set up in a "user->system" mode. There's a > fundamental weakness in this, at least for UDP. [The vulnerability > probably also exists for TCP, but may be harder to exploit.] > There is no weakness, unless the receiving system implementation is weak. > Again, if I'm reading you correctly, if user A at host X wishes to > have a two-way encrypted channel with user B at host Y, User A has _NO_ say as to whether a "channel" is encrypted "two-way". Encryption policy is in the sender direction only. This is a design principle of Photuris. > then you're > suggesting that there will be two photuris exchanges (ouch -- that's 8 > DH modular exponentiations before anyone gets to talk..), For this extremely rare and ungainly association, it takes two exchanges. But of course, as is repeated at least twice in the specification, when multiple exchanges occur and the exchange-values are the same, the shared-secret is the same. No additional calculation is needed. > Now, if there's a second malicious user C at host Y, what's to stop C > from noticing when B releases his UDP port, grabbing the port, > replaying A's traffic, and thus receiving the encrypted data? > Your scenario is also applicable to manual keying. If your implementation is that poorly done, I don't consider that a "secure" workstation. As our IP Security Architecture clearly states: Users need to understand that the quality of the security provided by the mechanisms provided by these two IP security mechanisms depends completely on ... the correct implementation of IP and the several security mechanisms in all of the participating systems. The security of the implementation is in part related to the security of the operating system which embodies the security implementations. > Or do we have to mandate that transports not reuse ports within the > longest SPI lifetime they allow? > Whatever it takes for your implementation to not have a failure mode. This is outside the scope of Photuris. IP Security is _not_ a transport layer security mechanism. There are no "ports". If you think this is terribly important, even as an implementation note, then you need to get it included in the next revision of the IP Security Architecture. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sun Oct 22 15:41:24 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA16704 (5.65c/IDA-1.4.4 for ); Sun, 22 Oct 1995 12:15:55 -0400 Received: by interlock.ans.net id AA28210 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 22 Oct 1995 12:08:08 -0400 Message-Id: <199510221608.AA28210@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 22 Oct 1995 12:08:08 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 22 Oct 1995 12:08:08 -0400 Date: Sun, 22 Oct 95 15:41:24 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Photuris Appendices Having completed WG review of Chapters 5 to 7 over the past week and a half, it is time to cover Appendices A and B, the Security Considerations, et alia. I will be considering suggestions for text on those topics this week. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Sun Oct 22 19:45:59 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18778 (5.65c/IDA-1.4.4 for ); Sun, 22 Oct 1995 14:51:13 -0400 Received: by interlock.ans.net id AA29402 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 22 Oct 1995 14:46:37 -0400 Message-Id: <199510221846.AA29402@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Sun, 22 Oct 1995 14:46:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Sun, 22 Oct 1995 14:46:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sun, 22 Oct 1995 14:46:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 22 Oct 1995 14:46:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 22 Oct 1995 14:46:37 -0400 From: perk@watson.ibm.com (Charlie Perkins) To: ipsec@ans.net Subject: IP4-within-IP4 encapsulation (draft-ietf-ip4inip4-01.txt) Date: Sun, 22 Oct 95 14:45:59 -0500 The mobile-IP version has been submitted as an Internet Draft, but takes a day or two to become available. In the meantime, you can find it on software.watson.ibm.com, if you're interested. When I posted my first note, I thought the draft was already out there, but it wasn't. Sorry for any confusion. Charlie P. From ipsec-request@ans.net Sun Oct 22 19:22:50 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04283 (5.65c/IDA-1.4.4 for ); Sun, 22 Oct 1995 15:28:32 -0400 Received: by interlock.ans.net id AA29677 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 22 Oct 1995 15:23:19 -0400 Message-Id: <199510221923.AA29677@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 22 Oct 1995 15:23:19 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 22 Oct 1995 15:23:19 -0400 X-Sender: jis@e40-po.mit.edu (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 22 Oct 1995 15:22:50 -0400 To: "William Allen Simpson" From: jis@mit.edu (Jeffrey I. Schiller) Subject: Re: Nodes and Users Cc: ipsec@ans.net -----BEGIN PGP SIGNED MESSAGE----- At 11:15 10/22/95, William Allen Simpson wrote: >> From: smb@research.att.com >> Bill has expressed to me in private mail that he thinks that the >> question of certificates, certificate formats and naming can wait, but >> frankly I don't think it can because we don't have a usable system >> without it. >> >> I agree very strongly with Perry about this. I tried raising the >> issue a few months ago; it met with a resounding silence. We need >> to settle this immediately, if not sooner. It is, as far as I'm >> concerned, an absolute show-stopper -- without some resolution, I >> would vote against -- well, not precisely vote in the IETF, but you >> know what I mean -- Photuris, on those grounds alone. >> >I have responded to this thread several times. (The title is mine) > >Very good, then I am sure that the Chairs will count this as opposing >Photuris submission as a Proposed Standard. If there is insufficient >support, I will submit it as Experimental instead. Thank you. Oh come on! We were able to move forward with ESP and AH without having a firm automated key management infrastructure installed. We can move forward with Photuris just as well. If we wait until we have a fully fleshed out architecture with complete consensus of the whole IETF before move forward, we will never get anywhere (this has been the yoke of the Security Area for years). I believe that all Photuris needs to specify is the format of the public keys it expects to have available. These keys can always be manually configured if necessary. Personally I favor an approach based on using PGP keys, but that is my personal preference based on the wide deployment of PGP in the community (ok, so I am probably biased a little as well...). However the point is that Photuris doesn't have to specify exactly where these keys come from. Now I'll admit here that I am not completely up to date on the latest Photuris drafts (though I certainly will be by Dallas!), however the requirement of user to user keying probably implies that when an initiator wishes to establish an association with some party at a destination, there needs to be a way to communicate this information to the destination host. The following "mappings" have to happen: Entity "A" wishes to communicate with entity "B". 1) A has to map "B" into "B@somehost.somedomain" (ie. this is the service location problem). 2) A's host has to initiate an association with somehost.somedomain and specify that the permanent key to use is associated with "B". 3) A's host uses A's keying material and somehost.somedomain uses B's keying material and the Photuris protocol can commence, generating SPID's and session keys and attributes as appropriate. 4) A at "host" communicates with "B" at somehost.somedomain in an authenticated and/or confidential fashion. Problem [1] is the service location problem and is well beyond the scope of Photuris. Problem [4] is what is addressed by AH and ESP. Problem [2,3] is what Photuris should do. However Photuris doesn't have to specify where the keys for A and B come from. Ultimately we have to solve this problem, but Photuris isn't the place to solve it. The contenders (from my point of view) are: o Secure DNS [This is moving along] o PGP [Available today but not "standardized" (though that is being worked on). Appropriateness of Web of Trust is debatable] o X.509/X.500 [Some will argue that this is *the* way to do all of this. Problem is that it doesn't mix well with DNS names and has had years to come into existence, but hasn't] Finally there is the whole issue of the availability of the various public key crypto systems. As I am sure you are all aware, this whole situation is in a state of flux here in the U.S. and I hope it will stabilize shortly. -Jeff -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMIqXA8UtR20Nv5BtAQHF8QP/dLsT8UtMxfoFOLYYFAGRY7qyh6ybAKXh 4UPfht4XRN9rOxlgRstgpU1d78s9vO4tQhWk7X0ktcgKNnymMpE2uyI52W1uuo2X PggIi94bLK95RKGGXuStipNp8jswUQmYbtMII04gcm4wEJ+DttPj1c9N6kvOE1Q4 5aDjcdytjb8= =kZ9K -----END PGP SIGNATURE----- From ipsec-request@ans.net Mon Oct 23 11:52:38 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13657 (5.65c/IDA-1.4.4 for ); Mon, 23 Oct 1995 08:17:27 -0400 Received: by interlock.ans.net id AA10316 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 23 Oct 1995 08:13:21 -0400 Message-Id: <199510231213.AA10316@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 23 Oct 1995 08:13:21 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 23 Oct 1995 08:13:21 -0400 Date: Mon, 23 Oct 95 11:52:38 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: photuris-06 The latest Photuris draft may be found at ftp.morningstar.com: pub/I-Net/photuris-06 Since the number of changes is small, this has change bars to help you find them. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Mon Oct 23 15:10:30 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13748 (5.65c/IDA-1.4.4 for ); Mon, 23 Oct 1995 11:20:54 -0400 Received: by interlock.ans.net id AA14375 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 23 Oct 1995 11:12:15 -0400 Message-Id: <199510231512.AA14375@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 23 Oct 1995 11:12:15 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 23 Oct 1995 11:12:15 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 23 Oct 1995 11:12:15 -0400 X-Mailer: exmh version 1.6.2 7/18/95 To: "William Allen Simpson" Cc: ipsec@ans.net Subject: Re: Photuris // entities In-Reply-To: bsimpson's message of Sun, 22 Oct 1995 14:28:49 +0000. <199510221544.AA28005@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 23 Oct 1995 11:10:30 -0400 From: Bill Sommerfeld -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii > From: Bill Sommerfeld > That's not the issue, the issue is how an *initiator* can select which > of several possible server identities it intends to send encrypted > data to. You don't want to send something down an encrypted link > unless you know who on the other end has the key! > First of all, as I've pointed many times before, this nothing to so with the most common use of Photuris. This is _only_ for MLS workstations. Could we have a "terminology check" here? By "MLS", do you mean "Multi Level Secure" (aka military/orange book/nondiscretionary access control), or something else? Thanks in advance for the clarification. - Bill [I see systems with multiple initiator and responder identities as "multi user" systems, not "multi level" systems. While MLS systems are fairly rare outside government, multi-user systems (especially in "server" roles) are quite common. Am I completely off-base here?] -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBMIuwY1pj/0M1dMJ/AQE9tgP9Gvja7QyYnWngp0rho48VNz7LSgbBZN9M yngY7p6rPV0pfbdYczagmaVq0AMKHf5+9j2mXrZ+WTzeRG67s4MK45L1pr8RGckh KDRVfjMuU3BFZ4Rl+CcUbXj6dYQCZzbTuGqiJva3Oc3yJapcYogJpFIe0DSSAM2A 9LRlPJsN/Pg= =dj8A -----END PGP SIGNATURE----- From ipsec-request@ans.net Mon Oct 23 13:00:51 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10880 (5.65c/IDA-1.4.4 for ); Mon, 23 Oct 1995 13:00:51 -0400 Received: by interlock.ans.net id AA17828 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 23 Oct 1995 12:54:53 -0400 Message-Id: <199510231654.AA17828@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 23 Oct 1995 12:54:53 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 23 Oct 1995 12:54:53 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 23 Oct 1995 12:54:53 -0400 Date: Mon, 23 Oct 95 09:25:59 From: "Housley, Russ" Encoding: 819 Text Cc: ipsec@ans.net Subject: Re: Nodes and Users We need to specify this ASAP. Further, the PKIX group will meet for the first time at the Dallas IETF, and we need to make sure that the IPSEC requirements are met by the infrastructure that is developed in that group. Russ ______________________________ Reply Separator _________________________________ Subject: Re: Nodes and Users Author: smb@research.att.com at internet Date: 10/20/95 8:44 PM I agree very strongly with Perry about this. I tried raising the issue a few months ago; it met with a resounding silence. We need to settle this immediately, if not sooner. It is, as far as I'm concerned, an absolute show-stopper -- without some resolution, I would vote against -- well, not precisely vote in the IETF, but you know what I mean -- Photuris, on those grounds alone. From ipsec-request@ans.net Mon Oct 23 18:41:56 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04194 (5.65c/IDA-1.4.4 for ); Mon, 23 Oct 1995 14:58:04 -0400 Received: by interlock.ans.net id AA20885 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 23 Oct 1995 14:51:16 -0400 Message-Id: <199510231851.AA20885@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 23 Oct 1995 14:51:16 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 23 Oct 1995 14:51:16 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 23 Oct 1995 14:51:16 -0400 From: alten@na.SJF.Novell.COM (Alex Alten) Subject: Re: Nodes and Users To: smb@research.att.com Date: Mon, 23 Oct 1995 11:41:56 -0700 (PDT) Cc: perry@piermont.com, bsimpson@morningstar.com, ipsec@ans.net In-Reply-To: <199510210045.AA08301@interlock.ans.net> from "smb@research.att.com" at Oct 20, 95 08:44:32 pm X-Mailer: ELM [version 2.4 PL22] Original-Content-Type: text Content-Type: text/plain Content-Length: 2180 > > > "William Allen Simpson" writes: >>> From: rivest@theory.lcs.mit.edu (Ron Rivest) >>> IPSEC needs to provide EXPLICT answers to these questions. The Photuris >>> spec needs to be based on these answers. This cannot be swept under the >>> rug any longer. >>> >> No rug sweeping has been attempted, we have discussed this at length in >> the Security Architecture. > > Bill has expressed to me in private mail that he thinks that the > question of certificates, certificate formats and naming can wait, but > frankly I don't think it can because we don't have a usable system > without it. > > I agree very strongly with Perry about this. I tried raising the > issue a few months ago; it met with a resounding silence. We need > to settle this immediately, if not sooner. It is, as far as I'm > concerned, an absolute show-stopper -- without some resolution, I > would vote against -- well, not precisely vote in the IETF, but you > know what I mean -- Photuris, on those grounds alone. > > I'm noticing that each proposed secure protocol is reinventing the wheel regarding algorithms for public keys and formats for signatures. While I feel that certification is important, I'm uncertain as to how we wish to approach it. Certainly the PEM approach which specifies a standard certification hierarchy, etc., has not been successful. Meanwhile PGP certification has been more successful, albeit it is still a small fraction of the e-mail usage. I suspect that we will need a certification solution which allows both PGP style certification and a more hierachical form. Given all this what I'd like to see first is an RFC specifying a public key algorithm (PKCS#1 or PGP style internal formats using RSA or ElGamal, etc.) and signature formats (net order, ASN.1 and MIME formats). This allows this technology to be uniformly applied among all the other proposals. Future key distribution and certification RFC proposals will then have a good foundation to build on. - Alex -- Alexander I. Alten Alten@Na.Sjf.Novell.Com (408) 577-8224 Novell, Inc. Member of Technical Staff Mail Stop F1-42-D2 2180 Fortune Drive San Jose, CA 95131 USA From ipsec-request@ans.net Mon Oct 23 18:58:04 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11698 (5.65c/IDA-1.4.4 for ); Mon, 23 Oct 1995 15:28:30 -0400 Received: by interlock.ans.net id AA22027 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 23 Oct 1995 15:22:38 -0400 Message-Id: <199510231922.AA22027@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 23 Oct 1995 15:22:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 23 Oct 1995 15:22:38 -0400 Date: Mon, 23 Oct 95 18:58:04 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Photuris // entities > From: Bill Sommerfeld > Could we have a "terminology check" here? > > By "MLS", do you mean "Multi Level Secure" (aka military/orange > book/nondiscretionary access control), or something else? > The former. > [I see systems with multiple initiator and responder identities as > "multi user" systems, not "multi level" systems. While MLS systems are fairly > rare outside government, multi-user systems (especially in "server" roles) are > quite common. Am I completely off-base here?] > A lot of such systems exist. They aren't secure systems. Therefore, they do not fall within our scope. If the "multi-user" node isn't secure, why do you think Photuris will make it more secure? Why would you expect Photuris to do something that you cannot hand configure, a facility which is already required? Finally, specifying that any multi-user system must meet MLS requirements obviates all the "what if another process takes over the UDP port" queries.... Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Mon Oct 23 11:47:10 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14969 (5.65c/IDA-1.4.4 for ); Mon, 23 Oct 1995 16:47:44 -0400 Received: by interlock.ans.net id AA24113 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 23 Oct 1995 16:39:21 -0400 Message-Id: <199510232039.AA24113@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 23 Oct 1995 16:39:21 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 23 Oct 1995 16:39:21 -0400 To: alten@na.SJF.Novell.COM (Alex Alten) Cc: perry@piermont.com, bsimpson@morningstar.com, ipsec@ans.net Subject: Re: Nodes and Users Date: Mon, 23 Oct 95 15:47:10 EDT > I'm noticing that each proposed secure protocol is reinventing the wheel > regarding algorithms for public keys and formats for signatures. While > I feel that certification is important, I'm uncertain as to how we wish > to approach it. Certainly the PEM approach which specifies a standard > certification hierarchy, etc., has not been successful. Meanwhile PGP > certification has been more successful, albeit it is still a small fraction > of the e-mail usage. I suspect that we will need a certification solution > which allows both PGP style certification and a more hierachical form. > > Given all this what I'd like to see first is an RFC specifying a public key > algorithm (PKCS#1 or PGP style internal formats using RSA or ElGamal, etc.) > and signature formats (net order, ASN.1 and MIME formats). This allows this > technology to be uniformly applied among all the other proposals. Future > key distribution and certification RFC proposals will then have a good > foundation to build on. The syntax and certificate issues are important, but they're not what I'm talking about. Here's the relevant passage from section B.1 of Draft 5: Identity-Choice When selected as an Identity-Choice, the resulting Verification field is 128-bits (18 octets including Size). The Identification field contains a variable precision number that identifies the party. Typically, the Identification is a Domain Name or a user email address which contains a Domain Name. In other words, we haven't agreed on what the endpoints are. This is a serious matter. The reason this is so crucial is implied by the following excerpt from Section 5.3: Each party implements local policy that determines what access, if any, is granted to the holder of a particular identity. In other words, an IPSP end-system has to make authorization decisions based on some string whose syntax and semantics are both unspecified. Let's look at possible ways that IPSEC can be used. One is gateway-to- gateway encryption, to support private virtual networks. In that case, the (decrypted) IP address of the sender may be important for authorization. But there is no specified format for ``list of IP addresses''. The closest we come is a domain name, but that can only be used indirectly, and then if and only if we're using DNSSEC. The Photuris draft says nothing about DNSSEC, and the one reference to it in RFC 1825 refers to it for host name keying. We can also use IPSEC, and hence Photuris, for host-to-host encryption. Again, the receiving system needs to know the IP address of its peer, not just the domain name. For that matter, when the sender tries to to do automated Photuris negotiation, it also wants a key tied to IP address. But the user wants a key tied to the DNS name, since that's the entity a user is dealing with. Finally, IPSEC can be used for user-to-user encryption. This format is properly supported by the Photuris mechanisms, but only because the string user@domain can be treated as an opaque quantity. The first two cases largely nullify the whole authentication mechanism of Photuris, since in the final analysis -- that is, at the point where one actually wants to make a decision based on identity -- there is no real assurance of the identity of the other party. We may as well fall back to straight Diffie-Hellman, since if we don't know to whom we're talking, authentication matters little. I don't have any pat answers for this. I suggest, though, that the identity string be a 3-tuple of 0 or more usernames, 0 or more domain names, and 0 or more IP address ranges. I'll leave the syntax and certificate format issues to someone else... (I'll also note that even this scheme doesn't work very well for IPv6, where the high-order address bits aren't indicative of identity.) From ipsec-request@ans.net Mon Oct 23 16:48:50 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10878 (5.65c/IDA-1.4.4 for ); Mon, 23 Oct 1995 16:48:50 -0400 Received: by interlock.ans.net id AA24441 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 23 Oct 1995 16:46:48 -0400 Message-Id: <199510232046.AA24441@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 23 Oct 1995 16:46:48 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 23 Oct 1995 16:46:48 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 23 Oct 1995 16:46:48 -0400 Date: Mon, 23 Oct 95 12:53:51 From: "Housley, Russ" Encoding: 1730 Text To: Germano Caronni Cc: ipsec@ans.net Subject: Re: Preliminary comment skip draft 03 Okay. It was not clear to me that you were using RC4. Of course, position in the stream must be communicated to deal with out of order delivery. Russ ______________________________ Reply Separator _________________________________ Subject: Re: Preliminary comment skip draft 03 Author: Germano Caronni at internet Date: 10/21/95 6:19 AM Housley, Russ wrote: > Germano Caronni provided this diagram: > encrypted part > +---------------+-----------------------+====+========================+ > |32-bit SKIP SPI|64-bit MI network order|data|8bit next protocol field| > +---------------+-----------------------+====+========================+ > where MI is the number of bytes that were already encrypted with the > current Kp. > Why do you want to limit the MI (a.k.a. IV) to the counter? A random > number works fine too. Because I am talking about RC4, a stream cipher. Stream ciphers have the property that encryption of a (bit|byte|...) is position dependant, but usually does not depend on the data encrypted before. To use a stream cipher in IP, where packets may be reordered by the network, you have to know at which 'offset' of the stream this particular block has been encrypted. Then you can 'seek' (and cache states) in the stream upon receipt of the packet, and thus decrypt it. Additional care has to be taken about denial-of-service attacks asking you to seeek to say 2^63 in the stream, and about the need for resynchronisation, which could be done when scheduled keychanges occur. Do you agree? Friendly greetings, Germano From ipsec-request@ans.net Tue Oct 24 12:53:16 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15519 (5.65c/IDA-1.4.4 for ); Tue, 24 Oct 1995 09:24:56 -0400 Received: by interlock.ans.net id AA08418 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 24 Oct 1995 09:17:26 -0400 Message-Id: <199510241317.AA08418@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 24 Oct 1995 09:17:26 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 24 Oct 1995 09:17:26 -0400 Date: Tue, 24 Oct 95 12:53:16 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Nodes and Users > From: smb@research.att.com > The syntax and certificate issues are important, but they're not what > I'm talking about. Here's the relevant passage from section B.1 of > Draft 5: > ... > Each party implements local policy that determines what access, if > any, is granted to the holder of a particular identity. > > In other words, an IPSP end-system has to make authorization decisions > based on some string whose syntax and semantics are both unspecified. > Absolutely. This is particularly easy, since these particular authorized Nodes and Users are preconfigured. > Let's look at possible ways that IPSEC can be used. One is gateway-to- > gateway encryption, to support private virtual networks. In that case, > the (decrypted) IP address of the sender may be important for authorization. > It is a design principle of Photuris that IP addresses are _NOT_ used for authorization. See page 1. > We can also use IPSEC, and hence Photuris, for host-to-host encryption. > Again, the receiving system needs to know the IP address of its peer, > not just the domain name. For that matter, when the sender tries to > to do automated Photuris negotiation, it also wants a key tied to IP > address. But the user wants a key tied to the DNS name, since that's > the entity a user is dealing with. > It is a design feature of Photuris that IP addresses are _NOT_ tied to a particular user identity. See page 7. > Finally, IPSEC can be used for user-to-user encryption. This format > is properly supported by the Photuris mechanisms, but only because > the string user@domain can be treated as an opaque quantity. Correct. Indeed, the identity need not even be a string. It could be any number, such as 1234 with 12 significant bits! As you say, it is an opaque quantity. > there is no > real assurance of the identity of the other party. We may as well > fall back to straight Diffie-Hellman, since if we don't know to whom > we're talking, authentication matters little. > I surely don't understand this point. The text is quite explicit: Valid Identifications and secret-keys are preconfigured by the parties. [page 47 in draft -05, page 49 in draft -06] Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Tue Oct 24 13:37:47 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12759 (5.65c/IDA-1.4.4 for ); Tue, 24 Oct 1995 10:04:19 -0400 Received: by interlock.ans.net id AA09529 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 24 Oct 1995 09:55:17 -0400 Message-Id: <199510241355.AA09529@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 24 Oct 1995 09:55:17 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 24 Oct 1995 09:55:17 -0400 Date: Tue, 24 Oct 95 13:37:47 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: scenarios Steve's 3 examples reminds me that I promised Scott Bradner that I would write up some example scenarios. I will try to come up with something in the next day or so. Maybe then folks will see how the pieces fit together.... (Surely, it's already obvious ;-) > From: smb@research.att.com > Let's look at possible ways that IPSEC can be used. One is gateway-to- > gateway encryption, to support private virtual networks. ... > host-to-host encryption. ... user-to-user encryption. My mental models are node-node, user-node, and user-user. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Tue Oct 24 13:24:59 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10809 (5.65c/IDA-1.4.4 for ); Tue, 24 Oct 1995 10:38:45 -0400 Received: by interlock.ans.net id AA10338 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 24 Oct 1995 10:28:37 -0400 Message-Id: <199510241428.AA10338@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 24 Oct 1995 10:28:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 24 Oct 1995 10:28:37 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-photuris-06.txt Date: Tue, 24 Oct 95 09:24:59 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Photuris Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-photuris-06.txt Pages : 56 Date : 10/23/1995 Photuris is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-photuris-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-06.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-photuris-06.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951023104516.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-photuris-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-photuris-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951023104516.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Oct 24 17:07:09 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12679 (5.65c/IDA-1.4.4 for ); Tue, 24 Oct 1995 13:21:48 -0400 Received: by interlock.ans.net id AA14182 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 24 Oct 1995 13:08:41 -0400 Message-Id: <199510241708.AA14182@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 24 Oct 1995 13:08:41 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 24 Oct 1995 13:08:41 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 24 Oct 1995 13:08:41 -0400 X-Mailer: exmh version 1.6.2 7/18/95 To: smb@research.att.com Cc: alten@na.SJF.Novell.COM (Alex Alten), perry@piermont.com, bsimpson@morningstar.com, ipsec@ans.net Subject: Re: Nodes and Users In-Reply-To: smb's message of Mon, 23 Oct 1995 15:47:10 -0400. <199510232039.AA24113@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 24 Oct 1995 13:07:09 -0400 From: Bill Sommerfeld -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii I don't have any pat answers for this. I suggest, though, that the identity string be a 3-tuple of 0 or more usernames, 0 or more domain names, and 0 or more IP address ranges. I'll leave the syntax and certificate format issues to someone else... I would suggest adding protocols/ports to this mix, at least so that initiators can suggest which principal on the responder they want to talk to. The experience we've had building distributed systems in DCE indicates that for some applications, particularly where you've got redundant replicated services, you're better off with an approach which can be summarized as "find out who you're talking to, then see if they're on the right ACL" rather than having to know in advance the full name of the entity you want to communicate with. As a hypothetical (and probably bad) example, if the Responder supports multiple entities, it may be more convenient to express things as "set up an association with whoever's in control of TCP port 25"., then verify that the certificate you get back has the right "magic" SMTP-server attribute. If the responder is a single-user system, it could respond with an indication to that effect and forestall future attempts from its peer to establish redundant security associations. I'd also like to suggest that an attribute-value form of identity (note that this does *NOT* imply X.500 syntax) might be more extensible and less clumsy than a 3-tuple or 4-tuple of possibly empty sets of values - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCUAwUBMI0dOVpj/0M1dMJ/AQFXJAP3ejTR0VMKT81UHw3P/1VWVorB1WFp0eXU QRYy4NgeoWUZ2LEYnw0hfWUKgOYxufau2qDHbGC4EuFuAl4Ngd7lZdCDO8dCFEVD Jr23jULhl3/I8HI908eKOQ6uNbzNKvzH+09J2ESb5drE+YmdLK8szZlpelri93RB UNP3r4G/jw== =QOoK -----END PGP SIGNATURE----- From ipsec-request@ans.net Tue Oct 24 12:53:16 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18725 (5.65c/IDA-1.4.4 for ); Tue, 24 Oct 1995 14:56:15 -0400 Message-Id: <199510241856.AA18725@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 24 Oct 1995 14:48:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 24 Oct 1995 14:48:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 24 Oct 1995 14:48:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 24 Oct 1995 14:48:38 -0400 Date: Tue, 24 Oct 95 12:53:16 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Nodes and Users > From: smb@research.att.com > The syntax and certificate issues are important, but they're not what > I'm talking about. Here's the relevant passage from section B.1 of > Draft 5: > ... > Each party implements local policy that determines what access, if > any, is granted to the holder of a particular identity. > > In other words, an IPSP end-system has to make authorization decisions > based on some string whose syntax and semantics are both unspecified. > Absolutely. This is particularly easy, since these particular authorized Nodes and Users are preconfigured. > Let's look at possible ways that IPSEC can be used. One is gateway-to- > gateway encryption, to support private virtual networks. In that case, > the (decrypted) IP address of the sender may be important for authorization. > It is a design principle of Photuris that IP addresses are _NOT_ used for authorization. See page 1. > We can also use IPSEC, and hence Photuris, for host-to-host encryption. > Again, the receiving system needs to know the IP address of its peer, > not just the domain name. For that matter, when the sender tries to > to do automated Photuris negotiation, it also wants a key tied to IP > address. But the user wants a key tied to the DNS name, since that's > the entity a user is dealing with. > It is a design feature of Photuris that IP addresses are _NOT_ tied to a particular user identity. See page 7. > Finally, IPSEC can be used for user-to-user encryption. This format > is properly supported by the Photuris mechanisms, but only because > the string user@domain can be treated as an opaque quantity. Correct. Indeed, the identity need not even be a string. It could be any number, such as 1234 with 12 significant bits! As you say, it is an opaque quantity. > there is no > real assurance of the identity of the other party. We may as well > fall back to straight Diffie-Hellman, since if we don't know to whom > we're talking, authentication matters little. > I surely don't understand this point. The text is quite explicit: Valid Identifications and secret-keys are preconfigured by the parties. [page 47 in draft -05, page 49 in draft -06] Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Tue Oct 24 13:37:47 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15229 (5.65c/IDA-1.4.4 for ); Tue, 24 Oct 1995 15:24:44 -0400 Message-Id: <199510241924.AA15229@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 24 Oct 1995 15:15:12 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 24 Oct 1995 15:15:12 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 24 Oct 1995 15:15:12 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 24 Oct 1995 15:15:12 -0400 Date: Tue, 24 Oct 95 13:37:47 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: scenarios Steve's 3 examples reminds me that I promised Scott Bradner that I would write up some example scenarios. I will try to come up with something in the next day or so. Maybe then folks will see how the pieces fit together.... (Surely, it's already obvious ;-) > From: smb@research.att.com > Let's look at possible ways that IPSEC can be used. One is gateway-to- > gateway encryption, to support private virtual networks. ... > host-to-host encryption. ... user-to-user encryption. My mental models are node-node, user-node, and user-user. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Tue Oct 24 13:24:59 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15566 (5.65c/IDA-1.4.4 for ); Tue, 24 Oct 1995 15:49:36 -0400 Message-Id: <199510241949.AA15566@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 24 Oct 1995 15:43:24 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 24 Oct 1995 15:43:24 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 24 Oct 1995 15:43:24 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 24 Oct 1995 15:43:24 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-photuris-06.txt Date: Tue, 24 Oct 95 09:24:59 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Photuris Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-ietf-ipsec-photuris-06.txt Pages : 56 Date : 10/23/1995 Photuris is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-photuris-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-06.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-photuris-06.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951023104516.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-photuris-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-photuris-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951023104516.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Oct 24 17:07:09 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18754 (5.65c/IDA-1.4.4 for ); Tue, 24 Oct 1995 16:22:20 -0400 Message-Id: <199510242022.AA18754@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Tue, 24 Oct 1995 16:13:11 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 24 Oct 1995 16:13:11 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 24 Oct 1995 16:13:11 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 24 Oct 1995 16:13:11 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 24 Oct 1995 16:13:11 -0400 X-Mailer: exmh version 1.6.2 7/18/95 To: smb@research.att.com Cc: alten@na.SJF.Novell.COM (Alex Alten), perry@piermont.com, bsimpson@morningstar.com, ipsec@ans.net Subject: Re: Nodes and Users In-Reply-To: smb's message of Mon, 23 Oct 1995 15:47:10 -0400. <199510232039.AA24113@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 24 Oct 1995 13:07:09 -0400 From: Bill Sommerfeld -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii I don't have any pat answers for this. I suggest, though, that the identity string be a 3-tuple of 0 or more usernames, 0 or more domain names, and 0 or more IP address ranges. I'll leave the syntax and certificate format issues to someone else... I would suggest adding protocols/ports to this mix, at least so that initiators can suggest which principal on the responder they want to talk to. The experience we've had building distributed systems in DCE indicates that for some applications, particularly where you've got redundant replicated services, you're better off with an approach which can be summarized as "find out who you're talking to, then see if they're on the right ACL" rather than having to know in advance the full name of the entity you want to communicate with. As a hypothetical (and probably bad) example, if the Responder supports multiple entities, it may be more convenient to express things as "set up an association with whoever's in control of TCP port 25"., then verify that the certificate you get back has the right "magic" SMTP-server attribute. If the responder is a single-user system, it could respond with an indication to that effect and forestall future attempts from its peer to establish redundant security associations. I'd also like to suggest that an attribute-value form of identity (note that this does *NOT* imply X.500 syntax) might be more extensible and less clumsy than a 3-tuple or 4-tuple of possibly empty sets of values - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCUAwUBMI0dOVpj/0M1dMJ/AQFXJAP3ejTR0VMKT81UHw3P/1VWVorB1WFp0eXU QRYy4NgeoWUZ2LEYnw0hfWUKgOYxufau2qDHbGC4EuFuAl4Ngd7lZdCDO8dCFEVD Jr23jULhl3/I8HI908eKOQ6uNbzNKvzH+09J2ESb5drE+YmdLK8szZlpelri93RB UNP3r4G/jw== =QOoK -----END PGP SIGNATURE----- From ipsec-request@ans.net Tue Oct 24 20:15:20 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14939 (5.65c/IDA-1.4.4 for ); Tue, 24 Oct 1995 16:36:48 -0400 Received: by interlock.ans.net id AA04256 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 24 Oct 1995 16:27:36 -0400 Message-Id: <199510242027.AA04256@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 24 Oct 1995 16:27:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 24 Oct 1995 16:27:36 -0400 Date: Tue, 24 Oct 95 20:15:20 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: scenario: Virtual Private Network For discussion purposes, an administrator has two networks, and wishes all traffic between them to be encrypted. The boundary routers are 1.0.0.1 and 2.0.0.2. The commands to tunnel and encrypt are added. In the former router, route addp 2.0.0.0/8 tunnel 2.0.0.2 secure 2.0.0.2 and in the latter router, route addp 1.0.0.0/8 tunnel 1.0.0.1 secure 1.0.0.1 In each router, the lazy administrator uses the same username and password, user "root" "abracadabra" When the first datagram arrives at router 1.0.0.1 destined for net 2, the routing table indicates that it should be encapsulated for 2.0.0.2. However, the more specific routing table entry for 2.0.0.2 indicates that security is required. None is currently available, so the encapsulated datagram is tossed in the bit-bucket, and a Photuris exchange is initiated instead. Router 1.0.0.1 selects a random number (0x1111) and a UDP port (4097). It hashes these together with its IP Source and the IP Destination, and saves the hash value as its unique cookie for this exchange. A Cookie_Request is sent to 2.0.0.2 at UDP Port 468 containing the Initiator_Cookie. Router 2.0.0.2 also generates a random number (0x2222) and saves it in a global variable. When Router 2.0.0.2 receives the Cookie_Request, it hashes the UDP Ports (4097 and 468) together with its IP Source, the IP Destination, and its global random number, and sends a Cookie_Response. The reply also indicates that only Exchange Scheme 2 is offered. When Router 1.0.0.1 receives (and validates) the Cookie_Response, it generates a second random number with enough bits of strength for the strongest attributes supported (default 128-bits: 0x1111...1111), and calculates an exchange-value for Exchange Scheme 2. An Exchange_Request is sent to 2.0.0.2 containing the scheme and value, and offering three attributes (MD5, DES-CBC-32, DES-CBC-64). When Router 2.0.0.2 receives (and validates) the Exchange_Request, it also generates a second random number with enough bits of strength for the strongest attributes supported (default 128-bits: 0x2222...2222), calculates an exchange-value for Exchange Scheme 2, and sends an Exchange_Response. The reply also indicates that the next steps will be encrypted with DES-CBC-64, as well as offering three attributes (MD5, DES-CBC-32, DES-CBC-64). Router 2.0.0.2 begins calculating the shared-secret. When Router 1.0.0.1 receives (and validates) the Exchange_Response, it also calculates the shared-secret. When Router 1.0.0.1 finishes calculating the shared-secret, it generates a third random number for its SPI (0x12345678), and indicates an appropriate LifeTime (300 seconds). It chooses a Key-Generator (MD5) and a set of Attributes (MD5 and DES-CBC-32). Based on its Identity-Choice (MD5), Identification (root), and the secret (abracadabra), it calculates a hash over the many values exchanged, and stores this in the Verification field. Then, the Type through SPI fields are used as an Initialization Vector, and DES-CBC-64 is used to encrypt the remainder of the message after the SPI. The resulting Identification_Message is sent to 2.0.0.2. When Router 2.0.0.2 receives (and validates) the Identification_Message, and finishes calculating the shared-secret, it also generates a third random number for its SPI (0xdeadbeef), indicates an appropriate LifeTime (600 seconds), and performs the same functions described above. In this example, the Identification and secret-key are the same for both parties. Note that even in the face of implementations with very poor random number generation yielding the same random numbers for both parties at every step, the calculation order of the fields is different and the verification result will have a very high probability of difference. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Oct 25 03:02:39 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15255 (5.65c/IDA-1.4.4 for ); Tue, 24 Oct 1995 23:09:10 -0400 Received: by interlock.ans.net id AA11451 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 24 Oct 1995 23:03:11 -0400 Message-Id: <199510250303.AA11451@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 24 Oct 1995 23:03:11 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 24 Oct 1995 23:03:11 -0400 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 24 Oct 1995 23:03:11 -0400 Subject: Extended comments on draft skip-03 To: ashar@incog.com, markson@incog.com, ipsec@ans.net, skip@tik.ee.ethz.ch (SKIP Software), skip-info@tik.ee.ethz.ch, plattner@tik.ee.ethz.ch (Bernhard Plattner) Date: Wed, 25 Oct 1995 04:02:39 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 10109 -----BEGIN PGP SIGNED MESSAGE----- Hi Ashar, everybody I did reread the skip draft 03, and I still like it very much ;-) Sorry to give this set of comments without exact quotes of the original, they were written on the way... I will give as few editorial comments as I can myself force to, as you requested, just let me say that section 1.1 and on still have some of the deficiences I mentioned in my comments to 02. I would add the Non-Goal of authentication with nonrepudiation characteristics as 1.7.5. You mention the problem with asymmetric signatures somewhere, perhaps this could be moved to here? page 14, 'identify a particulay Kij' ^typo page 14, between 3th and 4th paragraph Do we provide for the fact, that at any given time a machine may use multiple Kij's over the same link? We could tell them that this really would work -- you are not bound to one shared secret per link. Example: Use a machine-specific DH value for NFS etc. AND use the smartcard-supplied shared secret for a telnet / X connection whatever. This could be an example for user-level keying in section 1.8. (I know this demands user-level stuff like sockopt(), but that is not a problem here, I believe) page 14, last paragraph You introduce the notion of a 'principal'. Is this a user, a service, a machine? (probably all of them, depending on the application of this key distribution scheme) I am now for some while thinking about the possibility to take an RSA public value and somehow use it as an DH public value. (after conversion) Is this feasible, secure & interesting? One wonders... ;-) page 15, paragraph 1 (about hash of public value for naming purposes - which I like very much. This will be a good step for us testing certificate discovery interoperabi- lity in december) ... a name and a public value. + However the binding between name and identity has to be provided in a secure manner, see also note in 4.1. page 15, last paragraph here the notion of the receiver master-key ID introduces itself. Some pages earlier it was the 'Destination NSID'. I suggest to stick to either source NSID & source Master-Key ID or sender NSID sender Master-Key ID. Same for destination & receiver. And yes, this _is_ yet another editorial comment;-) page 18, last paragraph ...All RESERVED fields will be set... ^MUST 1.10, page 19, first paragraph Authentication must follow encryption and/or compression, because... ^drop the rest I know I already mangled this paragraph once. If you do authentication before encryption you could still check it after decryption. (Unneeded work in the case of a modified packet). The becasue... part seems not relevant to me anymore. (Probably I am overseeing something?) 1.12 page 21, 3th paragraph Note:... Hmm. The cryptographic distinction in this case is the fact that anybody can check (and generate) the integrity of the packet, but only those in possesion of the shared secret may check (and generate) the authenticity of the packet. (never mind...) In 1.12.2 you removed the fields to cover for the MAC computation - especially the IPSO label field. Sigh. It was wise to do so. Still I enjoyed the explicit and coarse listing from 02 of what implementors _have_ to do ;-) Quote from 1826 [Atk95a]. In some situations, users MAY choose to carry explicit labels (for example, IPSO labels as defined by RFC-1108 might be used with IPv4) in addition to using the implicit labels provided by the Authentication Header. Explicit label options could be defined for use with IPv6 (e.g., using the IPv6 end-to-end options header or the IPv6 hop-by-hop options header). Implementations MAY support explicit labels in addition to implicit labels, but implementations are not required to support explicit labels. If explicit labels are in use, then the explicit label MUST be included in the authentication calculation. Does this solve the IPSO problem I mentioned in the comments to draft 02? What do you do in SKIP if e.g. only authentication is specified, and the length field as described in RFC1826 is set to 0? This would mean no authentication data. AGAIN: (I mentioned this twice already, I fear) What to do if a SKIP header with Kij alg/Crypt alg/MAC alg etc. == 0 comes in / is to be produced? Do we declare this invalid? Do we just leave out 'Kp' in the appropriate cases (dropping the field) so we can still have compression without the rest? I would somewhere set up a table of possible zeros, and discuss (il-) legaility of the different cases. We want to operate in the same way, don't we? ;-) Kij alg | Crypt alg | MAC alg | ESP header | AH header | (RFC 1826 length) ========+===========+=========+============+===========+================== 0 | 0 | 0 | not pres. | not pres. | ----- 1) 0 | non 0 | x | x | x | x 2) 0 | x | non 0 | x | x | x 2) 0 | x | x | x | present | x 2) non 0 | 0 | 0 | x | x | x 3) non 0 | non 0 | x | not pres. | x | x 2) non 0 | non 0 | x | present | x | x 4) non 0 | x | non 0 | x | not pres. | ----- 2) non 0 | x | non 0 | x | present | non 0 4) non 0 | x | non 0 | x | present | 0 5) Instead of ESP and/or AH header, this could be a RIP header with(-out) authentication etc. 1) legal. Kp field not present. Usefull e.g. for compression without rest. 2) Illegal. Discard packet. 3) Illegal. Discard packet. How would you try to determine length of Kp... 4) Perfectly decent. 5) You tell me. Sounds quite stupid... If there is a SKIP header, and AH ESP attached, but the SPI is non-1 should we just ignore the SKIP header, and do different AH/ESP processing, or drop the packet? (drop it! ;-) Force ICMP answer with setting all alg fields to 0, including compression, as opposed to the method stated in the last paragraph of section 3. Oh yes. If we have an SKIP IP packet without trailing data of any form, but with a nice random Kp, how does Sunscreen do? Pass it on? Yet another sublime channel? ;-) Let's go back to SKIP: 1.13.1 / 1.13.2 The small images of 'IPv4 with SKIP/(AH)/ESP Example'. After ESP header I would write 'opaque transform data' instead of 'Upper Protocol'. It is not clear if after the ESP header there is an UPPER protocol (might be IP again) -- and you really can't look into it. The last line of the image on page 24 should be the same as the one in the image of page 25. (Usage of E_kp) On both images, the 'opaque transform data' is only partially ESP hdr. The rest is payload. (Delimiter at the border of the image) 1.14, 2nd paragraph, 1st line ...payload of of a... (--) ICMP vs. Multicast What happens if somebody in a multicast tree receives an incomprehensible SKIP packet? Does he send an ICMP? (No! Well, maybe...) To the sender, or to the group? (To the sender!) How does the sender find out the feedback concernes the group, and not the bilateral connection they perhaps also have? This might be an issue when we go on and _do_ SKIP on multicasts. Times Sometimes you use time since 1.1.1995, sometimes since 1.1.1970 (if I remember right), sometimes seconds since 1.1.1900 (64 bits) and sometimes since 1.1.1900 in NTP format (integer part, 32bits). Many different representations. Now it is clear we use 'n' on an hourly base, and it is okay to subtract about 788'400'000 (how much, exactly -- what about the infamous leap seconds ;-) ) from system time before using it. But why using NTP format, when the internal timing represenation most naturally available on the system is 'seconds since 1970'? I wonder... Page 28, Multicast Request. I gather 'reply attacks' do not work because a minimum of SKIP/AH is required. Do we want to note this? Or do we want to add a time field like in the authenticated ICMP message? (Either one time field is superflous, or there is one missing). Same for the Multicast reply providing the GIK? You define key change police for the multicast case. The same policy is very reasonable in the unicast-case too. You could reference section 6.2 in the first paragraph of page 29. I enjoyed the introductor paragraph to section 3.0. How true ! page 33, paragraph 2, second line ...The ICPM message is authenticated... ^MUST be Hmmmm... Assume 2 hosts are out of sync concerning their 'n'. Perhaps due to a different n scheduling, the posibility of this being suggested by the draft somewhere. Now, when the authenticated ICMP message comes in, it will be discarded because of the invalid n. But in the packet, the correct n would have been given. Quite a dilemma, isn't it? Comments? Page 35, first paragraph. I suggest to state that the minimal 'n' update Frequencey (or rather, the grace period for accepting older n) shold be at least as large as the time IP packets are expected to live in the network. I seem not to remember the correct name at the moment. Something like maximum packet latency or living time or whatever. Let's make it TTL ;-) Well, perhaps this would fit better in 6.3. [Comments about Certificate Discovery suppressed] That's about it. The draft really is good work, and in my belief going into the right direction. I look forward to the standard! ;-) Friendly greetings, Germano - -- <...cookie space for rent...> Germano Caronni caronni@tik.ee.ethz.ch http://www.tik.ee.ethz.ch/~caronni PGP-Key-ID:7B7AE5E1 gec@acm.org 997C6DC4AF930A5D2D5D6AEAA196C33B -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMI2ozLH8jId7euXhAQEjBwP/Sl5gy2DHYKgU3tVSevCMEupCls/LJyMX XP5xUuCLJ1lRvweBZZNICBxLv29I1tc/BxqNK8IW0ucuuHuVJkqVCSEUdZA9qXuB qnmUm8Em1DbsTwMRc1biBAt7MaLOrgYcYfAIfnpFMDCk+biQZM9BbkltvGNfTIh/ 3ZBBt+/o7qI= =dZOy -----END PGP SIGNATURE----- From ipsec-request@ans.net Wed Oct 25 05:13:05 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15580 (5.65c/IDA-1.4.4 for ); Wed, 25 Oct 1995 01:33:06 -0400 Received: by interlock.ans.net id AA13912 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 25 Oct 1995 01:30:12 -0400 Message-Id: <199510250530.AA13912@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 25 Oct 1995 01:30:12 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 25 Oct 1995 01:30:12 -0400 Subject: CFP: Special issue on ATM Switching To: ipsec@ans.net Date: Wed, 25 Oct 1995 15:13:05 +1000 (EST) Reply-To: atiq@eng.monash.edu.au (Mohammed Atiquzzaman) From: atiq@eng.monash.edu.au (Mohammed Atiquzzaman) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3297 Call for Papers Special Issue of International Journal of Computer Systems Science & Engineering on ATM Switching Guest Editors: Hussein T. Mouftah, Queen's University, Canada Mohammed Atiquzzaman, Monash University, Australia. _______________________________________________________________________________ Papers are solicited for a special issue of the International Journal of Computer Systems Science & Engineering on Asynchronous Transfer Mode (ATM) Switching to be published in the third quarter of 1996. During the past decade, a considerable amount of effort has been made in studying and designing ATM switches which is believed to be the most developed aspect of ATM. The field has now become a mature area and ATM switches are becoming commercially available. This special issue will include a set of original and survey articles from both industry and academia that represents the current state-of-the-art in ATM switching. Possible topics include (but are not limited to): o Switch architectures o Fault tolerance o Buffering schemes o Congestion control and traffic management o Performance modeling o Practical experience & field trials o Buffer management o Simulation techniques for large switches o Commercial switches Five copies of complete manuscripts (not to exceed 25 double-spaced pages) should be sent to Mohammed Atiquzzaman by 1 February 1996. Please include a title page containing author(s) names and affiliations, postal addresses, e-mail addresses, telephone numbers, and fax numbers. Electronic (PostScript only) submissions are encouraged. Authors should follow the IJCSSE manuscript submission format. _______________________________________________________________________________ Guest Editors: _______________________________________________________________________________ Mohammed Atiquzzaman Hussein T. Mouftah Dept. of Elect. & Comp. Systems Engg. Department of Elect. & Comp. Engg. Monash University, Clayton 3168 Queen's University, Kingston Melbourne, Australia. Ontario, Canada K7L 3N6. Tel: +61 3 9905 5383 Tel: +1 613-545-2934 Fax: +61 3 9905 3454 Fax: +1 613-545-6615 Email: atiq@eng.monash.edu.au Email: mouftah@eleceng.ee.queensu.ca WWW: http://www.eng.monash.edu.au/~atiq _______________________________________________________________________________ Important Dates: _______________________________________________________________________________ Deadline for receipt of manuscripts: 1 February 1996 Notification of acceptance/rejection: 30 April 1996 ASCII and PostScript versions of this announcement and the author's guidelines for IJCSSE are available from http://www.eng.monash.edu.au/~atiq IJCSSE is published by CRL Publishing, London, UK. Please contact the editor-in-chief Prof. Tharam Dillon (tharam@latcs1.lat.oz.au) for queries regarding the journal and J. Thompson (100113.2636@CompuServe.com) for sample copies. From ipsec-request@ans.net Wed Oct 25 14:10:20 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15177 (5.65c/IDA-1.4.4 for ); Wed, 25 Oct 1995 10:39:53 -0400 Received: by interlock.ans.net id AA20737 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 25 Oct 1995 10:32:39 -0400 Message-Id: <199510251432.AA20737@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 25 Oct 1995 10:32:39 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 25 Oct 1995 10:32:39 -0400 Date: Wed, 25 Oct 95 14:10:20 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: scenario: Authenticated Firewall Traversal An administrator has one or more networks, and a number of mobile users. It is desirable to restrict access to authorized external users. The boundary router is 3.0.0.3. Each user adds commands to tunnel and authenticate. route addp 3.0.0.0/8 tunnel 3.0.0.3 secure 3.0.0.3 authenticate-only In this example, the administrator gives each user a different username and password, together with a separate username and password for the router. (A lazy administrator can simply give one username and password to all users for both the user and the router, as described previously.) user "wanderer" "faldaree" user "router" "faldarah" The mobile host is assigned a temporary local IP address (4.0.0.4). When the first datagram is generated destined for a node on net 3, the routing table indicates that it should be encapsulated for 3.0.0.3. However, the more specific routing table entry for 3.0.0.3 indicates that authentication is required. None is currently available, so the encapsulated datagram is tossed in the bit-bucket, and a Photuris exchange is initiated instead. The Photuris exchange proceeds exactly as previously described, except that two Identifications are involved. Router 3.0.0.3 may be configured with all the usernames permitted, or more likely will access an external database of usernames and passwords using a mechanism such as RADIUS. Even though router 3.0.0.3 includes DES-CBC-32 in its Attribute-Choices, the mobile node configuration does not require that every datagram be encrypted. That is, the specific policy of this mobile node is that an AH be added whenever traffic is sent to 3.0.0.3, but that no ESP is used. In this example, the boundary router has no configured policy with respect to the mobile node. This would be difficult, as the actual IP address assignment is unpredictable. However, a serendipitous SPI has been created by the mobile node. When the router prepares to forward a datagram from inside net 3, it will discover that the routing table entry for 4.4.4.4 includes a security association. The router implementor could legitimately use that SPI for AH and/or ESP in the absence of contrary policy configuration. Therefore, the mobile node must be capable of receiving encapsulated authenticated and/or encrypted traffic using its SPI. It must also be capable of receiving unauthenticated and unencrypted traffic. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Oct 25 15:40:42 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10979 (5.65c/IDA-1.4.4 for ); Wed, 25 Oct 1995 12:04:26 -0400 Received: by interlock.ans.net id AA22469 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 25 Oct 1995 11:55:10 -0400 Message-Id: <199510251555.AA22469@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 25 Oct 1995 11:55:10 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 25 Oct 1995 11:55:10 -0400 Date: Wed, 25 Oct 95 15:40:42 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: scenario: Automated Firewall Bypass Although the previous examples may be adequate in early stages of deployment, where many nodes have not been upgraded to include Internet Security, the "ultimate goal" is direct IP connectivity. This is particularly required when both nodes are mobile, and there are no fixed well-known routers between them. This will also reduce configuration, and facilitate network renumbering. Instead of relying on an administrator, the users are empowered to select their own usernames and passwords. They may change them at any time with the standard tools provided by their operating systems. (A lazy user can simply have one username and password on all systems, as described previously.) user "myself@laptop.somewhere" "o,wabm," user "myself@desktop.somewhere" "o,wabd!" The user may find it convenient (or be required by the operating system) to use a more formal naming syntax (above), simply to keep the many accessible systems separate. When the laptop is attempting to access the desktop, it may be obstructed by an intervening router acting as a firewall. This is indicated by receipt of the ICMP message Destination Unreachable: Communication Administratively Prohibited (Type 3, Code 13). The Photuris exchange proceeds as previously described, except that rather than sending to the firewall, the exchange is attempted to the actual target system first. This will work when the firewall is capable of passing Photuris datagrams, as well as AH and ESP protected datagrams. If the implementation continues to receive ICMP messages in response to the Cookie_Request, it should abandon the exchange and attempt a Photuris exchange with the intervening router instead. This may be problematic when the router does not have a public-key form of signature available, as by definition the user has not configured the presence of this router. Such a mechanism is outside the scope of this document. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Oct 25 17:50:33 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13613 (5.65c/IDA-1.4.4 for ); Wed, 25 Oct 1995 14:30:31 -0400 Received: by interlock.ans.net id AA25557 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 25 Oct 1995 14:18:23 -0400 Message-Id: <199510251818.AA25557@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 25 Oct 1995 14:18:23 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 25 Oct 1995 14:18:23 -0400 Date: Wed, 25 Oct 95 17:50:33 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: scenario: Multi-User Access Control In certain extremely security conscious environments, all valid users sharing a node might not have the same level of authorization. The operating system itself is not the trusted entity. Each user or process requires its own identification and access control. These "Multi-Level Secure" environments require two or more Photuris exchanges. These exchanges involve 4 or more entities: user "myself@SomeWhere" "mairsydotes" user "rcmd@SomeWhere" "doesydotes" user "myself@ElseWhere" "liddellams" user "rcmd@ElseWhere" "eedivy" The first Photuris exchange might be triggered when sending a datagram from SomeWhere to ElseWhere. The Initiator would naturally use the Identification which is associated with the triggering transport-level process (myself@SomeWhere). Because Photuris is a network-level session key management protocol, the Responder Identification will be associated with the operating system which is processing the network-level exchange (rcmd@ElseWhere). Since authentication policy is in the receiver direction, when datagrams arrive at ElseWhere with the given SPI, the access policy will be dependent on the Initiator Identification. Likewise, when datagrams arrive at SomeWhere with the given SPI, the access policy will be dependent on the Responder Identification. This may not match the authorization level required for access. This is indicated by the ICMP message Security Failures: Need Authorization (Type 40, Code 5). The Responder in turn becomes the Initiator in a second exchange, and delivers the Identification which is associated with the triggering transport-level process (myself@ElseWhere). The peer might use its system-wide Identification (rcmd@SomeWhere). When repetitive Photuris exchanges occur between the same parties, and the exchange-values are discovered to be unchanged, the cached shared-secret can be used to rapidly generate new session-keys. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Oct 25 20:18:14 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18800 (5.65c/IDA-1.4.4 for ); Wed, 25 Oct 1995 16:28:27 -0400 Received: by interlock.ans.net id AA28896 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 25 Oct 1995 16:19:02 -0400 Message-Id: <199510252019.AA28896@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 25 Oct 1995 16:19:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 25 Oct 1995 16:19:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 25 Oct 1995 16:19:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 25 Oct 1995 16:19:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 25 Oct 1995 16:19:02 -0400 Date: Wed, 25 Oct 1995 13:18:14 -0700 From: pingn@jurassic.eng.sun.com (Teodora Ngo) To: ipsec@ans.net, skip-info@tik.ee.ethz.ch Subject: comments on draft 03 of SKIP X-Sun-Charset: US-ASCII General Comments ================ This draft is a great improvement over previous drafts, both in content and in clarity. 1. The SKIP header does not have a checksum. What assures the integrity of the SKIP header ? 2. There are two modes in ESP, tunnel mode and transport mode. This information is not on the SKIP header. How does an intermediate node which is encrypting/decrypting SKIP packets for multiple machines know whether the entire IP datagram is encrypted or only the upper-layer protocol ? 3. Why is sequencing dropped in draft 3 ? The n counter provides a very coarse-grain playback protection. For interoperability, section 6.3 specifies the n counter to be incremented once every hour. Since nodes are only required to be synchronized within an hour of each other, and packets are processed if the counter value differs by 1, this opens a window of an hour or more. Use of sequencing can provide better protection, if the implementation takes care of sequence number prediction. 4. The draft requires use of several numbers which must be assigned by IANA, Certificate Discovery Protocol - Ports 6455, 6456. SKIP Multicast GIK request port - to be assigned Algorithm Discovery - SKIP_ICMP type 39 How about introducing message types and use only one port ? With message format dependent on message type. For example, Message Type 1 - Certificate request 2 - Certificate response 3 - Algorithm request 4 - Algorithm response 5 - Multicast group interchange key request 6 - Multicast group interchange key response Specific Comments ================= Page 6, paragraph 2 > Once n certificates are assigned to n IP nodes, O(n^2) mutually > authenticated pairwise keys arise, simply as a result of the > authenticated public value distribution process. What is the notation O(n^2) ? In Math Probability, there is a combination function, nCj = n! /[(n-j)! j!], which is the number of ways of selecting j objects out of n objects. nC2 maps nicely into the number of pairwise keys from n certificates. Perhaps one can change the notation to use C(n,2) instead of nC2. Page 6, paragraph 3 > Since there is nothing secret about DH public values, one natural way > to discover the relevant authenticated public value is to distribute > these using a directory service. authenticated directory service ? Does this require a secure directory or naming service ? Page 8, paragraph 3 > Once the counter has moved forward, packets encrypted with the help of > counter values that differ by more than 1 from the local n MUST be > ejected. As mentioned in general comments, if packets with counter value differing by 1 are accepted, the window can be an hour or more. This is very coarse playback protection. Page 9, paragraph 1 > This counter value is passed in the field labeled "n" following the > version and processing mode bits of the SKIP header described in Section > 1.9. There is no longer processing mode bits in the SKIP header. The counter value n follows the next header field of the SKIP header. Page 12, Section 1.7.2 > and that should be infeasible even given a very large number of > known/chosen Kp keys as long as the key-encryption algorithm is immune > to a chosen text attack, which will always be the case. always be the case ? depends on key-encryption algorithm chosen. Page 14, paragraph 6 > The usage of NSIDs also allows many different name spaces (up to 256) to > be used with SKIP, by letting the Master Key-ID be the message digest of > the name in its native name space. If the Master Key-ID is the message digest of the name in its name space, it will be unique only if the message digest is collision resistant. It is possible to produce collitions in the compression function of MD5. ( B. den Boer and A. Bosselaers ) Page 17, diagram of SKIP header Kp encrypted in Kijn, Sender/Receiver Master Key-ID, do not have right borders of their boxes. Since these are variable length, I suggest using a box that looks like +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ~ ~ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Page 22, diagram of SKIP with AH Missing sender/receiver Master Key-ID in the SKIP header. Page 24, diagram of SKIP with ESP Missing sender/receiver Master Key-ID in the SKIP header. Page 24, paragraph 3 > The Opaque transform data is defined by the particular transform (such > as DES-CBC in RFC 1827). RFC 1827 is ESP. Should this be RFC 1829 ESP DES-CDC ? Page 26, Section 1.13.3 > For ESP transforms which combine encryption and authentication (for > instance: Keyed MD5 with DES-CBC), only an ESP header is needed. What is being specified ? Is it allowed to have both AH and ESP headers ? Or It MUST only contain the ESP header, without AH header ? What is the assigned algorithm number for this combined transform example, Keyed MD5 with DES-CBC ? Page 27, paragraph 5 > Nodes wishing to transmit/receive encrypted datagrams to multicast > address M need to acquire the GIK Kg. This is done by sending an > encrypted/authenticated request-to-join primitive to the group owner. How will this be encrypted/authenticated ? Using unicast SKIP ? Page 31, Section 2.2.1 > groups, we describe SKIP for RIPv2 [RFC 1388] RFC 1388 is obsoleted by RFC 1723. Page 32, diagram of SKIP with RIP V2. Missing sender/receiver Master Key-ID in the SKIP header. Page 33, paragraph 2 > The ICMP message is authenticated using RFC > 1825 as the default authentication algorithm An RFC is not an algorithm. Suggestion : using Keyed MD5 [RFC1828] as the default authentication algorithm. Page 34. > The Algorithm discovery ICMP message: 0 1 2 3 > 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TYPE=SKIP_ICMP| CODE | CHECKSUM | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ > CODE should be interpreted as a bit field in the following way: 7 6 5 4 3 2 1 0 > +-+-+-+-+-+-+-+-+ > |I|P|M|C|N| res | > +-+-+-+-+-+-+-+-+ The top diagram shows CODE occupies bits 0-7 of octet 1. The lower diagram reverses the bits 0-7. So is the I bit in bit 0 of octet 1 ? or Bit 7 of octet 1 ? How about showing the diagram in the same orientation ? eg, 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|P|M|C|N| res | +-+-+-+-+-+-+-+-+ or 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | res |N|C|M|P|I| +-+-+-+-+-+-+-+-+ > The time field, Current Time, is set to the system's concept of current > time in seconds since 0h Jan 1, 1900. This is identical to the Integer > portion of the NTP timestamp. If the time field is 32-bits, in seconds, it can accommodate a little over 136 years beyond 1900, ~2036. How about increasing this to 64 bits ? Section 6.3, n counter start time is 0h Jan 1, 1995. How about having both use year 1995 ? There is no description for the field Expected n. Is this always present or present only when N bit is set (invalid n counter sent in the packet) ? In RFC1825 (Security Architecture), it states : "Given two endpoints, it MUST be possible to have more than one concurrent Security Association for communications between them." Does this draft address this requirement ? On Page 14, description of Master Key-ID, it states : "More importantly, it allows non-IP entities, such as individual users, to be identified using whatever name space is being used for them." The Algorithm discovery message does not contain NSID nor Master Key-ID. Will this allow different encryption algorithms to be used for different Master Key-IDs ? or between two systems ? > A host may force an ICMP message by sending a SKIP packet to the remote > host with Kij set to zero. force ? What if the remote host does not support Algorithm Discovery, which is optional ? Suggest rewording "force", maybe induce or elicit. Page 39, paragraph 2 Suggestion : Spell out CRL on first use of acronym. Page 40, last paragraph > "by-pass" channel for encryption. Please explain that this means traffic between the two ports are not encrypted. There are numerous places in the document referrring to things described later. These can be made to explicit references. Here is a list : Page 5, Section 1.1 > Another mechanism, described later, relies on naming principals > using the message digest of their DH public value. described in section 1.4,... Page 8, paragraph 2 and 3 > Recommended time units/counter update frequency and the agreed upon > start time is specified later in the document. specified in section 6.3. Page 9, Section 1.3.2 > As before, n can be computed as the difference between an agreed upon > start time (specified later in this document) and the current time. specified in section 6.3 Page 17, paragraph 3 > Examples of protocols other than AH/ESP that may use SKIP are given later. There is only one example described (RIPv2). Suggestion : "An example ....... is described in section 2.2.1" Page 18, paragraph 3 > For instance, it is possible to have a Crypt Alg which provides > both encryption and MAC computation. This is further described in > a later section. described in section 1.13.3. Page 24, paragraph 2 and 3 > The SKIP_SPI value is specified later in this document. specified in section 5.2 Page 34 > The ICMP type field SKIP_ICMP is specified later in this document. specified in section 5.5 Page 35, last paragraph > Although, strictly speaking, an unsigned DH public value is not a > certificate, this value is distributed using the optional certificate > discovery protocol specified later. specified in section 4.3 Section 4.3, paragraph 2 > An algorithm for choosing a particular certificate > (essentially a Diffie-Hellman public value) when more than one exist is > described later. in section 4.4 From ipsec-request@ans.net Wed Oct 25 21:32:16 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11000 (5.65c/IDA-1.4.4 for ); Wed, 25 Oct 1995 17:38:32 -0400 Received: by interlock.ans.net id AA00695 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 25 Oct 1995 17:32:27 -0400 Message-Id: <199510252132.AA00695@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 25 Oct 1995 17:32:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 25 Oct 1995 17:32:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 25 Oct 1995 17:32:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 25 Oct 1995 17:32:27 -0400 From: markson@osmosys.incog.com (Tom Markson) Subject: SKIP: Fixes to certificate discovery protocol To: ipsec@ans.net, skip-info@tik.ee.ethz.ch Date: Wed, 25 Oct 1995 14:32:16 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, As Germano Caronni pointed out, the certificate discovery protocol described in the most recent SKIP draft is "botched". We would like to propose this as the replacement to the Certificate Discovery Protocol. If there are no problems with it, we will replace the text in the next round of draft. --tom 4.3 Certificate Discovery Protocol An optional protocol is described to enable communicating IP-nodes to discover each other's certificate(s). This obviates the need for an on- line certificate directory server. A number of certificate types currently exist, for example, X.509, PGP DNS-SIG, Unsigned DH pub value. This protocol allows for all of these types. Also note, that a particular IP-node may have more than one certificate. A node could have the same Diffie-Hellman public value in different certificate formats, or have multiple Diffie-Hellman public values each in a separate certificate or have the same Diffie-Hellman public value certified by different Certifying Authorities, and so on. In all these possible certificates the identity of the node remains constant. An algorithm for choosing a particular certificate (essentially a Diffie-Hellman public value) when more than one exist is described later. All certificate discovery protocol communication use the User Datagram Protocol (UDP). The initiator binds to port skip-cert-send (6456) and sends a certificate request to port skip-cert-recv (6455). The responder binds to port skip-cert-recv and sends the response to port skip-cert-send. Two separate ports are used to allow for multiple certificate requests to be made without waiting for the response to be received, (that means, one port is used to simply send requests out and the other port is used to receive responses). A simple cache of the Master Key-ID and the IP address to which the request was sent is all that is required to manage outstanding certificate requests. Implementation Note: Considering that a node may be pre-configured to allow only encrypted communication with any other node, a certificate request would be rejected. It is suggested that the two ports (skip- cert-send and skip-cert-recv) be treated as a "by-pass" channel for encryption. As only certificates requests are satisfied on these ports the window for vulnerability is limited. The certificate discovery packet: 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VERS |ACTION | STATUS | NUMBER-OF-CERTS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Master Key-ID of certificate ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CERT-TYPE | NSID |CERT-LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CERTIFICATE ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CERT-TYPE | NSID |CERT-LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CERTIFICATE ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... VERS indicates protocol version #. VERS = 1 for this protocol. ACTION indicates the type of message. Possible values are: 1 (Request) - request for remote parties certificate(s). 2 (Response) - response to a certificate request. STATUS is used only in responses (i.e. ACTION = 2). Possible values are: 0 (OK) - process the certificates sent. NUMBER-OF-CERTS must not be zero. 1 (Unknown Error) - an error has occurred. 2 (Unknown Master Key-ID) - no certificates for the requested Master Key-ID can be found in the local certificate database. NUMBER-OF-CERTS - if 0 then no certificates are present in the message and the message is simply a request for all certificates for the specified Master Key-ID or a response where the STATUS octet indicates an error. Master Key-ID - this is the identifier as described in the section on Master Key-IDs. It's length is dependent on the value of the NSID field. It is only used when requesting certificates with a specific master key-id from another entity. The requester may set this to zero (0) in which case the receiver should consider the request for ALL certificates. The responder should always set this field to zero (0). Each public key or certificate will be returned with the following information present. CERT-TYPE - specifies the certificate type of the certificate that is to follow. Some well known types have been assigned values below in the Assigned Numbers section. NSID - identifies the namespace that the Key-ID belongs to. The values of this field are described in the assigned numbers portion of this document. CERT-LENGTH - specifies the length of the certificate in bytes CERTIFICATE - the actual certificate. Note that this allows for the initiator to request all certificates or just certificates for a particular Master Key-ID. It also allows the requester to send in the same message all the certificates it has. As certificates have the subjects identity (i.e. specifies the certificate owner), this information does not have to be sent to other party. The Certificate Discovery Protocol allows certificate requests to be made to any arbitrary IP-node. This feature allows the initiator to send requests to, say, an IP-node which is acting as a DNS or NFS server (and hence would have many certificates stored in its local certificate database). --tom From ipsec-request@ans.net Thu Oct 26 00:29:02 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15228 (5.65c/IDA-1.4.4 for ); Wed, 25 Oct 1995 20:37:23 -0400 Received: by interlock.ans.net id AA05276 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 25 Oct 1995 20:32:43 -0400 Message-Id: <199510260032.AA05276@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 25 Oct 1995 20:32:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 25 Oct 1995 20:32:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 25 Oct 1995 20:32:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 25 Oct 1995 20:32:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 25 Oct 1995 20:32:43 -0400 Date: Wed, 25 Oct 1995 17:29:02 -0700 From: pingn@jurassic.eng.sun.com (Teodora Ngo) To: ipsec@ans.net, skip-info@tik.ee.ethz.ch Subject: Re: SKIP: Fixes to certificate discovery protocol Cc: markson@osmosys.incog.com X-Sun-Charset: US-ASCII Hi, Tom, I am confused by this fix. Germano wrote : > | > |Master Key-ID - this is a 32 bit or a 128 bit identifier as described > | in the section on Master Key-IDs. > > Hmm. How do I know if it is 32bit or 128 bit? Why only the two values? > Redesign. Include NSID! This comment from Germano is for Draft 2, because the cerificate discovery message contains Master Key-ID, but no NSID. Draft 2 : > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VERSION | ACTION | STATUS |NUMBER-OF-CERTS| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Master Key-ID of certificate(s) in packet ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I thought this is fixed in Draft 3 : > 0 1 2 3 > 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VERS |ACTION | STATUS | NSID |NUMBER-OF-CERTS| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Master Key-ID of certificate(s) in packet ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fix has NSID with each certificate. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VERS |ACTION | STATUS | NUMBER-OF-CERTS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Master Key-ID of certificate ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CERT-TYPE | NSID |CERT-LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CERTIFICATE ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CERT-TYPE | NSID |CERT-LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CERTIFICATE ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... > Master Key-ID - this is the identifier as described in the section on > Master Key-IDs. It's length is dependent on the value > of the NSID field. It is only used when requesting > certificates with a specific master key-id from another > entity. The requester may set this to zero (0) in which > case the receiver should consider the request for ALL > certificates. The responder should always set this > field to zero (0). Suggestion : The responder should retain the same Master Key-ID so one can match a certificate response to its certificate request. There can be multiple outstanding certificate requests. ... NSID - identifies the namespace that the Key-ID belongs to. The values of this field are described in the assigned numbers portion of this document. There is only one Master Key-ID, Why do you need NSID with each certificate ? Is the intent to associate each certificate with a Key-ID ? If so, then you need both NSID and Master Key-ID with each certificate. Cheers, Ping-Ping From ipsec-request@ans.net Fri Oct 27 00:40:01 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04177 (5.65c/IDA-1.4.4 for ); Thu, 26 Oct 1995 20:45:33 -0400 Received: by interlock.ans.net id AA00951 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 26 Oct 1995 20:40:30 -0400 Message-Id: <199510270040.AA00951@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 26 Oct 1995 20:40:30 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 26 Oct 1995 20:40:30 -0400 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 26 Oct 1995 20:40:30 -0400 Subject: Re: comments on draft 03 of SKIP To: pingn@jurassic.eng.sun.com (Teodora Ngo) Date: Fri, 27 Oct 1995 01:40:01 +0100 (MET) Cc: ipsec@ans.net, skip-info@tik.ee.ethz.ch, skip@tik.ee.ethz.ch (SKIP Software), ashar@incog.com, markson@incog.com In-Reply-To: <199510252019.AA28896@interlock.ans.net> from "Teodora Ngo" at Oct 25, 95 01:18:14 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 9836 -----BEGIN PGP SIGNED MESSAGE----- Teodora Ngo wrote: > Subject: comments on draft 03 of SKIP I allow myself to comment your comments, as I have a strong opinion on some of them. I enjoyed reading them, even when I disagreed. There is no advance without contrasting opinions! ;-) > 1. The SKIP header does not have a checksum. What assures the > integrity of the SKIP header ? If the packet is authenticated, then this provides the integrity check. If not then the encapsulated packet will be decrypted wrongly, and the next protocol field, the upper protocol checksum, or the data will be junk. This will be discovered at the appropriate level. SKIP implemen- tations may check some of these conditions after decrypting. > 2. There are two modes in ESP, tunnel mode and transport mode. > This information is not on the SKIP header. How does an > intermediate node which is encrypting/decrypting SKIP packets > for multiple machines know whether the entire IP datagram is > encrypted or only the upper-layer protocol ? a) does it matter? b) by looking at the next protocol field. > 3. Why is sequencing dropped in draft 3 ? The n counter provides That is a *very* good question. I would like to see this feature back, either in the ESP transform, the AH transform, or somewhere else. I believe you, Ashar, have a solution to this up your sleeve?! > How about introducing message types and use only one port ? With > message format dependent on message type. For example, Only one port would *FORCE* the one binding to the port to understand all of these. But my certificate broker will never want to bother with multicast access control at all... A different question is, why do you have different ports for sender and receiver? Frankly, I do not know. No need for this? > > Once n certificates are assigned to n IP nodes, O(n^2) mutually > > authenticated pairwise keys arise, simply as a result of the > > authenticated public value distribution process. > What is the notation O(n^2) ? In Math Probability, there is a combination > function, nCj = n! /[(n-j)! j!], which is the number of ways of selecting > j objects out of n objects. nC2 maps nicely into the number of pairwise > keys from n certificates. Perhaps one can change the notation to use > C(n,2) instead of nC2. Given the above example, we could also just write n(n-1) instead of O(n^2) which would be the exact answer in the given scenario. The 'O' notation IMHO expresses 'on_the_order_of' computational behaviour. > > Since there is nothing secret about DH public values, one natural way > > to discover the relevant authenticated _public value_ is to distribute > > these using a directory service. > authenticated directory service ? > Does this require a secure directory or naming service ? no authenticated _directory service_ is needed here. > > and that should be infeasible even given a very large number of > > known/chosen Kp keys as long as the key-encryption algorithm is immune > > to a chosen text attack, which will always be the case. > always be the case ? depends on key-encryption algorithm chosen. I strongly agree. > Page 14, paragraph 6 > > The usage of NSIDs also allows many different name spaces (up to 256) to > > be used with SKIP, by letting the Master Key-ID be the message digest of > > the name in its native name space. > If the Master Key-ID is the message digest of the name in its name space, > it will be unique only if the message digest is collision resistant. > It is possible to produce collitions in the compression function of MD5. > ( B. den Boer and A. Bosselaers ) ######################################################################## Let me quote parts of a mail from Sender: "paul (p.c.) van oorschot" Date: Mon, 26 Jun 1995 18:26:00 -0400 Subject: response to Last Call on: IP Authentication using Keyed MD5 which can be found in the ipsec mailing list archive. ... Regarding attacks on specific hash functions, the I-D notes an attack on the compression function of MD5 by den Boer and Bosselaers, and states: ``There is not yet a known method to exploit these collisions to attack MD5 in practice, but this fact is disturbing to some authors [Schneier94].'' Indeed, considerable additional research has been recently carried out. Bert den Boer himself proposed a new hash function, namely RIPEMD, which was analyzed under the European RACE/RIPE consortium in 1992. RIPEMD is a ``very strong'' version of MD4 involving essentially two strengthened versions of MD4 running in parallel. It was designed to counter known two-round attacks on MD4 and MD5. However, more recent cryptanalytic work on MD4 by Vaudenay [md4-attack] and on RIPEMD by Dobbertin [ripemd-attack] suggests that both MD4 and (very likely) MD5 fail to be as resistent as previously believed to manipulations of their internal structures. As a result of this work, some European researchers now believe that collisions for MD4 and MD5 themselves (rather than just for their compression functions) may soon be found by similar techniques. ... ######################################################################### and from a private communication with Shahram Bakhtiari H. L. (3.2.95) ... Note: Psudocollision for MD5 that is proposed by two fellows, cannot find Psudocollision when one of the initial vectors is fixed (secret). They start from the middle point and sometimes can find two initial vectors (which only differ in 4 bits) for MD5. Therefore, if you fix the initial vector, they cannot find the other that collide with it. ... ######################################################################### just to remind myself and you, patient readers, why keyed-MD5 is being used in AH, and that it *might* be broken any day now. There are alternatives, and they were proposed. Oh well. Now, back to the issue of a single hash for two different (legal) names, and two different keys that are bound to it by cryptographic means. If the collision happens by accident, a user will experience denial of service, because the side in error will use the wrong DH public value. No way to fix that, collisions *may* always happen where a compression is involved. But if the collision can be willfully achieved for a man-in-the-middle attack (I remember somebody announcing that ONE collision has been achieved, I am sorry but I do not remember the details), SKIP is doomed. We can use another hashing algorithm, which is supposedly more secure. (e.g. SHA, Tandem Davis-Meyer, or MDx-MAC [crypto95]) What else could we do? Until we have no vastly better solution than MD5, I suggest staying with MD5! Comments anyone? > > For ESP transforms which combine encryption and authentication (for > > instance: Keyed MD5 with DES-CBC), only an ESP header is needed. > What is being specified ? Is it allowed to have both AH and ESP headers ? > Or It MUST only contain the ESP header, without AH header ? > What is the assigned algorithm number for this combined transform example, > Keyed MD5 with DES-CBC ? I suggest to forbid the existence of a separate Ah header, as the corresponding MAC Alg has been allocated for the combined transform. > > Nodes wishing to transmit/receive encrypted datagrams to multicast > > address M need to acquire the GIK Kg. This is done by sending an > > encrypted/authenticated request-to-join primitive to the group owner. > How will this be encrypted/authenticated ? Using unicast SKIP ? Yes. This is stated in the paragraph you quoted, just 3 lines below. [about missing sender/receiver ID fields] they are optional, and thus need not be present in all pictures. > In RFC1825 (Security Architecture), it states : > "Given two endpoints, it MUST be possible to have more than one > concurrent Security Association for communications between them." > Does this draft address this requirement ? It does not forbid this. And it allows user-dependant keying information. Additionally, 1825 is stated as a base for SKIP. I belive it is job of the implementor to be conformant to 1825. The draft suerely is, by not forbidding this. Additionally, implementations should produce a lot of syslog output in the case of conformance with 1825. Which will cause each garbled packet to be logged. sigh. > The Algorithm discovery message does not contain NSID nor Master Key-ID. > Will this allow different encryption algorithms to be used for > different Master Key-IDs ? or between two systems ? I see no need for multiple encryption algorithms between two machines at one point in time. Comments anybody? > Page 39, paragraph 2 > Suggestion : Spell out CRL on first use of acronym. YES! > Page 40, last paragraph > > "by-pass" channel for encryption. > Please explain that this means traffic between the two ports > are not encrypted. And not authenticated! > There are numerous places in the document referrring to things described > later. These can be made to explicit references. Here is a list : See my comments to (02). Thank you for backing my claim! I am sure this can be done when editorial changes are ellicited. Friendly greetings, Germano - -- <...cookie space for rent...> Germano Caronni caronni@tik.ee.ethz.ch http://www.tik.ee.ethz.ch/~caronni PGP-Key-ID:7B7AE5E1 gec@acm.org 997C6DC4AF930A5D2D5D6AEAA196C33B -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMJAqXrH8jId7euXhAQE/4wQAqgyYdQYhFq5LjhGpw7NLHBm76LXDh9xM ZML4X25yLqUml73+EBWCKuKLRX6yayz6ygEFYCZUOWjXdxpB6XqzpjOIfnigXEvc 3Roc5kC1PVkRhldFYrVbnZbRPmD4yQ6gL4aV5RTjRadG5WAZCxzHyOYOSWmfvCqi 4yKpc9kJrc4= =ySjx -----END PGP SIGNATURE----- From ipsec-request@ans.net Fri Oct 27 00:44:07 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13654 (5.65c/IDA-1.4.4 for ); Thu, 26 Oct 1995 20:48:40 -0400 Received: by interlock.ans.net id AA01005 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 26 Oct 1995 20:47:46 -0400 Message-Id: <199510270047.AA01005@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 26 Oct 1995 20:47:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 26 Oct 1995 20:47:46 -0400 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 26 Oct 1995 20:47:46 -0400 Subject: Re: SKIP: Fixes to certificate discovery protocol To: pingn@jurassic.eng.sun.com (Teodora Ngo) Date: Fri, 27 Oct 1995 01:44:07 +0100 (MET) Cc: ipsec@ans.net, skip-info@tik.ee.ethz.ch, markson@osmosys.incog.com, ashar@incog.com In-Reply-To: <199510260032.AA05276@interlock.ans.net> from "Teodora Ngo" at Oct 25, 95 05:29:02 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 1419 -----BEGIN PGP SIGNED MESSAGE----- Teodora Ngo wrote: > > > Master Key-ID - this is the identifier as described in the section on > > Master Key-IDs. It's length is dependent on the value > > of the NSID field. It is only used when requesting > > certificates with a specific master key-id from another > > entity. The requester may set this to zero (0) in which > > case the receiver should consider the request for ALL > > certificates. The responder should always set this > > field to zero (0). > > Suggestion : The responder should retain the same Master Key-ID so > one can match a certificate response to its certificate request. > There can be multiple outstanding certificate requests. I assume ?! that each certificate in the response contains its appropriate master ID. > There is only one Master Key-ID, Why do you need NSID with each certificate ? > Is the intent to associate each certificate with a Key-ID ? If so, > then you need both NSID and Master Key-ID with each certificate. Yeah! Now, is it in the certificate, or not ? /gec -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMJArVLH8jId7euXhAQGI2QP+JlCxnAYz3uiFRgS6CMTzyUNhjooKmP/C YDJjwv5MzgufEE0OR9BYW46b+MVyOmqS+/FvKcU2/FHBYdatLVB8L84c9Uz8Lc4n ftkRXAiVNtoyFL1EVHRELmKWyIS+vNC43+4OMtqD1QslQzc/mW3WaOv+RZ8zEbFh jjxlUjxFW0k= =kM0R -----END PGP SIGNATURE----- From ipsec-request@ans.net Fri Oct 27 07:03:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13795 (5.65c/IDA-1.4.4 for ); Fri, 27 Oct 1995 03:08:19 -0400 Received: by interlock.ans.net id AA05148 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 27 Oct 1995 03:03:44 -0400 Message-Id: <199510270703.AA05148@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 27 Oct 1995 03:03:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 27 Oct 1995 03:03:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 27 Oct 1995 03:03:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 27 Oct 1995 03:03:44 -0400 From: markson@osmosys.incog.com (Tom Markson) Subject: Re: SKIP: Fixes to certificate discovery protocol To: caronni@tik.ee.ethz.ch (Germano Caronni) Date: Fri, 27 Oct 1995 00:03:26 -0700 (PDT) Cc: ipsec@ans.net, skip-info@tik.ee.ethz.ch In-Reply-To: <199510270047.AA01005@interlock.ans.net> from "Germano Caronni" at Oct 27, 95 01:44:07 am X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Germano Caronni Wrote: > I assume ?! that each certificate in the response contains its appropriate > master ID. Yes. Since a certificate serves as a binding between a name and a public value, the name is present in the certificate. In the case of a hashed public key, the hash of the key IS the name, so it is inherently present. >> There is only one Master Key-ID, Why do you need NSID with each certificate ? > > Is the intent to associate each certificate with a Key-ID ? If so, > > then you need both NSID and Master Key-ID with each certificate. > > Yeah! Now, is it in the certificate, or not ? Master key-ids (Names) are present in the certificate as discussed above. Name spaces, however, are not present in current certificates (X509, PGP). Therefore, we need a way of providing this information. That's why the NSID is sent with each certificate. Warm Regards, --tom From ipsec-request@ans.net Fri Oct 27 12:13:20 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15207 (5.65c/IDA-1.4.4 for ); Fri, 27 Oct 1995 08:21:41 -0400 Received: by interlock.ans.net id AA07854 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 27 Oct 1995 08:13:52 -0400 Message-Id: <199510271213.AA07854@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 27 Oct 1995 08:13:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 27 Oct 1995 08:13:52 -0400 Subject: Re: comments on draft 03 of SKIP To: caronni@tik.ee.ethz.ch (Germano Caronni) Date: Fri, 27 Oct 1995 13:13:20 +0100 (MET) From: "Christian Schneider" Cc: pingn@jurassic.eng.sun.com, ipsec@ans.net, skip-info@tik.ee.ethz.ch, skip@tik.ee.ethz.ch, ashar@incog.com, markson@incog.com In-Reply-To: <199510270040.BAA00380@ktik6> from "Germano Caronni" at Oct 27, 95 01:40:01 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 2760 > > 2. There are two modes in ESP, tunnel mode and transport mode. > > This information is not on the SKIP header. How does an > > intermediate node which is encrypting/decrypting SKIP packets > > for multiple machines know whether the entire IP datagram is > > encrypted or only the upper-layer protocol ? > > a) does it matter? Yes. You have to either append the original IP header or use the IP header from inside the ESP payload to forward the packet. So you have to know, haven't you? > b) by looking at the next protocol field. But not all ESP transforms contain a next protocol field (namely the ones using the PKCS #7 padding scheme), right? The whole padding stuff is unnecesserally complicated IMHO. One padding scheme should be sufficient. I generally dislike the PKCS padding and I don't like the RFC 1829 having its padding and especially the payload type after the payload. This makes it necessary to decrypt the payload prior to being able to decide whether tunnel or transport mode is used and has some negative effects on efficient implementations. My proposition would be to adopt the AH scheme, i.e. start with Next Header and Length fields (meaning payload type and padding len). Something like: +---------------+---------------+---------------+---------------+ | Security Parameters Index | +---------------+---------------+---------------+---------------+ | Next Header | Length | RESERVED (or remove this) | +---------------+---------------+---------------+---------------+ | IV | +---------------------------------------------------------------+ | Payload Data (padded) | +---------------------------------------------------------------+ > > 3. Why is sequencing dropped in draft 3 ? The n counter provides > > That is a *very* good question. I would like to see this feature back, Probably because the proposed sequencing does not work. A working yet has to be proposed I think. > > The Algorithm discovery message does not contain NSID nor Master Key-ID. > > Will this allow different encryption algorithms to be used for > > different Master Key-IDs ? or between two systems ? > > I see no need for multiple encryption algorithms between two machines at one > point in time. There are some pointers towards user-oriented Master-Keys propagated from upper level protocols (Social Security Number et altera). This suggests being able to send Master Key-IDs with an ICMP message, wrong? - Chris -- Chris Schneider - cschneid@amiga.icu.net.ch BIX: hschneider IRC: cschneid Computers are not intelligent. They only think they are. From ipsec-request@ans.net Fri Oct 27 14:48:12 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04232 (5.65c/IDA-1.4.4 for ); Fri, 27 Oct 1995 11:04:12 -0400 Received: by interlock.ans.net id AA12548 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 27 Oct 1995 10:56:29 -0400 Message-Id: <199510271456.AA12548@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 27 Oct 1995 10:56:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 27 Oct 1995 10:56:29 -0400 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 27 Oct 1995 10:56:29 -0400 Subject: Re: comments on draft 03 of SKIP To: skip@tik.ee.ethz.ch (SKIP Software), skip-info@tik.ee.ethz.ch Date: Fri, 27 Oct 1995 15:48:12 +0100 (MET) Cc: pingn@jurassic.eng.sun.com, markson@incog.com, aziz@incog.com X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 2627 Christian Schneider wrote: > > > This information is not on the SKIP header. How does an > > > intermediate node which is encrypting/decrypting SKIP packets > > > for multiple machines know whether the entire IP datagram is > > > encrypted or only the upper-layer protocol ? > > a) does it matter? > Yes. You have to either append the original IP header or use the IP header > from inside the ESP payload to forward the packet. So you have to know, > haven't you? If the IP header destination address points to the intermediate node, then it *has* to process the packet. By doing this, it can look at the Master Key-ID. If there is none, then the .... [hesitate] ... You are perfectly right. It matters. This demands that each final transform owns a next-protocol field, which I assume each transform defined as an RFC will have. > But not all ESP transforms contain a next protocol field (namely the ones > using the PKCS #7 padding scheme), right? We will have to change our internal SKIP ESP transforms to *have* an next protocol field. > The whole padding stuff is unnecesserally complicated IMHO. One padding scheme > should be sufficient. I agree. But we will not see a change to the padding scheme in RFC 1829 in the next few years, I believe. ;-) > My proposition would be to adopt the AH scheme, i.e. start with Next > Header and Length fields (meaning payload type and padding len). Any comments from other SKIP implementors? Perhaps you want to fix the 'correct' behaviour for the SKIP internal algorithms, as proposed in my comments to (02)? > > > > > 3. Why is sequencing dropped in draft 3 ? The n counter provides > > That is a *very* good question. I would like to see this feature back, > Probably because the proposed sequencing does not work. A working yet has > to be proposed I think. What were the problems with the sequencing as proposed? I thought using a true counter would be okay, as long as a) the counter resets when Kp changes b) Kp changes frequently enough to recover from deadlocks c) No Kp is reused before 'n' is updated. Comments? > > I see no need for multiple encryption algorithms between two machines at one > > point in time. > There are some pointers towards user-oriented Master-Keys propagated from > upper level protocols (Social Security Number et altera). This suggests > being able to send Master Key-IDs with an ICMP message, wrong? I do not believe so. The ICMP message is used only to coordinate algorithm usage between two machines. The UDP certificate discovery? protocol is used to get the key partaining to a Master Key-ID. Germano From ipsec-request@ans.net Fri Oct 27 17:32:01 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15345 (5.65c/IDA-1.4.4 for ); Fri, 27 Oct 1995 13:46:01 -0400 Received: by interlock.ans.net id AA16746 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 27 Oct 1995 13:38:59 -0400 Message-Id: <199510271738.AA16746@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 27 Oct 1995 13:38:59 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 27 Oct 1995 13:38:59 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 27 Oct 1995 13:38:59 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 27 Oct 1995 13:38:59 -0400 X-Sender: cds@denver.ssds.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 1995 12:32:01 -0500 To: Germano Caronni , pingn@jurassic.eng.sun.com (Teodora Ngo) From: "Chris Liljenstolpe (Swanson)" Subject: Re: comments on draft 03 of SKIP Cc: ipsec@ans.net, skip-info@tik.ee.ethz.ch, skip@tik.ee.ethz.ch (SKIP Software), ashar@incog.com, markson@incog.com -----BEGIN PGP SIGNED MESSAGE----- At 01:40 95/10/27 +0100, Germano Caronni wrote: > >Teodora Ngo wrote: >> Subject: comments on draft 03 of SKIP > [Stuff Deleted] >> > Since there is nothing secret about DH public values, one natural way >> > to discover the relevant authenticated _public value_ is to distribute >> > these using a directory service. >> authenticated directory service ? >> Does this require a secure directory or naming service ? > >no authenticated _directory service_ is needed here. I disagree with this. If I am receiving public keys from some directory service that I have decided to trust (I think that they take proper authentication actions, etc), I want to know that I am really talking to that directory service and not some mitm or imposter. Regards, -=Chris [Stuff Deleted] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMJEXS8K+xPnoVGvVAQG53wP9ES/3YL/taMVoClzkuLLb9BDZKiRpLlSt MxLUtqnL6v5xU0EQMdgBWPKaico2OFb/utvVyx6Xl/92T+tMsUR2+oqqE0Nhe+B3 KMDvt8BHj2T0lhDQUPsKWbY95LWjN8yf2E7VCJgW1goFu6xdwwaICKJnC1ffDR0v wa3J+6y0cB0= =1kLl -----END PGP SIGNATURE----- / Chris Liljenstolpe (Swanson) ____/ ____/ ___ / ____/ Engineer ____ / ____ / /__/ / ____ / 8400 Normandale Lake Blvd #993 _______/ _______/ _______/ _______/ Bloomington, MN 55473 business driven technology solutions. (612) 921-2392 FAX (612) 921-2395 Key Fingerprint = FE 43 BD A6 3C 13 6C DB 89 B3 E4 A1 BF 6D 2A A9 Um Yah Yah! From ipsec-request@ans.net Fri Oct 27 23:00:58 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10963 (5.65c/IDA-1.4.4 for ); Fri, 27 Oct 1995 19:05:58 -0400 Received: by interlock.ans.net id AA25324 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 27 Oct 1995 19:01:26 -0400 Message-Id: <199510272301.AA25324@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 27 Oct 1995 19:01:26 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 27 Oct 1995 19:01:26 -0400 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 27 Oct 1995 19:01:26 -0400 Subject: Re: comments on draft 03 of SKIP To: chris.swanson@ssds.com (Chris Liljenstolpe) Date: Sat, 28 Oct 1995 00:00:58 +0100 (MET) Cc: pingn@jurassic.eng.sun.com, ipsec@ans.net, skip-info@tik.ee.ethz.ch, skip@tik.ee.ethz.ch, ashar@incog.com, markson@incog.com In-Reply-To: <199510271738.AA16746@interlock.ans.net> from "Chris Liljenstolpe" at Oct 27, 95 12:32:01 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 864 Chris Liljenstolpe wrote: > >> > Since there is nothing secret about DH public values, one natural way > >> > to discover the relevant authenticated _public value_ is to distribute > >> > these using a directory service. > >> authenticated directory service ? > >no authenticated _directory service_ is needed here. > I disagree with this. If I am receiving public keys from some directory > service that I have decided to trust (I think that they take proper > authentication actions, etc), I want to know that I am really talking to > that directory service and not some mitm or imposter. Hi Chris, I thought we were talking about authenticated public values. I do not mind who sends me the values, as long as I can trust one of the parties that authenticated them, and I securely get the public key of such a party. Did I oversee something? Germano From ipsec-request@ans.net Sat Oct 28 02:46:09 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13669 (5.65c/IDA-1.4.4 for ); Fri, 27 Oct 1995 22:53:14 -0400 Received: by interlock.ans.net id AA29325 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 27 Oct 1995 22:46:43 -0400 Message-Id: <199510280246.AA29325@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 27 Oct 1995 22:46:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 27 Oct 1995 22:46:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 27 Oct 1995 22:46:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 27 Oct 1995 22:46:43 -0400 X-Sender: cds@denver.ssds.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Oct 1995 21:46:09 -0500 To: Germano Caronni From: "Chris Liljenstolpe (Swanson)" Subject: Re: comments on draft 03 of SKIP Cc: pingn@jurassic.eng.sun.com, ipsec@ans.net, skip-info@tik.ee.ethz.ch, skip@tik.ee.ethz.ch, ashar@incog.com, markson@incog.com Greetings, I guess I mis-understood. I mistook the directory service for the CA. The CA's signature needs to be authenticated, not the Directory/Distribution service - you are correct. Regards, -=Chris At 00:00 95/10/28 +0100, Germano Caronni wrote: >Chris Liljenstolpe wrote: >> >> > Since there is nothing secret about DH public values, one natural way >> >> > to discover the relevant authenticated _public value_ is to distribute >> >> > these using a directory service. >> >> authenticated directory service ? >> >no authenticated _directory service_ is needed here. >> I disagree with this. If I am receiving public keys from some directory >> service that I have decided to trust (I think that they take proper >> authentication actions, etc), I want to know that I am really talking to >> that directory service and not some mitm or imposter. > >Hi Chris, >I thought we were talking about authenticated public values. I do not mind >who sends me the values, as long as I can trust one of the parties that >authenticated them, and I securely get the public key of such a party. > >Did I oversee something? > >Germano > > / Chris Liljenstolpe (Swanson) ____/ ____/ ___ / ____/ Engineer ____ / ____ / /__/ / ____ / 8400 Normandale Lake Blvd #993 _______/ _______/ _______/ _______/ Bloomington, MN 55473 business driven technology solutions. (612) 921-2392 FAX (612) 921-2395 Key Fingerprint = FE 43 BD A6 3C 13 6C DB 89 B3 E4 A1 BF 6D 2A A9 Um Yah Yah! From ipsec-request@ans.net Tue Oct 31 09:48:53 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13600 (5.65c/IDA-1.4.4 for ); Tue, 31 Oct 1995 05:32:16 -0500 Received: by interlock.ans.net id AA10116 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 31 Oct 1995 05:12:35 -0500 Message-Id: <199510311012.AA10116@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 31 Oct 1995 05:12:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 31 Oct 1995 05:12:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 31 Oct 1995 05:12:35 -0500 Date: Tue, 31 Oct 1995 09:48:53 +0000 (GMT) From: Xavier Gosselin Subject: key management information To: ipsec@ans.net Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I'm sorry if it's not really the topic of the discussion, but here I can reach the people who may know what I need. I'm looking for information on key management in general and in the IP suite. - documents - links to web or anonym. ftp - anything interesting ?!?!?! Thanks for any help. Xavier. --------------------------------------------------- | Xavier Gosselin | Staffordshire University -UK | - - - - - - - - - - - - - - - - - - - - - - - - - - | E-mail : cm2bcxg@bs47c.staffs.ac.uk | --------------------------------------------------- From ipsec-request@ans.net Tue Oct 31 17:24:17 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13664 (5.65c/IDA-1.4.4 for ); Tue, 31 Oct 1995 12:31:25 -0500 Received: by interlock.ans.net id AA18224 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 31 Oct 1995 12:24:42 -0500 Message-Id: <199510311724.AA18224@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 31 Oct 1995 12:24:42 -0500 From: Ran Atkinson Date: Tue, 31 Oct 1995 12:24:17 -0500 Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: ipsec@ans.net Subject: naming Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rja@bodhi.cs.nrl.navy.mil It seems to me that there are two kinds of naming that need to be supported. There are probably several mechanisms that could be used to support such certificates. The first kind of naming is a simple host-to-host mapping (probably using fully qualified domain names or using IP addresses to distinguish entities). Signed host-keys from the DNS are an example of a practical way to handle this case. The second kind of naming is a user-to-user mapping (probably using Internet mailbox names -- user@host.domain initially, though other forms might also be used). I, for one, do not believe that it is a requirement that a single user certificate support all of the possible mailboxes of a user. That would be "nice" to have and I'd be interested if a specific scalable approach were proposed, but it isn't required IMHO. PGP certificates meet my minimum requirements, for example. It is conceivable that one might want to use a user certificate for one party to a session but use a host certificate for the other party to the session. I suspect that none of this is unique to Photuris, though it does seem to apply to Photuris. I want to avoid going down any road that would _require_ us to use X.509 though I don't have any problem with making that an option that mutually consenting parties could use if they wished to do so. Ran rja@cs.nrl.navy.mil