From msec-admin@securemulticast.org Tue Sep 3 07:35:42 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22139 for ; Tue, 3 Sep 2002 07:35:41 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CF9715374F; Tue, 3 Sep 2002 07:32:52 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5538B5375C for ; Tue, 3 Sep 2002 07:31:52 -0400 (EDT) Received: (qmail 45226 invoked by uid 3269); 3 Sep 2002 11:35:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 45222 invoked from network); 3 Sep 2002 11:35:44 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 3 Sep 2002 11:35:44 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21992; Tue, 3 Sep 2002 07:34:07 -0400 (EDT) Message-Id: <200209031134.HAA21992@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-mikey-dhhmac-00.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 03 Sep 2002 07:34:07 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : HMAC-authenticated Diffie-Hellman for MIKEY Author(s) : M. Euchner Filename : draft-ietf-msec-mikey-dhhmac-00.txt Pages : 18 Date : 2002-8-30 This document describes a point-to-point key management protocol variant for the multimedia Internet keying (MIKEY). In particular, the classic Diffie-Hellman key agreement protocol is used for key establishment in conjunction with a keyed hash (HMAC-SHA1) for achieving mutual authentication and message integrity of the key management messages exchanged. This MIKEY variant is called the HMAC-authenticated Diffie-Hellmann (DH-HMAC). It addresses the security and performance constraints of multimedia key management in MIKEY. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-dhhmac-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-mikey-dhhmac-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-mikey-dhhmac-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-8-30145224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-mikey-dhhmac-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-mikey-dhhmac-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-30145224.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Sep 3 07:38:31 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22275 for ; Tue, 3 Sep 2002 07:38:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9CC3253728; Tue, 3 Sep 2002 07:35:42 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id CE7345355C for ; Tue, 3 Sep 2002 07:32:12 -0400 (EDT) Received: (qmail 45269 invoked by uid 3269); 3 Sep 2002 11:36:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 45264 invoked from network); 3 Sep 2002 11:36:04 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 3 Sep 2002 11:36:04 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22057; Tue, 3 Sep 2002 07:34:29 -0400 (EDT) Message-Id: <200209031134.HAA22057@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-mikey-04.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 03 Sep 2002 07:34:27 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : MIKEY: Multimedia Internet KEYing Author(s) : J. Arkko et al. Filename : draft-ietf-msec-mikey-04.txt Pages : 53 Date : 2002-8-29 Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. Such a solution has to be suitable to be used in the context of conversational multimedia in a heterogeneous environment. This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication), and shows how it may work together with protocols such as SIP and RTSP. In particular, its use to support the Secure Real-time Transport Protocol, [SRTP], is described in detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-mikey-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-mikey-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-8-29142328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-mikey-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-mikey-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-29142328.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Sep 5 03:54:56 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12266 for ; Thu, 5 Sep 2002 03:54:55 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5D48D53909; Thu, 5 Sep 2002 03:52:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C4C585376C for ; Thu, 5 Sep 2002 03:51:26 -0400 (EDT) Received: (qmail 81302 invoked by uid 3269); 5 Sep 2002 07:55:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81299 invoked from network); 5 Sep 2002 07:55:23 -0000 Received: from relay1.clb.oleane.net (213.56.31.21) by klesh.pair.com with SMTP; 5 Sep 2002 07:55:23 -0000 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by relay1.clb.oleane.net with SMTP id g857spBa019125 for ; Thu, 5 Sep 2002 09:54:51 +0200 Message-ID: <00b901c254b1$d02ab6c0$0701a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00B5_01C254C2.935F9A60"; type="multipart/alternative" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [MSEC] "Deploying IPv6 Networks" and "IPsec Global Summit" conferences Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 5 Sep 2002 09:56:59 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_00B5_01C254C2.935F9A60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00B6_01C254C2.935F9A60" ------=_NextPart_001_00B6_01C254C2.935F9A60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 The "Deploying IPv6 Networks" and "IPsec Global Summit" conferences will = be held at the same time at La D=E9fense Paris, from December 3 to 6, = 2002. This is the second consecutive year that "Deploying IPv6 Networks" is = being organized and over the past four years "IPsec Global Summit" has = earned its place as THE major event for IP network security protocol = specialists.=20 These two major events will gather an impressive panel of specialists = and deliver a lot of instructive case studies of IPsec developments and = IPv6 live networks. A half-day joint session on security has been programmed for the two = sets of delegates. The complementary aspects of these two subjects has prompted Upper Side = to promote Special Offers:=20 Take advantage of a 20% discount on delegate's registration fees until = the 21st of September=20 For each person who signs up for one conference, a second may register = for the second conference at a 50% discount.=20 For each IPsec or IPv6 registration, you may get the proceedings of the = IPv6 or IPsec conference for an additional cost of 100 USD/euros. Get all details at: http://www.upperside.fr/ipsec02/ipv6etipsec.htm ------=_NextPart_001_00B6_01C254C2.935F9A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
 
The "Deploying IPv6 Networks" = and=20 "IPsec Global Summit" conferences will be held at the = same time=20 at La D=E9fense Paris, from December 3 to 6, 2002.
 
This is the second consecutive year that = "Deploying IPv6=20 Networks" is being organized and over the past four years "IPsec Global = Summit"=20 has earned its place as THE major event for IP network security protocol = specialists.
 
These two major events will gather an impressive = panel of=20 specialists and deliver a lot of instructive case studies of IPsec = developments=20 and IPv6 live networks.
A half-day joint session on security has been = programmed=20 for the two sets of delegates.
 
The complementary aspects of these two subjects = has=20 prompted Upper Side to promote Special Offers:
Take advantage of a 20% discount on delegate's=20 registration fees until the 21st of September
For each person who signs up for one conference, = a second=20 may register for the second conference at a 50% discount.
For each IPsec or IPv6 registration, you may get = the=20 proceedings of the IPv6 or IPsec conference for an additional cost of = 100=20 USD/euros.
 
Get all details at: http://www.upper= side.fr/ipsec02/ipv6etipsec.htm
 
------=_NextPart_001_00B6_01C254C2.935F9A60-- ------=_NextPart_000_00B5_01C254C2.935F9A60 Content-Type: image/jpeg; name="pieddepagecomun.jpg" Content-Transfer-Encoding: base64 Content-ID: <00b401c254b1$cfd6ca60$0701a8c0@oleane.com> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAMgAA/+4AIUFkb2JlAGTAAAAAAQMA EAMDBgkAAAlfAAAUigAAHcj/2wCEAAgGBgYGBggGBggMCAcIDA4KCAgKDhANDQ4NDRARDA4NDQ4M EQ8SExQTEg8YGBoaGBgjIiIiIycnJycnJycnJycBCQgICQoJCwkJCw4LDQsOEQ4ODg4REw0NDg0N ExgRDw8PDxEYFhcUFBQXFhoaGBgaGiEhICEhJycnJycnJycnJ//CABEIAFoCvAMBIgACEQEDEQH/ xAD3AAEAAQUBAQAAAAAAAAAAAAAABAEDBQYHAggBAQEBAQEBAAAAAAAAAAAAAAABAgMEBRAAAQQB AwMDBAEFAQAAAAAAAQACAwQFERIVExQGUCEWEEBgMSIgMEE0BzMRAAIABAIGBgYECQkJAAAAAAEC ABESAyExQVHRIjITcZGh0jMEYYGxQlKiYCOjBRBikrLic+MUNCDB4XLCY4Oz00BQ8PGCU5MkNRIA AQMCAwcFAAAAAAAAAAAAAAERMRAhUFGBIEBgcGGh4XGR0QJSEwEAAgICAQIFBAIDAAAAAAABABEh MUFhUYHREPBxkaEgUGCxQOEwwfH/2gAMAwEAAhEDEQAAANyi4rRZmdrvOugW9Pv6ziXPoed+een7 13zx7Y2ApWhUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHCPnv6P1fheZdmzmW4ObZXK6J7Oe 7S9My2uvf3M4m3V3GJB19xfpEmwIjlZaF5ieheSege6mIfknI1knvMKyei+ZZjG34lolKmIcywNQ AAAAAAAAAAAAAAAAAAAAAAAADgOLwuS5Tc5ULJ4xqOF391mm5qXP9Pv061sly659c6JW3mPUcHan PqHnQ3n8+/V5+N+9c/ob775+N99aAOg+NBHRbGgq6B656jfLvPh0K1oQ6Bf5wro7nCzo7nFToznI 6O5zU6K51U6JXndTobnvo6C5/U6A0H0b7XQvRvddF9G810j0brXS/ZuVdO9m311H2bZXVfZtHrWL hsldd9mw1wNyM36wtwy/rFXDJesdcJ3qH7JVY/svVt1Ljz6PnSb03XrnAY/dPVxrkrMROdwe0YLY OH043nO4znq6mzmdUyuwePRx8yZMnt5sb4ydgiW87BIF67NMPcplDCypONJKz7Pa1HJq3kTDpV8x 1ZlCzdnyY1uZkMRV9WyKZSIeXjyXl2Oe7Wbixjb/AKjVIWfR693rIiZvFl5GsmQQxNri82WIuYiR RjrlTqwbRlETMRDrLEWskR63xZXharcHivoea1FFQpUUVFKeqHM8xjM1j2TVqbzxcpet9OaFmMRr GwC5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUqOeT9hsZ74y3l1xjrWWamNmX5ySxMgAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf//aAAgBAgABBQH6/wCPSHPDUZNUxj3LY4HaVtK0K3Bb mrcFuC3BbhpqFuC3NW4IEH7t0Yci0JjyFuWq3Jx9toW0LaFtC2hbQtAtAtoW0LQfd+y1RATw9HqA ayJhJ9Jd9R6SdF7ekf/aAAgBAwABBQE/T3Xv6ToiEdEAVtK0K0Wi0K0K0K0K0Wi0K0K0+810WqKH 1f8ArU/XUrUrX66la/eELatENF7LVqedR6SfofSf5L39I//aAAgBAQABBQHyjK36F3vcqst5jk6s o838mJrZXOCsMnmnI380xvjuSuW504kD8O83DnZPO5V9FiwWMcrctbHo5u+4T5/Il3gdnuZ/xD/o Nh9S0975X4uiLcsGTxzWiHDQv7yhE+3hq/klDxXCSYO3+IebxsmyVHGY5+TrV69bHNrxtkNmPbZz rzJVntur4OxbxL3eWOan+ZuY356U3zguHz464jJ8rUMkhf1jubajce7Yu5HUFuMyttse0WYyuv8A xFppjimbMpLBZKCHCCZ8wbO1xZaheTdiAM4XXGgsJlmOT1by3IRT5HH2yb8UTXq5JJ2l+tZdDl6x cqEZ7d8f8S0p8GsbahLpItUYekvHMnBSpuzOPceYx2ozOOaGZrHsRzOP3DNY8EZjHAHM44uGXxwX M4/RmboRl2YxryM9SaGZnHxoZnHA83QC5fGoZrHhHN48oZjHBczjgfkFNfIKa+QU18gpr5BTXyCm ufprn6a5+mufprn6a5+mueqLnqi56oudqLnai52oucqrnKq5uqubqrmqq5qsuZrLmKy5isuXrrl6 65auuVgXKQLk4FycK5KFcjCuQiXfxLvol3sa7yNd0xdyxdwxddq6zV1WrqBbwt4W5arVeWvdG/Cz zQ1IrdZybHBOpKj2uMcD214GhnQ9pKxBir7kYA4vrNjDq/8AKAbX+vj+3/0SrDA6rbeInQdcdrPX MNqRosWacFTEzGWjucU4PJDmBFzIzLs6Ta4e7G4yq9z6OGjcMTjSDiMaAzF4uVrsVjGNjxuJlUmN xMKGJxrgcbiQ92KxjGsoYeR3D45cPjlw+OXD45cPjlw+OXD45Oo4Vrn0MNG51DDMRoYZrWYvFSt4 fHI0sKH8PjlxGOXEY5SY3FRCPHYmVcRjlxGOXE49cTj1xOPUmOxcQjoYqVcVQXFUFxdBcbjt3F0V xtAJlfESHjaS42kuOpLjqa4+muPqLsKi6WN39jVXZVV2VZdnWXaV12lddrAu2gXbwrt4V0Il0Y10 o10mLpsWxq2tW0LQLQLT6ZzA1M0h4xE1fHWhfHgvjwVnxWC1HVqtrQxxNkd2sZHaSNRx8khNGdzG QTtdQ/8AexFYkUQlYrEDp1XisVoZWCSKCKZs1uvPNJXZMyJ9OxutROnqmOxLLDj5Y4zReYW0XdOS hO8cdN0zQMkVOA1oJoLckpisNkir2K7uhbZXqxOhiazaTE7umUZAm1rAUOOdHYswOnUtJz0ak5L6 Mr4eyaxtem+J7mbjZgdOpKbnB9CWVgpSCOnUkryyMnFixXsWVo90TYLJhrU3wzMxnTx/Yucx9Kdz OPnMFePpRsZsEEDon18c6CZtSy0spSxmGk+NlGq6s37LRaLRaIj2ZAXyNre3TEUQrgsYCYxAdIRq af8As/h5/TGHWFugezcme0UHs1zzIY2taqn+1+Hn9GGzDKyzM0d7Lp3Uq76bb3cqZdmYaIkMn4hJ +/6ovwv/2gAIAQICBj8Bpa51wnRyW8DEvsydiaOJ1JJpbe9BHSLiLk/qr57MEEEEDNSCCN8vTIVv 0ns1xkVVnxf7OLM2iH+C76s/bhW+E//aAAgBAwIGPwHD44Y05A//2gAIAQEBBj8B+6vL+TvclPNP cW8aVYyFEpVhpcRjd89c/Is/6cfu/kfPG46eLcZLRWfwrJIkPNAk5DlW+7Ct53zxHmGxKJbsyX0G aHGN3zrfkWv9OKn+8GH+Ha/0481a83f54RbRSaqsqjcnwBfhH4MPof8AcYXMvdl9lB8hYf8A9hx9 c49wH3R6T+AeduLMnwFP5+yKvPXaWOK2hvOfVtifkPu56dD3JnsEvbBTzNsKdKyKntjzz4iQsgz/ AMT6I/dPmbfHaN5lnr+rhrlw1OxmzHSTDXL0x5WxSbxGmo0qgnLFjAWxbuE4W1KoJglat0T90QPN JzL128vON1/rGAkza85IThAW+zhj8SnUrYyOpp9cC5aZbVy2xVLrLiJZqaScI81ZuXheN1LTgqCJ Y3Rp+iP3LburUjNeDKdPhx5+0/lUdLaWjbQjAEgky6YSflrXlnusvNtKs1mf62qG4A1NZcCWHTDv btW7dm2s7t5hIKraMMyfhGcNybck1uTWfSZHCNy6UDruhWcU9AqlF655m83nmuhADcYikJVrrzqj +DB/xf2cFv3GcsfF/Zx/877b9nBY+QkBp537OJD7u+2/ZwPMm1yTUVoqqy9Mlh1QDclmdcUcti1I ZgKcKp6SRqhBiK1DAn04AdMW5KSbgmo3R6NJGuDaCmsSmJrpE9LRypGdRT3cx6Jz0aoZgppQEsZr o9AaeiBKeIJ6KZTB64Lm2yrSXmZZDoJg3aTSNM1PsYwadHpB/NJjlgD0kmWOqeuWMBhiDiDAaQA0 jGfshlkZpxg6P+cWwjTNzIAiYwnjCmR30FwcIwPSwxhpKzUgMZSyMzpI1QpZWWoEicsgJ6CYWdtl r4SadVWgmEpnN9BzGFWPq/3t90XLdu4eU10lZCZ4MgD6I855kWbgS8lsJMAHcmpzOuATg8s2M/bD eWQGt1o5uEqPexnPKPL+R8qxCWwLrkZvdfT6hlHlwN9/L2VtX72dbiZz005Ti30fhbojUBmYpUbo yEfjnsjk3VckMTugaekiCxt3pnOWHscRPl3hIBd3DAZDB/TEhauSpoyGQ0YtC02ropFK4DL8qC9F 4E5yMssMg8Ai1dmCW0ZnP3oK8u9SZgieGOeFcVcq5VKmchlq4oly7x3SmJngcxi/oimi/Lp1Y4b8 ErbuzbMnHLpcwxa1dNXENB0YiuWiAoS7IdB9rQKUvCWQnh1VxMWrs8ccNOc97GE+ru/V8GAwwl8W qABbvClQgkZboyGDwQLVzEBTgMhl70Cdq5uiQwGWXxQPq727lMz9Gl4Q8q5O2JIZDLL4o4LvUvej gu9S96OC71L3o4LvUvejgu9S96OC71L3o4LvUvejgu9S96OC71L3o4LvUvejgu9S96OC71L3o4Lv Uvejw7vUvejw7vUvejgudS96OC51L3o4LnUvejgudS96OC51L3o4LnUvejgudS96OC51DvRwXOod 6OC51DvRwXOod6OC51DvRwXOod6OC51DbHA/UNscD9Q2xwP1DbHA/UNscD9Q2xwv1DbHC/UNscL9 m2OFuzbHC3Ztjhbs2xwt2bY4W7NsZN/x64yMZGMjGRjI/wAryboaWHMkR/0QjXgztcPMLMJ5mYje NPqMblxvUI43p+HIdkUOnoEhKKVyDOB6mMS/BI+uKVG7E5CrRGIi4Pxtn0L+7hYSmrnTz/u9cJZp FKKFHqEowIUxUt2cfWCqLnnLoAW2J9J0AdMW77cTrWRo3m/pgBAOk/0QFYCZnlqiQVqQTMygCgs2 gCK2RgzYS0xIKQc8dUX+fbqYXJTmRoGowVuKoIxIqbDpxiYszByNTbYmbMh/WbbAe3bDKcmDNL2w Xe1JVE2JZsAPXB5dsNLPefbAN1As8pu22ARamDiCGbbAtFF5hyStp9VUF3tUqomxLNgBmc4oRVLf DW0+qceD8zbY8H5m2x4PzNtjwfmbbHg/M22PB+ZtseD8zbYKMqhgZEVtgTrx9MFXUBhmKm2wAyjE VDfbI5HOFcqtL8BrbHoxiu3bDLrDNow1x4PzNtjllRX8NTdGuPB+ZtseD8zbY8H5m2wGuWwoJkJs 2fXB5aBqc5M2HbHg/M22PB+ZtseD8zbY8H5m2x4PzNtgNcthQTITZs+uDy0DU5yZsO2PB7W2x4Pa 22PB7W2xRyxVKcqmy648LtbbE+V2ttgKlJLcIqOOnDHGPC7Ttjwu07Y8LtO2PC7Ttjwu07Y8PtO2 PD7TtijCoGREznqjw+07Y8PtO2PD7Ttjg7THB2mODtMcHtjg9scPtjhjhjhjKMoyjKMv5VlvNBp2 KuXSZcUp/mxhcu/lDZHjXesd2PGu9Y7seLd617sC1fe66LiFqkJ+oCP3e3w2y1sT1K5H80LUAUGj 0wRaULrIjBVB0GpvZAICuJe8SPZCzorUzljKUVXaKQJUpPPXjHmv1v8AZWHRFShhxVsjZSxkrTEJ bYAqEFTj4hISA1QoD0qMWWUw2qcC2ZXGrJMsJKzEk9sPbIqDAiUys56JjERWZrbpIKG41ybTEjvZ SxhWtkSQbm8VKv8AFgrTw0GKb7BnBO8uAlow0dEXjbMjceoXOa4lkMUApMpRfsJINctsizymwIxi 01xURbTV7rFiTSVliqyzi6hS3U6uBdmJiqeq2p06TF62tmzZNyy1oMhOJYS3t1cI5bIibysXQirA z9y3by0R5gm4He/aFuo4CYJ0YyEjF9ALa80WwBMe4xbGm2o0/CYt2ilu3TcDsVpMwARly1WeOqBa aU5sZjLEzyAEuiG3bfJmGVKiKiJb1yS45ZTi+baoy3pHeYqRuhdCtqgMgR/qbVozYrjbrxwVs6ot W7PL5izrcnET/wC2aT2iKHABmTuktmZzLNIkmCZk1GeJn1Qt7CkW2T0zJU/zRbHKshkuBzeB3yA1 XwaemFtkJQt971dRnJnZ5U0/ja4W+SDK5duECQ4y1O9TUcGxBMWqWpoesnTKRGGeuCFeYuS5xuTa YXhWS04Y44xZN1bfmOUrp9ZMTqKUtir4yWDbFCE+XuWAoJpDPKUpjKLYtAAq6u7SVSQJ/AoGmLZN mzNGYm8CazMN+KNekwpmRTqMuuLVLU0PWTplIjDPXBCPPmS5zXN6arkshTgZ4xZt3XU8mqTyDTEp LNXDZdMW13dyxdskT95yhGIUYbuqCxCKhWmS0znPDht24F60qsKKCGYrpnoVoWbLbCiYzY1/EODh 0RS8uYVk0sp+iLHl7gtqtrlkurEn6uRwBVc5a4e46W2quXHD4VAOzMJfVznI/FH7uKDfNtUZ5KMp TEwk5YaRFtCiW6bgdmQyY4MPcS3iJ4ReVytw3HRgThggA3t1hPDVKGtfV43VuBd2UgADOVoDR8MB Cip6EyPpwVMfVBEyZme8ZxddnO+5YLokfVnC3pqSDcJGAxYmW8FmcDph3LoTeUi6JEYkbpnMzpyy GEWgHnbtqRSc1JWndOqAnJsoRaNs3EJqJIAx3V1RS9u2DKVayn0btu3h/tF0/wB7d/zGiQ9cDPGO ac9UGniEEuSIpM5R5r9b/ZX6I3Gnndu/5jRrMAnIQfVDMcokMBEgZnTHm/1v9hfoi9VoOC7su/LB nLDCn0x/DD/yfoRT+6/afoR/DfafoRR+6yH6z9CP4b7T9CJjy32n6EXrtxaOa9VIM5boXOQ1fRHR Hux7se7Hux7se7Gj6F//2gAIAQIDAT8QenPiBxFD+ziAXVOlftLiItaPrUoLgtA/LV3EkOt9eL9p iqDOJ0TriRaT6m607Jiunz/7O/n7vEHzTM7+L06iIthaIkjnT0mnDOD+oNq07fx5gFqzr/LQWlcN 1i7ly0DpjGIribJTZu+yIW/MruVgPqnLT7QGqGOp0vOuZw0+06X2mGwrxWJdVhjWNSrQ+0B0D0iu UfaAaA+kqVKlSpUqVKlSv8AxaW8QRgbPCRWTLqPbkGjNY+BHcplOTScuGRiNj9Bj199oMmq/UY8P 1es9Z6z1/T6/D1nr8PWevx9Z6z1+HrPX/lW8wgEG/wBp+RcPGvzMdfmcY/Zv/9oACAEDAwE/ELWB FolrqGWdftJb+oGLL1+Yq2kpYp6zonVFGyW+WdU6uL9J1Tq6lrqskFS+Nzo1OqW8REwlf5axjzBF 07KmQnmvSocH0lSoK9c7GW+WW+WdjOx+8td23LfO5b5Z2Mt5Yq7/AMtGqloPmYj5XC28a+cRKsn5 3BweT9pBozxLHPMttqK7/aXE1XwFxvn9m//aAAgBAQMBPxCvuRKLnGpBRBS6JT7MQmDGBtOW4OeF AqrwThmxgDrMhzF6rureNVDdMSiUmkgc9fJ8ACLbB5wuf0X/AAvSHf1XHLGjyLZwX2Pr8H/bQOx8 ufEFDCyYujo7oRmpxzJ5DH5Qyt2ieif6gACCFebeGGv01/CyEEM0pjfrHKpMWotWBFgF3RsAsVlw W8RGMXpyEtOcVEbwV3hLeGnGqylkH0wq1XAIjrbxyJcSaQzMXqHV4YYyEqCq+mGv4gdzPwBWLGIX 0djjkEG1ItMqcWWhcuQNslVF5ai2PgrzgbTrYgFmEoE4qr9GTyw9awFrXkOTqJeAzodCbC6wTgdo pFpw5wNBz0cuXiMRqrRDOIK1cc+yjV4ErCovgmIA1lAQDL5epqqhQM1KLViOFknkqynO8CWtekLg 1BaHNEJCzYvk20x+UMPgBULbQL0sgeQplZoQLwwYymYRAa5zeLgXx+FpUKxCrzdQ5irg+UXx4QVA F4CfEhoXuPSCAZEdJL8KWGK/qBh8MlIHUc00yVcBIa1HgY41Mb8AqcJuYaLgxOHaEEHxNoY6grHY 9SAtaC2A0qZ2iH7jQVJxb50r92F0DTXG8WwximtAug1F9UAWUWZq7XpLNm44TpsaajKBnQBzT6UW a50CkvxklmZ4fZSb5uPUqavv/sRlZtJEJQxBz3COh/ElyjZQaMRMIhfVDVhooA0W3PsqurTVLKKm ZFb5nbo5po1nrFXdi6CgFhNEGIAIBtv6L41ApSI2pelq8wQ6zOTfa5wZpGhi1UW1dNQB2FWFtWBZ xycTBMmK3Ks+ZLgVHHcByTA2SuiKLGr6qswTvMD1MggAAQWTKz+6BgECv9k/qmAl+ooFN13Bwoa4 dB9IwQpEPSix6Y2xaIaoJahzUCE9iJTDzx5/YmjRo0aNOlSpUKFOmRJcuHPjjwYtOuVIlyRi9euW LB2/CJEX2oC+3AT2YC+zAT2IX+xC/wBoi72z3g/tnvLvYPeDewe8v/0e86n8e86GU8Mr4ZXwxreR VJYMMdkRIqSh/PrEg+iZKF7wLX5Zvlr4HjK66uC9coAH0BI8CvowMjaFmCyMqMeWqhwIejLAQZ6U Y7hLQVbVCGPgHj0/ZRCHwKhCEIQqEKhCoQqFQqFQhUKhUKhCAhCEAgQhCoSuJZ41ZK6x2fMoNdLh D+oCKTmiLg+hK1U5t94x89EL09pYIOwUJoqodQ25rd20UQIAlrKUBvMQTyLtNY3Gc4CGwDdzYAUQ KXSA6l/HsBppXzcLrEWmvNHmElcVeHTwwUYFg4jyMoAAWqYByzdXezKmmk8yH9cKwFq9ScCThgvX 4woHuUN0W0eMOOIQxHIiSXNQ6C6dlYh/FisBaPEIMSRSig2iu1/wPvvvvvvgwE7SKOHSAF0WvLLL rHEQBphbd2jVpqEdc46XpnCCUpZlqx9KfBtESFNvDbHf4t99WMeaGHaFo9Mqb9K27as850Y+jH14 +vD0IQZIYFoWj0ypv0rYtqzznSl6UvUl/JVmVXXedORIoAFq6iDM8zePLwZxOvN0JupN0pupF04u vFWq4yunkzudKLqQdKDo/J3Ov8nc6Hydynh9/dOp9/dOv9/dPkr7z5C+8r/2fefNX3ny1nyFnzr+ E6Z1TolJRGmN5Y/Ow3pMUchNQZuD7rwuU1QJbrH4FW53rNWrq2hzPLUlQIqstsGJUHJRt9RbWQlp vF4QuopVU4vB6jCiMXtGi6v8Ro4aLlp2oal82G2J4kgoNNkc8eYAZMivEHbLCr32TqUNmDxp5jGu YsQU8oWr0hoU1kAq14PkifKwSiDxgGHN6xLKk3WhRwZcNEJYiBZbSpQMbV5ZQtXddgLShSlzGATS 4ArQWrfEZUyz8GKY578SgNzWYqm12tifC5GkNC+xYq8UjEcwA9EZ1UtxTiGk85uZsABQrmD2U+5i HSAKtzNpYb1jwIMpFfcB30MeXcpTChwwVWaAHm437QVgaUJ5bgWnN2KkZRFqMyApatmdur9CeSnZ 7KIibWoRWcBgdW0RAWyDODXVVUi3UHZAxXIwzq4QWwejekothowPwYtdBeRwEquDjao4/K4rGRmy +22ZT6Gbl6i8QXFOBUfruEbc4oZCNa/1BZohqKbpNMQBRDQCGDO1uw9aYDt5YMHoGyVXBxtUcflc ZxybORbcKcmsZgURHNCyFvR25vMPeV4aVAoMt0KxRN/woIBS44Xu5lKeIHeZUdOH8GfJf1Ld22Yh jXkFzlORdXH0gk+4lSvV8Fh8SwOCU6lt9Q6tEBLGNknlPmFShDhCNiEOn+0f5Znch30uvBoUUFB0 pQkVeTjqOOVFKC9K3NQAF8siL4L4i0AUtmisUdPMS4Qw9rqfAiw5zDtu/KFDymP1GQhW7WVDUqzf NOuMYHsn6LYYVLZu2VQEp26At4C82/4VDKeJTxKeJTxCtiHrTPQF64w4IaGU8ty8LbJZwXUKrKUZ 4Y56mrb++ZdIqXSuIaP+IPdAmoUy5qANm2NyNXrKBNUPWVxAJn6S7x2terA6SZQw0H8QOyOqdw9l raazzKFcwtuNQBb0grUNmMmPlCMtrVZgDVUcC2v6H+IOp/7/ANYGv/T+F//Z ------=_NextPart_000_00B5_01C254C2.935F9A60-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Sep 20 12:40:32 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28912 for ; Fri, 20 Sep 2002 12:40:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6A6025392C; Fri, 20 Sep 2002 12:37:07 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 71AD253541 for ; Fri, 20 Sep 2002 12:36:52 -0400 (EDT) Received: (qmail 49914 invoked by uid 3269); 20 Sep 2002 16:41:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49909 invoked from network); 20 Sep 2002 16:41:29 -0000 Received: from smtp016.mail.yahoo.com (216.136.174.113) by klesh.pair.com with SMTP; 20 Sep 2002 16:41:29 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.128.44.201 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 20 Sep 2002 16:40:33 -0000 Message-Id: <5.0.0.25.2.20020920123654.04484a70@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Call for Agenda items for MSEC WG at IETF-55 in Atlanta Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 20 Sep 2002 12:42:25 -0400 Folks, The MSEC WG will meet in Atlanta at IETF-55. If you have items for the MSEC Agenda, please email Ran/Thomas as we are in the process of setting it up. The IETF draft schedule has MSEC meeting on a Monday morning. Note, however, that the IETF schedule is *not* final. In the past, we have been moved from a Monday morning to a Friday morning). Please monitor http://www.ietf.org/meetings/agenda_55.txt for the schedule. cheers, Thomas/Ran ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Sep 26 21:14:35 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27144 for ; Thu, 26 Sep 2002 21:14:35 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E3CEC53667; Thu, 26 Sep 2002 21:11:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1952E535BF for ; Thu, 26 Sep 2002 21:09:08 -0400 (EDT) Received: (qmail 51896 invoked by uid 3269); 27 Sep 2002 01:14:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51873 invoked from network); 27 Sep 2002 01:14:01 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 27 Sep 2002 01:14:01 -0000 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8R1DOaW018124 for ; Thu, 26 Sep 2002 18:13:24 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8R1DThL022634 for ; Thu, 26 Sep 2002 18:13:29 -0700 (PDT) Received: from cisco.com (dhcp-128-107-212-72.cisco.com [128.107.212.72]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA22232 for ; Thu, 26 Sep 2002 18:13:28 -0700 (PDT) Message-ID: <3D93B0B8.DDC2BA27@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] GDOI Update Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 26 Sep 2002 18:13:28 -0700 Content-Transfer-Encoding: 7bit A new draft of GDOI is being prepared which adds some clarification text. This mail describes that clarification. Feedback is welcomed. The GDOI draft describes two protocols: the GROUPKEY-PULL registration protocol which is protected by a "phase 1" protocol, and the GROUPKEY-PUSH rekey message which stands alone. The rest of this email is in relation to the GROUPKEY-PULL registration protocol. As defined in draft-ietf-msec-gdoi-05.txt, the "phase 1" protocol protecting GROUPKEY-PULL is specified to be the Phase 1 protocol definitions from RFC 2409. It also describes the specific requirements placed on those protocols. This will not change. However, GDOI itself has no unique dependency on these Phase 1 protocol definitions, and in fact other protocols could be used instead. As long as a protocol satisfies the security requirements, it is an acceptable choice. The next draft will clarify the role of the Phase 1 protocol, and also will sketch out how two other potential "phase 1" protocol definitions could be used to protect the GDOI protocol. Following is the proposed section describing the requirements for the phase 1 protocol. This expands the text found in section 2.0 of draft-ietf-msec-gdoi-05.txt. 2.0 GDOI Phase 1 protocol GDOI is a "phase 2" protocol which MUST be protected by a "phase 1" protocol. The "phase 1" protocol can be any protocol which provides for the following protections: o Peer Authentication o Confidentiality o Message Integrity The following sections describe one such "phase 1" protocol. Others protocols which may be potential "phase 1" protocols are described in Appendix A. 2.1 ISAKMP Phase 1 protocol This document defines how the ISAKMP phase 1 exchanges as defined in [RFC2409] can be used a "phase 1" protocol for GDOI. The following sections define characteristics of the ISAKMP phase 1 protocols that are unique for these exchanges when used for GDOI. Section 6.1 describes how the ISAKMP Phase 1 protocols meet the requirements of a GDOI "phase 1" protocol. 2.1.1 DOI value The Phase 1 SA payload has a DOI value. That value MUST be the GDOI DOI value as defined later in this document. 2.1.2 UDP port. GDOI MUST NOT run on port 500 (the port commonly used for IKE). A new port number MUST be defined by IANA for GDOI. An appendix is added which sketches out two additional possible phase 1 protocols. These sketches are intended to be examples, not actual protocol definitions. Appendix A: Alternate GDOI Phase 1 protocols This section describes a manner in which other protocols could be used as GDOI Phase 1 protocols in place of the ISAKMP Phase 1 protocol. However, a separate document MUST be written in order for another protocol to be used as a GDOI Phase 1 protocol. Any GDOI phase 1 protocol MUST satisfy the requirements specified in Section 2 of this document. A.1 IKEv2 Phase 1 protocol Version 2 of the IKE protocol (IKEv2) is a work in progress [IKEv2]. That protocol seeks to simplify the IKE Phase 1 and Phase 2 protocols, and improve the security of the IKE protocol. An IKEv2 Phase 1 negotiates an IPSEC SA during phase 1, which was not possible in IKE. However, IKEv2 also defines a phase 2 protocol. The phase 2 protocol is protected by the Phase 1, similar in concept to how IKE Quick Mode is protected by the IKE Phase 1 protocols in [RFC2409]. IKEv2 may not include a DOI value in the SA payload. However, since GDOI uses a unique port, choice of a phase 2 protocol in the SA payload using a GDOI value is not necessary. It is expected that an IKEv2 Phase 1 protocol definition could be run on the GDOI port. The SA payload in the protocol would be specific to GDOI, or omitted if not needed at all. The GROUPKEY-PULL protocol would follow the IKEv2 Phase 1 protocol in the same manner as described in this document. A.2 KINK Protocol A work in progress [KINK] has defined a method of encapsulating an IKE Quick Mode [RFC2409] encapsulated in Kerberos KRB_AP_REQ and KRB_AP_REP payloads. KINK provides a low-latency, computationally inexpensive, easily managed, and cryptographically sound method of setting up IPSec security associations. The KINK message format includes a GDOI field in the KINK header. The [KINK] document defines the DOI for the IPSEC DOI. A new DOI for KINK could be defined which would encapsulate a GROUPKEY-PULL exchange in the Kerberos KRB_AP_REQ and KRB_AP_REP payloads. As such, GDOI would benefit from the computational efficiencies of KINK. Comments? Brian -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Sep 27 12:02:14 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26552 for ; Fri, 27 Sep 2002 12:02:13 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 655685391F; Fri, 27 Sep 2002 11:58:11 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6037853624 for ; Fri, 27 Sep 2002 11:57:38 -0400 (EDT) Received: (qmail 60375 invoked by uid 3269); 27 Sep 2002 16:02:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60372 invoked from network); 27 Sep 2002 16:02:33 -0000 Received: from zcars04f.nortelnetworks.com (HELO zcars04f.ca.nortel.com) (47.129.242.57) by klesh.pair.com with SMTP; 27 Sep 2002 16:02:33 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8RG1X413881; Fri, 27 Sep 2002 12:01:33 -0400 (EDT) Received: from zbl6c002.us.nortel.com ([132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TWX0C3TN; Fri, 27 Sep 2002 12:01:35 -0400 Received: from nortelnetworks.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TSNCZZGR; Fri, 27 Sep 2002 12:00:45 -0400 Message-ID: <3D947FA4.9060300@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Weis Cc: msec@securemulticast.org Subject: Re: [MSEC] GDOI Update References: <3D93B0B8.DDC2BA27@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 27 Sep 2002 11:56:20 -0400 Content-Transfer-Encoding: 7bit Brian, I think we will be better of specifying ONE protocol for phase 1, and ISAKMP Phase 1 sounds good. IKEv2 in the appendix is also welcome, since that looks like the evolutionary path. But, I would strongly suggest against specifying options for phase 1 in GDOI. We may end up with GDOI implementations that do not interoperate with each other. I did notice that you used the word "examples" for the protocols (to be) listed in the Appendix, but why risk ambiguity. Instead, we might put these options in the GKMArch draft, if necessary. cheers, Lakshminath Brian Weis wrote: > A new draft of GDOI is being prepared which adds some clarification > text. This mail describes that clarification. Feedback is welcomed. > > The GDOI draft describes two protocols: the GROUPKEY-PULL registration > protocol which is protected by a "phase 1" protocol, and the > GROUPKEY-PUSH rekey message which stands alone. The rest of this email > is in relation to the GROUPKEY-PULL registration protocol. > > As defined in draft-ietf-msec-gdoi-05.txt, the "phase 1" protocol > protecting GROUPKEY-PULL is specified to be the Phase 1 protocol > definitions from RFC 2409. It also describes the specific requirements > placed on those protocols. This will not change. However, GDOI itself > has no unique dependency on these Phase 1 protocol definitions, and in > fact other protocols could be used instead. As long as a protocol > satisfies the security requirements, it is an acceptable choice. > > The next draft will clarify the role of the Phase 1 protocol, and also > will sketch out how two other potential "phase 1" protocol definitions > could be used to protect the GDOI protocol. > > Following is the proposed section describing the requirements for the > phase 1 protocol. This expands the text found in section 2.0 of > draft-ietf-msec-gdoi-05.txt. > > 2.0 GDOI Phase 1 protocol > > GDOI is a "phase 2" protocol which MUST be protected by a "phase 1" > protocol. The "phase 1" protocol can be any protocol which provides > for the following protections: > > o Peer Authentication > o Confidentiality > o Message Integrity > > The following sections describe one such "phase 1" protocol. Others > protocols which may be potential "phase 1" protocols are described in > Appendix A. > > 2.1 ISAKMP Phase 1 protocol > > This document defines how the ISAKMP phase 1 exchanges as defined in > [RFC2409] can be used a "phase 1" protocol for GDOI. The following > sections define characteristics of the ISAKMP phase 1 protocols that > are unique for these exchanges when used for GDOI. > > Section 6.1 describes how the ISAKMP Phase 1 protocols meet the > requirements of a GDOI "phase 1" protocol. > > > 2.1.1 DOI value > > The Phase 1 SA payload has a DOI value. That value MUST be the GDOI > DOI value as defined later in this document. > > 2.1.2 UDP port. > > GDOI MUST NOT run on port 500 (the port commonly used for IKE). A new > port number MUST be defined by IANA for GDOI. > > > An appendix is added which sketches out two additional possible phase 1 > protocols. These sketches are intended to be examples, not actual > protocol definitions. > > Appendix A: Alternate GDOI Phase 1 protocols > > This section describes a manner in which other protocols could be > used as GDOI Phase 1 protocols in place of the ISAKMP Phase 1 > protocol. However, a separate document MUST be written in order for > another protocol to be used as a GDOI Phase 1 protocol. > > Any GDOI phase 1 protocol MUST satisfy the requirements specified in > Section 2 of this document. > > A.1 IKEv2 Phase 1 protocol > > Version 2 of the IKE protocol (IKEv2) is a work in progress [IKEv2]. > That protocol seeks to simplify the IKE Phase 1 and Phase 2 > protocols, and improve the security of the IKE protocol. An IKEv2 > Phase 1 negotiates an IPSEC SA during phase 1, which was not possible > in IKE. However, IKEv2 also defines a phase 2 protocol. The phase 2 > protocol is protected by the Phase 1, similar in concept to how IKE > Quick Mode is protected by the IKE Phase 1 protocols in [RFC2409]. > > IKEv2 may not include a DOI value in the SA payload. However, since > GDOI uses a unique port, choice of a phase 2 protocol in the SA > payload using a GDOI value is not necessary. It is expected that an > IKEv2 Phase 1 protocol definition could be run on the GDOI port. > The SA payload in the protocol would be specific to GDOI, or omitted > if not needed at all. > > The GROUPKEY-PULL protocol would follow the IKEv2 Phase 1 protocol in > the same manner as described in this document. > > A.2 KINK Protocol > A work in progress [KINK] has defined a method of encapsulating an > IKE Quick Mode [RFC2409] encapsulated in Kerberos KRB_AP_REQ and > KRB_AP_REP payloads. KINK provides a low-latency, computationally > inexpensive, easily managed, and cryptographically sound method of > setting up IPSec security associations. > > The KINK message format includes a GDOI field in the KINK header. The > [KINK] document defines the DOI for the IPSEC DOI. > > A new DOI for KINK could be defined which would encapsulate a > GROUPKEY-PULL exchange in the Kerberos KRB_AP_REQ and KRB_AP_REP > payloads. As such, GDOI would benefit from the computational > efficiencies of KINK. > > Comments? > Brian > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Sep 28 06:01:50 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01718 for ; Sat, 28 Sep 2002 06:01:49 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C5DDF53685; Sat, 28 Sep 2002 05:58:16 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id ECE745363F for ; Sat, 28 Sep 2002 05:57:36 -0400 (EDT) Received: (qmail 87928 invoked by uid 3269); 28 Sep 2002 10:02:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 87925 invoked from network); 28 Sep 2002 10:02:34 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 28 Sep 2002 10:02:34 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g8SA1qf13618; Sat, 28 Sep 2002 06:01:52 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g8SA1p0433630; Sat, 28 Sep 2002 06:01:51 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id GAA32074; Sat, 28 Sep 2002 06:01:51 -0400 From: Ran Canetti Message-Id: <200209281001.GAA32074@ornavella.watson.ibm.com> To: bew@cisco.com, ldondeti@nortelnetworks.com Subject: Re: [MSEC] GDOI Update Cc: msec@securemulticast.org Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sat, 28 Sep 2002 06:01:51 -0400 Just a clarification: The suggested additions to the GDOI document are a result of concerns expressed recently regarding whether GDOI violates the "moratorium" that the ADs imposed last summer on developing new protocols based on IKEv1. In a discussion between the ADs, the WG chairs, and the authors of GDOI, it was agreed that GDOI will add language that will make it clear that GDOI is not just and extenstion of IKEv1, but rather it can be based on any "phase 1" protocol that provides some basic security proerties. Furthermore, when IKEv2 will stabilize, the GDOI document (or a subsequent document) will specify how exactly to use GDOI with ikev2-based phase 1. It is my understanding that text below posted by Brian is a result of this agreement. (Correct me if I'm wrong, Brian.) Any further remarks from the WG are welcome. Ran > From: Lakshminath Dondeti > > Brian, > > I think we will be better of specifying ONE protocol for phase 1, and > ISAKMP Phase 1 sounds good. IKEv2 in the appendix is also welcome, > since that looks like the evolutionary path. But, I would strongly > suggest against specifying options for phase 1 in GDOI. We may end up > with GDOI implementations that do not interoperate with each other. > > I did notice that you used the word "examples" for the protocols (to be) > listed in the Appendix, but why risk ambiguity. Instead, we might put > these options in the GKMArch draft, if necessary. > > cheers, > Lakshminath > > Brian Weis wrote: > > A new draft of GDOI is being prepared which adds some clarification > > text. This mail describes that clarification. Feedback is welcomed. > > > > The GDOI draft describes two protocols: the GROUPKEY-PULL registration > > protocol which is protected by a "phase 1" protocol, and the > > GROUPKEY-PUSH rekey message which stands alone. The rest of this email > > is in relation to the GROUPKEY-PULL registration protocol. > > > > As defined in draft-ietf-msec-gdoi-05.txt, the "phase 1" protocol > > protecting GROUPKEY-PULL is specified to be the Phase 1 protocol > > definitions from RFC 2409. It also describes the specific requirements > > placed on those protocols. This will not change. However, GDOI itself > > has no unique dependency on these Phase 1 protocol definitions, and in > > fact other protocols could be used instead. As long as a protocol > > satisfies the security requirements, it is an acceptable choice. > > > > The next draft will clarify the role of the Phase 1 protocol, and also > > will sketch out how two other potential "phase 1" protocol definitions > > could be used to protect the GDOI protocol. > > > > Following is the proposed section describing the requirements for the > > phase 1 protocol. This expands the text found in section 2.0 of > > draft-ietf-msec-gdoi-05.txt. > > > > 2.0 GDOI Phase 1 protocol > > > > GDOI is a "phase 2" protocol which MUST be protected by a "phase 1" > > protocol. The "phase 1" protocol can be any protocol which provides > > for the following protections: > > > > o Peer Authentication > > o Confidentiality > > o Message Integrity > > > > The following sections describe one such "phase 1" protocol. Others > > protocols which may be potential "phase 1" protocols are described in > > Appendix A. > > > > 2.1 ISAKMP Phase 1 protocol > > > > This document defines how the ISAKMP phase 1 exchanges as defined in > > [RFC2409] can be used a "phase 1" protocol for GDOI. The following > > sections define characteristics of the ISAKMP phase 1 protocols that > > are unique for these exchanges when used for GDOI. > > > > Section 6.1 describes how the ISAKMP Phase 1 protocols meet the > > requirements of a GDOI "phase 1" protocol. > > > > > > 2.1.1 DOI value > > > > The Phase 1 SA payload has a DOI value. That value MUST be the GDOI > > DOI value as defined later in this document. > > > > 2.1.2 UDP port. > > > > GDOI MUST NOT run on port 500 (the port commonly used for IKE). A new > > port number MUST be defined by IANA for GDOI. > > > > > > An appendix is added which sketches out two additional possible phase 1 > > protocols. These sketches are intended to be examples, not actual > > protocol definitions. > > > > Appendix A: Alternate GDOI Phase 1 protocols > > > > This section describes a manner in which other protocols could be > > used as GDOI Phase 1 protocols in place of the ISAKMP Phase 1 > > protocol. However, a separate document MUST be written in order for > > another protocol to be used as a GDOI Phase 1 protocol. > > > > Any GDOI phase 1 protocol MUST satisfy the requirements specified in > > Section 2 of this document. > > > > A.1 IKEv2 Phase 1 protocol > > > > Version 2 of the IKE protocol (IKEv2) is a work in progress [IKEv2]. > > That protocol seeks to simplify the IKE Phase 1 and Phase 2 > > protocols, and improve the security of the IKE protocol. An IKEv2 > > Phase 1 negotiates an IPSEC SA during phase 1, which was not possible > > in IKE. However, IKEv2 also defines a phase 2 protocol. The phase 2 > > protocol is protected by the Phase 1, similar in concept to how IKE > > Quick Mode is protected by the IKE Phase 1 protocols in [RFC2409]. > > > > IKEv2 may not include a DOI value in the SA payload. However, since > > GDOI uses a unique port, choice of a phase 2 protocol in the SA > > payload using a GDOI value is not necessary. It is expected that an > > IKEv2 Phase 1 protocol definition could be run on the GDOI port. > > The SA payload in the protocol would be specific to GDOI, or omitted > > if not needed at all. > > > > The GROUPKEY-PULL protocol would follow the IKEv2 Phase 1 protocol in > > the same manner as described in this document. > > > > A.2 KINK Protocol > > A work in progress [KINK] has defined a method of encapsulating an > > IKE Quick Mode [RFC2409] encapsulated in Kerberos KRB_AP_REQ and > > KRB_AP_REP payloads. KINK provides a low-latency, computationally > > inexpensive, easily managed, and cryptographically sound method of > > setting up IPSec security associations. > > > > The KINK message format includes a GDOI field in the KINK header. The > > [KINK] document defines the DOI for the IPSEC DOI. > > > > A new DOI for KINK could be defined which would encapsulate a > > GROUPKEY-PULL exchange in the Kerberos KRB_AP_REQ and KRB_AP_REP > > payloads. As such, GDOI would benefit from the computational > > efficiencies of KINK. > > > > Comments? > > Brian > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec