From owner-saag Fri Mar 11 16:03:00 1995 Received: from relay.tis.com by neptune.TIS.COM id aa01822; 10 Mar 95 16:03 EST Received: from mailhub.tis.com(192.33.112.100) by relay.tis.com via smap (a1.4) id sma006924; Fri Mar 10 16:06:49 1995 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA14243; Fri, 10 Mar 95 16:06:51 EST Message-Id: <9503102106.AA14243@tis.com> Reply-To: James M Galvin To: saag@tis.com Subject: archives for this list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <22062.794869639.1@tis.com> Date: Fri, 10 Mar 1995 16:07:20 -0500 From: James M Galvin This list is now archived. This message will become the first message in the archives. The following excerpt will now appear in the initial subscription message sent to new subscribers: The SAAG archives are available via anonymous ftp from the host "ftp.tis.com" in the directory "/pub/ietf/saag". There you will find files called saag-YYMM.txt.Z, compressed text files which contain all messages sent to the SAAG list up through the month MM and the year YY. The most recent messages are in a file called saag.mbox. Enjoy, Jim From owner-saag Fri May 10 14:05:00 1995 Received: from relay.tis.com by neptune.TIS.COM id aa01080; 10 May 95 14:05 EDT Received: from big-screw.mit.edu(18.72.0.176) by relay.tis.com via smap (g3.0) id sma028230; Wed, 10 May 95 14:07:41 -0400 Received: by big-screw id AA13991; Wed, 10 May 95 14:09:15 -0400 X-Sender: jis@e40-po.mit.edu (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 May 1995 14:09:30 -0400 To: minutes@cnri.reston.va.us From: "Jeffrey I. Schiller" Subject: Security Area Report Cc: saag@TIS.COM -----BEGIN PGP SIGNED MESSAGE----- IETF Security Area Report Jeff Schiller and Jim Galvin jis@mit.edu galvin@tis.com April 3-7, 1995 The Security Area within the IETF is responsible for development of security oriented protocols, security review of RFCs, development of candidate policies, and review of operational security on the Internet. The Area Director is assisted by a Directorate, an advisory entity with no standards-setting powers. The members of the Security Directorate are as follows. Jeffrey I. Schiller Ran Atkinson Steve Bellovin Steve Crocker Barbara Fraser James M. Galvin Phil Karn Steve Kent John Linn Clifford Neuman Rob Shirey Ted Ts'o In addition to the Directorate the Security Area is assisted by the Security Area Advisory Group (SAAG). The SAAG is an open group that meets at least once during each IETF meeting as well as electronically via the saag@tis.com mailing list. During the Security Area Advisory Group (SAAG) meeting, the activities of the Security Area, including the Directorate, will be reported and discussed. In addition, the SAAG meeting will provide an opportunity for open discussion of security issues. Included below is a summary from those working groups and birds of a feather sessions with security relevant activities to report and the Security Directorate meeting summary. In addition, the following topic was discussed during the SAAG meeting. o Encapsulating Security Payload IPv6 requires security, specifically that authentication and encryption be available at all times and that authentication be turned on by default. This decision received considerable attention at the open IESG meeting held after this SAAG meeting. Jeff Schiller conducted a number of straw polls to assess some measure of the community during this meeting. In particular: Question One Q: Should we require ESP or recommend it? A: The overwhelming response was to require it Question Two Q: (1) Should we require ESP and DES or (2) should we require ESP but leave DES optional or (3) should we leave ESP optional but if you do it use DES or (4) should we leave ESP optional and leave DES optional? A: The overwhelming response was in favor of requiring both ESP and DES (1); a number approximating 25% of that response was in favor of the third option. Question Three Q: Should we allow other transformations in addition to requiring DES? A: The overwhelming response was in favor. The activity of the following working groups and birds of a feather sessions was reported: o Common Authentication Technology (CAT) The working group charter is being revised to include scope compatible with Independent Data Unit Protection (IDUP) and with future authorization support facilities. The following documents are eligible for the issuance of a working group last call (as indicated) in advance of their submission to the IESG for publication as Proposed Standards. The FTP Security specification has been resurrected with a new editor: March Horowitz. A revised specification is expected to be available soon. A revision of Version 2 of the GSS specification and C bindings documents is expected to be available soon. The Simple Public Key Mechanism is considered stable at this time, pending resolution of an identified issue re X9.44 replay protection, and was placed in working group last call on 5 April 1995 in advance of its submission to the IESG for publication as a Proposed Standard. RFC1510 (Kerberos) is now eligible for advancement to a Draft Standard. One issue is relevant to advancement of the document and will be resolved on the mailing list. A presentation on Secure Socket Layer was given by NetScape. An internet-draft is expected to be available soon. Discussion continued on the other documents and activities. o Domain Name System Security (DNSSEC) This working group did not meet at this IETF. Nonetheless, it was reported that a revised specification will be released shortly in parallel with an alpha implementation. A working group last call will be issued as soon as it's released and the document will be progressed to submission to the IESG for publication as a Proposed Standard. o Guidelines and Recommendations for Security Incident Processing (GRIP) Note: GRIP is part of the Operational Requirements Area but is tracked by the SAAG and Security Area. This new working group has drafted guidelines for security incident response teams. A revised draft is expected to be available soon at which time a working group last call will be issued. The document will be submitted to the IESG for publication as a Proposed Standard by the next IETF. o IP Security (IPSEC) Eight Internet-Drafts were submitted for this meeting. Five of these specifications describe the network layer cryptographic mechanisms and are in working group last call. The working group has reached consensus on requiring the implementation of a hybrid Diffie-Hellman key exchange for the IKMP. The "Photuris" specification will be progressed in the working group as the baseline description of this key exchange. Additional presentations were given on possible modifications to the Photuris exchange and on a framework for the IKMP protocol signaling. o Privacy Enhanced Mail (PEM) This working group did not meet at this IETF. Nonetheless, it was reported that the latest version of the PEM/MIME integration specification (now called MIME Object Security Services (MOSS)) is waiting for the working group chair to issue a working last call [done as of the writing of this report] and to progress the document to submission to the IESG for publication as a Proposed Standard. Upon publication of the documents this working group is expected to go dormant. Other working groups will be created to address related issues, e.g., the Internet certification hierarchy. o Router Requirements The router requirements working group has a document ready to be submitted to the IESG for publication as a Proposed Standard. It will include a requirement level of SHOULD for strong remote authentication. An issue to be resolved before the document advances to Draft Standard is the use of security by routing protocols. o Web Transport Security A web transport security working group will be formed with Charlie Kaufman as the Chair. It will pickup where the SHTTP birds of a feather from the last IETF meeting left off. o Other The Authenticated Firewall Traversal working group and One-Time Password birds-of-a-feather also met during this IETF. The latter is expected to submit a charter to become a working group by the next IETF; Neil Haller and Ran Atkinson will be co-Chairs. The Security Area Directorate met on Monday afternoon for a 2 hour meeting. In addition to all of the above, the following was noted. o Audio/Video Transport (AVT) and ONC Remote Procedure Call (ONCRPC) Both of these working groups have documents ready for advancement to Proposed Standards. Allison Mankin, the Transport Area Director, has requested a security review of their documents, as follows: draft-ietf-avt-cellb-profile-04.txt draft-ietf-avt-jpeg-01.txt draft-ietf-avt-profile-04.txt draft-ietf-avt-rtp-07.txt draft-ietf-avt-video-packet-04.txt draft-ietf-oncrpc-xdr-01.txt draft-ietf-oncrpc-rpcv2-01.txt draft-ietf-oncrpc-bind-00.txt draft-ietf-oncrpc-auth-00.txt -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBL7DGdcUtR20Nv5BtAQEcOAP+MjQjq1w0Oe7yhhzgjRvtx5s7GK37JwjN INZ9ua7H0oA7zlYalyqkAwffW6lrM9W2H5bhW+hu6WP4Fcix4zpEWPGrcRbjHrdg EirG6b78M07AscTf/CpjtqIDrsDtRNEdUkDweMdY/S6FPn4oFvZZtQUc0YpySZdP 8uRc2xOSbho= =wqH8 -----END PGP SIGNATURE----- From owner-saag Fri Aug 17 14:50:00 1995 Received: from relay.tis.com by neptune.TIS.COM id aa05686; 17 Aug 95 14:50 EDT Received: from uu.psi.com(136.161.128.3) by relay.tis.com via smap (g3.0.1) id xma000418; Thu, 17 Aug 95 14:41:30 -0400 Received: by uu.psi.com (5.65b/4.0.061193-PSI/PSINet) via UUCP; id AA06063 for ; Thu, 17 Aug 95 14:33:16 -0400 Received: from asgaard.rocket.com (asgaard.ARPA) by earth.rocket.com (4.1/3.2.083191-Olin Aerospace Company - Redmond Wa) id AA26219; Thu, 17 Aug 95 11:29:57 PDT Organization: Olin Aerospace Company Telephone: (206)885-5000 Fax: (206)882-5804 Received: by asgaard.rocket.com (4.1/SMI-4.1) id AA08790; Thu, 17 Aug 95 11:29:28 PDT Date: Thu, 17 Aug 95 11:29:28 PDT Message-Id: <9508171829.AA08790@asgaard.rocket.com> To: saag@TIS.COM Subject: [mshaver@schoolnet.carleton.ca: SSL message broken (fwd)] From: "Philip J. Nesser" Sender: pjnesser@rocket.com Us-Snail: 16015 84th Avenue NE, Bothell WA 98011-4451 FYI, ---> Phil ============================================================ >From: Mike Shaver Subject: SSL message broken (fwd) To: best-of-security@suburbia.net Date: Wed, 16 Aug 1995 20:03:40 -0400 (EDT) Reply-To: shaver@neon.ingenia.com (Me) That Whispering Wolf... mumbled something vague about: >From owner-bugtraq@CRIMELAB.COM Wed Aug 16 19:22 EDT 1995 Approved-By: CHASIN@CRIMELAB.COM X-Mailer: ELM [version 2.4 PL24 PGP3A] Approved-By: "That Whispering Wolf..." Message-ID: <199508162124.OAA04184@lupine.org> Date: Wed, 16 Aug 1995 14:24:53 -0700 Reply-To: Bugtraq List Sender: Bugtraq List >From: "That Whispering Wolf..." Subject: SSL message broken X-To: bugtraq@CRIMELAB.COM To: Multiple recipients of list BUGTRAQ Content-Type: text Content-Length: 6508 This came down the SSL mailing list from netscape, which came (I believe) from the Cypherpunk list. Summary: Someone (see below) did an SSL-encrypted transaction to netscape's server, and posted the traffic generated to a web page, saying "Okay, here it is, break it". Someone on cypherpunks did just that -- Did a brute force sweep of the 40 bit (IDEA, I think, is what SSL uses) keyspace. IMPORTANT NOTE: This was a -single- person, not a group codebreaking effort. Cypherpunks WAS going to do something like this (and have already attempted it once, but failed for various reasons), but this guy beat them to it. Repercussions: Well, let me say this... Actual repercussions are up to the reader. Well's Fargo has just started allowing account manipulations via Netscape and a secure server. ----- CUT HERE ----- -----BEGIN PGP SIGNED MESSAGE----- SSL challenge -- broken This is to announce the solution of the SSL challenge posted by Hal Finney on July 17, 1995 (message-ID: <3u6kmg$pm4@jobe.shell.portal.com>), also found at: The 40-bit secret part of the key is 7e f0 96 1f a6. I found it by a brute force search on a network of about 120 workstations and a few parallel computers at INRIA, Ecole Polytechnique, and ENS. The key was found after scanning a little more than half the key space in 8 days. The cleartext of the encrypted data is as follows: The SERVER-VERIFY message is: 9C B1 C7 83 D9 BB B7 75 01 6F 19 19 03 58 EC 05 MAC-DATA 05 MSG-SERVER-VERIFY AF 84 A7 79 F8 13 69 20 25 9B 53 A0 60 AE 75 51 CHALLENGE The CHALLENGE part is a copy of the challenge sent by the client in its first message. The answer is the CLIENT-FINISHED message: 22 BB 23 39 55 B0 7F B6 1A B0 35 85 F7 DB C1 E5 MAC-DATA 03 MSG-CLIENT-FINISHED BF EB 90 F8 2C 0C E1 EA 18 AC 11 4C 83 14 21 B6 CONNECTION-ID The next message is SERVER-FINISHED: D4 CD F3 4E 38 F1 2B 1E DC FD 72 C8 34 02 CD FF MAC-DATA 06 SERVER-FINISHED-BYTE 23 1C 05 40 60 72 49 6E 83 BA D1 28 CC 9B 5F 63 SESSION-ID-DATA Then comes the data message sent by the client. This is the juicy one. I have broken the contents into its fields (the body was just one long line) 72 23 B5 98 0D D0 07 1A DA F1 C7 A4 40 41 5A 10 MAC-DATA POST /order2.cgi HTTP/1.0 Referer: https://order.netscape.com/order2.cgi User-Agent: Mozilla/1.1N (Macintosh; I; PPC) Accept: */* Accept: image/gif Accept: image/x-xbitmap Accept: image/jpeg Content-type: application/x-www-form-urlencoded Content-length: 472 source-form=order2-cust.html& order_number=31770& prod_80-01020-00_Mac=1& carrier_code=UM& ship_first=Cosmic& ship_last=Kumquat& ship_org=SSL+Trusters+Inc.& ship_addr1=1234+Squeamish+Ossifrage+Road& ship_addr2=& ship_city=Anywhere& ship_state=NY& ship_zip=12345& ship_country=USA& ship_phone=& ship_fax=& ship_email=& bill_first=& bill_last=& bill_org=& bill_addr1=& bill_addr2=& bill_city=& bill_state=& bill_zip=& bill_country=USA& bill_phone=& bill_fax=& bill_email=& submit=+Submit+Customer+Data+ This order came from Mr Cosmic Kumquat, SSL Trusters Inc., 1234 Squeamish Ossifrage Road, Anywhere, NY 12345 (USA). Unfortunately, Mr Kumquat forgot to give his phone number, and the server's reply (in two packets) is: 09 12 AD FE A5 A9 BF D1 8C 8C E2 6A A3 48 B9 75 MAC-DATA HTTP/1.0 200 OK Server: Netscape-Commerce/1.1 Date: Wednesday, 12-Jul-95 05:40:30 GMT Content-type: text/html 1C CD C4 3D 80 F1 7B 94 11 AC E8 72 B1 99 BC FA MAC-DATA Error

Error

The shipping address you supplied is not complete. The street address, city, state, zip code, country and phone number are mandatory fields. Please go back and specify the full shipping address. Thank you. This result was found with a quick-and-dirty distributed search program, which I wrote when I realized that the cypherpunks were going to be a few weeks late with their collective effort. When the program was running, it took little more than one week to find the key (it would have taken about 15 days to sweep the entire key space). I ran it on almost all the machines I have access to, summarized in the following table: type speed (keys/s) number notes - -------------------------------------------------------- DEC (alpha) 18000-33000 34 DEC (MIPS) 2500-7500 11 SPARC 2000-13000 57 HP (HPPA/snake) 15000 3 Sony (R3000) 1100-4000 3 Sun 3 600 2 Sequent B8000 100 x 10 1 (1) Multimax (NS532) 600 x 14 1 (1) KSR 3200 x 64 1 (1) (2) Notes: 1. These are multiprocessor machines 2. The KSR spent only about 2 days on this computation. The total average searching speed was about 850000 keys/s, with a maximum of 1350000 keys/s (1150000 without the KSR). Conclusions: * Many people have access to the amount of computing power that I used. The exportable SSL protocol is supposed to be weak enough to be easily broken by governments, yet strong enough to resist the attempts of amateurs. It fails on the second count. Don't trust your credit card number to this protocol. * Cypherpunks write code, all right, but they shouldn't forget to run it. I want to thank the people at INRIA, Ecole Polytechnique, and Ecole Normale Superieure for giving their CPU time. (Most of them are on vacation anyway...) You can find a copy of this text at -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCSAwUBMDG4dVNZwSQVabihAQGeFAPnUZil4WlauoMke9HaULDNOVf1hLXS0i9U VJWZsPHcihDbn6nBN9T6f3sW/S08N5YJFSCmuZzqO59c0nOAKILb6a3TsXjFEcu8 W8UfwFsZa6gx7iuYqandhoHBEkkc5NSwMe1f+lPiV2MdclzQ4/VtZ7Oa1VB+RftD Am4+w/Y= =Fju1 -----END PGP SIGNATURE----- **** This is a timestamp of the above message: -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQBVAwUAMDGsOeWrvYiumrHZAQF0QwIAnDWdVVTiVmUTY5lp08yPeLRoFetczb+U E0WVgTUJ4a16tinOPaJl/6jOpPUUPWMjkDaD2N1xw8lGqm0UgZJiGIkAkgMFATAx uKJTWcEkFWm4oQEBAQ8D5ixvYrpEAQYfeNXmbB46BTTnBwBPS/JjfVFEEnC0Zsoj cyh/WELUsZf785b23vEq9JFvZB+bq1UsJTpttl335TrW344ZYof3kl6fdEF2Jf5q LxQjkuP9s/OQX5iJZpHz4LUxbb+/hOwSdZ2O3LV7ETiHs9AK1+bnKfOGDyei =qO7V -----END PGP MESSAGE----- From owner-saag Fri Sep 1 16:18:00 1995 Received: from relay.tis.com by neptune.TIS.COM id aa06595; 1 Sep 95 16:18 EDT Received: from big-screw.mit.edu(18.72.0.176) by relay.tis.com via smap (g3.0.1) id xma004617; Fri, 1 Sep 95 16:07:54 -0400 Received: by big-screw id AA23873; Fri, 1 Sep 95 16:18:03 -0400 Date: Fri, 1 Sep 95 16:18:03 -0400 Message-Id: <9509012018.AA23873@big-screw> From: "Jeffrey I. Schiller" Sender: jis@mit.edu To: minutes@cnri.reston.va.us Subject: IETF Security Area Report (July 17-21, 1995: 33rd IETF meeting) Cc: secdir@TIS.COM, saag@TIS.COM -----BEGIN PGP SIGNED MESSAGE----- IETF Security Area Report Jeff Schiller and Jim Galvin jis@mit.edu galvin@tis.com July 17-21, 1995 The Security Area within the IETF is responsible for development of security oriented protocols, security review of RFCs, development of candidate policies, and review of operational security on the Internet. The Area Director is assisted by a Directorate, an advisory entity with no standards-setting powers. The members of the Security Directorate are as follows. Jeffrey I. Schiller Ran Atkinson Steve Bellovin Steve Crocker Barbara Fraser James M. Galvin Phil Karn Steve Kent John Linn Clifford Neuman Rob Shirey Ted Ts'o In addition to the Directorate the Security Area is assisted by the Security Area Advisory Group (SAAG). The SAAG is an open group that meets at least once during each IETF meeting as well as electronically via the saag@tis.com mailing list. Send a message to the address saag-request@tis.com to join the list. During the Security Area Advisory Group (SAAG) meeting, the activities of the Security Area, including the Directorate, are reported and discussed. In addition, the SAAG meeting provides an opportunity for open discussion of security issues. Included below is a summary from those working groups and birds of a feather sessions with security relevant activities to report and the Security Directorate meeting summary. In addition, the following topics were discussed during the SAAG meeting. o Documents Approved as Proposed Standards The IESG approved the advancement of five of the IPSEC documents to proposed standards. With the advancement of these documents the IPSEC working group will focus on issues related to key management. The IESG approved the advancement of the two MOSS documents to proposed standards. With the advancement of these documents the PEM working group has completed its charter and will be closed. o Domain Name System Security The last revision of the enhancements for the DNS to support security has been released. It will enter working group last call very soon; no issues are expected to be raised. At the end of the working group last call the document will be submitted to the IESG to be considered for publication as a Proposed Standard. An implementation of the specification is available to U.S. and Canadian sites and individuals via anonymous FTP (see ftp://ftp.tis.com/pub/DNSSEC/README for details). o Key Management It was noted that the Internet needs two kinds of key management: one for short-term keys and one for long-term keys. The expected usage of short-term keys would be on a per connection or per message basis. Long-term keys, on the other hand, would probably be used to exchanged short-term keys. The distribution and management of long-term keys requires the existence of a global infrastructure. There are two options for the global infrastructure today: Secure DNS or The Directory (X.500). It is also possible that something completely different will be needed and developed. Key management is expected to get increasing attention in the IETF. o Internet Security Architecture Steve Crocker gave an abbreviated version of his presentation to the IAB the previous evening. He posed a challenge to the community to improve the network security at IETF meetings. The specific proposal is to have IPSEC available with manual keying, which would be enough to make a difference when compared to the current configuration. This should be available for use in the IETF terminal room by both the terminals/workstations and laptops. In addition, we should install a demonstration firewall that is IPSEC friendly. The goal is to make it available at the next IETF meeting in Dallas (December 4-8, 1995). The activity of the following working groups and birds of a feather sessions was reported. o Secure Socket Layer (SSL) BOF A consensus developed for the need for a session layer security protocol. This was predicated on observing that IPSEC is below the transport layer and the session layer is above it, and that implementing security in the transport or network layer would require changes to operating systems. In contrast, session layer security could be implemented and added non-invasively to existing systems, thus making security services available to a broad range of application protocols. As a result, a working group called Session Layer Security will be proposed. The Secure Socket Layer specification will serve as the starting point for the new working group. o Internet Secure Payments Protocol (ISPP) BOF This BOF met two times with more than a dozen technology presentations. Fortunately, the various technologies are much more similar than they are different. The consensus was that the IETF should have one or more working groups in this area. Charters will be proposed and submitted to the area director for consideration. o Simple Key Management for IP (SKIP) BOF SKIP is Sun's proposal for key management on the Internet. It is a competitor to the Photouris specification being discussed in IPSEC. It is still undecided as to whether this specification should be discussed as part of the IPSEC working group or within its own working group. Although there appeared to be consensus to move the SKIP specification onto the standards track, the authors will need to discuss the process and relationship to IPSEC with the area director and the Chairs of the IPSEC working group before this can be done. [Note: Since the IETF meeting took place discussions between the various parties are proceeding. The likely outcome will be for the SKIP work to take place within the IPSEC working group.] o Authenticated Firewall Traversal (AFT) There are currently four implementations underway with interoperability testing expected to begin shortly. If the testing is successful three documents will be submitted to the IESG to be considered for publication as Proposed Standards before the next IETF meeting in Dallas. o Common Authentication Technology (CAT) The CAT working group discussed topics related to active documents, including GSS-V2 (to receive another set of specific revisions at the Internet-Draft level, and then to be recommended for advancement to Proposed Standards), IDUP (where revised interface specifications and a new mechanism specification were discussed, with standards advancement to be considered at the Dallas IETF), GSS-API Negotiation (new draft discussed), Kerberos mechanism and extensions (status and comments discussed, new drafts to follow), FTP Security (to be recommended for advancement to Proposed Standard after inclusion of clarifying revisions), and a presentation of a new mechanism based on FIPS PUB JJJ cryptography. Presentations on work in progress included GSS-API integration into World-Wide Web browsers and servers, loadable GSS-API multi-mechanism support, and discussion of the use of RFC-1731 as a generic framework for integration of security tokens into text-based applications. The group also discussed a range of candidate follow-on topic areas related to authorization, and identified a subset with apparent common value and feasibility for proposals and work by group members. o Web Transaction Security (WTS) There were three short presentations on related subjects and a review of the two documents being developed by the working group. With respect to the requirements specification, several new issues were raised at this meeting and most, but not all, were resolved. There was consensus to resolve the remaining issues on the list and then submit the document to the IESG to be considered for publication as an information RFC. Recent changes to the SHTTP document were reviewed and no objections were raised. An outstanding issue is coordinating SHTTP with MOSS, which is dependent on the harder (and outside our scope) problem of coordinating HTTP with MIME. We remain hopeful that we will reach consensus on a document to propose to advance to Proposed Standard by the next IETF meeting Dallas. o IP Security (IPSEC) The interoperability testing of the recently approved Proposed Standards was discussed. The majority of the meeting was devoted to discussing Internet key management and the two working documents on Photouris and ISAKMP. o Site Security Handbook (SSH) Two documents are expected to be available by the first week of November, which will allow for final revisions to be proposed during the next IETF meeting in Dallas followed by advancing the documents onto the standards track as quickly as possible. The Security Area Directorate met on Monday afternoon for a 2 hour meeting. In addition to all of the above, the following was noted. o Intellectual Property Rights (IPR) The purpose of the discussion was information exchange. Several protocols are pending in the IESG as a result of unresolved IPR issues and several protocols from the security area are about to be submitted to the IESG with unresolved IPR issues. It is uncertain exactly what the outcome will be of any specific case. o Key-ed MD5 Key-ed MD5 is being used in a variety of protocols for authentication. The IETF needs an applicability statement which includes advice on how often to change the secrets. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMEdqFMUtR20Nv5BtAQELhwP/eTwVc+07AA19P0Q7KdfHxTAaNjnsPBRY 4bb2ekatHDaL5oVH2bbad1DECgOVU2Y0tKBXBNO3Pw1vQiMOV874ZeMIWNtcuxJE MUcd9PLXekRoIUGmUdQMdnVhGEhb4NWPAi6KXzkWRxLN0wZNG9tyjkb7qLCo0dLe +98gDe4dO1c= =2CtY -----END PGP SIGNATURE-----