Mailing list archive ipsec, Jan 10 through Mar 19, 1996

Hemma:

1. I think that there should be one method for encoding Diffie-Hellman 
public values in the Internet, and the method descrived in PKCS#3 is fine 
by me.

2. I agree with Warwick Ford's response regarding ipAddress.  I prefer the 
use of the alternate name extension rather than defining a new Attribute 
Value Assertion (AVA) component that can be used in Distinguished Names.  
In my experience with the Defense Message System (DMS), adding AVA that can 
appear in Distinguished Names has ripple effects in many system components, 
including directories and client certificate path valaidation software.  
The use of the extension significantly reduces the ripple effect.

3. Compiling an OID list would be a big task.  The fact that OIDs can be 
assigned without coordination is a technical benifit of OIDs, but it makes 
it nearly impossible to compile a "definitive" list.  Perhaps advertising a 
registry would work.  People who assign OIDs could place an entry in the 
registery if they think that someone else would benifit from the same OID 
assignment.  This voluntary sharing would be a very useful service.

Russ

Xref subject next

------------------------------------------------------------------------------

                THE INTERNET SOCIETY 1996 SYMPOSIUM ON
                NETWORK AND DISTRIBUTED SYSTEM SECURITY
                               (NDSS '96)

                          22-23 FEBRUARY 1996

            SAN DIEGO PRINCESS RESORT, SAN DIEGO, CALIFORNIA

The symposium will bring together people who are building software
and/or hardware to provide network and distributed system security
services.  The symposium is intended for those interested in the more
practical aspects of network and distributed system security, focusing
on actual system design and implementation, rather than in theory.  We
hope to foster the exchange of technical information that will
encourage and enable the Internet community to apply, deploy and
advance the state of the available security technology.

------------------------------------------------------------------------------

                 P R E L I M I N A R Y   P R O G R A M


WEDNESDAY, FEBRUARY 21

6:00 P.M. - 8:00 P.M.
RECEPTION

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

THURSDAY, FEBRUARY 22

7:30 A.M.
CONTINENTAL BREAKFAST

8:30 A.M.
OPENING REMARKS

9:00 A.M.
SESSION 1: ELECTRONIC MAIL SECURITY
Chair: Stephen T. Kent (BBN Corporation, USA)

    Mixing E-mail with BABEL, Gene Tsudik and Ceki Gulcu (IBM
    Research Division, Zurich Research Laboratory, SWITZERLAND)
    
    An Integration of PGP and MIME, Kazuhiko Yamamoto (Nara
    Institute of Science and Technology, JAPAN)
    
10:00 A.M.
BREAK

10:30 A.M.
SESSION 2: DISTRIBUTED OBJECT SYSTEMS
Chair: Dan Nessett (Sun Microsystems, USA)

    A Security Framework Supporting Domain Based Access Control in
    Distributed Systems, Nicholas Yialelis and Morris Sloman
    (Imperial College, London, UNITED KINGDOM)
    
    PANEL: Scalability of Security in Distributed Object Systems
    Chair: Dan Nessett (Sun Microsystems, USA)
    Panelists: Dan Nessett (Sun Microsystems, USA), Nicholas Yialelis 
    (Imperial College, London, UNITED KINGDOM), and Bret Hartman (Odyssey
    Research Associates, USA)

12:00 NOON
LUNCH

1:30 P.M.
SESSION 3: DISTRIBUTED SYSTEM SECURITY
Chair: Michael Roe (University of Cambridge, UNITED KINGDOM)

    A Flexible Distributed Authorization Protocol, Jonathan Trostle 
    (CyberSAFE, USA) and B. Clifford Neuman (Information Sciences 
    Institute, University of Southern California, USA)
    
    Preserving Integrity in Remote File Location and Retrieval, Trent
    Jaeger (University of Michigan, USA) and Aviel D. Rubin (Bellcore, USA)
    
    C-HTTP - The Development of a Secure, Closed HTTP-Based Network on the
    Internet, Takahiro Kiuchi (University of Tokyo, JAPAN)
    and Shigekoto Kaihara (University of Tokyo Hospital, JAPAN)

3:00 P.M.
BREAK

3:30 P.M.
SESSION 4: PANEL: INTELLECTUAL PROPERTY PROTECTION
Chair: Peter Neumann (SRI International, USA)
Panelists: David Bernstein (Electronic Publishing Resources, USA), 
Russ Housley (Spyrus, USA), and Dan Boneh (Princeton University, USA)

7:00 P.M.
DINNER BANQUET

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

FRIDAY, FEBRUARY 23

7:30 A.M.
CONTINENTAL BREAKFAST

8:30 A.M.
SESSION 5: NETWORK SECURITY
Chair: Matt Bishop (University of California at Davis, USA)

    Designing an Academic Firewall: Policy, Practice and Experience with 
    SURF, Michael B. Greenwald, Sandeep K. Singhal, Jonathan R. Stone, 
    and David R. Cheriton (Stanford University, USA)
    
    Digital Signature Protection of the OSPF Routing Protocol, Sandra
    Murphy and Madelyn Badger (Trusted Information Systems, USA)
    
    A Case Study of Secure ATM Switch Booting, Shaw-Cheng Chuang and
    Michael Roe (University of Cambridge, UNITED KINGDOM)
    
10:00 A.M.
BREAK

10:30 A.M.
SESSION 6: KEY MANAGEMENT
Chair: Burt Kaliski (RSA Laboratories, USA)

    SKEME: A Versatile Secure Key Exchange Mechanism for Internet,
    Hugo Krawczyk (IBM T.J. Watson Research Center, USA)

    IDUP and SPKM:  Developing Public-Key-Based APIs and Mechanisms for 
    Communication Security Services, Carlisle Adams (Bell-Northern Research,
    CANADA)

11:30 A.M.
LUNCH

1:00 P.M.
SESSION 7: ENCRYPTION
Chair: Paul Lambert (Oracle, USA)

    An Empirical Study of Secure MPEG Video Transmissions, Iskender
    Agi and Li Gong (SRI International, USA)
    
    Parallelized Network Security Protocols, Erich Nahum and David J. Yates
    (University of Massachusetts, USA), Sean O'Malley, Hilarie Orman and 
    Richard Schroeppel (University of Arizona, USA)
    
    A "Bump in the Stack" Encryptor for MS-DOS Systems, David A.
    Wagner (University of California at Berkeley, USA) and Steven M. Bellovin 
    (AT&T Bell Laboratories, USA)

2:30 P.M.
BREAK

3:00 P.M.
SESSION 8: PANEL: PUBLIC-KEY INFRASTRUCTURE
Chair: Warwick Ford (Bell Northern Research, CANADA)
Panelists: John Wankmueller (MasterCard International, USA), Taher ElGamal 
(Netscape Communications, USA), and Michael Baum (VeriSign, USA).


------------------------------------------------------------------------------

GENERAL CHAIR:
   Jim Ellis, CERT Coordination Center

PROGRAM CHAIRS:
   David Balenson, Trusted Information Systems
   B. Clifford Neuman, USC Information Sciences Institute

PROGRAM COMMITTEE:
   Tom Berson, Anagram Laboratories
   Matt Bishop, University of California at Davis
   Doug Engert, Argonne National Laboratory
   Warwick Ford, Bell Northern Research (Canada)
   Burt Kaliski, RSA Laboratories
   Steve Kent, BBN Corporation
   Paul Lambert, Oracle
   John Linn, OpenVision Technologies
   Teresa Lunt, Advanced Research Projects Agency
   Dan Nessett, Sun Microsystems
   Hilarie Orman, University of Arizona
   Michael Roe, Cambridge University (UK)
   Rob Rosenthal, U.S. National Institute of Standards and Technology
   Avi Rubin, Bellcore
   Jeff Schiller, Massachusetts Institute of Technology
   Rob Shirey, BBN Corporation
   Doug Tygar, Carnegie Mellon University
   Roberto Zamparo, Telia Research (Sweden)

LOCAL ARRANGEMENTS CHAIR:
   Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
   Steve Welke, Institute for Defense Analyses

REGISTRATIONS CHAIR:
   Donna Leggett, Internet Society

STEERING GROUP
   Internet Research Task Force, Privacy and Security Research Group

------------------------------------------------------------------------------

BEAUTIFUL SAN DIEGO PRINCESS RESORT

                              Location

The Symposium venue is the San Diego Princess Resort, a tropical
paradise on a forty-four acre island in Mission Bay, ten minutes from
the international airport.  Lush gardens landscaped with hundreds of
species of tropical and subtropical plants are always ablaze with color
and perfect for themed group events.  Charming pathways wander among
sparkling waterfalls, across quaint footbridges and sleepy lagoons
filled with water lilies and waterfowl.  A white sand beach curves
around the island for over a mile, and the award-winning grounds
encompass five swimming pools and six lighted tennis courts.

Spouses and family members can catch a convenient Harbor Hopper for a
quick trip to Sea World.  After the Symposium, plan to spend the
weekend visiting La Jolla, the world famous San Diego Zoo or Mexico,
only 30 minutes by car or Trolley.

                         Housing Information

We have reserved a special block of sleeping rooms at the San Diego
Princess Resort at the following rates:

    Lanai Patio & Garden View Rooms                 $ 81*
    Lanai Garden & Lagoon View Rooms                $112
    One Bedroom Suite                               $115

* This represents the Government Rate for San Diego.  We have a limited
  number of rooms available at this rate.  If you need a government rate,
  reserve your room early!  You must present a valid government id upon 
  check- in.

Based on room type and space availability, these special group rates
are applicable two days prior to and two days after the symposium.
Current Room Tax is 10.5%.

Check-in availability cannot be committed prior to 4:00 p.m. Check-out
time is 12:00 noon. The San Diego Princess Resort will make every
effort to accommodate any early arrivals, so make sure you give them
your arrival time when you make your reservation.

                       To make a reservation

Contact the San Diego Princess Resort at 1-800-344-2626
(+1-619-274-4630 if outside the United States).  To receive the special
group rates, reservations must be made no later than January 20, 1996.


CLIMATE

February weather in San Diego is normally very pleasant.  Early morning 
temperatures average 55 degrees while afternoon temperatures average 67
degrees.  Generally, a light jacket or sweater is adequate during February;
although, occasionally it rains.


REGISTRATION FEES
                                ISOC            Non-
                                Members         Member
Early registration 
(postmarked by Jan. 19)         $295            $330

Late registration               $365            $400

REGISTRATION INCLUDES

- Attendance        - Symposium Proceedings     - Two luncheons
- Reception         - Banquet                   - Coffee Breaks

FOR MORE INFORMATION on registration contact Donna Leggett by phone at 
703-648-9888 or via e-mail to Ndss96reg@isoc.org.

WEB PAGE - Additional information about the symposium and San Diego, 
as well as an on-line registration form, are available via the Web at:

              http://www.isoc.org/conferences/ndss96

------------------------------------------------------------------------------
Internet Society Symposium on Network and Distributed System Security
22-23 February, 1996     San Diego, California, USA

Registration Form

---------------------------------------------------------------------------
Fill out this form and FAX it to NDSS'96 Registration (703) 648-9887,
send it via electronic mail to Ndss96reg@isoc.org, or mail it to NDSS96,
12020 Sunrise Valley Drive, Suite 210, Reston, VA, 22091, USA
---------------------------------------------------------------------------

Personal Information

__Mr __Ms __Mrs __Dr __Prof __M __Prof Dr __Dip Ing __Ing __Miss __Mlle

First Name:         __________________________  Middle Name:  _______________

Family Name:        __________________________     __sr __jr __II __III __PhD

Please enter your name as you would like it to appear on your conference
name tag.

Badge Name:         _____________________________

Contact Information

Your title:         _____________________________

Your affiliation:   _____________________________

Your address:       _____________________________

                    _____________________________

City:               _____________________________

State or Province:  _____________________________ Postal Code: _____________

Country:            _____________________________

Tel (work) Number:  _____________________________

Tel (home) Number:  _____________________________

Fax Number:         _____________________________

EMail address:      _____________________________

Special Needs?

Do you have any special needs (vegetarian meals, wheelchair access, etc?):

_________________________________________________________________________

_________________________________________________________________________

Appear on the Registrants List?

___  Please check here if you would NOT like your name included in the
     list of registrants.

Payment Information

All Payments must be in United States Dollars.

Conference Charges

If you are an Internet Society member, you are eligible for a reduced
registration fee.  Non-member symposium attendees will receive a one year
Internet Society membership as part of the non-member registration fees.

Check one:                                    Before        After
                                            January 19    January 19
                                            ----------    ----------
___Internet Society Member Conference Fee   US$ 295.00    US$ 365.00

___Non-Member Conference Fee                US$ 330.00    US$ 400.00

Method of Payment

1. __ Check

   Make payable to the Internet Society.  Checks must be postmarked before
   February 16, 1996 or you will not be registered.

2. __ Credit Card
          __ American Expres
          __ Mastercard
          __ Visa

           Name on Credit Card:__________________________

            Credit Card Number:__________________________

               Expiration Date:__________

3. __ First Virtual

   First Virtual Account Number: _________________________

4. __ Wire Transfer*

   Riggs Bank of Virginia     Bank ABA number: 056001260
   8315 Lee Highway           Account number: Internet Society 148 387 10
   Fairfax  VA  22031
   USA

         Wire Transfer Confirmation Number:____________________________

   * Please process wire transfer before sending the registration form.

5. __ U.S. Government Purchase order*

            Please provide the P.O. Number: ___________________________

   * Please fax or mail a copy of your purchase order along with your
     registration form.

Cancellation Policy
-------------------

Refunds will be issued for cancellations received before February 16, 1996.
No refunds will be issued after February 16, 1996.

---------------------------------------------------------------------------

Xref subject next

--NextPart

A Revised Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Domain Name System Security 
Working Group of the IETF.                                                 

       Title     : Domain Name System Security Extensions                  
       Author(s) : D. Eastlake, C. Kaufman
       Filename  : draft-ietf-dnssec-secext-08.txt
       Pages     : 45
       Date      : 01/05/1996

The Domain Name System (DNS) has become a critical operational part of the 
Internet infrastructure yet it has no strong security mechanisms to assure 
data integrity or authentication.  Extensions to the DNS are described that
provide these services to security aware resolvers or applications through 
the use of cryptographic digital signatures.  These digital signatures are 
included in secured zones as resource records.  Security can still be 
provided even through non-security aware DNS servers in many cases.       

The extensions also provide for the storage of authenticated public keys in
the DNS.  This storage of keys can support general public key distribution 
service as well as DNS security.  The stored keys enable security aware 
resolvers to learn the authenticating key of zones in addition to those for
which they are initially configured.  Keys associated with DNS names can be
retrieved to support other protocols.  Provision is made for a variety of 
key types and algorithms.    

In addition, the security extensions provide for the optional 
authentication of DNS protocol transactions.              

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-dnssec-secext-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-08.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-dnssec-secext-08.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: <19960105170813.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-secext-08.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-dnssec-secext-08.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960105170813.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous

------------------------------------------------------------------------------

                THE INTERNET SOCIETY 1996 SYMPOSIUM ON
                NETWORK AND DISTRIBUTED SYSTEM SECURITY
                               (NDSS '96)

                          22-23 FEBRUARY 1996

            SAN DIEGO PRINCESS RESORT, SAN DIEGO, CALIFORNIA

The symposium will bring together people who are building software
and/or hardware to provide network and distributed system security
services.  The symposium is intended for those interested in the more
practical aspects of network and distributed system security, focusing
on actual system design and implementation, rather than in theory.  We
hope to foster the exchange of technical information that will
encourage and enable the Internet community to apply, deploy and
advance the state of the available security technology.

------------------------------------------------------------------------------

                 P R E L I M I N A R Y   P R O G R A M


WEDNESDAY, FEBRUARY 21

6:00 P.M. - 8:00 P.M.
RECEPTION

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

THURSDAY, FEBRUARY 22

7:30 A.M.
CONTINENTAL BREAKFAST

8:30 A.M.
OPENING REMARKS

9:00 A.M.
SESSION 1: ELECTRONIC MAIL SECURITY
Chair: Stephen T. Kent (BBN Corporation, USA)

    Mixing E-mail with BABEL, Gene Tsudik and Ceki Gulcu (IBM
    Research Division, Zurich Research Laboratory, SWITZERLAND)
    
    An Integration of PGP and MIME, Kazuhiko Yamamoto (Nara
    Institute of Science and Technology, JAPAN)
    
10:00 A.M.
BREAK

10:30 A.M.
SESSION 2: DISTRIBUTED OBJECT SYSTEMS
Chair: Dan Nessett (Sun Microsystems, USA)

    A Security Framework Supporting Domain Based Access Control in
    Distributed Systems, Nicholas Yialelis and Morris Sloman
    (Imperial College, London, UNITED KINGDOM)
    
    PANEL: Scalability of Security in Distributed Object Systems
    Chair: Dan Nessett (Sun Microsystems, USA)
    Panelists: Dan Nessett (Sun Microsystems, USA), Nicholas Yialelis 
    (Imperial College, London, UNITED KINGDOM), and Bret Hartman (Odyssey
    Research Associates, USA)

12:00 NOON
LUNCH

1:30 P.M.
SESSION 3: DISTRIBUTED SYSTEM SECURITY
Chair: Michael Roe (University of Cambridge, UNITED KINGDOM)

    A Flexible Distributed Authorization Protocol, Jonathan Trostle 
    (CyberSAFE, USA) and B. Clifford Neuman (Information Sciences 
    Institute, University of Southern California, USA)
    
    Preserving Integrity in Remote File Location and Retrieval, Trent
    Jaeger (University of Michigan, USA) and Aviel D. Rubin (Bellcore, USA)
    
    C-HTTP - The Development of a Secure, Closed HTTP-Based Network on the
    Internet, Takahiro Kiuchi (University of Tokyo, JAPAN)
    and Shigekoto Kaihara (University of Tokyo Hospital, JAPAN)

3:00 P.M.
BREAK

3:30 P.M.
SESSION 4: PANEL: INTELLECTUAL PROPERTY PROTECTION
Chair: Peter Neumann (SRI International, USA)
Panelists: David Bernstein (Electronic Publishing Resources, USA), 
Russ Housley (Spyrus, USA), and Dan Boneh (Princeton University, USA)

7:00 P.M.
DINNER BANQUET

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

FRIDAY, FEBRUARY 23

7:30 A.M.
CONTINENTAL BREAKFAST

8:30 A.M.
SESSION 5: NETWORK SECURITY
Chair: Matt Bishop (University of California at Davis, USA)

    Designing an Academic Firewall: Policy, Practice and Experience with 
    SURF, Michael B. Greenwald, Sandeep K. Singhal, Jonathan R. Stone, 
    and David R. Cheriton (Stanford University, USA)
    
    Digital Signature Protection of the OSPF Routing Protocol, Sandra
    Murphy and Madelyn Badger (Trusted Information Systems, USA)
    
    A Case Study of Secure ATM Switch Booting, Shaw-Cheng Chuang and
    Michael Roe (University of Cambridge, UNITED KINGDOM)
    
10:00 A.M.
BREAK

10:30 A.M.
SESSION 6: KEY MANAGEMENT
Chair: Burt Kaliski (RSA Laboratories, USA)

    SKEME: A Versatile Secure Key Exchange Mechanism for Internet,
    Hugo Krawczyk (IBM T.J. Watson Research Center, USA)

    IDUP and SPKM:  Developing Public-Key-Based APIs and Mechanisms for 
    Communication Security Services, Carlisle Adams (Bell-Northern Research,
    CANADA)

11:30 A.M.
LUNCH

1:00 P.M.
SESSION 7: ENCRYPTION
Chair: Paul Lambert (Oracle, USA)

    An Empirical Study of Secure MPEG Video Transmissions, Iskender
    Agi and Li Gong (SRI International, USA)
    
    Parallelized Network Security Protocols, Erich Nahum and David J. Yates
    (University of Massachusetts, USA), Sean O'Malley, Hilarie Orman and 
    Richard Schroeppel (University of Arizona, USA)
    
    A "Bump in the Stack" Encryptor for MS-DOS Systems, David A.
    Wagner (University of California at Berkeley, USA) and Steven M. Bellovin 
    (AT&T Bell Laboratories, USA)

2:30 P.M.
BREAK

3:00 P.M.
SESSION 8: PANEL: PUBLIC-KEY INFRASTRUCTURE
Chair: Warwick Ford (Bell Northern Research, CANADA)
Panelists: John Wankmueller (MasterCard International, USA), Taher ElGamal 
(Netscape Communications, USA), and Michael Baum (VeriSign, USA).


------------------------------------------------------------------------------

GENERAL CHAIR:
   Jim Ellis, CERT Coordination Center

PROGRAM CHAIRS:
   David Balenson, Trusted Information Systems
   B. Clifford Neuman, USC Information Sciences Institute

PROGRAM COMMITTEE:
   Tom Berson, Anagram Laboratories
   Matt Bishop, University of California at Davis
   Doug Engert, Argonne National Laboratory
   Warwick Ford, Bell Northern Research (Canada)
   Burt Kaliski, RSA Laboratories
   Steve Kent, BBN Corporation
   Paul Lambert, Oracle
   John Linn, OpenVision Technologies
   Teresa Lunt, Advanced Research Projects Agency
   Dan Nessett, Sun Microsystems
   Hilarie Orman, University of Arizona
   Michael Roe, Cambridge University (UK)
   Rob Rosenthal, U.S. National Institute of Standards and Technology
   Avi Rubin, Bellcore
   Jeff Schiller, Massachusetts Institute of Technology
   Rob Shirey, BBN Corporation
   Doug Tygar, Carnegie Mellon University
   Roberto Zamparo, Telia Research (Sweden)

LOCAL ARRANGEMENTS CHAIR:
   Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
   Steve Welke, Institute for Defense Analyses

REGISTRATIONS CHAIR:
   Donna Leggett, Internet Society

STEERING GROUP
   Internet Research Task Force, Privacy and Security Research Group

------------------------------------------------------------------------------

BEAUTIFUL SAN DIEGO PRINCESS RESORT

                              Location

The Symposium venue is the San Diego Princess Resort, a tropical
paradise on a forty-four acre island in Mission Bay, ten minutes from
the international airport.  Lush gardens landscaped with hundreds of
species of tropical and subtropical plants are always ablaze with color
and perfect for themed group events.  Charming pathways wander among
sparkling waterfalls, across quaint footbridges and sleepy lagoons
filled with water lilies and waterfowl.  A white sand beach curves
around the island for over a mile, and the award-winning grounds
encompass five swimming pools and six lighted tennis courts.

Spouses and family members can catch a convenient Harbor Hopper for a
quick trip to Sea World.  After the Symposium, plan to spend the
weekend visiting La Jolla, the world famous San Diego Zoo or Mexico,
only 30 minutes by car or Trolley.

                         Housing Information

We have reserved a special block of sleeping rooms at the San Diego
Princess Resort at the following rates:

    Lanai Patio & Garden View Rooms                 $ 81*
    Lanai Garden & Lagoon View Rooms                $112
    One Bedroom Suite                               $115

* This represents the Government Rate for San Diego.  We have a limited
  number of rooms available at this rate.  If you need a government rate,
  reserve your room early!  You must present a valid government id upon 
  check- in.

Based on room type and space availability, these special group rates
are applicable two days prior to and two days after the symposium.
Current Room Tax is 10.5%.

Check-in availability cannot be committed prior to 4:00 p.m. Check-out
time is 12:00 noon. The San Diego Princess Resort will make every
effort to accommodate any early arrivals, so make sure you give them
your arrival time when you make your reservation.

                       To make a reservation

Contact the San Diego Princess Resort at 1-800-344-2626
(+1-619-274-4630 if outside the United States).  To receive the special
group rates, reservations must be made no later than January 20, 1996.


CLIMATE

February weather in San Diego is normally very pleasant.  Early morning 
temperatures average 55 degrees while afternoon temperatures average 67
degrees.  Generally, a light jacket or sweater is adequate during February;
although, occasionally it rains.


REGISTRATION FEES
                                ISOC            Non-
                                Members         Member
Early registration 
(postmarked by Jan. 19)         $295            $330

Late registration               $365            $400

REGISTRATION INCLUDES

- Attendance        - Symposium Proceedings     - Two luncheons
- Reception         - Banquet                   - Coffee Breaks

FOR MORE INFORMATION on registration contact Donna Leggett by phone at 
703-648-9888 or via e-mail to Ndss96reg@isoc.org.

WEB PAGE - Additional information about the symposium and San Diego, 
as well as an on-line registration form, are available via the Web at:

              http://www.isoc.org/conferences/ndss96

------------------------------------------------------------------------------
Internet Society Symposium on Network and Distributed System Security
22-23 February, 1996     San Diego, California, USA

Registration Form

---------------------------------------------------------------------------
Fill out this form and FAX it to NDSS'96 Registration (703) 648-9887,
send it via electronic mail to Ndss96reg@isoc.org, or mail it to NDSS96,
12020 Sunrise Valley Drive, Suite 210, Reston, VA, 22091, USA
---------------------------------------------------------------------------

Personal Information

__Mr __Ms __Mrs __Dr __Prof __M __Prof Dr __Dip Ing __Ing __Miss __Mlle

First Name:         __________________________  Middle Name:  _______________

Family Name:        __________________________     __sr __jr __II __III __PhD

Please enter your name as you would like it to appear on your conference
name tag.

Badge Name:         _____________________________

Contact Information

Your title:         _____________________________

Your affiliation:   _____________________________

Your address:       _____________________________

                    _____________________________

City:               _____________________________

State or Province:  _____________________________ Postal Code: _____________

Country:            _____________________________

Tel (work) Number:  _____________________________

Tel (home) Number:  _____________________________

Fax Number:         _____________________________

EMail address:      _____________________________

Special Needs?

Do you have any special needs (vegetarian meals, wheelchair access, etc?):

_________________________________________________________________________

_________________________________________________________________________

Appear on the Registrants List?

___  Please check here if you would NOT like your name included in the
     list of registrants.

Payment Information

All Payments must be in United States Dollars.

Conference Charges

If you are an Internet Society member, you are eligible for a reduced
registration fee.  Non-member symposium attendees will receive a one year
Internet Society membership as part of the non-member registration fees.

Check one:                                    Before        After
                                            January 19    January 19
                                            ----------    ----------
___Internet Society Member Conference Fee   US$ 295.00    US$ 365.00

___Non-Member Conference Fee                US$ 330.00    US$ 400.00

Method of Payment

1. __ Check

   Make payable to the Internet Society.  Checks must be postmarked before
   February 16, 1996 or you will not be registered.

2. __ Credit Card
          __ American Expres
          __ Mastercard
          __ Visa

           Name on Credit Card:__________________________

            Credit Card Number:__________________________

               Expiration Date:__________

3. __ First Virtual

   First Virtual Account Number: _________________________

4. __ Wire Transfer*

   Riggs Bank of Virginia     Bank ABA number: 056001260
   8315 Lee Highway           Account number: Internet Society 148 387 10
   Fairfax  VA  22031
   USA

         Wire Transfer Confirmation Number:____________________________

   * Please process wire transfer before sending the registration form.

5. __ U.S. Government Purchase order*

            Please provide the P.O. Number: ___________________________

   * Please fax or mail a copy of your purchase order along with your
     registration form.

Cancellation Policy
-------------------

Refunds will be issued for cancellations received before February 16, 1996.
No refunds will be issued after February 16, 1996.

---------------------------------------------------------------------------

Xref subject previous

--NextPart

A Revised Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Domain Name System Security 
Working Group of the IETF.                                                 

       Title     : Domain Name System Security Extensions                  
       Author(s) : D. Eastlake, C. Kaufman
       Filename  : draft-ietf-dnssec-secext-08.txt
       Pages     : 45
       Date      : 01/05/1996

The Domain Name System (DNS) has become a critical operational part of the 
Internet infrastructure yet it has no strong security mechanisms to assure 
data integrity or authentication.  Extensions to the DNS are described that
provide these services to security aware resolvers or applications through 
the use of cryptographic digital signatures.  These digital signatures are 
included in secured zones as resource records.  Security can still be 
provided even through non-security aware DNS servers in many cases.       

The extensions also provide for the storage of authenticated public keys in
the DNS.  This storage of keys can support general public key distribution 
service as well as DNS security.  The stored keys enable security aware 
resolvers to learn the authenticating key of zones in addition to those for
which they are initially configured.  Keys associated with DNS names can be
retrieved to support other protocols.  Provision is made for a variety of 
key types and algorithms.    

In addition, the security extensions provide for the optional 
authentication of DNS protocol transactions.              

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-dnssec-secext-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-08.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-dnssec-secext-08.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: <19960105170813.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-secext-08.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-dnssec-secext-08.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960105170813.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject next

Hi everybody,

a short question relating to a kind of 'cheating' attack when using
tunnelling mode.

Assume you get an AH/ESP protected ip packet from source A. You check the
authentication, and it is the correct authentication for an association 
you have with node A. Now you decode ESP, and see the payload is IP, thus
you give it back to the IP handling part of your kernel.

+-----------+-------+----+-----+-------------+-------------
+ outer IP  +  AUX  + AH + ESP +  inner IP   +  UDP payload
+ srcaddr = +       +    +     +  srcaddr =  +           
+ 1.2.3.4   +       +    +     +  5.6.7.8    +     
+-----------+-------+----+-----+-------------+-------------

This encapsulated IP packet claims to come from node B, and as part of an
UDP data exchange will be passed up to the application. The application has
been tricked in accepting the packet. Bad.

Does this imply that for each socket/whatever you have to indicate for each
received packet to which SPI it belongs, respectively have to do some 
filtering before passing up data?

I would be very interested in knowing your views concerning this problem...

Friendly greetings,

	Germano Caronni

Xref: Re: Tunneling / Cheating Germano Caronni
Xref subject previous
Xref subject next

> From: Germano Caronni 
> a short question relating to a kind of 'cheating' attack when using
> tunnelling mode.
>
This is not "cheating", this is exactly what is supposed to happen!


> Assume you get an AH/ESP protected ip packet from source A. You check the
> authentication, and it is the correct authentication for an association
> you have with node A. Now you decode ESP, and see the payload is IP, thus
> you give it back to the IP handling part of your kernel.
>
> This encapsulated IP packet claims to come from node B, and as part of an
> UDP data exchange will be passed up to the application. The application has
> been tricked in accepting the packet. Bad.
>
No, Good!  This is not a "trick"!  This is as designed!

The security association is with A.  You trust A.  If the packet from A
is really from another incarnation of A called B, that's fine.  Mobility.

   Internet Security does not place any significance on easily forged IP
   Source addresses.  It relies instead on proof of possession of secret
   knowledge: that is, a cryptographic key.


> Does this imply that for each socket/whatever you have to indicate for each
> received packet to which SPI it belongs, respectively have to do some
> filtering before passing up data?
>
Depends on your API.  Some do, some don't.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

Germano,

        Bill provided you with one answer, based on the model he has
documented in the Photuris spec.  This general topic has been the focus of
some discussion on this list for a couple of weeks.  Some of us are
concerned about the scenario you described, when it occurs in the context
of a router vs. a host.  One can argue that the host has access to identity
info from the SA establishment procedure and can maintain a binding between
that info and whatever packets arrive on the SA, thus avoiding security
problems due the possible difference in IP-layer identities for inner and
outer IP headers.  However, this does not work well at a router (which is
not the ultimate target of the tarffic) and we have no mechanism to pass
back to the target whatever identity info we may have received during SA
establishment.

        The fact that the IP address in the inner header is different from
the outer header is not the problem, as Bill says, it's a feature.  It's
necessary, especially if the other end of the IPSEC SA is another router.
The focus of the debate is whether there ought to be required controls as
part of a tunneling IPSEC implementation (on a router) to constrain the
range of addresses that may be expressed in the inner header.  On that
score, I don't think we yet have a concensus.

Steve

Xref subject previous
Xref subject next

William Allen Simpson wrote:
> > Assume you get an AH/ESP protected ip packet from source A. You check the
> > authentication, and it is the correct authentication for an association
> > you have with node A. Now you decode ESP, and see the payload is IP, thus
> > you give it back to the IP handling part of your kernel.
> >
> > This encapsulated IP packet claims to come from node B, and as part of an
> > UDP data exchange will be passed up to the application. The application has
> > been tricked in accepting the packet. Bad.
> The security association is with A.  You trust A.  If the packet from A
> is really from another incarnation of A called B, that's fine.  Mobility.

Well, yes, I trust A, but I sure would not like A to impersonate B.
An SPI belonging to A is used to send me traffic for B. Just imagine A 
being my news-server, and B my NFS server... 
Germano

Xref: Re: Tunneling / Cheating & diverging assumptions Ran Atkinson
Xref subject previous
Xref subject next

> From: Germano Caronni 
> William Allen Simpson wrote:
> > The security association is with A.  You trust A.  If the packet from A
> > is really from another incarnation of A called B, that's fine.  Mobility.
>
> Well, yes, I trust A, but I sure would not like A to impersonate B.
> An SPI belonging to A is used to send me traffic for B. Just imagine A
> being my news-server, and B my NFS server...
>
How is this a problem?  You trust A as a news-server.  You would never
grant it permission to be your NFS-server, just because it has _any_ SPI
that you recognize.  If the SPI is associated exclusively with your
news-server, that is a parameter in your SA.

If, on the other hand, you gave the same SPI keys to more than one
server, why then your policy must be that either can be the NSF-server.
That policy is entirely up to you!

This is what I understand to be "user-oriented" keying, and requires
some significant changes in the transport and application API.

Note how Karn described his stack earlier.  His SPI really _IS_ an
"index" (which is why I coined the name) used to find the SA parameters.
It is passed up the stack.  The application takes note of the SPI, not
the IP Source.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Folks,

[General note:  Different folks are posting answers that might be valid
	under different implicit assumptions.  It is important that folks'
	try to make very explicit what their assumptions are -- in 
	particular it makes a HUGE difference whether host-oriented keying
	or user-oriented keying is being used for a packet.  I've tried
	to make my own assumptions more clear, but if I've failed to be
	sufficiently clear please don't flame me, just enquire gently. 
	Steve Kent has been consistently precise in his router scenario
	and could stand to be emulated by others in this regard. :-]

>> Well, yes, I trust A, but I sure would not like A to impersonate B.
>> An SPI belonging to A is used to send me traffic for B. Just imagine A
>> being my news-server, and B my NFS server...

In article <4731.bsimpson@morningstar.com> Bill Simpson wrote:
>How is this a problem?  

	Assume that host-oriented keying is in use (this IS explicitly
permitted with IPsec).  With that assumption (very likely to be true when
one has a router encrypting packets originating at some other node), then
the attack outlined at the top is a real threat and comparing inner/outer
source IP addresses is a sufficient defence against that threat.  

  	For this reason, the NRL implementation includes that defence.  

	Also, the NRL implementation of an SA has a field used to store the
address of a "proxy" encryptor (e.g. an encrypting router that is
explicitly trusted to protect some host that can't encrypt its own packets)
so that in future (after we've solved the encrypting router issues that
Steve Kent has carefully outlined) host-oriented keying can safely be used
in this scenario.

> You trust A as a news-server.  You would never
> grant it permission to be your NFS-server, just because it has _any_ SPI
> that you recognize.  If the SPI is associated exclusively with your
> news-server, that is a parameter in your SA.
>
>If, on the other hand, you gave the same SPI keys to more than one
>server, why then your policy must be that either can be the NSF-server.
>That policy is entirely up to you!
>
>This is what I understand to be "user-oriented" keying, and requires
>some significant changes in the transport and application API.

	Your outline above is not _necessarily_ user-oriented keying,
though it might be.  Your text is sufficiently imprecise that it isn't
clear to the reader what your assumptions are.

	Moreover, user-oriented keying, as _already implemented_ in the NRL
IPsec implementation, simply didn't require big changes to BSD.
Essentially, the application now has additional network socket options that
can be set (e.g. authentication required, authentication required with a
unique key, encryption requested but not required, encryption required,
encryption with unique key required).  User-oriented keying is enabled
whenever a unique key is requested via setsockopt() OR whenever the system
administrator has set the minimum system security level to require unique
keying for each session.

	User-oriented keying, which is required to be _implemented_ in
hosts but is NOT required to be _used_ by users, would map an SA to a
particular network socket (and thence implicitly to the owner of that
network socket) OR to a mailbox identifier (and thence it might be
authorisation for any socket owned by the user having that mailbox
identifier).

	The other set of assumptions to watch out for in notes to this list
relate to whether a node is running a single-user operating system
(e.g. KA9Q with DOS, routers based on KA9Q, Windows95, MacOS) or a
multi-user operating system (e.g. UNIX, ClosedVMS, most routers,
WindowsNT).  Between single-user systems, having a key is often implicitly
using user-oriented keying.  From a multi-user system to a single-user
system, possession of the key does not imply user-oriented keying, though
it might have been used that way.  There can be risks if one isn't
thoughtful (e.g. if some user "Bill" has a host-oriented SA between an IETF
workstation and his KA9Q PC, but then some other user "Tony" uses the SA
"Bill" configured on that IETF workstation to improperly access Bill's PC
-- to give a purely hypothetical example :-).  Between multi-user systems,
host-oriented keying cannot be used by itself to distinguish users and
other methods (e.g. logins/passwords) should be used.

Ran
rja@cisco.com

Note 1:
  I use the term "mailbox identifier" to mean the tuple of (userid,
fully-qualified domain name of node).  For example, mine might be expressed
as either (rja, inet.org) or rja@inet.org.

Note 2:
  One of the items that really needs to be fixed in RFC-1825-bis is
specifying what kinds of names are used with IPsec.  Many of our list
discussions would be obviated if we had agreement on naming.  This problem
was noted a year ago but was not fixable then for lack of time.  It needs
to be fixed before Draft Standard, IMHO.  Now would be an appropriate time
for people to explain their preferences on naming.

Xref subject previous

/.

I've placed a release of all of the xkernel software in our ftp area.
This is our protocol development toolkit, with particular pieces that
might be of interest to this community.  Our elliptic curve group over
GF[2^155] subroutines are available, both standalone and for use with
Photuris.  Our implementations of Photuris (draft 08) and AH/ESP are
also included.  This software is not a drop-in Unix library --- the
xkernel runs as a protocol simulator under most standard Unix systems,
or as a supplementary networking facility under Mach3, but it is not
suitable for nor intended for production use.

Sketchy release notes (please read):
ftp://ftp.cs.arizona.edu/xkernel/README.v3.2.sec
The full manual
ftp://ftp.cs.arizona.edu/xkernel/manual-v3.2.security.ps.Z
The entire source base
xkernel.v3.2.security.tar.Z

I've posted a new version.  Other than the date and file name, I believe that
only section 4.1.3 has changed.  This change was to clarify how the AXFR
signature is calculated.  The new version of 4.1.3 is below.

Donald
=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     dee@cybercash.com
   318 Acton Street        +1 508-371-7148(fax)     dee@world.std.com
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)



"4.1.3 Zone Transfer (AXFR) SIG"

The above SIG mechanisms assure the authentication of all zone
signed RRs of a particular name, class and type.  However, to
efficiently assure the completeness of and secure zone transfers, a SIG RR
owned by the zone name must be created with a type covered of AXFR
that covers all RRs in the zone other than those signed by dynamic
update keys and the SIG AXFR itself.  The RRs are ordered and
concatenated for hashing as described in Section 4.1.1.  (See also
ordering discussion in Section 5.1.)

The AXFR SIG must be calculated last of all zone key signed SIGs in
the zone.  In effect, when signing the zone, you order, as
described above, all RRs to be signed by the zone.  You can then make
one pass inserting all the zone SIGs.  As you proceed you hash RRs
into both an RRset hash and the zone hash.  When the name or type
changes you calculate and insert the RRset SIG, clear the RRset
hash, and hash that SIG into the zone hash. When you have finished
processing all the starting RRs as described above, you can then
use the cumulative zone hash RR to calculate and insert an AXFR SIG
covering the zone.  Of course any computational technique producing
the same results as above is permitted.

The AXFR SIG really belongs to the zone as a whole, not to the zone
name.  Although it should be correct for the zone name, the labels
field of an AXFR SIG is otherwise meaningless. The AXFR SIG is only
retrieved as part of a zone transfer.  After validation of the AXFR
SIG, the zone MAY be considered valid without verification of the
internal zone signed SIGs in the zone; however, any SIGs signed by
entity keys or the like must still be validated.  The AXFR SIG
SHOULD be transmitted first in a zone transfer so the receiver can
tell immediately that they may be able to avoid verifying other
zone signed SIGs.

RRs which are authenticated by a dynamic update key and not by the
zone key (see Section 3.2) are not included in the AXFR SIG. They
may originate in the network and might not, in general, be migrated
to the recommended off line zone signing procedure (see Section
7.2). Thus, such RRs are not directly signed by the zone, are not
included in the AXFR SIG, and are protected against omission from
zone transfers only to the extent that the server and communication
can be trusted.

+end+

Xref subject next

--NextPart

A Revised Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Domain Name System Security 
Working Group of the IETF.                                                 

       Title     : Domain Name System Security Extensions                  
       Author(s) : D. Eastlake, C. Kaufman
       Filename  : draft-ietf-dnssec-secext-09.txt
       Pages     : 45
       Date      : 01/29/1996

The Domain Name System (DNS) has become a critical operational part of the 
Internet infrastructure yet it has no strong security mechanisms to assure 
data integrity or authentication.  Extensions to the DNS are described that
provide these services to security aware resolvers or applications through 
the use of cryptographic digital signatures.  These digital signatures are 
included in secured zones as resource records.  Security can still be 
provided even through non-security aware DNS servers in many cases. 
      
The extensions also provide for the storage of authenticated public keys in
the DNS.  This storage of keys can support general public key distribution 
service as well as DNS security.  The stored keys enable security aware 
resolvers to learn the authenticating key of zones in addition to those for
which they are initially configured.  Keys associated with DNS names can be
retrieved to support other protocols.  Provision is made for a variety of 
key types and algorithms.    

In addition, the security extensions provide for the optional 
authentication of DNS protocol transactions.              

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-dnssec-secext-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-09.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-dnssec-secext-09.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: <19960129133506.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-secext-09.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-dnssec-secext-09.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960129133506.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous

--NextPart

A Revised Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Domain Name System Security 
Working Group of the IETF.                                                 

       Title     : Domain Name System Security Extensions                  
       Author(s) : D. Eastlake, C. Kaufman
       Filename  : draft-ietf-dnssec-secext-09.txt
       Pages     : 45
       Date      : 01/29/1996

The Domain Name System (DNS) has become a critical operational part of the 
Internet infrastructure yet it has no strong security mechanisms to assure 
data integrity or authentication.  Extensions to the DNS are described that
provide these services to security aware resolvers or applications through 
the use of cryptographic digital signatures.  These digital signatures are 
included in secured zones as resource records.  Security can still be 
provided even through non-security aware DNS servers in many cases. 
      
The extensions also provide for the storage of authenticated public keys in
the DNS.  This storage of keys can support general public key distribution 
service as well as DNS security.  The stored keys enable security aware 
resolvers to learn the authenticating key of zones in addition to those for
which they are initially configured.  Keys associated with DNS names can be
retrieved to support other protocols.  Provision is made for a variety of 
key types and algorithms.    

In addition, the security extensions provide for the optional 
authentication of DNS protocol transactions.              

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-dnssec-secext-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-09.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-dnssec-secext-09.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: <19960129133506.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-secext-09.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-dnssec-secext-09.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960129133506.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Hi,

Sun Microsystems is pleased to announce the release of source code 
to an exportable version our X.509 Certificate library.   It features:

        o Encoding for Version 1 X.509 certificates (X509Cert, X509Skip)
        o Encoding of Hashed Public Key Certificates (HashCert)
        o Useful primitive Classes such as Bstream.
        o Generic Interface Class (SkipCert)
        o ASN BER encoder/decoder
        o MD2 and MD5 Hash Functions
        o SHA-1 Hash Function
	o Includes Big Number library written by Colin Plumb.

Note: This library can only encode or decode Certificates.  It is unable
to sign or verify signatures on certificates.  This is a nontrivial library
and the documentation is minimal.  If you are not a developer, who is i
interested in digging into C++ class libraries, this library may not be 
for you.

You can find more information at http://skip.incog.com

----------------------------------------------------------------------------
License for this software:

  Copyright (C) 1994, 1995, 1996  Sun Microsystems, Inc.  All Rights
  Reserved.
 
  Permission is hereby granted, free of charge, to any person
  obtaining a copy of this software and associated documentation
  files (the "Software"), to deal in the Software without
  restriction, including without limitation the rights to use,
  copy, modify, merge, publish, distribute, sublicense, and/or sell
  copies of the Software or derivatives of the Software, and to 
  permit persons to whom the Software or its derivatives is furnished 
  to do so, subject to the following conditions:
 
  The above copyright notice and this permission notice shall be
  included in all copies or substantial portions of the Software.
 
  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  NONINFRINGEMENT.  IN NO EVENT SHALL SUN MICROSYSTEMS, INC., BE LIABLE
  FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
  OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
  CONNECTION WITH THE SOFTWARE OR DERIVATES OF THIS SOFTWARE OR 
  THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 
  Except as contained in this notice, the name of Sun Microsystems, Inc.
  shall not be used in advertising or otherwise to promote
  the sale, use or other dealings in this Software or its derivatives 
  without prior written authorization from Sun Microsystems, Inc.

--
Tom Markson
Internet Commerce Group
Sun Microsystems, Inc

Xref subject next


I was asked to forward this information to appropriate IETF Working
Groups.  The main item of interest is probably the "ATM Security"
mailing list, though the other lists might also be of interest.

These lists are open to anyone, unlike the other "closed, members-only"
ATM Forum mailing lists.

Ran
rja@cisco.com
Co-chair, IP Security WG

----- Begin Included Message -----

Date: Thu, 1 Feb 1996 20:47:53 -0500 (EST)
To: rolc@nexen.com, af-all@atmforum.com
From: Jim Grace 
Subject: ATM Forum External Mailing Lists now available

The ATM Forum has set up the following mailing lists for use by both members and
non-members in order to generate a wider discussion on some of the topics which
the Forum is pursuing.  (Until now, mailing lists maintained by the ATM Forum
were for use by member companies only.)  The new lists are:

             af-xpnni@atmforum.com      (Private ATM Network-Node Interface)
             af-xmpoa@atmforum.com      (Multiprotocol Routing over ATM)
         af-xsecurity@atmforum.com      (Security and ATM)

Anyone may subscribe to these lists, and anyone contributing to the
discussion in
these areas may send email to these addresses.  To subscribe to these lists,
send
an email message to:

      af-xpnni-request@atmforum.com     (For PNNI)
      af-xmpoa-request@atmforum.com     (For MPOA)
  af-xsecurity-request@atmforum.com     (For Security)

containing the following command:

    subscribe

Subsequently, you may remove yourself from the mailing list by sending an
email message to the same address containing the following command:

    unsubscribe

ATM Forum members who already subscribe to af-pnni, af-mpoa or af-security
will automatically receive all mail sent to the corresponding 'x' list as well.
ATM Forum members who already subscribe to all ATM Forum lists will also
receive all messages sent to any of these 'x' lists.

ATM Forum principal member companies have the option of sending to af-pnni,
af-mpoa or af-security for distribution to member companies only, or they may
send to the corresponding 'x' lists for a wider distribution.

Further questions about the ATM Forum or the mailing lists can be directed to:

    info@atmforum.com

Regards,

Jim Grace
Vice-Chair, ATM Forum Technical Committee


----- End Included Message -----



----- End Included Message -----

Xref subject previous


I was asked to forward this information to appropriate IETF Working
Groups.  The main item of interest is probably the "ATM Security"
mailing list, though the other lists might also be of interest.

These lists are open to anyone, unlike the other "closed, members-only"
ATM Forum mailing lists.

Ran
rja@cisco.com
Co-chair, IP Security WG

----- Begin Included Message -----

Date: Thu, 1 Feb 1996 20:47:53 -0500 (EST)
To: rolc@nexen.com, af-all@atmforum.com
From: Jim Grace 
Subject: ATM Forum External Mailing Lists now available

The ATM Forum has set up the following mailing lists for use by both members and
non-members in order to generate a wider discussion on some of the topics which
the Forum is pursuing.  (Until now, mailing lists maintained by the ATM Forum
were for use by member companies only.)  The new lists are:

             af-xpnni@atmforum.com      (Private ATM Network-Node Interface)
             af-xmpoa@atmforum.com      (Multiprotocol Routing over ATM)
         af-xsecurity@atmforum.com      (Security and ATM)

Anyone may subscribe to these lists, and anyone contributing to the
discussion in
these areas may send email to these addresses.  To subscribe to these lists,
send
an email message to:

      af-xpnni-request@atmforum.com     (For PNNI)
      af-xmpoa-request@atmforum.com     (For MPOA)
  af-xsecurity-request@atmforum.com     (For Security)

containing the following command:

    subscribe

Subsequently, you may remove yourself from the mailing list by sending an
email message to the same address containing the following command:

    unsubscribe

ATM Forum members who already subscribe to af-pnni, af-mpoa or af-security
will automatically receive all mail sent to the corresponding 'x' list as well.
ATM Forum members who already subscribe to all ATM Forum lists will also
receive all messages sent to any of these 'x' lists.

ATM Forum principal member companies have the option of sending to af-pnni,
af-mpoa or af-security for distribution to member companies only, or they may
send to the corresponding 'x' lists for a wider distribution.

Further questions about the ATM Forum or the mailing lists can be directed to:

    info@atmforum.com

Regards,

Jim Grace
Vice-Chair, ATM Forum Technical Committee


----- End Included Message -----



----- End Included Message -----

Xref: Re: network security products  Michael Richardson
Xref: Re: network security products Ran Atkinson
Xref subject next

I am working on a report on network security products for a UK market 
research company: Cambridge Market Intelligence (CMI).

CMI is a specialist IT market information provider with a long 
pedigree of service to blue chip companies worldwide.  CMI currently 
has over 800 clients, including 38 of the top 100 companies worldwide
Their Enterprise Library currently covers more than more than 50 
technologies.

The network security report will include information on:
firewalls, network encyptors, single sign on authentication, 
authentication servers, digital signature, key management, security 
APIs;
for a range of network technologies including: dial up, point to point, 
X.25, ATM, ISDN, TCP/IP, E-mail, World Wide Beb, EDI, Directories.

If your company has a product relating to network security and which 
would be of interest to CMI's clients, could you E-mail me with contact 
details including E-mail, FAX and postal (snail mail) address to:

     pope@secstan.demon.co.uk


Nick Pope

-------------------------------------


Security & Standards
Suite A
191 Moulsham St.
Chelmsford
Essex
CM2 0LG
U.K.

Tel: +44 1245 495018
Fax: +44 1245 494517

Xref subject next

--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-09.txt
       Pages     : 69
       Date      : 02/01/1996

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-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-09.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-09.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: <19960201114242.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-photuris-09.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-photuris-09.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960201114242.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref: Re: network security products  Michael Richardson
Xref subject previous
Xref subject next

No relevant information, I am afraid, Nick!!

But it is interesting to see that you are alive and, I presume,well; long
time no see!

  Incidentally, I should apologise for all these Christmas cards that you
so generously sent me and I so niggardly did not acknowledge.  It would
be hard to tell from my behavior but I appreciated both the gesture and
the thought behind it.

  Please give my greetings to your wife and let your son know that I am now
at the age when I use in soccer the judo techniques that I learned in earlier you

youth; against inexperienced players, sometimes, they work.  Give me a buzz if y
you are ever in town with time to spare.

     Tassos

Xref: Bandwidth reservation and AH, and non-MD5 based AH. Michael Richardson
Xref subject previous
Xref subject next

In a galaxy far, far away, : Mon, 05 Feb 1996 13:27:16 GMT
> I am working on a report on network security products for a UK market 
> research company: Cambridge Market Intelligence (CMI).

  IPSEC is not a place to ask these questions. Try 
firewalls-request@greatcircle.com please. You might start with:

  http://www.greatcircle.com/firewalls/

Xref subject previous
Xref subject next

Please include Cisco Systems Network Translation Inc.'s Private Internet
Exchange.

Robert.

Xref subject previous
Xref subject next

--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-09.txt
       Pages     : 69
       Date      : 02/01/1996

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-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-photuris-09.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-09.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: <19960201114242.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-photuris-09.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-photuris-09.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960201114242.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous
Xref subject next

Sorry about that, wasn't paying attention to the reply to field.

Robert.

Xref subject previous
Xref subject next

In a galaxy far, far away, : Mon, 05 Feb 1996 10:30:23 EST
> No relevant information, I am afraid, Nick!!

  Please don't post this to ipsec. Just take it to private email
if you have complaints.

Xref: Re: Bandwidth reservation and AH, and non-MD5 based AH. David A Wagner
Xref subject next


In a galaxy far, far away, : Mon, 05 Feb 1996 11:39:55 EST
>   IPSEC is not a place to ask these questions. Try 
> firewalls-request@greatcircle.com please. You might start with:

  Dang. I replied to the list. Exactly what I hate people doing.
  
  Here is some genuine content to go with my appology. I think this
topic came up (I know I asked the question once), but seems to have died.
  The issue was how do deal with a possibly unknown number of gateways
between a sender and recipient. The simplest case is a single security
gateway with a host behind it. I think the opinion was that 
	IP-AH-IP-AH 
  was the way to do this. This works fine for some finite number of gateways
and when the packet will go via the same route each time. It gets to be a
pain when the number of gateways gets more than a couple. The gateways
could use ICMP "Authentication Required" to get more and more AH headers 
added..
  If one is talking about bandwidth reservation then one wants the packets
examined at several places. One could share (via photoris or other) the secret
keying information with all these gateways. I dislike this. I don't think
Photuris can handle this at present.
  Or, one could use a public key based digital signature. I worry that checking
this signature may take so long that the bandwidth reservation becomes moot
due to latency... I know that the bandwidth reservation people (RSVP) are 
working on something to address this. From my reading, there doesn't seem
to be a lot of protection against other people stealing your expensive
bandwidth, although draft-ietf-rsvp-md5-01.txt provides protection for the
RSVP protocol messages themselves. 
  The biggest reason I can see for widespread use of RSVP type services is that
if they are simple a cheap, then we can work around a large number of the 
denial
of service attacks that "ping -f victim" can cause.

Xref subject previous
Xref subject next

contact neal goldman product line manager
        FTP software, inc
        2 high st 
        N. Andover, Ma 01845
        ngoldman@ftp.com
        508 685 4000

He can outline details of our security products which include
secure TCP/IP stack
secure email
secure web ... et al




>I am working on a report on network security products for a UK market 
>research company: Cambridge Market Intelligence (CMI).
>
>CMI is a specialist IT market information provider with a long 
>pedigree of service to blue chip companies worldwide.  CMI currently 
>has over 800 clients, including 38 of the top 100 companies worldwide
>Their Enterprise Library currently covers more than more than 50 
>technologies.
>
>The network security report will include information on:
>firewalls, network encyptors, single sign on authentication, 
>authentication servers, digital signature, key management, security 
>APIs;
>for a range of network technologies including: dial up, point to point, 
>X.25, ATM, ISDN, TCP/IP, E-mail, World Wide Beb, EDI, Directories.
>
>If your company has a product relating to network security and which 
>would be of interest to CMI's clients, could you E-mail me with contact 
>details including E-mail, FAX and postal (snail mail) address to:
>
>     pope@secstan.demon.co.uk
>
>
>Nick Pope
>
>-------------------------------------
>
>
>Security & Standards
>Suite A
>191 Moulsham St.
>Chelmsford
>Essex
>CM2 0LG
>U.K.
>
>Tel: +44 1245 495018
>Fax: +44 1245 494517
>
>

Xref subject previous
Xref subject next

  My excuses;  I must have hit R instead of r.  Else, I have some e-mail 
problem I am unaware of.

Again,  I am truly sorry.

  Tassos Nakassis

Xref subject previous
Xref subject next


Mr. Pope,

Since you are using a mail list dedicated to advancing the state of network 
security, I assume that your efforts are in the best interest of the 
community at large and that you will make the results of your study 
available to the public.

Looking forward to a pointer to a FTP or Web site,

Dale
 ----------
>From: ipsec-owner
>To: ipsec
>Subject: network security products
>Date: Monday, February 05, 1996 1:27PM
>
>I am working on a report on network security products for a UK market
>research company: Cambridge Market Intelligence (CMI).
>
>CMI is a specialist IT market information provider with a long
>pedigree of service to blue chip companies worldwide.  CMI currently
>has over 800 clients, including 38 of the top 100 companies worldwide
>Their Enterprise Library currently covers more than more than 50
>technologies.
>
>The network security report will include information on:
>firewalls, network encyptors, single sign on authentication,
>authentication servers, digital signature, key management, security
>APIs;
>for a range of network technologies including: dial up, point to point,
>X.25, ATM, ISDN, TCP/IP, E-mail, World Wide Beb, EDI, Directories.
>
>If your company has a product relating to network security and which
>would be of interest to CMI's clients, could you E-mail me with contact
>details including E-mail, FAX and postal (snail mail) address to:
>
>     pope@secstan.demon.co.uk
>
>
>Nick Pope
>
>-------------------------------------
>
>
>Security & Standards
>Suite A
>191 Moulsham St.
>Chelmsford
>Essex
>CM2 0LG
>U.K.
>
>Tel: +44 1245 495018
>Fax: +44 1245 494517
>

Xref subject previous
Xref subject next

NSC has encrypting filrewalls at the IP level (with support for X.25, ATM,
ISDN) and all applications (TCP/IP, E-mail, World Wide Beb, EDI,
Directories). Please check our home page http://www.network.com for more
information.

If there is more information needed please ask.

The encrypting firewall routers ("The Security Routers" and "BorderGuard")
are available today and have been shipping to  US and international
customers for over a year. The Security Router won "Best of Show" in the
Spring 1995 Interop Show.

>I am working on a report on network security products for a UK market
>research company: Cambridge Market Intelligence (CMI).
>
>CMI is a specialist IT market information provider with a long
>pedigree of service to blue chip companies worldwide.  CMI currently
>has over 800 clients, including 38 of the top 100 companies worldwide
>Their Enterprise Library currently covers more than more than 50
>technologies.
>
>The network security report will include information on:
>firewalls, network encyptors, single sign on authentication,
>authentication servers, digital signature, key management, security
>APIs;
>for a range of network technologies including: dial up, point to point,
>X.25, ATM, ISDN, TCP/IP, E-mail, World Wide Beb, EDI, Directories.
>
>If your company has a product relating to network security and which
>would be of interest to CMI's clients, could you E-mail me with contact
>details including E-mail, FAX and postal (snail mail) address to:
>
>     pope@secstan.demon.co.uk
>
>
>Nick Pope
>
>-------------------------------------
>
>
>Security & Standards
>Suite A
>191 Moulsham St.
>Chelmsford
>Essex
>CM2 0LG
>U.K.
>
>Tel: +44 1245 495018
>Fax: +44 1245 494517

--------------
HTTP://WWW.Network.com/~hughes

Xref subject previous

Nick Pope,

  Your note was not an appropriate use of the IETF's IP Security (IPsec)
Working Group Mailing list.  Please do NOT repeat that kind of note to the
ipsec mailing list.

Randall Atkinson
rja@cisco.com

Co-chair, IP Security WG

Xref: Re: Bandwidth reservation and AH, and non-MD5 based AH.  Michael Richardson
Xref subject previous
Xref subject next

>   If one is talking about bandwidth reservation then one wants the packets
> examined at several places. One could share (via photoris or other) the secret
> keying information with all these gateways. I dislike this.

Hrmm, why?

If AH with a symmetrically-keyed MAC is used just for protecting reserved
bandwidth (not for secure end-to-end source authentication or message
integrity), then it doesn't seem like such a big deal to have to trust a
few routers to hold your bandwidth session-key.

(After all, you have to trust them to actually give you the bandwidth which
they've promised to reserve for you.)

I'd expect that you'll exchange short-lived session MAC keys based on some
public-key algorithm anyhow, so that oughta decrease the risk even further.

But then again, I know nothing about bandwidth reservation.

> Or, one could use a public key based digital signature. I worry that checking
> this signature may take so long that the bandwidth reservation becomes moot
> due to latency...

Yeah, that's a problem with public-key stuff: it's so slow.  Do note that
signature verification is much faster than signature generation when you use
RSA with a small public exponent, though it is admittedly still quite slow.

Xref subject previous
Xref subject next

Please stop sending me so much mail. This really getting rediculous. I am
greatfull that you replied to me but I only need info reguarding fraud or
computer hacking. If there is a way for you to just send me information on
the above topics it would be greatlly appreciated.
Thank you
Jeffrey  G. Vallese

Xref subject previous
Xref subject next

Gentlefolk, I believe this draft to be relatively stable, and to include
the features and editorial comments requested in the past 2 months.

The only significant changes are the new support for passing the moduli
from Responder to Initiator, and adding attributes to more clearly
detail the AH ESP ordering for each security association.

Note that the scenarios and security considerations have been moved to
separate drafts, and that other folks are (hopefully) posting a
user-keying draft.  The nroff difference engine was confused by the
massive deletions, so there are no change bars in this draft.  Please
read every word carefully, and send me your comments.

I request that the WG Chair(s) issue Last Call, as was done for SKIP.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next


Hi Jeffrey,

Per your request, your email address has been removed from
the IETF Announcement mailing list.

Because of the mail queue, this might take awhile.

Kind Regards, 

Cynthia Clark 
 

------- Forwarded Message

Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13571;
          6 Feb 96 10:18 EST
Received: from emout07.mx.aol.com by CNRI.Reston.VA.US id aa07809;
          6 Feb 96 10:18 EST
Received: by emout07.mail.aol.com (8.6.12/8.6.12) id KAA29034; Tue, 6 Feb 1996 10:18:34 -0500
Date: Tue, 6 Feb 1996 10:18:34 -0500
From: JVallese@aol.com
Message-ID: <960206101831_314090663@emout07.mail.aol.com>
To: Internet-Drafts@CNRI.Reston.VA.US, IETF-Announce@aol.com
cc: ipsec@ans.net
Subject: Re: I-D ACTION:draft-ietf-ipsec-photuris-09.txt

Please stop sending me so much mail. This really getting rediculous. I am
greatfull that you replied to me but I only need info reguarding fraud or
computer hacking. If there is a way for you to just send me information on
the above topics it would be greatlly appreciated.
Thank you
Jeffrey  G. Vallese

------- End of Forwarded Message

The paper describing the security analysis behind the proposal in
draft-krawczyk-keyed-md5-01.txt (that I also described during the Dallas
IETF) is available. You can retrieve it from

http://www.research.ibm.com/security/keyed-md5.html
or from
http://www-cse.ucsd.edu/users/mihir/papers/papers.html

The title of the paper is:
"Keying hash functions for message authentication" by
Bellare, Canetti, and Krawczyk.

Notice that the construction proposed to the IETF is called HMAC
in the paper.

Hugo

Xref subject previous

>Please stop sending me so much mail. This really getting rediculous. I am
>greatfull that you replied to me but I only need info reguarding fraud or
>computer hacking. If there is a way for you to just send me information on
>the above topics it would be greatlly appreciated.
>Thank you
>Jeffrey  G. Vallese

Mr. Vallese,

1.  Since you obviously don't know the purpose of the list to which you
have subscribed, how it is operated, or the sheer number of people on it,
you should get off.

2.  Since you obviously don't know how to restrict your replies so that
thousands of other people don't receive your personal business, you should
learn.  For that purpose, please consider:

When you want to be added to or removed from a mailing list "foo" at host "bar",
the proper form of address is to "foo-request@bar".  The "-request" suffix
is a widely supported Internet convention for communicating with the list
administrator.  That way, everyone on the list does not get a copy of
personal "administrivia".



Regards, -Rob-

RShirey@BBN.com,   Tel 703-284-4641,  Sec 284-4600,  Fax 284-4777
Robert W. Shirey,  BBN Corporation,  Mail Stop 30/4C, Suite 1200,
1300 North Seventeenth Street, Arlington, Virginia 22209-3801 USA

This mailing list, dns-security, will soon be migrated to majordomo
management.  You will know the migration is complete when you receive a
welcome message from majordomo.  The message will include all the
instructions you need for getting off (or on) the list, but you're probably
already familiar with them anyway.

Enjoy,

Jim

----------------------------------------------------------------------------
James M. Galvin                                               galvin@eit.com
Verifone/EIT, PO Box 220, Glenwood, MD 21738                 +1 410.795.6882

unsubscribe
exit

Hi,

We've just released the Alpha-2 SKIP reference source for SunOS 4.1.3.
This is a bug fix release of our Alpha-1 Source reference Source.

The source is available from http://skip.incog.com.    Included in this
mail message are excerpts from the README file for the the package.

Enjoy!

Tom Markson
Sun Microsystems

-------------------------------------------------------------------------



	ALPHA 2 Release of SKIP Reference Source for SunOS 4.1.3
	--------------------------------------------------------
			Overview and Release Notes

Overview
--------
SKIP is a Key-management protocol for IP based protocols.  It is an 
acronym for Simple Key-management for Internet Protocols. SKIP is 
documented in the SKIP IETF IPSEC draft included in this directory 
as draft-ietf-ipsec-skip-06.txt.  The most recent SKIP draft is 
always available at http://skip.incog.com and the Internet-Drafts
directories.

>From this public domain source release, you can build a fully 
functional IP-layer encryption package which supports DES and 
Triple-DES for SunOS 4.1.3.  This means that every IP networked 
application can have it's network traffic encrypted.   Unlike
application level encryption packages, this package encrypts 
IP packets.  Thus, applications do not need to be recompiled or 
modified to take advantage of encryption.

The SKIP source is possible through the efforts of engineers in Sun
Microsystems Internet Commerce Group.  The developers and designers
are Ashar Aziz, Tom Markson, Martin Patterson, Hemma Prafullchandra and
Joseph Reveane.  Linda Cavanaugh worked on the documentation.

The package compiles under both the SunPro compiler and GCC.  We expect 
that this release should port without too much pain to any operating 
system which uses BSD style networking (mbufs).  

A legal warning: Because this package contains strong encryption, the
Software must not be transferred to persons who are not US citizens or
permanent residents of the US, or exported outside the US (except
Canada) in any form (including by electronic transmission) without
prior written approval from the US Government. Non-compliance with
these restrictions constitutes a violation of the U.S. Export Control
Laws.

This source release may be used for both commercial and noncommercial 
purposes, subject to the restrictions described in the software and
patent license statements.  

Furthermore, Sun Microsystems has licensed the Stanford public key patents 
from Cylink Corp. which are available to users of this package on a royalty 
free basis. The patent statement is in README.PATENT.  Be sure to read this,
as it contains some restrictions and other important information.  

Also included in this release is a high speed Big Number package written 
by Colin Plumb. bnlib/legal.c contains Colin's software license statement. 

Features
--------
	1.  SKIP V2 compliant implementation using ESP encapsulation.
	2.  Support for DES/3DES for traffic and key encryption.
	3.  Diffie-Hellman Public Key Agreement based system.
	4.  Full Support for manual establishment of master keys.
	5.  Support for multiple NSIDs and multiple local certificates.
	6.  GUI tool for user friendly manipulation of access control lists
	    and key statistics.
	7.  Command line tools for manipulating access control lists, etc.
	8.  Implementation of the Certificate Discovery protocol fully
	    integrated into SKIP.
	9   Implementation of X.509 public key certificates.
	10. Implementation of DSA signature algorithm for certificate
	    signatures.
	11. Implementation for MD2, MD5 and SHA message digest algorithms.
	12. Implementation of ASN.1 DER encoding/decoding.
	13. SunScreen(tm) SKIP compatibility mode.
	14. Implementation of hashed public keys as defined in the SKIP 
	    draft.  Implementation of programs to generate hashed public
	    keys.
	15. Certificate utilities to convert X.509 Certificates to hashed
	    keys and  print both X.509 and Hashed certificates.
	16. High performance Big Number library for Diffie-Hellman 
	    calculations.
	17. Implementation is effectively "public domain" and may be used both 
	    commercially and non-commercially.
	18. Patent Agreement with Cylink allows roylaty-free use of the 
            Diffie-Hellman and other Stanford patents with this package for 
	    commercial and non-commercial use.  Read README.PATENT for 
	    some restrictions.
	19. Inclusion of prime generation program used to generate the 
	    primes in SKIP draft.

Release Notes
-------------
Here are the release notes for this Alpha 2 release of the SKIP source.

	1.  This release is a bug fix release for Alpha-1.  Major areas
	    of change include:
			o Fix ESP and AH protocol numbers.
			o Fix Unsigned DH Public encoding.
			o Remove truncatation of shared secret (for this
			  release only).
			o Various other Bug fixes.
			o Fix Triple DES.

	2.  This release does not interoperate with Alpha-1.   Alpha-1
	    sites should upgrade.  Alpha-1 had a bug where unsigned public
	    keys were being encoded incorrectly.  Therefore, unsigned DH 
	    keys generated with alpha-1 do not work with Alpha-2.  
	    Regenerate your unsigned public keys.  X509 Certificates from
	    alpha-1 will continue to work.

	3.  This release interoperates with Swiss ETH SKIP using unsigned
	    DH keys and DES and triple DES.  It was tested at the Dallas 
	    1995 IETF.  However, the certificate discovery protocol does 
	    not interoperate.  This will be fixed in the next release.

	4.  This release does not fully comply with the SKIP drafts.   It
	    is closest to the 05 version of the draft.  However, the shared
	    secret is not truncated according to that draft.  This change is
	    made to interoperate with the ETH implementation.  The next
	    release will correspond to the 06 draft. 
	   
							....

Below is a status update on some results regarding keyed MD5 proposals.  
In July of last year there was much discussion about the security 
of various proposals.  A summary of attacks on the secret prefix, secret 
suffix, and various envelope methods may be found in the Crypto'95 paper
by B. Preneel and P. van Oorschot, `MDx-MAC and Building Fast MACs from 
Hash Functions', pp.1-14, available at:

   ftp.esat.kuleuven.ac.be pub/COSIC/preneel mdxmac_crypto95.ps

This paper also proposed the MD5-based MAC algorithm called MD5-MAC.
A reference C implementation (including test values and some 
timings) of MD5-MAC has been posted at

   ftp.esat.kuleuven.ac.be pub/COSIC/preneel/md5mac
   files: README      key.dat     md5mac.res  mddrive2.c
          global.h    md5mac.h    md5macc.c   speed.res

At the Crypto'95 rump session, a key recovery attack on the envelope method
of RFC 1828 was announced.  This result is contained in our paper to be 
presented at Eurocrypt'96 in May, ``On the security of two MAC algorithms'',
a draft version of which is available at

    ftp.esat.kuleuven.ac.be  pub/COSIC/preneel  twomacs.ps


Bart Preneel
bart.preneel@esat.kuleuven.ac.be

Xref subject next

There are (at least :-) two directions in which to look for solutions:

 1) Internet Draft "draft-krawczyk-keyed-md5-01.txt" presents an
    analysis of the use of hash functions as Message Authenticators.
    It suggests using the construct:

       Hash(Key, Pad2, Hash(Key, Pad1, Text))

    in lieu of other structures such as Hash(Key, Text, Key).
    The Krawczyk MAC relies on significantly fewer assumptions about
    the properties of the hash algorithm than do other methods (which
    were apparently concocted without much in the way of security
    analysis).

 2) The Secure Hash Algorithm (SHA) (ftp://csrc.ncsl.nist.gov/pub/fips/
    fip180-1.txt) produces a 160 bit hash value as opposed to MD5's 128
    bit value.  I am not aware of an analysis of the inherent strengths
    of the two algorithms, but assuming they are equivalent, SHA's
    additional 32 bits would increase the work factor of the attack by
    2**32. It would be interesting to know if in fact the attack
    referenced below is effective at all against SHA.

Netscape's SSL Version 3 (ftp://ftp.netscape.com/pub/review/ssl-spec.tar.Z)
has adopted the Krawczyk MAC using both MD5 and SHA.  Also, a very
influential vendor consortium recently switched from using MD5 to SHA
because, despite the increased size of its hash value, SHA is
computationally faster than MD5.

Food for thought.

Regards,

Dave Kemp


==================================

> I am forwarding this memo from the mobile-ip IETF mailing list, as it
> addresses MD5 used to hide keys (passwords).  I haven't been following
> this thread on the mobile-ip list, but thought it may be of some interest 
> to us.
> 
> Regards,
> 
> Dave Nelson
> Internetworking Products Engineering Group
> Digital Equipment Corporation 
> 
> --------------------------------------------------------------------------
> 
> It seems that MD5 isn't as secure as we thought.
> I'd suggest we shop around for a fix to this problem
> before finishing Working Group last call.  The algorithm
> we are using to compute authenticators is (apparently)
> called an MD5-envelope algorithm.  I'm not a security
> weenie, but here's my distillation of the article.
> 
> 1) MD5 was not designed to hide keys.
> 
> 2) It's possible to choose plaintexts and trial keys
>    in such a way to dramatically reduce the amount of
>    time needed to recover a key, to about 2**64
>    keyed operations on 2**13 plaintexts in some cases.
>    Were we expecting 2**128 key trials to be needed?
> 
> 3) If keys are chosen poorly, even fewer trials are
>    needed to find the key.
> 
> The danger could be that, even if 2**64 is still good
> enough for our purposes (is it??), that this result
> will point the way towards another drastic reduction
> in the security of MD5(key||text||key).
> 
> Does anyone know if "suffix-only" mode is more secure
> than the "envelope" or "prefix+suffix" mode that we
> have specified in the mobile-IP draft?
> 
> Regards,
> Charlie Perkins

Xref subject next


The IESG has received a request from the Domain Name System Security
Working Group to consider the following two Internet-Drafts for the
status of Proposed Standards:

 1. Domain Name System Security Extensions
	 <draft-ietf-dnssec-secext-09.txt>

 2. Mapping Automous Systems Number into the Domain Name System
	 <draft-ietf-dnssec-as-map-03.txt>


The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by
February 26, 1996.

Xref subject previous
Xref subject next

>There are (at least :-) two directions in which to look for solutions:
     
 >1) Internet Draft "draft-krawczyk-keyed-md5-01.txt" presents an
    >analysis of the use of hash functions as Message Authenticators. 
    >It suggests using the construct:
     
       >Hash(Key, Pad2, Hash(Key, Pad1, Text))
     
     >...
     
 >2) The Secure Hash Algorithm (SHA) (ftp://csrc.ncsl.nist.gov/pub/fips/
    >fip180-1.txt) produces a 160 bit hash value as opposed to MD5's 128 
    >bit value.  I am not aware of an analysis of the inherent strengths 
    >of the two algorithms, but assuming they are equivalent, SHA's 
    >additional 32 bits would increase the work factor of the attack by 
    >2**32. It would be interesting to know if in fact the attack 
    >referenced below is effective at all against SHA.
     
     At the expense of being a pain about my extensions proposal, the 
     extended authentication mechanism allows for alternate encryption 
     schemes. There exists a flag in the message header which is used for 
     this. You will notice that I have only defined the current MD5 method, 
     but there are plenty of bits left which may be used in order to 
     indicate the encoding scheme. I would certainly be interested in 
     talking about any "new" encoding schemes and add these to my 
     proposals.
     
     The only lacking piece is that both peers should negotiate an encoding 
     scheme BEFORE authentication begins. This should be done in the 
     NAS-Reboot message, where certain other negotiations exists.
     
Pat R. Calhoun                                  e-mail: pcalhoun@usr.com 
Project Engineer - Lan Access R&D                phone: (847) 933-5181 
US Robotics Access Corp.

Xref subject next

%    Date: Thu, 4 Jan 1996 10:44:11 -0800
%    From: Ran Atkinson 
% 
%     1) Can the IPsec WG produce multiple standards-track  
%        protocols for key management ? 

The consensus is that multiple standards-track protocols can be produced
by the working group provided that there are significant differences
in applicability among the protocols.  The most common example that
was mentioned was that multicast key distribution will probably need to
be a separate protocol than unicast key distribution.

%     2) If yes to the above, then can a protocol not conforming 
% 	to the WG requirements for a key management protocol 
% 	be on the IETF standards-track ? 

The consensus is NO.  All standards-track protocols MUST conform with
the IPsec WG requirements.  As of now there are 2 main agreed-upon
requirements:
	(1) Perfect Forward Secrecy (PFS) must be available to users of
	   the protocol that desire PFS.  This means that a conforming
	   protocol might have a mode that provides PFS and another mode
	   that doesn't, for example.

	(2) The key management protocol must be able to negotiate/
	   indicate the value of each of the components of an IPsec
	   Security Association (RFC-1825) with/to all of the parties to
	   that IPsec Security Association.  Users are not necessarily
	   required to use all of those components, but the protocol MUST
	   be capable of providing that support and conforming implementations
	   of the protocol MUST support negotiation/indication of
	   all of those components.

%     3) If yes to both of the above, should the WG chairs write up a formal 
%        applicability statement to be accompany each standards-track 
%        key management protocol so that the intended use of that protocol 
%        is made clear? 

There is overwhelming (possibly unanimous) consensus that the WG chairs
should be required to write up a formal applicability statement to accompany
each standards-track  key management protocol so that the intended use of
that protocol is made clear in an RFC.  Hence, the co-chairs will do this
if/when some protocol moves to standards-track RFC.

CONCLUSIONS:
	(1) None of the proposals currently online appear to fully meet all
	    of the requirements, though it does appear that all of them could
	    be modified to meet all of the requirements.
	(2) None of the current proposals can go to Last Call at this time
	    because of (1).
	(3) All of the editors of the current documents should work on refining
	    their proposals to fully meet all of the WG requirements.  
	    The co-chairs look forward to seeing revised proposals in LA.

  In a situation like this one where the WG consensus is clear, the WG chairs
do not have any real discretion on handling matters.  We are forbidden by
IETF standards process from doing anything contrary to WG consensus, so our
hands are completely tied on holding a Last Call at this time.

Paul Lambert 
Randall Atkinson 

Xref: Re: Last Call: Domain Name System Security Extensions to Proposed bmanning@isi.edu
Xref subject previous
Xref subject next


The IESG has received a request from the Domain Name System Security
Working Group to consider the following two Internet-Drafts for the
status of Proposed Standards:

 1. Domain Name System Security Extensions
	 <draft-ietf-dnssec-secext-09.txt>

 2. Mapping Automous Systems Number into the Domain Name System
	 <draft-ietf-dnssec-as-map-03.txt>


The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by
February 26, 1996.

Xref subject previous

> 
>  2. Mapping Automous Systems Number into the Domain Name System
> 	 <draft-ietf-dnssec-as-map-03.txt>

	I think it is about time for this draft to be advanced.

-- 
--bill

Xref: Re: ADMIN: Straw Poll Results on Key Mgmt Theodore Ts'o
Xref subject previous
Xref subject next

> From: Ran Atkinson 
> The consensus is NO.  All standards-track protocols MUST conform with
> the IPsec WG requirements.  As of now there are 2 main agreed-upon
> requirements:
> 	(1) Perfect Forward Secrecy (PFS) must be available to users of
> 	   the protocol that desire PFS.  This means that a conforming
> 	   protocol might have a mode that provides PFS and another mode
> 	   that doesn't, for example.
>
I remember this one.


> 	(2) The key management protocol must be able to negotiate/
> 	   indicate the value of each of the components of an IPsec
> 	   Security Association (RFC-1825) with/to all of the parties to
> 	   that IPsec Security Association.  Users are not necessarily
> 	   required to use all of those components, but the protocol MUST
> 	   be capable of providing that support and conforming implementations
> 	   of the protocol MUST support negotiation/indication of
> 	   all of those components.
>
I don't remember this one, and in fact, don't understand it.  Each of
what components?  Where did this requirement arise?

I have examined RFC-1825, and find the use of the word "component"
exactly once:

    2. DESIGN OBJECTIVES

       This section describes some of the design objectives of this security
       architecture and its component mechanisms.

So, let us assume that the "components" are actually "mechanisms".

The next chapter of RFC-1825 specifies "mechanisms":

    3. IP-LAYER SECURITY MECHANISMS

       There are two cryptographic security mechanisms for IP.  The first is
       the Authentication Header which provides integrity and authentication
       without confidentiality [Atk95a].  The second is the Encapsulating
       Security Payload which always provides confidentiality, and
       (depending on algorithm and mode) might also provide integrity and
       authentication [Atk95b].  The two IP security mechanisms may be used
       together or separately.

Thus, the "component mechanisms" are AH and ESP.


> %     3) If yes to both of the above, should the WG chairs write up a formal
> %        applicability statement to be accompany each standards-track
> %        key management protocol so that the intended use of that protocol
> %        is made clear?
>
> There is overwhelming (possibly unanimous) consensus that the WG chairs
> should be required to write up a formal applicability statement to accompany
> each standards-track  key management protocol so that the intended use of
> that protocol is made clear in an RFC.  Hence, the co-chairs will do this
> if/when some protocol moves to standards-track RFC.
>
It couldn't have been unanimous, since I opposed it.  Any Applicability
Statements belong in the documents themselves, as has long been the IETF
practice.  Photuris contains an Applicability Statement.


> CONCLUSIONS:
> 	(1) None of the proposals currently online appear to fully meet all
> 	    of the requirements, though it does appear that all of them could
> 	    be modified to meet all of the requirements.

Well, since I don't know what you are talking about, perhaps you could
indicate exactly where Photuris doesn't meet some such requirement?

Are you saying that Photuris doesn't provide support for PFS, and/or
doesn't support AH and ESP?

You _have_ read the drafts, haven't you?

I call for the rest of the WG to bombard the chairs with their support
for Photuris.  If it is found in the next few days to be lacking such
public WG support, I will instead publish immediately as Experimental,
pursuant to RFC-1602.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

All,

  TIS has kindly agreed to become the new home for the IPsec mailing list.
This transition should occur during the next few weeks.  The list will
be handled by MajorDomo once it is transitioned to TIS, so response to
subscription changes should be a bit faster.  It will continue to be
automatically archived with the archives available via anonymous ftp.

  Jim Galvin  has been kind enough to handle this for us.
He'll be posting more detailed information on the transition as it occurs.
I really appreciate all of his help in making this happen.

Ran
rja@inet.org

Xref subject next

Suppose say I want all packets going from host A to host B
encrypted/authenticated and an error occurs. The ICMP packet that I send
back will also be encrypted or authenticated and hence one will not be able
to understand the ICMP messages as either an SPI is incorrect or the keys
are incorrect.

Now, do we say that ICMP messages are not encrypted? In that case we cannot
say that all packets going from host A to host B are to be encrypted?

Thanks,

--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)659-6743 (O)

Xref subject previous
Xref subject next

Bill, 
	The requirement which Ran is referring to in RFC-1825 is that
the key management protocol must be able to negotiate all of the
parameters which may be associated with a security association, as found
in section 1.4 of RFC-1825.  This includes Encryption Algorith, Security
Association Lifetime, and sensitivity label.  In other words, those
things addressed by Schertler's ISAKMP protocol.

	Right now we have a number of differnet proposals on the table,
none of which completely meet all of the original requirements.
However, it wouldn't be that hard to fix this; it wouldn't be hard for
SKIP to add PFS, or Photoris to add support for full Security
Association attributes negotiation, etc.  Instead of bickering around
playing procedural games and raising meta-issues, if the various people
who are proposing key management protocols to this wg simply sat down
and did the work to meet all of the requirements as originally specified
by this wg, we could be done in relatively short order.  I really don't
think it's all that hard for any of the proposals currently on the
table.

							- Ted

Yesterday, I wrote:

> Netscape's SSL Version 3 (ftp://ftp.netscape.com/pub/review/ssl-spec.tar.Z)
> has adopted the Krawczyk MAC using both MD5 and SHA.  Also, a very
> influential vendor consortium recently switched from using MD5 to SHA
> because, despite the increased size of its hash value, SHA is
> computationally faster than MD5.

Several prominent experts have pointed out that the SHA is NOT faster
than MD5.  I have not yet been able to get clarification from the source
of the above information - I may have misinterpreted what he said, or
it may apply only in special circumstances.

In any case, it is clear that on general purpose computers such as those
that might be expected to host a RADIUS server, MD5 is faster than SHA.
Sorry for the mis-information.

   Dave Kemp

Xref subject previous
Xref subject next

	 Suppose say I want all packets going from host A to host B
	 encrypted/authenticated and an error occurs. The ICMP packet that I se
	nd
	 back will also be encrypted or authenticated and hence one will not be
	 able
	 to understand the ICMP messages as either an SPI is incorrect or the k
	eys
	 are incorrect.

	 Now, do we say that ICMP messages are not encrypted? In that case we c
	annot
	 say that all packets going from host A to host B are to be encrypted?

	 Thanks,

	 --Naganand
	 ----------------------------------------------------------------
	 naganand@ftp.com
	 Tel #: (508)659-6743 (O)

Worse yet, if an intermediate route generates the ICMP bounce, there
won't be enough information in the returned portion of the header to
tie it to a particular socket.

Xref: Re: ADMIN: Straw Poll Results on Key Mgmt Theodore Ts'o
Xref subject previous
Xref subject next

> From: "Theodore Ts'o" 
> 	The requirement which Ran is referring to in RFC-1825 is that
> the key management protocol must be able to negotiate all of the
> parameters which may be associated with a security association, as found
> in section 1.4 of RFC-1825.  This includes
> Encryption Algorith,

Photuris has this.

> Security Association Lifetime,

Photuris has this.

> and sensitivity label.
>
Photuris has this.   Although it is only "recommended" in RFC-1825,
and therefore only listed as a Photuris extension, not required in the
base protocol.


> 	Right now we have a number of differnet proposals on the table,
> none of which completely meet all of the original requirements.

Not true.  Photuris includes all of the features listed in RFC-1825 1.4.
This should not be surprising, as I also made contributions to that list.

So, it must be some other set of requirements that Photuris does not meet.


> However, it wouldn't be that hard to fix this; it wouldn't be hard for
> SKIP to add PFS, or Photoris to add support for full Security
> Association attributes negotiation, etc.  Instead of bickering around
> playing procedural games and raising meta-issues, if the various people
> who are proposing key management protocols to this wg simply sat down
> and did the work to meet all of the requirements as originally specified
> by this wg, we could be done in relatively short order.

Ted, Phil and I already did this long ago.  I'm tired of the procedural
games that others are playing.  That explicitly includes our chairs.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

> From: smb@research.att.com
> Worse yet, if an intermediate route generates the ICMP bounce, there
> won't be enough information in the returned portion of the header to
> tie it to a particular socket.
>
Only if you are using the same Destination+SPI for more than one socket.

In general, this is not a problem for VPNs or mobility, since the tunnel
is between hosts.  It is only a problem for user-user keys, and then
only for those not using automated key management to coordinate the SPIs.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

> From: naganand@ftp.com (Naganand Doraswamy)
> Suppose say I want all packets going from host A to host B
> encrypted/authenticated and an error occurs. The ICMP packet that I send
> back will also be encrypted or authenticated and hence one will not be able
> to understand the ICMP messages as either an SPI is incorrect or the keys
> are incorrect.
>
True, but then any ICMP error message may also be dropped enroute, and
therefore you cannot depend on the error message transmission.


> Now, do we say that ICMP messages are not encrypted?

I do not believe that a general blanket statement can be made, except
that ICMP messages dealing with security failures cannot be encrypted.

Keep in mind this is also a problem with authentication, when the key is
lost.  So, the security failure messages cannot be authenticated either.

This is one of the reasons why the Security Failures is a separate ICMP
message set.


> In that case we cannot
> say that all packets going from host A to host B are to be encrypted?
>
Certainly not!  As usual, a more sophisticated model is needed.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

	 From: Bill.Simpson@um.cc.umich.edu

	 > From: smb@research.att.com
	 > Worse yet, if an intermediate route generates the ICMP bounce, there
	 > won't be enough information in the returned portion of the header to
	 > tie it to a particular socket.
	 >
	 Only if you are using the same Destination+SPI for more than one
	 socket.

	 In general, this is not a problem for VPNs or mobility, since the
	 tunnel is between hosts.  It is only a problem for user-user keys,
	 and then only for those not using automated key management to
	 coordinate the SP Is.

I beg your pardon?  First you say ``only if you are using the same
Destination+SPI for more than one socket.'', which is the case for
host-host keys.  Then you say ``only a problem for user-user keys'', in
which case you're less likely to have multiple sockets per SPI.  (Though
it's not impossible, of course.)

Scenarios I have in mind are things like ``destination unreachable'', from
an intermediate router.  With a VPN, there will be a lot of sockets
sharing the same SPI for the firewall-to-firewall key.  This is true
whether key management is manual or automated.

I confess that I'm surprised by your response, since I seem to remember
talking about this with you, and you agreeing that this was a problem.

Xref subject previous
Xref subject next

   Date: Tue, 13 Feb 96 22:06:34 GMT
   From: "William Allen Simpson" 

   Not true.  Photuris includes all of the features listed in RFC-1825 1.4.
   This should not be surprising, as I also made contributions to that list.

You're right; my apologies.  I hadn't thought to look in
draft-ietf-ipsec-photuris-ext-01.txt.

						- Ted

Xref subject previous
Xref subject next

At 01:44 PM 2/13/96 -0500, Theodore Ts'o wrote:
>
>	Right now we have a number of differnet proposals on the table,
>none of which completely meet all of the original requirements.
>However, it wouldn't be that hard to fix this; it wouldn't be hard for
>SKIP to add PFS, or Photoris to add support for full Security
>Association attributes negotiation, etc.  Instead of bickering around
>playing procedural games and raising meta-issues, if the various people
>who are proposing key management protocols to this wg simply sat down
>and did the work to meet all of the requirements as originally specified
>by this wg, we could be done in relatively short order.  I really don't
>think it's all that hard for any of the proposals currently on the
>table.

Seconded.  What is the Draft deadline?  If any of these protocols are
serious, let's see revisions to work on for LA.

BTW, I will be at the ISOC security symposium next week to discuss any of this.

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref: Re: Expires RR proposal Edie E. Gunter
Xref subject next

At the last IETF there was some discussion about an RR to achieve the
expiration features of the DNSSEC draft, but without the appearance of
any security (or the requirement for the security overhead).  Many
people put forward good reasons for having this as a separate thing.
I've put together a draft of a spec for this (extremely drafty :-).
It's attached to this message, and I'd appreciate any feedback (both
of the open questions in the document, and discussion on the list as
to whether this is the right approach).

In the document, meta comments are set off with [[[triple brackets]]]
to isolate them from the main text.  If people think it would be
useful, we should consider some discussion (at the end of :-) the
DNSIND meeting in LA (what's the deadline for submission?  I think
Friday, so get those comments in quick :-).

	-MAP

----------------------------------------------------------------




INTERNET DRAFT                                               M. A. Patton
Expiration Date: April 1996                                           BBN
</draft-ietf-dnsind-expires-??.txt>draft-ietf-dnsind-expires-??.txt>                          December 1995


	 Scheduled Expiration of DNS Resource Records


Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   ``work in progress.''

   To learn the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' listing contained in the Internet-
   Drafts Shadow Directories on ds.internic.net (US East Coast),
   nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
   munnari.oz.au (Pacific Rim).

   This Internet Draft expires April 1996.

   [[[Global issues for entire draft:
	Draft as written expires all RRs of a type together.  This
		seems to be reasonable given some other discussions,
		but may be controversial.  Since my inclination was
		towards treating a whole RR set the same already and I
		couldn't figure out a good way to be more fine-grained,
		I felt it was useful to do it this way, at least to
		start.  For all these reasons, I will leave it as is,
		unless someone comes up with a compelling reason for
		it, AND a good design for how to do it.
	Do we need to expire CNAMES?  Can't put an EXP there...unless
		we make EXP an exception to that rule.  I think the
		DNSsec does this for SIGs...just extend that exemption?
	Should the SOA serial be updated when records expire?  I think
		the same words that are in the DynDNS draft should be
		put here...  Problem is that this can happen in both
		primary and secondary servers.
	Interaction with Dynamic Update.  Do expired RRs appear to be
		there or not for the conditioning section of an
		update.  May want them to appear to be there for
		several reasons 1) they need to be deleted for real
		(maybe); 2) may be trying to replace just around time
		of expire and not having them is a race condition; and
		3) may have been used in conditioning because a recent
		query showed it there.  On the other hand, these may
		want to be really gone once expired, because they're
		no longer visible to queries and therefore updates may
		assume they don't exist and say that in the conditional
		part...
	Should anything be said about expiring EXP RRs?  This draft
		lets you do it, which can result in odd behaviour.  On
		the other hand, I don't see why outlawing it is really
		needed (maybe someone will come up with a good use for
		this "feature").
   ]]]


Abstract

   This document describes an additional RR type for the Domain Name
   System[7,8] which provides for scheduled expiration of RRs in the
   DNS.  These RRs record the time at which a referenced set of RRs
   are to be removed from the DNS.  This can be used to provide the
   information required to automatically support the reduced TTLs
   described in RFC1034[8] when anticipating a change, and by being in
   the zone data, will communicate that information to other servers
   that recognize the RR, in particular, secondary servers that
   recieve the data by Zone Transfer (AXFR or IXFR[2]).

Introduction

   [[[TBD]]] [[[Ref discussion in DNSIND and DNSSEC]]]

1. definition of the RR type

   The Expires RR is defined with mnemonic "EXP" and TYPE code
   [[[TBD]]] (decimal).  The format is based slightly on the format
   used for the SIG RR in the DNS Security Extensions[1]

   The format of an Expires (EXP) RR is:

                                            1  1  1  1  1  1
              0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                                               |
           /                                               /
           /                     NAME                      /
           |                                               |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                 TYPE = EXP                    |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                 CLASS = IN                    |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                     TTL                       |
           |                                               |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                   RDLENGTH                    |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                    COVERS                     |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                     TIME                      |
           |                                               |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where:

   *  NAME: an owner name, i.e., the name of the DNS node to which this
      resource record pertains.

   *  TYPE: two octets containing the EXP RR TYPE code of 31 (decimal).

   *  CLASS: two octets containing the RR IN CLASS code of 1.

   *  TTL: a 32 bit signed integer that specifies the time interval in
      seconds that the resource record may be cached before the source
      of the information should again be consulted.

   *  RDLENGTH: 6

   *  COVERS: is the type code of the RR set that it covers or 255 to
      indicate that it applies to all RRs of the same name and class.
      This is a subset of the QTYPE defined in RFC1035.

   *  TIME: The date and time that the referenced RRs are due to
      expire, represented as an unsigned number of seconds since the
      start of 1 January 1970, GMT, ignoring leap seconds.

   [[[It's been suggested to add an "Effective on" time or function.
   If that's desired by anyone, my temptation is to make it separate.
   For this to be useful, it (and EXP) would really need to apply to
   specific RRs rather than a whole RR set.  This makes it hard.  For
   all these reasons, I will leave it out, unless someone comes up
   with a compelling reason for it, AND a good design for how to do
   it.  My inclination is that this should be done with something like
   adding an EXP, then at the "effective time" doing a DYNDNS update
   removing the EXP and the RRs it covers and adding the new ones.
   This probably requires that the expired RRs appear to be there
   whether they've expired or not for the purposes of update, but they
   may not be visible to queries, can we make this reasonable.]]]

2. Master File Format

   The format of EXP RRs follows all the rules of RFC 1035,
   Section 5, "Master Files."  


   Example master file (based on the example in RFC1035):

   @   IN  SOA     VENERA      Action.domains (
				    20     ; SERIAL
				    7200   ; REFRESH
				    600    ; RETRY
				    3600000; EXPIRE
				    60)    ; MINIMUM

	   NS      A.ISI.EDU.
	   NS      VENERA
	   NS      VAXA
	   MX      10      VENERA
	   MX      20      VAXA

   ; address record for host A is good until 8am, 1 Jan 1996
   A       A       26.3.0.103
   	   EXP     A       19960101080000

   VENERA  A       10.1.0.52
	   A       128.9.0.32
   ; all address records for  host VENERA are good until midnight, 31 May 1996
           EXP     A       19960531000000

   ; no expiration for VAXA's addresses
   VAXA    A       10.2.0.27
	   A       128.9.0.33


3. Handling of Expires RRs and RRS covered by them

   When an authoritative server [[[is this limitation good?  bad?
   other?]]] returns any RR covered by an Expires RR, it must assure
   that the TTL is small enough that copies will not be cached beyond
   the given expiration time.

   Although the server does not need to actually remove expired RRs
   from its database, it must give the appearance of having done so when
   formulating replies to query or transfer requests.  A simple algorithm 
   for skipping over expired RRs or adjusting their TTL to match an 
   expiration time is shown below:

	if expire > now {
		if (expire - now) > TTL {
			TTL = (expire - now)
		}
		include RR in reply
	}

   This algorithm makes the TTL just small enough to satisfy the EXP
   requirements.  Some people have suggested more elaborate techniques
   to reduce the inherent inconsistencies introduced.  Such an
   algorithm might be to use a two day TTL when the change is more
   than a week away, but a week ahead, start lowering the TTL such
   that 3 days before the change only 1 day TTLs are given out, and a
   day in advance it's down to a few hours, and a few hours in advance
   it's down to 30 minutes.  The usefulness of this more gradual
   approach has been debated [[[do I have any references on this
   discussion???]]], but in any case it is a local matter as long as
   the TTL does not exceed that given by the simple algorithm above.

4. Additional Section Processing

   [[[Do we need this?]]]
   [[[Maybe suggest including them when they apply?  Probably not useful.]]]

5. Acknowledgements

   The original arguments for this as a separate RR were put forward
   by Robert Elz in the DNSIND Working Group.  Many others described
   uses and requirements that were the basis of this design.  Comments
   and some explanatory text from Walt Lazear were helpful.

   I'd also like to thank Arnt Gulbrandsen for his collected list of
   DNS RFCs and permission to use it as the basis for the References
   section and Bill Manning, the author of RFC1348[4], for unwittingly
   supplying the boilerplate and diagrams I used as a basis for this
   document.  Much of the layout of the RR was based on the work of
   Donald Eastlake and Charles Kaufman in the design of the DNS
   Security Extensions.

6.  Security Considerations

   Security issues are not [[[yet]]] discussed in this memo.
   [[[Should any be???]]]
   [[[ EXP allows add permission to be turned into delete
		permission]]]
   [[[ interaction with DNSSEC, which has a different variant of
		expiration, and with secure update[TBD]. ]]]

7. References

   [1]  DNSsec draft [[[fill in details]]]

   [2]  IXFR draft [[[fill in details]]]

   [3]  RFC 1536: A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller,
             "Common DNS Implementation Errors and Suggested Fixes.",
             10/06/1993.

   [4]  RFC 1348: B. Manning, "DNS NSAP RRs", 07/01/1992.

   [5]  RFC 1183: R. Ullman, P. Mockapetris, L. Mamakos, C. Everhart,
             "New DNS RR Definitions", 10/08/1990.

   [6]  RFC 1101: P. Mockapetris, "DNS encoding of network names and
             other types", 04/01/1989.

   [7]  RFC 1035: P. Mockapetris, "Domain names - implementation and
             specification", 11/01/1987.

   [8]  RFC 1034: P. Mockapetris, "Domain names - concepts and
             facilities", 11/01/1987.

   [9]  RFC 1033: M. Lottor, "Domain administrators operations guide",
             11/01/1987.

   [10]  RFC 1032: M. Stahl, "Domain administrators guide", 11/01/1987.

   [11]  RFC 974: C. Partridge, "Mail routing and the domain system",
             01/01/1986.

8. Authors' Address:

   Michael A. Patton
   Bolt Beranek and Newman
   10 Moulton Street
   Cambridge, MA, 02138

   Phone: (617) 873 2737
   FAX:   (617) 873 3457
   Email: map@bbn.com


This Internet Draft expires April 1996

Xref subject previous
Xref subject next

> From: "Theodore Ts'o" 
> Instead of bickering around
> playing procedural games and raising meta-issues,

It has been suggested in private email that calling for public "support
for Photuris" [my earlier message] is "playing procedural games".

Gentlefolk, that is our process.  The chairs are procedurally
constrained by the public comments.

Apparently, the chairs have received nothing but negative comments.
It is common for us during protocol design to detail only the flaws.

If there is not sufficient support for the chairs to go ahead with
Photuris, then I certainly wouldn't want to waste any more time in the
WG with the proposal.  Instead, lacking WG support, it should be
published as Experimental as originally intended, and the WG can get on
with SKIP as may be the consensus desired.

There are only a few days remaining for draft cut off.

The time to announce your support is now....

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref: Re: ICMP messages Phil Karn
Xref subject previous
Xref subject next

> From: smb@research.att.com
> I beg your pardon?  First you say ``only if you are using the same
> Destination+SPI for more than one socket.'', which is the case for
> host-host keys.

Not in host-host tunnel mode.  In that case, there is no socket.  As
explained in RFC-1853, soft state needs to be maintained for the tunnel
endpoints to reflect the ICMP messages to the originating host.

This may be that same host, of course, when the tunnel is internally
generated.  The same soft state can be reflected to the sockets
individually.


> Then you say ``only a problem for user-user keys'', in
> which case you're less likely to have multiple sockets per SPI.  (Though
> it's not impossible, of course.)
>
Some folks have contemplated such.  Indeed, your CBC concatenation
attack requires that the same SPI be used by more than one user.

While we probably cannot prohibit this behaviour for manually keyed
implementations, Photuris clearly states that such sharing is not
allowed because it is not secure, and contains mechanisms to prevent
this from happening.


> Scenarios I have in mind are things like ``destination unreachable'', from
> an intermediate router.  With a VPN, there will be a lot of sockets
> sharing the same SPI for the firewall-to-firewall key.  This is true
> whether key management is manual or automated.
>
The distinction is that the firewalls' tunnel has no sockets itself, and
therefore no need to search the internal headers.


> I confess that I'm surprised by your response, since I seem to remember
> talking about this with you, and you agreeing that this was a problem.
>
I cannot remember the details of our conversation.  Perhaps I was
agreeing that it is a problem for users sharing the same host SPI, which
lead to the restriction in Photuris.  I do not believe this is a problem
for VPNs following 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

Xref subject previous
Xref subject next

I do believe Photuris fulfills all the requirements of the WG; if the
chairs believe i'm at fault, i invite them to tell me why it is so.
Regards,
-Angelos

Xref subject previous

We have started Photuris implementation. At this point, we have been able to
implement it from the spec and I beleive is conforms to most of the
requirments in RFC1825. I say most because I have not thought about all
possible scenarios. 

If the Admin's and the working group feel that there are deficiencies in the
current key management drafts, I guess those should be enumerated as Angelos
mentioned in his mail. Having a key management protocol is critical for the
acceptance of IPSEC and we have to come up with standard(s) as soon as
possible. 

Regards,

--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)659-6743 (O)

Xref: Re: Expires RR proposal Michael A. Patton
Xref subject previous
Xref subject next


In light of DNSSEC, the EXP RR seems superfluous to me.
Everything you can do with EXP, I can do with a SIG.  I
can't think of when I'd ever want to use EXP.  (And in
a 10,000 node zone, where each node has an A, KEY, and SIG
RR, another 10,000 EXP RR's is going to be a hard sell, no?)

I was actually at the Dallas meetings, but I missed the
point behind defining a new RR to do something the SIG
is more than capable of handling.

Edie

Xref subject next


	As a result of some private communications, I'd just like to publicly
voice that I think that the Photuris protocol is a viable and reasonable
contender for Internet standards-track status and shouldn't be derailed.
However, I also think that it's very important the the spec document be as
well done as possible, and I have not seen anything in the new straw poll
consensus that is an unreasonable requirement for a specification to provide.
I'd like to see the Photuris spec changed to meet these requirements so that
it (and we) can move on to more important things like trying to implement.

								-Craig

Xref: Re: Expires RR proposal Edie E. Gunter
Xref subject previous
Xref subject next

   Date: Wed, 14 Feb 96 14:00:11 -0500
   From: "Edie E. Gunter" 

   In light of DNSSEC, the EXP RR seems superfluous to me.

That was my reaction when I first heard it mentioned in Dallas, but
many discussions at DNSIND, DNSSEC, and in the corridors, convinced me
that it was an interesting avenue to explore.  Since I was thus on
both sides of that question at different times, I figured I might be a
good candidate to balance the exposition.

   Everything you can do with EXP, I can do with a SIG.  I
   can't think of when I'd ever want to use EXP.

The times you'd want to use an EXP are when your zone does not run
security (which can happen for many reasons[*]) and thus you don't have
SIGs.  Even if you have some SIGs, using EXPs when what you want is
expiration, rather than overloading the SIGs for this function may be
simpler to manage (i.e. I could add EXPs by hand edit, I probably
wouldn't hand edit a SIG) in some contexts.

The original proposal (which is in the DNSSEC doc) was to use a SIG
that didn't have any signature data (this has been variously called
the NULL SIG algorithm or the "no security" algorithm).  The security
people were (rightfully, IMHO) somewhat leery of specifying in the DNS
Security spec, something that gave no security.  This concern came out
clearly near the end of the DNSIND meeting.  Thus the idea of a
separate RR for when this is the functionality you want.  Logically
use of the EXP RR replaces use of the SIG RR with NULL algorithm.

   I was actually at the Dallas meetings, but I missed the
   point behind defining a new RR to do something the SIG
   is more than capable of handling.

The discussion (as I recall) happened mostly at the end of the DNSIND
meeting, very briefly at DNSSEC, and in the corridors in between.  The
basic reason is that there are valid uses for expiration above and
beyond those required for DNSSEC, and since there may be reasons that
security isn't run[*], having the expiration available as a separable
part of the DNS seemed like the right idea.

There is a placeholder in the document where I intended to put some of
this discussion (in the intro), but I haven't had the time, yet.  I'll
save this message as a start on that...

	-MAP

(*) Is it even legal in France and/or China to have SIG RRs on your
server?  (I don't know IANAL, especially in those countries :-).  If I
have a large isolated (small i) internet on which I trust everyone,
why should I pay the cost of running crypto algorithms on all my DNS
servers all the time just so I can expire some RRs occasionally?

Xref subject previous
Xref subject next



>From: dpkemp@missi.ncsc.mil (David P. Kemp)
>Message-Id: <199602121439.JAA02761@argon.ncsc.mil>
>
>There are (at least :-) two directions in which to look for solutions:
>
> 1) Internet Draft "draft-krawczyk-keyed-md5-01.txt" presents an
>    analysis of the use of hash functions as Message Authenticators.
>    It suggests using the construct:
>
>       Hash(Key, Pad2, Hash(Key, Pad1, Text))
>
>    in lieu of other structures such as Hash(Key, Text, Key).
>    The Krawczyk MAC relies on significantly fewer assumptions about
>    the properties of the hash algorithm than do other methods (which
>    were apparently concocted without much in the way of security
>    analysis).

Just to expand a bit: the above  scheme is assured to serve as
a good MAC as long as the following two conditions hold.  (This
applies for any iterated hash function, in particular MD5 and SHA).

  1. The hash function is collision-free. 

  This is what hash functions are designed for.  (In fact, only a
  considerably weaker-than-standard collision-freeness assumption is
  needed, namely that collisions are hard to find when the iterated
  construction starts with a *random and secret* IV, rather than with
  the fixed public IV.  Furthermore, parallel collision-finding attacks
  a la Van-Oorschot-Weiner are infeasible here.)

  2. The internal compression function of the hash function
  is a good MAC on 512 bit messages.

  This is a minimal security requirement that is believed to hold 
  for both MD5 and SHA.

This scheme is proposed and analyzed in the paper 
"Keying Hash Functions for Message Authentication" 
by Mihir Bellare, Hugo Krawczyk and myself, available at

  http://www-cse.ucsd.edu/users/mihir
  http://www.research.ibm.com/security/keyed-md5.html

It is also summarized in the above Internet Draft.


Ran Canetti

Xref subject previous

>>From: dpkemp@missi.ncsc.mil (David P. Kemp)
>>Message-Id: <199602121439.JAA02761@argon.ncsc.mil>
>>
>>There are (at least :-) two directions in which to look for solutions:
>>
>> 1) Internet Draft "draft-krawczyk-keyed-md5-01.txt" presents an
>>    analysis of the use of hash functions as Message Authenticators.
>>    It suggests using the construct:
>>
>>       Hash(Key, Pad2, Hash(Key, Pad1, Text))
>>
>>    in lieu of other structures such as Hash(Key, Text, Key).
>>    The Krawczyk MAC relies on significantly fewer assumptions about
>>    the properties of the hash algorithm than do other methods (which
>>    were apparently concocted without much in the way of security
>>    analysis).

In light of this work, are there any plans to update RFC1828?


Derrell Piper   | piper@tgv.com      | 408/457-5384
TGV, Inc.       | 101 Cooper Street  | Santa Cruz, CA 95060 USA

Xref: Re: Straw Poll and Photuris Todd Graham Lewis
Xref subject previous
Xref subject next

> From: Craig Metz 
> However, I also think that it's very important the the spec document be as
> well done as possible, and I have not seen anything in the new straw poll
> consensus that is an unreasonable requirement for a specification to provide.

Indeed, neither have I.

Except that the straw poll statement goes beyond the actual results of
the 3 questions in the poll itself to indicate a "conclusion" not
indicated in any of the responses to the poll, and not germain to the
questions in the poll.

    CONCLUSIONS:
            (1) None of the proposals currently online appear to fully
                meet all of the requirements, though it does appear that
                all of them could be modified to meet all of the
                requirements.

How can this "conclusion" be reached, when examination of the list
archives yields not a single response to the straw poll mentioning that
none of the proposals fully meets the requirements?

This conclusion does not in any way represent "consensus".  It may be
the personal opinion of one or more chairs, but that is not within their
purview to impose upon the rest of us.


> I'd like to see the Photuris spec changed to meet these requirements so that
> it (and we) can move on to more important things like trying to implement.
>
It has been admitted that Photuris meets every single requirement listed
in RFC-1825 section 1.4 and section 2.  What requirement do you mean?

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref: Re: Straw Poll and Photuris Julio Sanchez
Xref subject previous
Xref subject next

On Thu, 15 Feb 1996, William Allen Simpson wrote:
(...)
> Except that the straw poll statement goes beyond the actual results of
> the 3 questions in the poll itself to indicate a "conclusion" not
> indicated in any of the responses to the poll, and not germain to the
> questions in the poll.
> 
>     CONCLUSIONS:
>             (1) None of the proposals currently online appear to fully
>                 meet all of the requirements, though it does appear that
>                 all of them could be modified to meet all of the
>                 requirements.
> 
> How can this "conclusion" be reached, when examination of the list
> archives yields not a single response to the straw poll mentioning that
> none of the proposals fully meets the requirements?
(...)
> It has been admitted that Photuris meets every single requirement listed
> in RFC-1825 section 1.4 and section 2.  What requirement do you mean?

I am confused as well by the nature of the previous days' objections.  My 
impression has been that Photuris does meet these requirements.  I have 
been wrong on these sorts of issues in the past, and I do not claim any 
great insight into the issue.  However, I personally would appreciate it 
those bearing objections would state "Photuris is not ready to progress 
beyond draft stage because it does not meet requirement (X) as stated in 
(Y) as evinced by the following quote from (Z)."  I think that such an 
approach might enable all of us to have a better idea of the sense of the 
working group, which I think is what the chairs are seeking.

My opinion, _in the absence of such specific objections_, is that Photuris 
has met the aforementioned requirements, and it should be allowed to advance.

Todd Lewis
todd@wooster.org

Xref subject previous


> Date: Thu, 15 Feb 1996 07:15:51 -0600 (CST)
> From: Todd Graham Lewis 
> 
> My opinion, _in the absence of such specific objections_, is that Photuris 
> has met the aforementioned requirements, and it should be allowed to advance.

I second this position. Please, tell what is wrong with Photuris here
so that we can all hear it and think about it. Maybe I have been to
sleepy, but I am yet to hear any strong objection.

Maybe it's that those like me who agree with the general principles
behind Photuris have been quiet. This has nothing to do with blanket
approval, it's rather than we are happy with the way the Photuris
design team has addressed those weaknesses pointed to them.

But I thought this was the IETF way, you don't speak unless you
object. Maybe I was wrong.

-- 
Julio Sanchez, SGI Soluciones Globales Internet
Tel/Fax: 91/804 14 05  WWW: http://www.esegi.es
jsanchez@esegi.es jsanchez@gmv.es
 PGP Key fingerprint =  E5 29 93 6F 41 4E 00 E2  90 11 A1 8C 72 D0 DE 71 

Xref: Re: Expires RR proposal Donald E. Eastlake 3rd
Xref subject previous
Xref subject next

> The original proposal (which is in the DNSSEC doc) was to use a SIG
> that didn't have any signature data (this has been variously called
> the NULL SIG algorithm or the "no security" algorithm).  The security
> people were (rightfully, IMHO) somewhat leery of specifying in the DNS
> Security spec, something that gave no security.

If this is the only argument, then why not remove SIG from the
DNS Security spec into its own spec and allow it to be general
purpose?  Seriously.  Rename it (if you like) and make the signature
information optional.

(Although I must ask, why is it okay to have a KEY RR with no key
data, but it is NOT okay to have a SIG RR with no signature data?)

> The times you'd want to use an EXP are when your zone does not run
> security (which can happen for many reasons[*]) and thus you don't have
> SIGs.

Are EXP's disallowed in secure DNS?  If not which expiration time
will win -- that of the SIG or that of the EXP?  Do we really want
2 set of rules regarding what happens to expired RRs -- DNSSEC
says they appear as if they've been deleted; the EXP spec implies
maybe not?  We want dynamic updates to work the same
whether you use security or not, right?  I do.

>  Even if you have some SIGs, using EXPs when what you want is
> expiration, rather than overloading the SIGs for this function may be
> simpler to manage (i.e. I could add EXPs by hand edit, I probably
> wouldn't hand edit a SIG) in some contexts.

Ah, but simpler for who?  A sysadmin surely doesn't need the duplication.
And, editting a NULL SIG by hand is as simple as editting
an EXP by hand, imho.

Edie

        From where I sit talking to IP security product vendors,
both Photuris and SKIP in their current forms meet the market requirements
for large rapidly growing markets.  The SKIP protocol has unique advantages
in the area of multi-cast transmissions, and the Photuris has advantages
for high security point to point communication that includes perfect 
forward secrecy.  Vendors need both.  Users will buy both.
        The IETF should help the vendors meet these growing user demands
as soon as possible.  Further delay in the working group will cause the
vendors to move on by themselves, which history shows will cause problems
down the road.
        This is a time for hard work by smart people cooperating with
each other.  This is not a time for dragging heals!
                --Bob

P.S. This is my personal opinion, not a company statement.
 

Xref: Re: support for Photuris  Perry E. Metzger
Xref subject next

I just wanted to express my support for Photuris: IMHO, it looks like
a reasonable solution.  I'm comfortable with Photuris; my personal feeling
is that it should be allowed to advance...

Are there any substantive objections to Photuris, in terms of the ipsec
requirements for a key management protocol?

Xref subject previous


David A Wagner writes:
> I just wanted to express my support for Photuris: IMHO, it looks like
> a reasonable solution.  I'm comfortable with Photuris; my personal feeling
> is that it should be allowed to advance...
> 
> Are there any substantive objections to Photuris, in terms of the ipsec
> requirements for a key management protocol?

I think that there are details in Photuris that need to be worked with
and possibly changed. I think we also need more field experience and
probably a bunch more experimentation. However, the fundamentals of
the Photuris approach are sound and I feel comfortable with them. I
think we might go from proposed standard back to proposed a second
time once we have more experience if that experience dictates more
than cosmetic changes, but thats another story. I certainly feel
Photuris is what we want and that it should move forward.

Perry

Xref subject next

As long as we are on the subject, I would like to suggest that we make
support for RSVP a requirement for the key management protocol.  Support
for RSVP is not difficult and most of the current proposals will already
support it.  Those that do not could be made to without too much effort.
The requirement is basically that unique SPIs be available for each flow.
A draft by Lou Berger  and Tim O'Malley  is
promissed to be available soon.

On another topic related to requirements, I do not agree that Photuris
meets the working group requirements.  For example, section 1.4 of RFC 1825
is nigh impossible to acomodate for an interoperable implementation based
on the Photuris draft and the extentions draft.  The entire draft(s) has
become unwieldy.

Dave

----------------------------------------------------------------------------
David Carrel				|  E-mail:  carrel@cisco.com
Security Development, cisco Systems	|  phone:   (408) 526-5207
170 W. Tasman Drive			|  fax:     (408) 526-4952
San Jose, CA 95134-1706			|  
----------------------------------------------------------------------------

Xref: Re: Working group requirements Todd Graham Lewis
Xref subject previous
Xref subject next

On IPsec, you wrote:
> I do not agree that Photuris meets the working group requirements.
> For example, section 1.4 of RFC 1825 is nigh impossible to acomodate [sic]
> for an interoperable implementation based on the Photuris draft and the
> extentions [sic] draft.  The entire draft(s) has become unwieldy.

I think it would be extremely useful for you to elaborate on precisely _how_
the Security Associations section of RFC 1825 is "nigh impossible" to
accommodate for an interoperable implementation based on the drafts. The WG
seems to be spending days upon days effectively 'voting' on whether or not
Photuris meets the WG requirements. At this stage of the game, this strikes
me as a bit silly. IMHO everyone (including the chairs) should be getting
down to brass tacks, so the remaining technical objections can be resolved
one way or another.

-Lewis

Xref subject previous

On Fri, 16 Feb 1996, Lewis McCarthy wrote:

> I think it would be extremely useful for you to elaborate on precisely _how_
> the Security Associations section of RFC 1825 is "nigh impossible" to
> accommodate for an interoperable implementation based on the drafts. The WG
> seems to be spending days upon days effectively 'voting' on whether or not
> Photuris meets the WG requirements. At this stage of the game, this strikes
> me as a bit silly. IMHO everyone (including the chairs) should be getting
> down to brass tacks, so the remaining technical objections can be resolved
> one way or another.

I strenuously agree with this objection.  I want to see the list of 
reasons why advancing Photuris is unacceptable.  I would like to see 
line-by-line references, as many members of this working group have done 
in the past.  I think that the amount of time we are spending on this is 
silly.

I say this because there are many members of this group more adept at 
addressing the issues than myself.  My impression is that Photuris is 
ready to advance.  If others disagree, then you should make your 
objections known.  If you do not, then I will pat myself on the back for 
being such a smart guy and then press for Photuris' advancement.

However, in the last 72 hours the only objection has been an 
un-referenced opinion that implementation of the RFC1825 Security 
Association requirements would be impossible (an objection that I do not 
understand after having re-read RFC1825 and the draft Photuris spec.)  
This leads me to believe that there are no members of the group who bear 
serious objections to Photuris' advancement.  I think that the Chairs 
should seriously consider taking appropriate steps to insure that we can 
meet the already-stretched timeframe for getting something (Photuris 
and/or others) out the door.


Todd Lewis
todd@wooster.org

P.s.,
(In reference to carrel@cisco.com)
	Reflecting over the development cycle through which Photuris has 
gone, I am of the opinion that its level of complexity is the result of 
its absolute demand for integrity.  If others could come up with a 
key-management method of less complexity which achieves equivalent 
results, then I wish that they had done so in a timely manner.  I 
personally think that any protocol "nigh" able to "accomodate section 1.4 of 
RFC1825" will be just as "unwieldy" as Photuris, and I wish that people 
with real objections (if there are any) would come forward so that we can 
finish this business and get on with securing IP traffic ASAP.  I don't 
think that this is an unreasonable demand.  
	I do think that the chairs are being awfully generous to those with 
objections to Photuris.  I also think that those with objections might 
just be Phantoms of a collectively over-active imagination, and this 
opinion will strengthen as time goes on and these phantom objections 
continue to keep themselves hidden from the rest of us too dumb to think 
them up ourselves.

Todd

Xref subject previous
Xref subject next

I don't really care that much either way on the EXP RR but I think the
primary argument for it was that you SIG's expiration dates may most
easily be set all the same by an application that goest through and signs
your zone.  So an RR might expire in some higher sense either before or
after its authenticating SIG expires.  Data would not be considered valid
if either the EXP or SIG had expired.

Donald

PS:  The dns sec draft does include a "null" SIG and KEY RR so you can use
these for expiration under the curretn dns sec draft if you want. 

On Thu, 15 Feb 1996, Edie E. Gunter wrote:

> Date: Thu, 15 Feb 96 10:34:35 -0500
> From: Edie E. Gunter 
> To: Namedroppers@internic.net, DNS-security@TIS.COM
> Subject: Re: Expires RR proposal
> 
> > The original proposal (which is in the DNSSEC doc) was to use a SIG
> > that didn't have any signature data (this has been variously called
> > the NULL SIG algorithm or the "no security" algorithm).  The security
> > people were (rightfully, IMHO) somewhat leery of specifying in the DNS
> > Security spec, something that gave no security.
> 
> If this is the only argument, then why not remove SIG from the
> DNS Security spec into its own spec and allow it to be general
> purpose?  Seriously.  Rename it (if you like) and make the signature
> information optional.
> 
> (Although I must ask, why is it okay to have a KEY RR with no key
> data, but it is NOT okay to have a SIG RR with no signature data?)
> 
> > The times you'd want to use an EXP are when your zone does not run
> > security (which can happen for many reasons[*]) and thus you don't have
> > SIGs.
> 
> Are EXP's disallowed in secure DNS?  If not which expiration time
> will win -- that of the SIG or that of the EXP?  Do we really want
> 2 set of rules regarding what happens to expired RRs -- DNSSEC
> says they appear as if they've been deleted; the EXP spec implies
> maybe not?  We want dynamic updates to work the same
> whether you use security or not, right?  I do.
> 
> >  Even if you have some SIGs, using EXPs when what you want is
> > expiration, rather than overloading the SIGs for this function may be
> > simpler to manage (i.e. I could add EXPs by hand edit, I probably
> > wouldn't hand edit a SIG) in some contexts.
> 
> Ah, but simpler for who?  A sysadmin surely doesn't need the duplication.
> And, editting a NULL SIG by hand is as simple as editting
> an EXP by hand, imho.
> 
> Edie
> 

=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     dee@cybercash.com
   318 Acton Street        +1 508-371-7148(fax)     dee@world.std.com
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.eff.org/blueribbon.html

Xref subject previous

In a galaxy far, far away, : Mon, 05 Feb 1996 23:49:31 PST
> If AH with a symmetrically-keyed MAC is used just for protecting reserved
> bandwidth (not for secure end-to-end source authentication or message
> integrity), then it doesn't seem like such a big deal to have to trust a
> few routers to hold your bandwidth session-key.

  I agree. It doesn't sound that bad. But, which routers do I share the
secret with? My packet could go via different routes each time. The routers
could be "owned" by malevolent entities.
  How do I negotiate the AH key for the RSVP differently from the one I use
for authentication?
  I'd like to use RSVP on *all* my data. It seems like an ideal way to
cope with many denial of service attacks. 
  RSVP specifies that the recipient sets up the reservations. IPsec does
a similar thing: the receiver picks the SPI. So in any public key system, the 
recipient has to let the router know what public key is going to be signing 
which SPI. I have to review RSVP again to figure out how that works... 
(RSVP does provide for having AH protected RSVP messages. But it also
provides its own encryption facilities. I think it should stick to AH)

> (After all, you have to trust them to actually give you the bandwidth which
> they've promised to reserve for you.)

  Yes, then the question arises: how close to the backbone do I have to reserve
bandwidth for? Do I let other people reserve bandwidth for their data
to leave my domain of physical control over my 56k link? 

> Yeah, that's a problem with public-key stuff: it's so slow.  Do note that
> signature verification is much faster than signature generation when you use
> RSA with a small public exponent, though it is admittedly still quite slow.

  Yes, I've read that paper.

  

I've recently submitted a draft for a key exchange protocol named
Oakley; the draft will be available in the archives and also as
http://www.cs.arizona.edu/xkernel/Papers/draft-ietf-ipsec-oakley-00.txt.

The technical rationale for Oakley is that two parties can establish
variation in the underlying problem facing a concerted passive attacker
who has recorded traffic and extensive time and resources.  The algorithms
are not new --- just Diffie-Hellman, encryption, etc., but the combinations
may provide a good degree of confidence in long-term privacy.

Oakley is intended for key exchange only; it separates the
establishment and naming of keying material from its eventual use.
The design stands on its own, but allows it (or will allow it) to be a
component of ISAKMP for establishing AH/ESP security associations.

I am distributing the Oakley draft even though it is far from complete
or perfect; the imperfections afflict many particulars.  It is my hope
that its basic precepts can be understood and discussed now, and this
will indicate if it has any merit within the working group.

I'd like to note that undertaking this task has been a humbling
experience (even without yet experiencing the lively public
commentary that draft writers provoke), and I take my hat off to those
who have trodden the draft path ahead of me.  If you will be at the ISOC
SNDSS meeting, you'll see on Friday that I have bought a hat
specifically for this purpose.

------------------------------------------  
IPSEC Implementation Survey 
 
Name of Implementation:  NRL  
Security Protocols: ESP, AH -- for BOTH IPv4 and IPv6
Security Transforms: ESP-DES, AH-MD5 
Key Management: manual, PF_KEY interface for key management daemons 
Lineage of Code: derived from and portable to 4.4-Lite BSD
Location of Source Code:  ftp://ftp.ripe.net/ipv6/nrl/IPv6_domestic.tar.gz
				for the September 1995 alpha release.

			   January 1996 alpha-2 release is not yet at an 
				ftp site, but should appear soon in the 
				protected "US-only" archives at ftp.c2.org. 
Point of Contact: ipv6-bugs@cs.nrl.navy.mil

Xref subject next


 
  
I have recieved several requests for the location of source code for ipsec 
implementations. Our working group also needs to coordinate interoperability 
testing amoung ourselves.  To this end, would ipsec implementors please fill 
out the following survey and post your completed survey to the ipsec mailing 
list. 
 
 
Thanks in advance, 
 
Paul A. Lambert 
ipsec co-chair  
 
------------------------------------------- 
IPSEC Implementation Survey 
 
 
Name of Implementation:  
Security Protocols:  
Security Transforms:  
Key Management:  
Lineage of Code:  
Location of Source Code:  
Point of Contact:  
------------------------------------------- 
 

Xref: Re: IPSEC Implementation Survey Antonio Fernandez
Xref subject previous
Xref subject next


 
I have received several requests for the location of source code for ipsec 
implementations. Our working group also needs to coordinate interoperability 
testing among ourselves.  To this end, would ipsec implementors please fill 
out the following survey and post your completed survey to the ipsec mailing 
list. 
 
 
Thanks in advance, 
 
Paul A. Lambert 
ipsec co-chair  
 
************************************************************ 
IPSEC Implementation Survey 
 
 
Name of Implementation:  
Security Protocols:  
Security Transforms:  
Key Management:  
Lineage of Code:  
Location of Source Code:  
Point of Contact:  
************************************************************ 

Xref subject previous
Xref subject next


--Boundary-16782935-0-0

Sorry for the double post with the survey, but our new Majordomo list server 
sent me a odd  (obvious only now non-fatal) error. 
 
p.l.


--Boundary-16782935-0-0
Content-Type: message/rfc822

Date: 21 Feb 96 14:31:41
From:"PALAMBER.US.ORACLE.COM" 
To: ipsec@tis.com
Subject: IPSEC Implementation Survey
Cc: PALAMBER@us.oracle.com
X-Orcl-Application: Mime-Version: 1.0
X-Orcl-Application: Sender: ipsec-request@neptune.tis.com
X-Orcl-Application: Precedence: bulk



 
I have received several requests for the location of source code for ipsec 
implementations. Our working group also needs to coordinate interoperability 
testing among ourselves.  To this end, would ipsec implementors please fill 
out the following survey and post your completed survey to the ipsec mailing 
list. 
 
 
Thanks in advance, 
 
Paul A. Lambert 
ipsec co-chair  
 
************************************************************ 
IPSEC Implementation Survey 
 
 
Name of Implementation:  
Security Protocols:  
Security Transforms:  
Key Management:  
Lineage of Code:  
Location of Source Code:  
Point of Contact:  
************************************************************ 




--Boundary-16782935-0-0--

The last call for the Mobile-IP proposals (to go to Proposed Standard)
includes one document

> 2. IP Encapsulation within IP
>	<draft-ietf-mobileip-ip4inip4-01.txt>

with broad applicability beyond Mobility. It also has strong interactions
with security in general and IPSEC in particular. So I hope the members of
this list have had a look at it.

Bob Smart

Xref subject previous

ICMP is a real pain in the IPSEC context. I'm not sure we can really
make all the cases work right, especially with tunnels.

But I'm not sure this is even a problem. Because spurious ICMP
messages are so easily generated in the Internet, and because you
can't count on them being generated even when they're warranted, most
hosts already treat them as purely advisory in nature. They are mostly
counted and ignored except when a human wants to look at them while
debugging a network path.

In the context of IPSEC, ICMP messages are even more problematic when
you consider that many are unsigned and could be easily faked. I'm a
little uncomfortable even with Bill's otherwise elegant idea of a
"security failure" ICMP message (re)triggering Photuris key exchange
because of the possibility of an attacker generating spurious ICMP
messages as a way to cause hosts to waste a lot of CPU time (re)doing
public key algorithms.

I'm afraid I don't have any real solutions here. Comments?

Phil

Xref subject next

For your consideration.

jim


8<------------------------------------------------------------------>8





Security Working Group                                         J. Hughes
Request for Comments: DRAFT                        Network Systems Corp.
                                                           February 1996


     Combined DES-CBC, MD5 and Replay Prevention Security Transform


Status of this Memo

   This document is a submission to the IETF Internet Protocol Security
   (IPSEC) Working Group. Comments are solicited and should be addressed
   to the working group mailing list (ipsec@tis.com) or to the author.

   This document is an Internet-Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working Groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet-Drafts draft documents are valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.

Abstract

   This draft describes a combination of privacy, authentication,
   integrity and optional replay prevention into a single packet format.

   This draft extends rfc1829.

Discussion

   This draft allows a combination of MD5 and DES-CBC. The goal is to
   ensure that the packet is authentic, can not be modified in transit,
   or replayed.

   Replay is optional. The inclusion of the replay field is negotiated
   as a part of the key exchange.




Hughes                                                  FORMFEED[Page 1]





RFC DRAFT                                                  February 1987


   The combinations of trasformations are summarized below.

                         DES-CBC    MD5      Replay

         RFC1829(ESP)      Yes       No        No
         RFC1828(AH)        No      Yes        No
         This Draft        Yes      Yes        No
         This Draft        Yes      Yes       Yes



Packet Format

The only difference from rfc1829 is s the inclusion of a MD5 residual
and an optional replay field.


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Security Parameters Index (SPI)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Initialization Vector (IV)                  ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---  ---
   |                                                               |   ^    ^
   ~                          Payload Data                         ~   |    |
   |                                                               |   |    |
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |    |
   |               |         Padding (0-7 bytes)                   |  MD5   |
   +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |    |
   |                               |  Pad Length   | Payload Type  |   |   DES-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |   CBC
   |                                                               |   |    |
   +               Replay Prevention Field (optional)              +   |    |
   |                                                               |   v    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---   |
   |                                                               |        |
   +                         MD5 Residual                          +        |
   |                                                               |        v
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       ---


Replay Prevention

   Replay prevention field is a 64 bit value that is used to make sure
   that a previous packet can not be sent again and be accepted as valid
   traffic.




Hughes                                                  FORMFEED[Page 2]





RFC DRAFT                                                  February 1987


   The format of the replay field is two 32 bit fields. The first 32
   bits is a session specific nonce. This value will be constant for the
   entire time that this key is in use. If both directions use the same
   encryption key, each directions shall use a different nonce.

   For example, the nonce can be the time of day that this session was
   established.

   This field is negotiated as a part of the key exchange.

   The second 32 bits is a simple binary up counter.

   The replay prevention is provided by making sure that the nonce is
   correct and that the counter is going up.

   The key must not be used for a period of time that allows the counter
   to wrap, that is, to transmit more than 2^32 packets using a single
   key. (Rfc1829 recommends changing the keys at least this often.)

        Note: It is possible to use the "incrementing IV" method
        discussed in rfc1829, but there are 2 problems. First, the
        "incrementing IV" method discussed in rfc1829 does not cover
        sending a packet which is recorded in one direction in the other
        direction (if both directions are using the same key).

        Second, the "incrementing IV" method described in rfc1829 is not
        checked for integrity. Changes in the IV will show through in
        the first block of the plaintext and may or may not be detected
        by the host once the packets are decrypted.

MD5 Residual

   The MD5 residual is a 128 bit MD5 (rfc1321) of the payload, padding,
   pad length, payload type and optional replay field. Note that the
   length of the area that the MD5 covers is a multiple of 64 bits.

   Note: This MD5 is not keyed nor includes any header nor other
   information than is specified here.

Security Considerations

   The claims of privacy, integrity, authentication, and optional replay
   prevention are made in this draft.

   Privacy is provided by DES-CBC. (This could actually be performed by
   any 64 bit block algorithm in CBC mode.) See the discussion of DES-
   CBC in rfc1829.




Hughes                                                  FORMFEED[Page 3]





RFC DRAFT                                                  February 1987


   Integrity is provided by the combination of DES and MD5.  Since the
   MD5 residual is under the DES transformation, the packet can not be
   changed in a reliable way that will not be detected by MD5.

   Authentication is provided since only the source and destination know
   the DES key. Since the MD5 is under the DES transformation, it can
   not be checked until after the packet is decrypted. If the MD5 is
   correct, it proves that it must have been encrypted by the source,
   since only the source knows the key. (If an evesdropper knows the
   keys, all bets are off anyway..)

   Replay prevention is provided by the combination of a constantly
   increasing count with a nonce, and the replay field is covered by MD5
   and MD5 is transformed by DES.



Author's  Address:

   James P. Hughes
   Network Systems Corporation
   Brooklyn Park, MN
   hughes@network.com
   http://www.network.com/~hughes



























Hughes                                                  FORMFEED[Page 4]


--------------
HTTP://WWW.Network.com/~hughes

Xref subject next

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the IP Security Protocol Working 
Group of the IETF.                                                         

       Title     : The Oakley Key Determination Protocol                   
       Author(s) : H. Orman
       Filename  : draft-ietf-ipsec-oakley-00.txt
       Pages     : 31
       Date      : 02/20/1996

This document describes a protocol, named OAKLEY, by which two 
authenticated parties can agree on secure and secret keying material.  The 
basic mechanism is the Diffie-Hellman key exchange algorithm.     
         
This protocol supports Perfect Forward Secrecy, compatibility with the 
ISAKMP protocol for managing security associations, user-defined abstract 
group structures for use with the Diffie-Hellman algorithm, key updates, 
and incorporation of keys distributed via out-of-band mechanisms.          

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-oakley-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-oakley-00.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-oakley-00.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: <19960220154420.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-oakley-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-oakley-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960220154420.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous
Xref subject next

At 11:34 AM 2/15/96, Edie E. Gunter wrote:
>> The original proposal (which is in the DNSSEC doc) was to use a SIG
>> that didn't have any signature data (this has been variously called
>> the NULL SIG algorithm or the "no security" algorithm).  The security
>> people were (rightfully, IMHO) somewhat leery of specifying in the DNS
>> Security spec, something that gave no security.
>
>If this is the only argument, then why not remove SIG from the
>DNS Security spec into its own spec and allow it to be general
>purpose?  Seriously.  Rename it (if you like) and make the signature
>information optional.

You are missing the point.  I was particularly vocal against the use of SIG
RRs with no signature.  It sounds like an oxymoron to me:  here's a SIG RR
to give you security; oh by the way there's no signature and thus no
security.

However, being sensitive to the needs of dynamic update in particular,
there is clearly a need for an expiration time for RRs.  So, the particular
suggestion at the DNS security meeting was that the expiration RR be
created (so that the concept is useful in general) and that the SIG RR
would later be specified to disallow NULL signatures and might even have
the expiration value removed in favor of this more general mechanism.  The
details of this suggestion will be visited when the specification is
advanced from proposed to draft.

>(Although I must ask, why is it okay to have a KEY RR with no key
>data, but it is NOT okay to have a SIG RR with no signature data?)

It is necessary to be able to state authoritatively, i.e., guarantee, that
key does not exist for a given domain name.  One mechanism by which this
might be accomplished is to have a SIG record that always covered all RRs
for a given domain.  Thus, whenever you retrieve a KEY RR you would have to
retrieve them all to verify that no KEY RR was intended to exist.  A
transaction SIG RR is also mechanism that could help this problem.

However, it should be straightforward to see that being able to state
authoritatively there is no key is a feature worth having.

>> The times you'd want to use an EXP are when your zone does not run
>> security (which can happen for many reasons[*]) and thus you don't have
>> SIGs.
>
>Are EXP's disallowed in secure DNS?  If not which expiration time
>will win -- that of the SIG or that of the EXP?  Do we really want
>2 set of rules regarding what happens to expired RRs -- DNSSEC
>says they appear as if they've been deleted; the EXP spec implies
>maybe not?  We want dynamic updates to work the same
>whether you use security or not, right?  I do.

An expire RR only applies to the RR which it covers, as indicated by the
COVER field in the RR.   Thus, there should be no conflict.

The only potential conflict I see is during the interim existence of both
an EXP RR and the expiration in the SIG RR, which wins if there is an EXP
RR that covers SIG RRs?  My preference is the EXP RR wins, in deference to
the migration path of eliminating the SIG RR expiration field.

Jim

----------------------------------------------------------------------------
James M. Galvin                                               galvin@eit.com
VeriFone/EIT, PO Box 220, Glenwood, MD 21738                 +1 410.795.6882

Xref subject previous

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the IP Security Protocol Working 
Group of the IETF.                                                         

       Title     : The Oakley Key Determination Protocol                   
       Author(s) : H. Orman
       Filename  : draft-ietf-ipsec-oakley-00.txt
       Pages     : 31
       Date      : 02/20/1996

This document describes a protocol, named OAKLEY, by which two 
authenticated parties can agree on secure and secret keying material.  The 
basic mechanism is the Diffie-Hellman key exchange algorithm.     
         
This protocol supports Perfect Forward Secrecy, compatibility with the 
ISAKMP protocol for managing security associations, user-defined abstract 
group structures for use with the Diffie-Hellman algorithm, key updates, 
and incorporation of keys distributed via out-of-band mechanisms.          

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-oakley-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-oakley-00.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-oakley-00.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: <19960220154420.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-oakley-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-oakley-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960220154420.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous
Xref subject next



TimeStep Corp. implementation successfully interoperated with Raptor and
SCC at RSA Conference.

************************************************************
IPSEC Implementation Survey
Name of Implementation: TimeStep PERMIT
Security Protocols: ESP, AH, proprietary
Security Transforms: ESP-DES
Key Management: proprietary, manual
Lineage of Code: from scratch
Location of Source Code: proprietary
Point of Contact: Stephane Lacelle 
************************************************************
 ---
stephane  

Xref subject previous
Xref subject next

> ************************************************************ 
> IPSEC Implementation Survey 
>  
>  
> Name of Implementation:   
> Security Protocols:  
> Security Transforms:  
> Key Management:  
> Location of Source Code:  
> Point of Contact:  
> ************************************************************ 

Xref subject next

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the IP Security Protocol Working 
Group of the IETF.                                                         

       Title     : SKIP extension for Perfect Forward Secrecy (PFS)        
       Author(s) : A. Aziz
       Filename  : draft-ietf-ipsec-skip-pfs-00.txt
       Pages     : 11
       Date      : 02/21/1996

This document describes an optional extension specifying how to use an 
ephemeral Diffie-Hellman exchange in conjunction with the SKIP protocol in 
order to provide perfect forward secrecy for situations where forward 
secrecy is necessary.                                                      

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-pfs-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-pfs-00.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-pfs-00.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: <19960221161154.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-pfs-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-skip-pfs-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960221161154.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject next


 
 
 
       DRAFT Agenda of the IPSEC Working Group 
          Thirty-Fifth IETF as of 2/22/96 
                   (March 4-5, 1996) 
 
MONDAY, March 4, 1996    1930-2200 IP Security Protocol WG 
19:30  Introductions 
       - brief background 
       - work items 
       - liaisons 
  ESP/AH         ------ 
19:45  RSVP & IPsec presentation, Lou Berger (BBN) 
20:05  ESP/AH Implementation summary, Ran (cisco) 
20:20  ESP transform for DES-CBC, unkeyed MD5,  
         & replay protection, Jim Hughes (Network Systems) 
  Key Management ------ 
20:45  Status and Progrssion of ISAKMP/SKIP/Photuris, Paul (Oracle) 
21:00  Patent Status Update, Paul (Oracle) 
21:15  ISAKMP update, Mark Schertler (US DoD) 
21:55  Summary and Action Items 
22:00  Adjourn 
 
TUESDAY, March 5, 1996   0900-1130 IP Security Protocol WG 
 9:00  Introductions 
       - brief review of 3/4/96 meeting and work items 
 9:15  Oakley Key Exchange, Hilarie Orman (Univ. of Arizona) 
10:05  SKIP and extensions for PFS, Ashar Aziz (Sun) 
10:45  Photuris update, Phil Karn (Qualcomm) 
11:25  Summary and Action Items 
11:30  Adjourn 

Xref subject previous

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the IP Security Protocol Working 
Group of the IETF.                                                         

       Title     : SKIP extension for Perfect Forward Secrecy (PFS)        
       Author(s) : A. Aziz
       Filename  : draft-ietf-ipsec-skip-pfs-00.txt
       Pages     : 11
       Date      : 02/21/1996

This document describes an optional extension specifying how to use an 
ephemeral Diffie-Hellman exchange in conjunction with the SKIP protocol in 
order to provide perfect forward secrecy for situations where forward 
secrecy is necessary.                                                      

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-pfs-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-pfs-00.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-pfs-00.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: <19960221161154.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-pfs-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-skip-pfs-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960221161154.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject next


All,
	I've been gone out of town taking care of family matters and have
just now resurfaced and caught up on email/lists.  Several folks have asked
for detailed discussion on the problems with Bill's draft.  Those folks
apparently are new subscribers to the IPsec list because the technical
problems have been discussed at some length over the course of the past
year.  From where I sit, the main problem is that Bill refuses to edit his
draft in conformance with RFC-1825 and Working Group consensus (he made a
public refusal to make needed changes last November in a posting to the
IPsec list, for example).  Now I'll try to rehash some of the highlights
for newcomers to this list.

1) There is a well-known attack possible by one user on a multi-user system
   against another user on the same multi-user system.  This has been 
   described in the past at length and is often called the "mutually
   suspicious users" problem.

   This was discussed at length, most recently during the Fall of 1995
   on the IPsec list.  Bill's draft does not have language on this topic
   that is consistent with the WG consensus, as I noted in a message to
   the IPsec list on 9 Nov 1995 entitled "naming and terminology".
   Bill explicitly refused to make the change and his draft continues
   to be broken in this area.

   One possible fix would be to rephrase part of Section 1.8 of Bill's
   draft to replace the text reading "When required for secure multi-user
   environments, ..." with "On multi-user systems,..." or "On
   multi-user systems having discretionary access controls (DAC), ..."
   AND replace the text reading "Each secure multi-user operating
   system MUST..." with "Each multi-user operating system SHOULD...".

   Implementation support for user-oriented keying on "multi-user systems" 
   is specified by RFC-1825 in section 4.6 paragraph 5.

   Additionally, the "Design Notes" of Section 1.8 need to be deleted.
   NRL's implementation is an existence proof that support for user-
   oriented keying does NOT require significant changes to an OS
   or its APIs, contrary to Bill's incorrect assertion.  

   Please note that this item has NOTHING to do with "multi-level
   security".

2) The draft incorrectly and unreasonably constrains the security policies
   that users may have.  In section 2.5.1, Bill requires that
   authentication policy may only be determined by the receiver when in
   fact this is not a useful or necessary restriction (as has been
   discussed on the IPsec list in the past). The NRL implementation is 
   again a counter-example to Bill's incorrect assertion in that it permits
   sender or receiver to each set their own policies on authentication.

   The same problem occurs in section 2.5.2 where Bill asserts that 
   encryption policy is a sender decision.  This is not a useful or
   necessary restriction either.  In particular, experiments at NRL
   using the NRL implementation demonstrated that the receiver can
   require the sender to use encryption for a session (e.g. telnet
   or ftp sessions where the TCP session will never become established).
   Again, these were both discussed on the list in some detail and 
   so this is not a new problem with Bill's draft.

   To fix this problem, Bill needs to remove the language in his draft
   that restricts the security policies that users can have.

3) Bill's draft does not fully conform with Section 1.4 of RFC-1825.

   To conform, the following changes need to be made:
	- The text in draft-ietf-ipsec-photuris-ext-01.txt, Section 2.7
 	  needs to be detailed sufficiently that 2 independent implementers
	  could create interoperable implementations that successfully
	  pass the Sensitivity Label between them.  

	  A sufficient approach would be to define the label values and
 	  semantics for the US DoD levels specified in RFC-1108, reserve
	  most label values to IANA for future allocation, and reserve
	  a small number of label values for private use amongst consenting
	  parties.

	- The sensitivity label option needs to be moved into the main
	  /draft-ietf-ipsec-photuris-*.txt>draft-ietf-ipsec-photuris-*.txt draft because it is a standard
	  component of an IPsec Security Association.

   This isn't hard and I've told this to Bill in the past, but he hasn't
   yet made the changes and in the past has specifically refused to change
   and fix this on grounds that he personally doesn't believe in
   Sensitivity Labels.

   For newcomers, I'll note that sensitivity labels aren't really a
   military-unique feature.  For example, GE has a multi-level security
   policy (Class I information is "all GE employees, but no outsiders"
   while Class II information is more restricted, for example).
  

4) The DNS-SIG option should be detailed with both syntax and semantics.
   DNS Security is about to move to Proposed Standard and the DNS is likely
   to be a primary near-term way for hosts to obtain each others' 
   certificates.  The DNS Security spec is plenty stable for Bill to
   finish this item now.

5) Section 2.11 of draft-ietf-ipsec-photuris-ext-01.txt MUST be deleted.
   It is WAY outside the scope of Bill's draft to modify any standards
   track protocol and the attempt to do so is more than sufficient grounds
   to bar publication as ANY kind of RFC until that section is deleted.

6) Please also see Bill Sommerfeld's note to the IPsec list with
   a subject of "Re: IPsec mailing list", date of 9 Oct 1995 16:57:19
   and his note subject "Re: Security Problems in Photuris #2" dated
   12 Oct 1995 15:25:28 and the note from Ron Rivest with subject
   "Photuris terminology" dated 12 Oct 1995 19:54:57 for other 
   unresolved technical problems (generally all of those notes suggest
   easy simple changes to fix the problems).

  In summary, the main obstacle to progress is Bill's unwillingness to
work with the standards process and edit in accordance with WG consensus,
existing standards-track protocols, and the WG requirements.  

  If the draft should move to WG Last Call in the future, I would not be
surprised if additional technical issues resurfaced or appeared new.

Ran
rja@cisco.com

Xref subject next

--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     : Internet Security Association and Key Management 
                   Protocol (ISAKMP)                                       
       Author(s) : D. Maughan, M. Schertler
       Filename  : draft-ietf-ipsec-isakmp-04.txt, .ps
       Pages     : 59
       Date      : 02/21/1996

This memo describes a protocol utilizing security concepts necessary for 
establishing Security Associations (SA) and cryptographic keys in an 
Internet environment.  A Security Association protocol that negotiates, 
establishes, modifies and deletes Security Associations and their 
attributes is required for an evolving Internet, where there will be 
numerous security mechanisms and several options for each security 
mechanism.  The key management protocol must be robust in order to handle 
public key generation for the Internet community at large and private key 
requirements for those private networks with that requirement.        

The Internet Security Association and Key Management Protocol (ISAKMP) 
defines the procedures for authenticating a communicating peer, creation and 
management of Security Associations, key generation techniques, and threat 
mitigation (e.g.  denial of service and replay attacks).  All of these are 
necessary to establish and maintain secure communications (via IP Security 
Service or any other security protocol) in an Internet environment.        

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-ipsec-isakmp-04.txt".
 Or 
     "get draft-ietf-ipsec-isakmp-04.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-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-isakmp-04.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-ipsec-isakmp-04.ps".
							
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: <19960222094519.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-isakmp-04.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-isakmp-04.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960222094519.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject next

-----BEGIN PGP SIGNED MESSAGE-----

content-type: text/plain; charset=us-ascii

Here's a follow up on the issues which I raised earlier which Ran
suggested might not have been addressed.  

      Please also see Bill Sommerfeld's note to the IPsec list with
      a subject of "Re: IPsec mailing list", date of 9 Oct 1995
      16:57:19

The crucial part of this (the possibility of using change_message to
replay the creation of an SPI which was previously deleted) has been
resolved.

I would, however, like to see some text in the draft regarding ways to prevent
SPI's from significantly outlasting the shared secret initially used
to create them.  I'd prefer to see text requiring the SPI to die when
the shared secret used to create it expires, but could live with
something more liberal..

The sender should stop using the SPI immediately when it expires.  The
receiver should allow a grace period of on the order of a minute or
two to allow for slews in real-time clock frequency between the
systems and to allow any packets in flight to be received.  

      and his note subject "Re: Security Problems in Photuris #2" dated
      12 Oct 1995 15:25:28 and the note from Ron Rivest with subject
      "Photuris terminology" dated 12 Oct 1995 19:54:57 for other 
      unresolved technical problems (generally all of those notes suggest
      easy simple changes to fix the problems).

The 12 Oct message raises some more important issues.

As best I can tell, a number of places in photuris-09.txt require the
use of the now-known-to-be-vulnerable hash(key | data | key) structure for
implementing a keyed MAC.

I'd like to echo Hugo's request to make a change to Photuris to
replace all occurances of

	hash (concat(key, data, key))

with

	keyed_hash(key, data)

There are a bunch of places where hash(key, data, key) is used:
	- section 5.4 privacy method key generation.
	- section 5.5 identity verification
	- section 5.6 session key computation
	- section 6.1.7 integrity verification on change_message

The way it's used in the change_message appears to me as if it might
allow the keyed hash to become a target for chosen-plaintext attacks.
I think the other uses are less of a risk, but then I'm not really a
cryptographer.

Recommended high-level changes:
	1) Redefine the following hash algorithm families as keyed hashes:
		validity-method
		identity-choice
		privacy-method key generation
		SPI session key generation		

	2) define the key used for validity-method, privacy-method keygen,
	   and SPI session keygen as the shared-secret

	3) define the key used for the identity-choice algorithm as
	   the shared secret, concatenated or otherwise combined with the
	   authentication secret-key if there was one.

I believe that this could be done in a way which preserves
interoperability with existing implemenations of Photuris if this is a
concern.

I believe these answer Hugo's original objection, but naturally I'd
like to see a "real cryptographer" review these, especially #3.  These
perhaps go further than is strictly necessary (perhaps only the
validity-message change is really needed to avoid "bare" use of
key|data|key, but I think we should be conservative with how we use
the cryptographic primitives..)

						- Bill




-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMSz4NFpj/0M1dMJ/AQHY0wP8Durc4LS8/d2ylEVEHWBXr8BCZvR0Yazj
EQcXWLz7oJ9BS6bur0f0cSW/AhxQ7tbbojeHqZgLIdEivAVzazZ8MGYnugDSXaUB
rHXxWnyt3JhEOhE8m7rgqyyqfDawV4VU9eTEuzoOw/bu0lMiWB6HYg5qqsg7zgn6
Hwdej8cJafU=
=vNgI
-----END PGP SIGNATURE-----

------------------------------------------- 
IPSEC Implementation Survey 
 
Name of Implementation: USC/ISI
Security Protocols: IPv4 AH 
Security Transforms: null, Internet checksum, MD5, proprietary
        null and Internet checksum for performance measurement
Key Management: Statically configured keys 
        implementation for performance measurement only
Lineage of Code: SunOS 4.1.3, using "from scratch" and code adapted from 
        the NRL IPv6 BSDI implementation
Location of Source Code: to be announced in March 
Point of Contact: Joe Touch (touch@isi.edu)
-------------------------------------------

Xref subject previous
Xref subject next

Ah, thank you, finally something solid that I can actually refute!

> From: Ran Atkinson 
> Now I'll try to rehash some of the highlights
> for newcomers to this list.
>
Gosh, Ran, start right off by insulting most of the posters in the past
2 weeks.  2 implementors, and several others who have been active in
this group for over 2 years!  I saw only 1 new name....


In brief, it is apparent that the chairs haven't read any draft in the
past 5 months, let alone the most recent.  Most of the "issues" raised
here (#1, #2, and three in #6) were addressed as soon as they were
raised.  In the #6 cases, as long ago as last October!!!

Since I am about to go to bed and cannot write such a long message now,
I will handle individual points in later messages.  However, I can
quickly dispense with a few:

> 3) Bill's draft does not fully conform with Section 1.4 of RFC-1825.
>
>    To conform, the following changes need to be made:
> 	- The text in draft-ietf-ipsec-photuris-ext-01.txt, Section 2.7
>
> 4) The DNS-SIG option should be detailed with both syntax and semantics.
>
> 5) Section 2.11 of draft-ietf-ipsec-photuris-ext-01.txt MUST be deleted.

All of these are in the Extensions draft.  That draft is not germane to
the "last call".  It is not finished.  It contains those items which
as clearly indicated ARE _NOT_ REQUIRED in every implementation.

In fact, nobody could agree on even the format of these things, such as
Security Labels, DNS-SIG, or the AH_Sequence.  There are ongoing WGs
which are deciding these items, and the Extensions will be published
when they are resolved.

So, let's stick with the actual Photuris draft, which has the required
to implement base protocol.


>   In summary, the main obstacle to progress is Bill's unwillingness to
> work with the standards process and edit in accordance with WG consensus,
> existing standards-track protocols, and the WG requirements.
>
This is unmitigated hogwash!!!

I have made 10 drafts in the past year, with several significant
improvements and dozens of editorial changes.  Some folks (including my
cohort Phil) have complained that there are _too_ many options from
conforming to "WG consensus".

At least one of the comments stated: "we are happy with the way the
Photuris design team has addressed those weaknesses pointed to them."

Seems to me that not only have you not read the drafts, but you are
completely out of touch with the WG!

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous

--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     : Internet Security Association and Key Management 
                   Protocol (ISAKMP)                                       
       Author(s) : D. Maughan, M. Schertler
       Filename  : draft-ietf-ipsec-isakmp-04.txt, .ps
       Pages     : 59
       Date      : 02/21/1996

This memo describes a protocol utilizing security concepts necessary for 
establishing Security Associations (SA) and cryptographic keys in an 
Internet environment.  A Security Association protocol that negotiates, 
establishes, modifies and deletes Security Associations and their 
attributes is required for an evolving Internet, where there will be 
numerous security mechanisms and several options for each security 
mechanism.  The key management protocol must be robust in order to handle 
public key generation for the Internet community at large and private key 
requirements for those private networks with that requirement.        

The Internet Security Association and Key Management Protocol (ISAKMP) 
defines the procedures for authenticating a communicating peer, creation and 
management of Security Associations, key generation techniques, and threat 
mitigation (e.g.  denial of service and replay attacks).  All of these are 
necessary to establish and maintain secure communications (via IP Security 
Service or any other security protocol) in an Internet environment.        

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-ipsec-isakmp-04.txt".
 Or 
     "get draft-ietf-ipsec-isakmp-04.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-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-isakmp-04.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-ipsec-isakmp-04.ps".
							
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: <19960222094519.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-isakmp-04.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-isakmp-04.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960222094519.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

------------------------------------------  
IPSEC Implementation Survey 
 
Name of Implementation:  JI
Security Protocols: ESP, AH, Protocol-4 encapsultation
Security Transforms: ESP-DES, AH-MD5
Key Management: manual, Photuris; PF_ENCAP keying i/f, PF_ROUTE extensionsl 
Lineage of Code: Written from scratch, entirely in Greece, for BSD/OS 2.0, 
Location of Source Code: ji's home machine
			  The promised end-January-96 release is not ready yet;
			  it should be (freely) available from ftp.ripe.net RSN.
Point of Contact: ji@hol.gr
------------------------------------------  

Xref subject next

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Domain Name System Security 
Working Group of the IETF.                                                 

       Title     : Detached Domain Name System Information                 
       Author(s) : D. Eastlake
       Filename  : draft-ietf-dnssec-ddi-00.txt
       Pages     : 8
       Date      : 02/22/1996

A standard format is defined for representing detached DNS information.  
This is anticipated to be of use for storing information retrieved from the
Domain Name System (DNS) in archival contexts or contexts not connected to 
the Internet.                                                              

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-dnssec-ddi-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-ddi-00.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-dnssec-ddi-00.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: <19960222175802.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-ddi-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-dnssec-ddi-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960222175802.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous

Your agenda seems to be missing 2 drafts, one of which was submitted
before the last IETF and still has not been granted agenda time, yet
has time for drafts which have not yet appeared.  Please add 20 minutes
each for:

   ICMP Security Failures
   The ESP DES-CBC plus MD5 Transform


> 20:05  ESP/AH Implementation summary, Ran (cisco)

Also, during or after the implementation summary, I would like to
describe current review of the RFC-1828 & 1829 security analysis.
Shouldn't take more than 5 minutes.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject next

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Domain Name System Security 
Working Group of the IETF.                                                 

       Title     : Secure Domain Name System Dynamic Update                
       Author(s) : D. Eastlake
       Filename  : draft-ietf-dnssec-update-00.txt
       Pages     : 15
       Date      : 02/22/1996

Domain Name System (DNS) protocol extensions have been defined to 
authenticate the data in DNS and provide key distribution service 
(/draft-ietf-dnssec-secext-*.txt>draft-ietf-dnssec-secext-*.txt).  DNS Dynamic Update operations have also 
been defined (/draft-ietf-dnsind-dynDNS-*.txt>draft-ietf-dnsind-dynDNS-*.txt>, but without a detailed 
description of strong security for the update operation.  This draft 
describes how to use DNS digital signatures covering requests and data to 
secure updates and restrict them to those authorized to perform them as 
indicated by the updater's possession of cryptographic keys.               

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-dnssec-update-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-update-00.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-dnssec-update-00.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: <19960222171824.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-update-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-dnssec-update-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960222171824.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Domain Name System Security 
Working Group of the IETF.                                                 

       Title     : Detached Domain Name System Information                 
       Author(s) : D. Eastlake
       Filename  : draft-ietf-dnssec-ddi-00.txt
       Pages     : 8
       Date      : 02/22/1996

A standard format is defined for representing detached DNS information.  
This is anticipated to be of use for storing information retrieved from the
Domain Name System (DNS) in archival contexts or contexts not connected to 
the Internet.                                                              

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-dnssec-ddi-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-ddi-00.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-dnssec-ddi-00.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: <19960222175802.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-ddi-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-dnssec-ddi-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960222175802.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous
Xref subject next

> You are missing the point.  I was particularly vocal against the use of SIG
> RRs with no signature.  It sounds like an oxymoron to me:  here's a SIG RR
> to give you security; oh by the way there's no signature and thus no
> security.

I'm afraid I may still be missing the point...

> However, being sensitive to the needs of dynamic update in particular,
> there is clearly a need for an expiration time for RRs.  So, the particular
> suggestion at the DNS security meeting was that the expiration RR be
> created (so that the concept is useful in general)

The concept is useful in general.  The EXPIRES RR, however, offers
no more generality than a NULL SIG, that I can see.

> and that the SIG RR
> would later be specified to disallow NULL signatures and might even have
> the expiration value removed in favor of this more general mechanism.  The
> details of this suggestion will be visited when the specification is
> advanced from proposed to draft.

I would hope that you'd leave DNSSEC just like it is.  The
NULL SIG has been found to work just fine in the AIX and
OS/2 DNS products which support dynamic updates.

> However, it should be straightforward to see that being able to state
> authoritatively there is no key is a feature worth having.

Granted.  Still, as you said above, it sounds like an oxymoron to me:
here's a KEY RR to give you security; oh by the way there's no key
data and thus no security.

I don't see why the SIG is different here.   Lack of signature
data in a SIG would be a pretty strong hint to me that there is
no security.  But, I could always verify that by going back
to the server and looking at the KEY.

Edie

Xref subject previous
Xref subject next



> From: "PALAMBER.US.ORACLE.COM" 
> To: ipsec@TIS.COM
> Subject: IPSEC Implementation Survey
> Cc: PALAMBER@us.oracle.com
> Mime-Version: 1.0
> Sender: ipsec-request@neptune.tis.com
> Precedence: bulk
> Content-Length: 1004
> Status: RO
>
>
>
> I have received several requests for the location of source code for ipsec
> implementations. Our working group also needs to coordinate interoperability
> testing among ourselves.  To this end, would ipsec implementors please fill
> out the following survey and post your completed survey to the ipsec mailing
> list.
>
>
> Thanks in advance,
>
> Paul A. Lambert
> ipsec co-chair
>
************************************************************
IPSEC Implementation Survey

Name of Implementation: IBM
Security Protocols: ESP, AH, both tunnel and transport mode
Security Transforms: ESP-DES (32-bit and 64-bit IV), keyed-MD5,
		     new keyed-MD5 proposed by Hugo
Key Management : , SKEME (in progress),
		  Photuris (in Progress)
Lineage of Code: IBM Proprietary, about 10k to 15K lines
		(rough estimate, including ESP, AH, and Key Management).
Location of Source Code: Proprietary
Point of Contact: pau@yktvmv.vnet.ibm.com
************************************************************

Xref subject previous

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Domain Name System Security 
Working Group of the IETF.                                                 

       Title     : Secure Domain Name System Dynamic Update                
       Author(s) : D. Eastlake
       Filename  : draft-ietf-dnssec-update-00.txt
       Pages     : 15
       Date      : 02/22/1996

Domain Name System (DNS) protocol extensions have been defined to 
authenticate the data in DNS and provide key distribution service 
(/draft-ietf-dnssec-secext-*.txt>draft-ietf-dnssec-secext-*.txt).  DNS Dynamic Update operations have also 
been defined (/draft-ietf-dnsind-dynDNS-*.txt>draft-ietf-dnsind-dynDNS-*.txt>, but without a detailed 
description of strong security for the update operation.  This draft 
describes how to use DNS digital signatures covering requests and data to 
secure updates and restrict them to those authorized to perform them as 
indicated by the updater's possession of cryptographic keys.               

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-dnssec-update-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-update-00.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-dnssec-update-00.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: <19960222171824.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-update-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-dnssec-update-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960222171824.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous

> From: Bill Sommerfeld 
> Here's a follow up on the issues which I raised earlier which Ran
> suggested might not have been addressed.
>
>       Please also see Bill Sommerfeld's note to the IPsec list with
>       a subject of "Re: IPsec mailing list", date of 9 Oct 1995
>       16:57:19
>
> The crucial part of this (the possibility of using change_message to
> replay the creation of an SPI which was previously deleted) has been
> resolved.
>
Thank you.  As I remember, you had privately indicated this was solved
last October (about 5 drafts ago).

On to the new issues:


> I would, however, like to see some text in the draft regarding ways to prevent
> SPI's from significantly outlasting the shared secret initially used
> to create them.  I'd prefer to see text requiring the SPI to die when
> the shared secret used to create it expires, but could live with
> something more liberal..
>
Actually, it is a fundamental "feature" of Photuris that the SPIs can
last longer than the exchange value:

    When an Exchange-Value expires (or is replaced by a newer value),
    the unexpired derived SPIs are not affected. This is important to
    allow traffic to continue without interruption during new Photuris
    exchanges.

Also, this feature allows Photuris to behave like SKIP (long-term stored
SPIs for authentication lasting past reboot).  Perhaps you should argue
with someone else as to whether this latter facility is useful....


> The sender should stop using the SPI immediately when it expires.  The
> receiver should allow a grace period of on the order of a minute or
> two to allow for slews in real-time clock frequency between the
> systems and to allow any packets in flight to be received.
>
That's a bit harder to do, and sounds implementation dependent
(as to both clock frequency and packet trip time).  A minute seems
rather long, especially when the LifeTime is in seconds.

How is this particular to Photuris?  Would that be more appropriate to
the general architecture document discussing LifeTimes?

Certainly, this isn't something you would like to see "negotiated"?

An implementation note already exists as to hold time:

    To prevent resurrection of deleted or expired SPIs, implementations
    SHOULD remember those SPIs, but mark them as unusable until the
    Photuris exchange shared-secret used to create them also expires and
    purges the associated state.

Perhaps you are asking for an implementation note that expands this need,
such as:

    When an implementation detects an incoming SPI that has recently
    expired, but the associated state has not yet been purged, the
    implementation MAY accept the SPI. The length of time allowed is
    highly dependent on clock drift and variable packet round trip time,
    and is therefore implementation dependent.


>       and his note subject "Re: Security Problems in Photuris #2" dated
>       12 Oct 1995 15:25:28
>
And again, as already stated above, the suggestion that the
"assumptions" about hashing funtions used as signatures be documented
resulted in the inclusion of Bill's suggested text (4 drafts ago):

    The Verification 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 an
    authenticated message from the verification value.

    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.

This was in the Security Consideration for several revisions, and has
now been moved to the Security Analysis document.


> As best I can tell, a number of places in photuris-09.txt require the
> use of the now-known-to-be-vulnerable hash(key | data | key) structure for
> implementing a keyed MAC.
> ...
>
> There are a bunch of places where hash(key, data, key) is used:
> 	- section 5.4 privacy method key generation.
> 	- section 5.5 identity verification
> 	- section 5.6 session key computation
> 	- section 6.1.7 integrity verification on change_message
>
> The way it's used in the change_message appears to me as if it might
> allow the keyed hash to become a target for chosen-plaintext attacks.
> I think the other uses are less of a risk, but then I'm not really a
> cryptographer.
>
The analysis is faulty.

In both cases, the key is both prefixed and appended in order to provide
additional key mixing over the potentially large amounts of data.  That
was a concern raised during earlier drafts, and the drafts were changed
to meet that earlier review.  There is no opportunity for an "appending
attack" on these values.

There could not possibly be an "attack" on the key generation.  This
creates a secret value, the key.

An attack on the verification is both unlikely and impractical.  This
value is encrypted, and therefore also "secret" from an observer.

See the Nov 17 paper by Preneel and van Oorschot:

    "Practical attacks often require that a forgery is _verifiable_ ...
    Verification of such an attack requires k/m text-MAC pairs."

In this case, the MAC is unknown, and therefore not verifiable.

More importantly, the attack requires a large number of different
chosen-messages.  Since it is not possible for an attacker to "choose"
the parameters being verified, this attack is impossible.

Most importantly, the attack requires an incredibly large number of
known-messages, on the order of 2**65 or more!  That makes it utterly
impractical (also stated by the authors).



> Recommended high-level changes:
> 	1) Redefine the following hash algorithm families as keyed hashes:
> 		validity-method
> 		identity-choice
> 		privacy-method key generation
> 		SPI session key generation		
>
They already are.  That is, a hash over the key.  MD5 is used in the
base document, but other hashes are possible for other Exchange-Schemes.
(See Extensions draft for details.)


> 	2) define the key used for validity-method, privacy-method keygen,
> 	   and SPI session keygen as the shared-secret
>
This is a cryptographically unsound idea.

Disclosure of the key for any one of these would disclose the
shared-secret used to generate all the other keys.  That would make it a
serious target.  Especially as it is so easy to determine the DES
privacy key.

The shared-secret is _never_ used directly.  As stated:

    Photuris generation of session-keys involves a cryptographic hash
    over the shared-secret. The shared-secret is itself only indirectly
    used for creating those keys that actually protect session traffic.

    This protects the shared-secret from discovery, and allows repeated
    use of the shared-secret for generating multiple session-keys.
    Discovery of one such key should not reveal related session-keys.


> 	3) define the key used for the identity-choice algorithm as
> 	   the shared secret, concatenated or otherwise combined with the
> 	   authentication secret-key if there was one.
>
Again, an incredibly insecure idea.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject next

-----BEGIN PGP SIGNED MESSAGE-----

content-type: text/plain; charset=us-ascii

   More importantly, the attack requires a large number of different
   chosen-messages.  Since it is not possible for an attacker to "choose"
   the parameters being verified, this attack is impossible.

That's not at all clear to me.  In particular, it seems that in a
system using per-user or per-transport-connection SPI's, an active
attacker could easily induce a system to create large numbers of SPI's
with a third party, each having similar, but not identical parameters.

   Most importantly, the attack requires an incredibly large number of
   known-messages, on the order of 2**65 or more!  That makes it utterly
   impractical (also stated by the authors).

That's an upper-bound on the strength of this construction, not a
lower bound.

As an engineer, not a cryptographer, the existance of this weakness
makes me suspicious of tying photuris so closely to
hash(concat(key,data,key)) instead of a more flexible
keyed_hash(key,data).
   
   > Recommended high-level changes:
   > 	1) Redefine the following hash algorithm families as keyed hashes:
   > 		validity-method
   > 		identity-choice
   > 		privacy-method key generation
   > 		SPI session key generation		
   >
   They already are.  That is, a hash over the key.  MD5 is used in the
   base document, but other hashes are possible for other Exchange-Schemes.
   (See Extensions draft for details.)

I'm sorry, but a keyed hash and a hash over a key and some other data
are *NOT* necessarily the same thing.  Hash(concat(key,data,key)) is just one
way to implement a keyed hash -- it's not necessarily the *best* way.

Hugo's work suggests that hash(key1, hash(key2, data)) may be better,
but there's no way to cleanly define photuris extensions which use
that structure in the future if the base draft insists on the
key,data,key form.

   > 2) define the key used for validity-method, privacy-method keygen,
   > 	   and SPI session keygen as the shared-secret
   >
   This is a cryptographically unsound idea.

Why?  That's exactly what photuris is doing today! It's doing a keyed
hash using the shared secret as the "key" and other fields as the
"data".

   > 	3) define the key used for the identity-choice algorithm as
   > 	   the shared secret, concatenated or otherwise combined with the
   > 	   authentication secret-key if there was one.
   >
   Again, an incredibly insecure idea.
   
Again, this is exactly what photuris is doing today.  It's doing a
keyed hash using the shared secret as the "key" and other fields as
the "data".

						- Bill




-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMS32y1pj/0M1dMJ/AQFXkQP9HoFnI4wUlUnCQtaQLRFMv1lGn90ys6Kn
pEeGX/UFkHF77TQomeXxFQ9fOVC4jYocWV0nTJR3R4Y0PM7hIektneApD96pDEW6
vwL2I6rFB1y5SCmjSVA0ATnlLs1I4TUgoM19dWgqp4bSqmsGJJNfkc50deCtTPBv
9ZAsPlHaM9c=
=iK8b
-----END PGP SIGNATURE-----

A small note to cover the bases:

> From: Ran Atkinson 
> 6) Please also see ...
>           the note from Ron Rivest with subject
>       "Photuris terminology" dated 12 Oct 1995 19:54:57
>
Which read (excerpted):

# *****************************************************************
# *** 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".
# ...
# 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.
# ...

The language appeared in draft -05 on Oct 14!  Cannot get much faster
than that!

Also, in response to other messages, the use of the term Signature was
changed to Verification, of which a "signature" is only one example....

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject next

--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     : ICMP Security Failures Messages                         
       Author(s) : P. Karn, W. Simpson
       Filename  : draft-ietf-ipsec-icmp-fail-01.txt
       Pages     : 4
       Date      : 02/22/1996

This document specifies ICMP messages for indicating failures when using IP
Security Protocols (AH, ESP, and Photuris).                                

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-icmp-fail-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-icmp-fail-01.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-icmp-fail-01.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: <19960222143602.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-icmp-fail-01.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-icmp-fail-01.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960222143602.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous
Xref subject next

> The concept is useful in general.  The EXPIRES RR, however, offers
> no more generality than a NULL SIG, that I can see.
> 

The EXPIRE RR does not need some other server to verify with a KEY RR
that the null SIG record is valid.  The EXPIRE RR stands by itself,
as do A, CNAME, and PTR records.  No other infrastructure is required.

> > and that the SIG RR
> > would later be specified to disallow NULL signatures and might even have
> > the expiration value removed in favor of this more general mechanism.  The
> > details of this suggestion will be visited when the specification is
> > advanced from proposed to draft.
> 
> I would hope that you'd leave DNSSEC just like it is.  The
> NULL SIG has been found to work just fine in the AIX and
> OS/2 DNS products which support dynamic updates.
> 

Did those systems have to implement *any* other infrastructure to make
the NULL SIG work?  It is the added complexity of nulling out the rest
of DNSSEC that is annoying to those who want EXPIRE RRs.

> > However, it should be straightforward to see that being able to state
> > authoritatively there is no key is a feature worth having.
> 
> Granted.  Still, as you said above, it sounds like an oxymoron to me:
> here's a KEY RR to give you security; oh by the way there's no key
> data and thus no security.
> 

The EXPIRE RR is a timer, not a security feature.  One doesn't
need to make the simple function more complicated.

> I don't see why the SIG is different here.   Lack of signature
> data in a SIG would be a pretty strong hint to me that there is
> no security.  But, I could always verify that by going back
> to the server and looking at the KEY.

Exactly the complexity to avoid.

	Walt

Xref subject previous
Xref subject next

Bill,
	My interpretation of the wg requirements is that it is not
enough that it be possible for the protocol to support a required
functionality, but that a compliant implementation must support it.
Users or system administrators may decide not to use such a feature, but
they must have the option of _using_ it; ergo, a compliant
implementation must support it, in an interoperable fashion. 

	Hence, a compliant implementation of IPV6 must include support
for encryption.  It is not enough that there be an optional way of doing
encryption in IPV6; a compliant implementation must support encryption.

	Likewise, for SKIP to pass muster vis-a-vis the wg requirements,
it is not enough for there to be an optional way of supporting Perfect
Forward Secrecy.  If SKIP is to meet the wg requirements, all compliant
implementations of SKIP must support PFS.

	And finally, it is not enough that Photoris support certain wg
requirements by providing a way to support them in the protocol via an
optional Photoris extensions document, where the extensions are very
clearly not well-enough defined to create interoperable implementations.
In order to meet the wg requirements, all complaint implementations have
to support those features listed in the Photuris extensions draft.

	After all, you'd probably be first to cry foul if the SKIP folks
claimed that their protocol meet all of the working group requirements
if the PFS was only described in an optional part of the protocol spec,
which none of their implementations supported.  Likewise, if Photoris is
to be considered as meeting all of the wg requirements, then all of
these requirements must be met in the base protocol spec, or failing
that, in an annex of the protocol spec which is well-formed and which is
mandatory for implementors to implement.

	Hence, I believe that we really do need to address those items
found in the Photoris extensions draft, or else consider Photuris as not
meeting the wg requirements.  Fair's fair, after all....

							- Ted

Xref subject previous
Xref subject next

> Did those systems have to implement *any* other infrastructure to make
> the NULL SIG work?  It is the added complexity of nulling out the rest
> of DNSSEC that is annoying to those who want EXPIRE RRs.

No, nothing else from DNSSEC was needed for NULL SIGs.

> > I don't see why the SIG is different here.   Lack of signature
> > data in a SIG would be a pretty strong hint to me that there is
> > no security.  But, I could always verify that by going back
> > to the server and looking at the KEY.

> Exactly the complexity to avoid.

And, if you don't care about security, you don't do this more
complex step.

The complexity I'd like to avoid is that of DNS as a whole --
duplication of function in multiple RRs and over-engineering
solutions to simple problems.

Edie

Xref subject previous
Xref subject next

--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     : ICMP Security Failures Messages                         
       Author(s) : P. Karn, W. Simpson
       Filename  : draft-ietf-ipsec-icmp-fail-01.txt
       Pages     : 4
       Date      : 02/22/1996

This document specifies ICMP messages for indicating failures when using IP
Security Protocols (AH, ESP, and Photuris).                                

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-icmp-fail-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-icmp-fail-01.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-icmp-fail-01.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: <19960222143602.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-icmp-fail-01.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-icmp-fail-01.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960222143602.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous
Xref subject next

> No, nothing else from DNSSEC was needed for NULL SIGs.

> And, if you don't care about security, you don't do this more
> complex step.
> 
> The complexity I'd like to avoid is that of DNS as a whole --
> duplication of function in multiple RRs and over-engineering
> solutions to simple problems.
> 

Perhaps it makes sense to split out the SIG RR into its own
document, to allow it to progress independant of the DNSSEC
work?  Perhaps as a "special case" description of the NULL SIG
and its usage, leaving the "secure" usage to be defined in the
context of the rest of the DNSSEC?  This might satisfy both
the secure and insecure usage environments?

	Walt

-----BEGIN PGP SIGNED MESSAGE-----

content-type: text/plain; charset=us-ascii

There is a small, but significant, difference between perfect forward
secrecy as implemented by Photuris and ISAKMP/OAKLEY, and how it is
proposed to be implemented for SKIP in draft-ietf-ipsec-skip-pfs-00.txt.

The basic exchange in that draft is:

	I->J: { g^x, g, p, [Cert_I]g^xj, EMKID_J_I}Kij
	J->I: { g^y, g, p, [Cert_J]g^xj, EMKID_J_I, EMKID_I_J}Kij

While I believe this provides perfect forward secrecy for subsequent
traffic keys derived from g^xy, this does not appear to provide
perfect forward privacy protection for the identities enclosed in the
ephemeral certificates Cert_I and Cert_J.

The problem is that the certificate is encrypted with a key g^xj which
has an ephemeral public component and a long-term private component.
If the long-term DH secret key `j' is later compromised, an attacker
than then decrypt both [Cert_I] and [Cert_J] and figure out who the
parties to the exchange really are.

Photuris does not have this problem, since the identity exchange is
encrypted in a completely ephemeral key (g^xy in the terminology used in
skip-pft).  A quick scan of the OAKLEY draft seems to indicate to me that
OAKLEY is essentially identical to Photuris in this regard.

					- Bill




-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMS4gbFpj/0M1dMJ/AQGeKwP7B1KeQp8anXJAQIKYs7ILArs5wynU3pRH
ohzWL5037YF0GVcLjxYXmXgMaPKNJUiEIUvMk8oKBR/jftn3pLKGs28Y5t3ZFZKX
P9i0HCEznnmFsFzO6aXyqTRFGcpDv1lOTIDgRtm/NaQqjOkWcFVaCowAp1MmOgys
ZrUZNfmjhdM=
=Amsi
-----END PGP SIGNATURE-----

Xref subject previous

--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     : ICMP Security Failures Messages                         
       Author(s) : P. Karn, W. Simpson
       Filename  : draft-ietf-ipsec-icmp-fail-01.txt
       Pages     : 4
       Date      : 02/22/1996

This document specifies ICMP messages for indicating failures when using IP
Security Protocols (AH, ESP, and Photuris).                                

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-icmp-fail-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-icmp-fail-01.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-icmp-fail-01.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: <19960222143602.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-icmp-fail-01.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-icmp-fail-01.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960222143602.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject next

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the IP Security Protocol Working 
Group of the IETF.                                                         

       Title     : Combined DES-CBC, MD5 and Replay Prevention Security 
                   Transform                                               
       Author(s) : J. Hughes
       Filename  : draft-ietf-ipsec-esp-des-md5-00.txt
       Pages     : 4
       Date      : 02/22/1996

This draft describes a combination of privacy, authentication, integrity 
and optional replay prevention into a single packet format.                

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-esp-des-md5-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-des-md5-00.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-esp-des-md5-00.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: <19960222112207.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-esp-des-md5-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-esp-des-md5-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960222112207.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the IP Security Protocol Working 
Group of the IETF.                                                         

       Title     : Combined DES-CBC, MD5 and Replay Prevention Security 
                   Transform                                               
       Author(s) : J. Hughes
       Filename  : draft-ietf-ipsec-esp-des-md5-00.txt
       Pages     : 4
       Date      : 02/22/1996

This draft describes a combination of privacy, authentication, integrity 
and optional replay prevention into a single packet format.                

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-esp-des-md5-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-des-md5-00.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-esp-des-md5-00.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: <19960222112207.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-esp-des-md5-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-esp-des-md5-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960222112207.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous
Xref subject next

> From: "Theodore Ts'o" 
> 	My interpretation of the wg requirements is that it is not
> enough that it be possible for the protocol to support a required
> functionality, but that a compliant implementation must support it.
> ....

Ted, I agree with everything you eloquently said (so I won't repeat the
rest), as you make no mention of any particular requirement.

For the remainder of this message, I will make the assumption that you
are referring to Sensitivity Labels, as you did in an earlier message.

If you are interested, just tell me about the details, and I'll whip up
a little separate draft in a few minutes.  So far, nobody has detailed
enough description about how such an option might be formatted and
negotiated.  It was removed to the extensions draft for lack of
interest.

Sensitivity Labels are clearly not required (by the working group, or any
proposed standard, or otherwise).  Complaint implementations of IP
Security are not required to support them.

I will go one step further.  In a separate message, I will call for the
removal of mention of Sensitivity Labels in the "architecture" document
as we go to Draft Standard.  For lack of 2 implementations.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous


Bill,

  There are at least 2 independent implementations of RFC-1825 that include 
support for sensitivity labels.

  There is no plan to move RFC-1825 through RFC-1827 forward prior to
or during LA in any event.

Ran
rja@cisco.com

Xref subject previous
Xref subject next

> From: Bill Sommerfeld 
>    More importantly, the attack requires a large number of different
>    chosen-messages.  Since it is not possible for an attacker to "choose"
>    the parameters being verified, this attack is impossible.
>
> That's not at all clear to me.  In particular, it seems that in a
> system using per-user or per-transport-connection SPI's, an active
> attacker could easily induce a system to create large numbers of SPI's
> with a third party, each having similar, but not identical parameters.
>
I am not following you; since it's apparently easy, please give a
concrete example of such an exchange.


>    Most importantly, the attack requires an incredibly large number of
>    known-messages, on the order of 2**65 or more!  That makes it utterly
>    impractical (also stated by the authors).
>
> That's an upper-bound on the strength of this construction, not a
> lower bound.
>
How true (although the number I gave was the smallest bound in the
paper).  In fact, it could be guessed on the very first try.  It's just
not very likely (1:2**65).  And there would be no confirmation of success.


> As an engineer, not a cryptographer, the existance of this weakness
> makes me suspicious of tying photuris so closely to
> hash(concat(key,data,key)) instead of a more flexible
> keyed_hash(key,data).
>
Thanks for your opinion.


>    They already are.  That is, a hash over the key.  MD5 is used in the
>    base document, but other hashes are possible for other Exchange-Schemes.
>    (See Extensions draft for details.)
>
> I'm sorry, but a keyed hash and a hash over a key and some other data
> are *NOT* necessarily the same thing.  Hash(concat(key,data,key)) is just one
> way to implement a keyed hash -- it's not necessarily the *best* way.
>
Never-the-less, it is _one_ way, and at this time is the one with field
experience and both qualitative and quantitative analysis.


> Hugo's work suggests that hash(key1, hash(key2, data)) may be better,
> but there's no way to cleanly define photuris extensions which use
> that structure in the future if the base draft insists on the
> key,data,key form.
>
Huh?  You mean Kaliski and Robshaw.  Hugo suggested some other variant
for another purpose.

And I don't understand your latter assertion, as Photuris has clear and
clean extension mechanisms.


>    > 2) define the key used for validity-method, privacy-method keygen,
>    > 	   and SPI session keygen as the shared-secret
>    >
>    This is a cryptographically unsound idea.
>
> Why?  That's exactly what photuris is doing today! It's doing a keyed
> hash using the shared secret as the "key" and other fields as the
> "data".
>
I don't see any "data" or "hash" in your suggestion.  If you are
suggesting that Photuris use the same method that it does today, then we
are in complete agreement.


>    > 	3) define the key used for the identity-choice algorithm as
>    > 	   the shared secret, concatenated or otherwise combined with the
>    > 	   authentication secret-key if there was one.
>    >
>    Again, an incredibly insecure idea.
>
> Again, this is exactly what photuris is doing today.  It's doing a
> keyed hash using the shared secret as the "key" and other fields as
> the "data".
>
Again, ditto.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

-----BEGIN PGP SIGNED MESSAGE-----

content-type: text/plain; charset=us-ascii

   > From: Bill Sommerfeld 
   >    More importantly, the attack requires a large number of different
   >    chosen-messages.  Since it is not possible for an attacker to "choose"
   >    the parameters being verified, this attack is impossible.
   >
   > That's not at all clear to me.  In particular, it seems that in a
   > system using per-user or per-transport-connection SPI's, an active
   > attacker could easily induce a system to create large numbers of SPI's
   > with a third party, each having similar, but not identical parameters.
   >
   I am not following you; since it's apparently easy, please give a
   concrete example of such an exchange.

Ok.  Here's an abstract overview.  If this is too abstract for you,
I'll refine this into something more concrete.

Assume that there's a replicated service which we wish to attack:

	client  <---->  server A   <----->  server B

Assume that we are a legitimate client of this replicated service, but
are only authorized to change a few things in the service's database.

As a legitimate user of this service, we can tweak its database at one
site; that site will then "push" our changes to the other sites, and
we can then snoop on the network traffic that results.

Assume the service is implemented on a set of hosts which implement
per-transport-connection SPI's, and the replicas only keep connections
open when they have a change to propagate between the replicas.

Then, each replication "push" will occur on a separate SPI, and a
change-message exchange will occur prior to each push and subsequent
to each push to set up and then tear down the new SPI.

Thus, as I said earlier, we can induce a system to create and destroy
a large number of SPI's with a third party to provide us with a large
number of chances to attack the hash function used to validate the
Photuris change_message protocol.

   > I'm sorry, but a keyed hash and a hash over a key and some other data
   > are *NOT* necessarily the same thing.  Hash(concat(key,data,key)) is just 
     one
   > way to implement a keyed hash -- it's not necessarily the *best* way.
   >
   Never-the-less, it is _one_ way, and at this time is the one with field
   experience and both qualitative and quantitative analysis.

I'm not saying "change the bit level encoding".  I'm saying "move the
abstraction boundary" -- at the layer within Photuris where you
dispatch to a particular keyed hash algorithm, keep the key separate
from the data; under the covers, it can combine it exactly as it's
specified in photuris-09, or in a new way.

   And I don't understand your latter assertion, as Photuris has clear and
   clean extension mechanisms.

Maybe to you; I had difficulty figuring out from photuris-09 where the
abstraction boundary was between the various transforms and their
uses.

   > Why?  That's exactly what photuris is doing today! It's doing a keyed
   > hash using the shared secret as the "key" and other fields as the
   > "data".
   >
   I don't see any "data" or "hash" in your suggestion.  If you are
   suggesting that Photuris use the same method that it does today, then we
   are in complete agreement.

Here is a concrete suggested wording change to address the primary problem.  
If you accept this change (which I doubt), I'll supply wording to fix up the
other places which use hash(concat(key,data,key))

Change 6.1.7 to the following text:

6.1.7.  Integrity Verification

   This message is authenticated using the Validity-Method indicated by
   the current Scheme-Choice.  It is separate from any authentication
   specified for Security Associations (see "Exchange Scheme List").

   The Verification field is calculated using the specified
   Validity-Method keyed hash, given the computed shared secret
   as a key, and the following concatenated values as the input data:

    + the Initiator Cookie,
    + the Responder Cookie,
    + the SPI Owner (receiver) Identity Verification,
    + the SPI User (sender) Identity Verification,
    + the Type, LifeTime and SPI,
    + the Attribute-Choices following the Verification field,

   Note that the order of the Identity Verification fields is different
   in each direction.

   If the verification fails, the users are notified, and a Photuris
   Error_Message (Type 7, Code 3) is sent, without adding or deleting
   any Security Associations.  On success, normal operation begins with
   the authentication and/or encryption of user datagrams.

Add section 6.1.8:

6.1.8.  Validity Methods
   Each exchange scheme specifies a particular validity method to use
   to authenticate subsequent change_message packets.

   Validity Methods are keyed hash functions, supplied with two
   inputs:
	a key			(a sequence of bytes)
	the data to be hashed	(a sequence of bytes)

   They produce a single output: 

	a hash value (a multiple precision integer)

   It should be infeasible to determine the value of the key
   given a large number of (data, hash) pairs.

- ---
Change the paragraph of Section 9.5 starting with "Validity Method"
to:
- ----

Validity-Method

      When specified as a Validity-Method, an MD5 hash is calculated
      over the concatenation of
	the supplied key
	the supplied data
	the supplied key again.

      Neither occurance of the key is padded to any particular
      alignment.

      The resulting Verification field is 128-bits (18 octets including
      Size).




-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMS5WVFpj/0M1dMJ/AQGoVQP8CCSX5ZoF55MLk16rj8eV3CwjGZvk4ZoK
871e1hLoHz4HN6M7cY1LWS+LfBrYZ/Ep1uNucTr7LVsLheWiUFIk67RJm6GJTdks
+FqsZ+JrqAwmXE7XVboTmhXkyywK710XSQmjrl8OlUUHuaf5jD7alSpwXBBVgOvZ
7y6wtNMIQ7E=
=biCa
-----END PGP SIGNATURE-----

Attached is a copy of a new draft for the working group's review.
Comments should be sent to the IPSEC mailing list (ipsec@ans.net) 
and/or directly to me (jkennedy@cylink.com).

Title: Digital Signature Standard (DSS) Profile for X.509 Certificates
       <draft-ietf-ipsec-dss-cert-00.txt>

Abstract:

This document describes the ASN.1 [1] encoding for a CCITT 1988 X.509 [2]
certificate profiled for use with the U.S. Government's Digital Signature
Standard (DSS) [3].

This profile aligns with the base standards and profile references
listed below.  It is intended to provide guidelines for those developing
software that will be used to issue and use DSS certificates.  This is
to insure that DSS-specific certificate information will be handled
consistently throughout the public key infrastructure.

        X.509 (1993) | ISO/IEC 9594-8
        Amendment 1 to ITU Rec. X.509 (1993) | ISO/IEC 9594-8 : 1995
        DoD Secure Data Network System (SDNS) SDN.702 Revision 2.7 : 1994
        USPS Postal ECS X.509 Certificate and CRL Profile, Rev. 0.5.: 1996


--------------------------------------------------------

IPSEC Working Group                                     John Kennedy
Internet Engineering Task				Cylink Corporation
INTERNET-DRAFT						John Marchioni
Expires in six months					Cylink Corporation
							February 21, 1996 
 


      Digital Signature Standard (DSS) Profile for X.509 Certificates 
                   <draft-ietf-ipsec-dss-cert-00.txt> 
 
Status of this Memo 
 
This document is a submission to the IETF Internet Protocol Security 
(IPSEC)Working Group.  Comments are solicited and should be addressed to 
the working group mailing list (ipsec@ans.net) or to the authors. 
 
This document is an Internet-Draft.  Internet-Drafts are working 
documents of the Internet Engineering Task Force (IETF), its areas, and 
its working groups.Note that other groups may also distribute working 
documents as Internet-Drafts. Comments should be sent to the IP
Security WG mailing list  (ipsec@ans.net). 
 
Internet-Drafts are draft documents valid for a maximum of six months 
and may be updated, replaced, or obsoleted by other documents at any 
time.  It is inappropriate to use Internet-Drafts as reference material 
or to cite them other than as ``work in progress.'' 
 
To learn the current status of any Internet-Draft, please check the 
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 
Directories on ftp.is.co.za (Africa),  nic.nordu.net (Europe), 
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 
ftp.isi.edu (US West Coast). 

Distribution of this memo is unlimited. 
 
 
Abstract 
 
This document describes the ASN.1 [1] encoding for a CCITT 1988 X.509 [2]
certificate profiled for use with the U.S. Government's Digital Signature 
Standard (DSS) [3].  

This profile aligns with the base standards and profile references 
listed below.  It is intended to provide guidelines for those developing 
software that will be used to issue and use DSS certificates.  This is 
to insure that DSS-specific certificate information will be handled 
consistently throughout the public key infrastructure.

	X.509 (1993) | ISO/IEC 9594-8
	Amendment 1 to ITU Rec. X.509 (1993) | ISO/IEC 9594-8 : 1995
	DoD Secure Data Network System (SDNS) SDN.702 Revision 2.7 : 1994
	USPS Postal ECS X.509 Certificate and CRL Profile, Rev. 0.5.: 1996
 
For details not covered in this document the reader should refer to its 
base references:X.509 (1993) | ISO/IEC 9594-8 and Amendment 1 to ITU

Rec. X.509 (1993) |ISO/IEC 9594-8 : 1995. 
 
1. ASN.1 Definition of Certificate 
 
The abstract definition of the certificate is as follows: 
 
Certificate	::=	SIGNED { SEQUENCE { 
	version		[0]	Version DEFAULT v1, 
	serialNumber		CertificateSerialNumber, 
	signature			AlgorithmIdentifier, 
	issuer			Name, 
	validity			Validity, 
	subject			Name, 
	subjectPublicKeyInfo		SubjectPublicKeyInfo, 
	issuerUniqueIdentifier	[1]	IMPLICIT UniqueIdentifier OPTIONAL, 
						-- if present, must be v2 or v3 
	subjectUniqueIdentifer	[2]	IMPLICIT UniqueIdentifier OPTIONAL, 
						-- if present, must be v2 or v3 
	extensions		[3]	Extensions OPTIONAL 
}} 
 
Version	::=	INTEGER { v1(0), v2(1), v3(2) } 
 
CertificateSerialNumber	::=	INTEGER 
 
AlgorithmIdentifier	::=	SEQUENCE { 
	algorithm	ALGORITHM.&id ({SupportedAlgorithms}), 
	parameters	ALGORITHM.&id ({SupportedAlgorithms}{
@algorithm}) 
	OPTIONAL } 
 
-- SupportedAlgorithms		ALGORITHM	::=	{...|...} 
 
-- DSA Signature Algorithm 
-- 
-- The Digital Signature Algorithm (DSA) is also called the 
-- Digital Signature Standard (DSS).  DSA  was developed by
-- the U.S. Government.  DSA is used in conjunction with
-- the SHA-1 one way hash function. (SHA-1 is described in FIPS 180-1).  
-- DSA is described in FIPS 186.
  
-- The ASN.1 object identifier used to identify this signature
-- algorithm is: 
 
	dsaWithSHA-1 OBJECT IDENTIFIER  ::=  { 
		joint-iso-ccitt(2) country(16) US(840) organization(1)
		us-government(101) dod(2) infosec(1) algorithms(1) 
		dsa-sha1 (2)  
	} 
 
 -- DSA Parameters 
 
-- When this object identifier is used with the ASN.1 type 
-- AlgorithmIdentifier, the parameters component of that type is
-- optional.  If it is absent, the DSA parameters p, q, and g are 
-- assumed to be known, otherwise the parameters are included using the 
-- following ASN.1 structure: 
 
	Dss-Parms  ::=  SEQUENCE  { 
		p	OCTET STRING, 
		q	OCTET STRING, 
		g	OCTET STRING } 
 
 
-- DSA Signature Block 
 
-- Prior to the bitstring encoding of the certificate issuer's DSA
-- signature, the signature block must be encoded using the
-- distinguished rules as follows: 
 
	Dss-Sig  ::=  SEQUENCE  { 
		r	OCTET STRING, 
		s	OCTET STRING} 
 
 
	Validity	::=	SEQUENCE { 
		notBefore	UTCTime, 
		notAfter	UTCTime } 
 
	SubjectPublicKeyInfo	::=	SEQUENCE { 
		algorithm	AlgorithmIdentifier, 
		subjectPublicKey	BIT STRING } 
 
 
2. Certificate Extensions 

The standard extensions are described in Amendment 1 to ITU Rec.  X.509 
(1993) | ISO/IEC 9594-8 : 1995.  A subset of these extensions will need 
to be chosen for this profile.  The extensions field allows addition of 
new fields to the certificate structure without modification to the 
ASN.1 definition.  An extension field consists of an extension object 
identifier, a criticality flag, and a canonical encoding of a data value 
of an ASN.1 type associated with the object identifier already 
specified. 
 
When a system processes a certificate but does not recognize an 
extension, if the criticality flag is FALSE, the extension may be 
ignored and the remainder of the certificate information may be 
processed as valid.  If the criticality flag is TRUE, an unrecognized 
extension shall cause the system to consider the entire certificate 
invalid. 
 
3. An overview of the use of the Distinguished Encoding Rules (DER) in 

Certificate Signature Operations. 
 
(1) Sign; The signing application converts the abstract value (or 
internal representation) of the certificate information into a bit 
representation using the DER and signs that bit representation.  The 
signature is then appended onto the abstract value, and both values are
then BER (Basic Encoding Rules) encoded to provide a transfer syntax. 

The same encoder used to apply the DER may be used to apply the transfer 
syntax, so the transfer syntax can also follow the DER. 

(2) Authenticate; The authenticating application will decode the 
received certificate (containing the certificate information and issuer 
signature).  This application will then have an abstract value for both 
the certificate information and a signature.  The application will then 
take the resulting abstract value of the certificate information and re-
encode it using the DER to produce the same bit representation that was
signed.   The received signature can now be authenticated using the 
exact bitstring representation used in the signing operation. 
 
When the DER are applied to information, before that information is 
signed, the authentication operation (also applying the DER) will always 
detect if that information has been modified and the incidence of false 
authentication failures is greatly reduced. 
 
4. Security Considerations 
 
Security issues are not discussed in this document 
 
5. References 
 
[1] CCITT Recommendation X.208 (1992),  "Abstract Syntax Notation One" 
 
[2] CCITT Recommendation X.509 (1988),"The Directory - Authentication Framework" 
[3] FIPS 186  Digital Signature Standard 


Author's Addresses

Questions about this document can be directed to:


	John Kennedy
	CYLINK Corporation
	910 Hermosa Court
	Sunnyvale, CA  94086
	jkennedy@cylink.com
	408-735-5885

	John Marchioni
	CYLINK Corporation
	910 Hermosa Court
	Sunnyvale, CA  94086
	johnmarc@cylink.com
	408-735-5800

Xref subject previous
Xref subject next

In article <9602232014.AA15345@edisto.watson.ibm.com>,
edie@watson.ibm.com ("Edie E. Gunter") writes:
>   The complexity I'd like to avoid is that of DNS as a whole --
>   duplication of function in multiple RRs and over-engineering
>   solutions to simple problems.

Me, too.  Since a SIG(NULL) does what EXP would do, and since SIG(NULL)
is much easier to implement than SIG(*), I see no reason for EXP.  I see
EXP as unnecessary complexity for a system whose comparitive simplicity
has been its biggest reason for success.
-- 
Paul Vixie
La Honda, CA			"Illegitimibus non carborundum."

pacbell!vixie!paul

Xref subject previous
Xref subject next

>Perhaps it makes sense to split out the SIG RR into its own
>document, to allow it to progress independant of the DNSSEC
>work?  Perhaps as a "special case" description of the NULL SIG
>and its usage, leaving the "secure" usage to be defined in the
>context of the rest of the DNSSEC?  This might satisfy both
>the secure and insecure usage environments?
>
>	Walt

DNSSEC is almost at PS.  And the description of SIG(NULL) in the
document is adequate to EXP's purposes.  Perhaps Donald and Charlie
will add a sentence or two during the PS review process?
-- 
Paul Vixie
La Honda, CA			"Illegitimibus non carborundum."

pacbell!vixie!paul

Xref subject previous
Xref subject next

************************************************************ 
IPSEC Implementation Survey 
 
 
Name of Implementation: Morning Star SecureConnect
Security Protocols: ESP, AH
Security Transforms: ESP-DES, AH-MD5
Key Management: manual
Lineage of Code: scratch
Location of Source Code: proprietary
Point of Contact: Karl Fox 
************************************************************ 
-- 
Karl Fox, servant of God, employee of Morning Star Technologies
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221    +1 614 451 1883

Xref subject next

Gentlefolk,

I propose that we officially remove the recommendation for Sensitivity
Labels from RFC-1825, for several reasons:

 A) Although there are many (> 6) interoperable implementations of
    RFC-1828 and RFC-1829, none of them implement Sensitivity Labels.

 B) Since RFC-1828 and RFC-1829 are more than ready to go to Draft
    Standard, but interoperability of Sensitivity Labels has not been
    demonstrated, by RFC-1602 we MUST remove Sensitivity Labels from our
    official WG documents.

 C) Sensitivity Labels are ill-defined.

 D) Commercial vendors have not found a demand for Sensitivity Labels.


> From: Ran Atkinson 
>   There are at least 2 independent implementations of RFC-1825 that include
> support for sensitivity labels.
>
Please indicate which implementations?

And if you cite NRL, please detail commands for manual configuration of
the security association that implement the feature.


>   There is no plan to move RFC-1825 through RFC-1827 forward prior to
> or during LA in any event.
>
Then, you have not followed the Standards Process in RFC-1602.  The time
for updating them is upon us.

Last Spring, we (the WG) allowed Ran Atkinson to publish RFC-1825 to
RFC-1827 without removing some of the nits, in order to make forward
progress.  Since then, he has been browbeating Photuris with an obscure
"requirement" (clearly "RECOMMENDED" not "REQUIRED" in RFC-1825) for
Sensitivity Labels.

There have been two respondents that have called for Sensitivity Labels
(in Photuris) in the past 3 weeks:

  1) Ran Atkinson
  2) Theodore Ts'o

I have spoken to the latter, and he assures me that his interest is in
having a "level playing field" for the protocol descriptions, not in
actually implementing Sensitivity Labels; nor has MIT any requirement or
current plans for deployment.

I will note here that someone has sent private messages "quoting" me as
stating: "i don't care for sensitivity labels".  I have examined both
the IPSec and my personal archives, and cannot find this string at any
location.  Dissemination of such false and out of context quote
information is excrable.

My previous _privately_ expressed position was "Personally, I don't
care.  It is a pretty simple thing to add syntactically, but takes 10-20
pages to describe all the security considerations."

I will note that I have previously cooperated with regard to Sensitivity
Labels.  Last September, at the request of Ran and NSA, I added the
"Modify" capability to Photuris.  The sole reason was to modify
Sensitivity Labels on the fly.  Last October, the WG, including
Sommerfeld, Orman, Bellovin and Housley (citing earlier IEEE arguments),
called for the removal of the Modify capability.

As to WG consensus, no public support (other than Atkinson) was
expressed for inclusion of Sensitivity Labels in Photuris.  Therefore,
it was removed to the "for future work" Extensions draft.

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 time to time, I have been privately chastised for being too
direct in my replies.  This has been known to make some folks think that
there is an unwritten subtext such as: "as any fool can see".

> Subject: Re: Regarding Bill's draft... another Bill's open issues with
>
> I'll point out that Bill Sommerfeld is a not-stupid...
>
    I have had two folks tell me in the past 3 months that there are a
few of you out there that actually won't publically comment on my work,
for fear of being personnally flayed.

    Gentlefolk, please take note that Bill and Bill get along quite
amicably in person.  I consider Ran a good freind (albeit you might not
know that from our public exchanges).

    It may interest you to know that this written perception problem is
not uncommon in scientific venues.  Quoting "Social Epistemology", 1992,
v. 6, n. 2, pp. 231-240, entitled "Howe and Lyne bully the critics", by
Henry Howe (an ecologist) and John Lyne (a rhetorician):

    Rhetoric is not used in this essay 'solely in a pejorative sense'.
    _Au_contraire_, rhetorics bind together and help organize practices.
    Whether rhetoric is good or bad depends on whether it is, well, good
    or bad. ...  Lyne wants it on record that he has no interest in an
    end to rhetoric.  Like [a critic], he wants 'better rhetoric'.

    A number of critics decry our intemperance, calling into question
    what they perceive to be innuendo, sneers, back-biting metaphor, and
    _ad_hominem_ attacks.  Sticks and stones.  We reject the
    characterization that our attacks are _ad_hominem_.  If we term an
    idea 'muddled' or a claim 'unrealistic', we really think that the
    adjectives describe muddled ideas and unrealistic claims, not
    muddled or unrealistic individuals.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Guess I should have cc'ed dns-security to star with on this message...
=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     dee@cybercash.com
   318 Acton Street        +1 508-371-7148(fax)     dee@world.std.com
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.eff.org/blueribbon.html

---------- Forwarded message ----------
Date: Sat, 24 Feb 1996 10:40:56 -0500
From: Donald E. Eastlake 3rd 
To: Multiple recipients of list NAMEDROPPERS
     
Subject: Re: Expires RR proposal

On Fri, 23 Feb 1996 lazear@GATEWAY.MITRE.ORG wrote:

> Perhaps it makes sense to split out the SIG RR into its own
> document, to allow it to progress independant of the DNSSEC
> work?  Perhaps as a "special case" description of the NULL SIG
> and its usage, leaving the "secure" usage to be defined in the
> context of the rest of the DNSSEC?  This might satisfy both
> the secure and insecure usage environments?

This doesn't seem particularly useful to me.  The current DNSSEC draft
(draft-ietf-dnssec-secext-09.txt) provides for null signatures
(algorithm 253 signatures) and currently has the following sort of
verbage is a couple of places: "... Number 253, known as the
"expiration date algorithm", is used when the expiration date or other
non-signature fields of the SIG are desired without any actual
security.  It is anticipated that this algorithm will only be used in
connection with some modes of DNS dynamic update.  For number 253, the
signature field will be null. ..."

I suspect some minor tweaking of this would be all that would be
required for separate expiration use.  But so far I haven't noticed
anyone answer my point that I thought the reason for an EXP RR was
when you *did* have security.  In that case, the SIGs are normally all
added by a seprate applicaton that puts a uniform expiration date in,
sometime far enough in the future that you are sure you will get
around to re-signing the zone before then.  I suppose it could take
into account TTL but that's not the right thing either as TTL is
really just for cache consistency, not ultimate expiration.  So if you
do have security and the SIG expiration is fixed by your security
machinery and TTL is for cache consistency, there is no place for
expiration other than EXP.

>         Walt

Donald
=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     dee@cybercash.com
   318 Acton Street        +1 508-371-7148(fax)     dee@world.std.com
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.eff.org/blueribbon.html

Xref subject previous

> From: Bill Sommerfeld 
> Ok.  Here's an abstract overview.  If this is too abstract for you,
> I'll refine this into something more concrete.
>
No, that was good enough for me to understand that you are measuring the
wrong text-message pairs.


> Assume that there's a replicated service which we wish to attack:
>
> 	client  <---->  server A   <----->  server B
> ...
>
> As a legitimate user of this service, we can tweak its database at one
> site; that site will then "push" our changes to the other sites, and
> we can then snoop on the network traffic that results.
> ...
>
> Thus, as I said earlier, we can induce a system to create and destroy
> a large number of SPI's with a third party to provide us with a large
> number of chances to attack the hash function used to validate the
> Photuris change_message protocol.
>
Now I understand.  Clever.  But, there are several reasons why this
attack provably (P&vO) cannot succeed:

 1) The shared-secret between the other parties will be different, even
    when the target uses the same public value, as the other party will
    have a different public value.  You cannot use your SA with server A
    to influence the SAs between A and B.  No calculable relation.

 2) You have no control over the SPI used (or any other parameter,
    visible or invisible), and therefore cannot get the requisite number
    of "chosen" message pairs.

 3) Much (or most) of the material covered by the hash is hidden
    (encrypted), and therefore you cannot see the data that you want to
    measure to get the "known" message pairs.

 4) The actual hash is also hidden (encrypted), and therefore you cannot
    verify any forgery attempts.


> I'm not saying "change the bit level encoding".  I'm saying "move the
> abstraction boundary" -- at the layer within Photuris where you
> dispatch to a particular keyed hash algorithm, keep the key separate
> from the data; under the covers, it can combine it exactly as it's
> specified in photuris-09, or in a new way.
>
Aha, why didn't you say so in the first place?


> I had difficulty figuring out from photuris-09 where the
> abstraction boundary was between the various transforms and their
> uses.
>
> Here is a concrete suggested wording change to address the primary problem.
> If you accept this change (which I doubt), I'll supply wording to fix up the
> other places which use hash(concat(key,data,key))
>
Surprise!  Accepted.  Well, I won't add a separate section, and I'm not
that fond of certain phraseology, but I will rearrange the text in the
manner that you suggest.  Seems reasonable to me!


   The Validity-Method keyed cryptographic hashing function is supplied
   with two inputs:

    - the computed shared-secret,
    - the data to be hashed (as a concatenated sequence of octets).

   The resulting hash value is stored in the Verification field
   (variable precision number).

   The Validity-Method cryptographic hash is calculated over the
   following concatenated data values:

    + the Initiator Cookie,
    + the Responder Cookie,
    + the SPI Owner (receiver) Identity Verification,
    + the SPI User (sender) Identity Verification,
    + the Type, LifeTime and SPI,
    + the Attribute-Choices following the Verification field.


   Validity-Method

      When specified as a Validity-Method,
      as described in "Integrity Verification",
      an MD5 hash is calculated
      over the concatenation of

         MD5( key, data, key, md5fill )

      The leading key is not padded to any particular alignment.

      The resulting Verification field is 128-bits
      (18 octets including Size).

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: Bill Sommerfeld 
> While I believe this provides perfect forward secrecy for 
subsequent
> traffic keys derived from g^xy, this does not appear to provide
> perfect forward privacy protection for the identities enclosed in 
the
> ephemeral certificates Cert_I and Cert_J.

Bill,

You are correct that the SKIP PFS draft does not provide
equal protection for identity information as it does
for traffic.

However, the same is true of OAKLEY (and I believe Photuris,
though I dont have a draft at hand to check), albeit in a 
different manner.

With, e.g., OAKLEY, the identity information is revealed
in the unauthenticated phase, meaning that identity information
would be disclosed under an active (intruder-in-the-middle) 
attack. Of course, traffic is secure against active forms of 
attack, since it is transmitted in the authenticated phase.

An intruder-in-the-middle attack on SKIP PFS does not 
disclose identity information. 

There are some additional points to consider. The most common
usage of the anonymity feature is likely to be for mobile users,
making secured access to corporate information across the
Internet. In this scenario, J is an organizational 
firewall, and I is the mobile user. Compromise of the 
mobile user's long-term keys does not disclose identity 
information. Only compromise of the firewall's long term
keys discloses identity information. 

From a practical point of view, a mobile user's long-term 
keys are more likely to be compromised than the long-term 
keys of a physically protected organizational firewall. 

Therefore, considering only identity protection, one has to 
ask oneself what is a greater threat: a) The possibility of 
a compromise of a firewall's long-term keys or b) the possibility
of an intruder-in-the-middle attack on the key exchange.

If a) is a greater threat then the identity protection provided by
Photuris/Oakley is better. If b) is a greater threat then
the identity protection provided by SKIP PFS is better.

In favor of the identity protection provided by Photuris/Oakley,
it is worth noting that identity disclosure requires an attack
on each key exchange, wherease with SKIP PFS compromise of a 
firewall's long-term keys discloses identity information for a 
large number of exchanges. However, in principle if one can
perform an active attack on one key exchange, one could perform
active attacks on many key exchanges.

Given these different tradeoffs, my own view is that the
anonymity protection of SKIP PFS is adequate, however I
am open to modifying this if the WG believes a) to be 
a greater threat than b). (It is possible for the anonymity
protection for SKIP PFS to be more like Oakley/Photuris, at 
the cost of some additional complexity.)

Regards,
Ashar.







-------------- Enclosure number 1 ----------------
From ashar  Sat, 24 Feb 1996 12:12:54 PST +0500  remote from sunpak
Received: from ashar@sunpak by sunpak.sdnpk.undp.org
          (PMail+UDG PegWaf v0.26 93.04.04) id 3761 for ipsec@ans.net;
          Sat, 24 Feb 1996 12:12:54 PST +0500
From:          ashar@sunpak.sdnpk.undp.org (Ashar Aziz)
To:            ipsec@ans.net
Date:          Sat, 24 Feb 1996 12:12:53 +0000
Subject:       Re: an imperfection in skip-pfs. (fwd)
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.01)

> From: Bill Sommerfeld 
> While I believe this provides perfect forward secrecy for subsequent
> traffic keys derived from g^xy, this does not appear to provide
> perfect forward privacy protection for the identities enclosed in the
> ephemeral certificates Cert_I and Cert_J.

Bill,

You are correct that the SKIP PFS draft does not provide
equal protection to identity information as it does
to traffic.

However, the same is true of OAKLEY (and I believe Photuris,
though I dont have a draft at hand to check), albeit in a 
different manner.

With, e.g., OAKLEY, the identity information is revealed
in the unauthenticated phase, meaning that identity information
would be disclosed under an active (intruder-in-the-middle) 
attack. Of course, traffic is secure against active forms of 
attack, since it is transmitted in the authenticated phase.

An intruder-in-the-middle attack on SKIP PFS does not 
disclose identity information. 

There are some additional points to consider. The most common
usage of the anonymity feature is likely to be for mobile users,
making secured access to corporate information across the
Internet. In this scenario, J is an organizational 
firewall, and I is the mobile user. Compromise of the 
mobile user's long-term keys does not disclose identity 
information. Only compromise of the firewall's long term
keys discloses identity information. 

From a practical point of view, a mobile user's long-term 
keys are more likely to be compromised than the long-term 
keys of a physically protected organizational firewall. 
This is why the identities are protected with g^xj and 
not g^ij.

Therefore, considering only identity protection, one has to 
ask oneself what is a greater threat: a) The possibility of 
a compromise of a firewall's long-term keys or b) the possibility
of an intruder-in-the-middle attack on the key exchange.

If a) is a greater threat then the identity protection provided by
Photuris/Oakley is better. If b) is a greater threat then
the identity protection provided by SKIP PFS is better.

In favor of the identity protection provided by Photuris/Oakley,
it is worth noting that identity disclosure requires an attack
on each key exchange, wherease with SKIP PFS compromise of a 
firewall's long-term keys discloses identity information for a 
large number of exchanges. However, in principle if one can
perform an active attack on one key exchange, one could perform
active attacks on many key exchanges.

Given these different tradeoffs, my own view is that the
anonymity protection of SKIP PFS is adequate, however I
am open to modifying this if the WG believes a) to be 
a greater threat than b). (It is possible for the anonymity
protection for SKIP PFS to be more like Oakley/Photuris, at 
the cost of some additional complexity.)

Regards,
Ashar.

Good observation.
I'll consider (re)submission to
the PKIX group after the meeting
in LA when I have had a chance to
chat with the appropriate working
group chairs. I don't disagree
with you, but timing constraints
dictated the current approach. 
For now, the DSS Certificate draft
submission has been approved by
the IPSEC co-chairs and will
proceed through the IPSEC group. 

[We're all just one big, happy
family anyway, right? :)]

Regards,

John Kennedy
CYLINK

>>> William Allen Simpson

02/24/96 06:35am >>>
John, you sent this to the wrong
group.  You want the PKIX group.
Please update your draft
accordingly.

> Date: Fri, 23 Feb 1996 15:18:25
-0800
> From: John Kennedy

>
> Attached is a copy of a new
draft for the working group's
review.
> Comments should be sent to the
IPSEC mailing list (ipsec@ans.net)
> and/or directly to me
(jkennedy@cylink.com).
>
> Title: Digital Signature
Standard (DSS) Profile for X.509
Certificates
>       
<draft-ietf-ipsec-dss-cert-00.txt>
>
> Abstract:
>
> This document describes the
ASN.1 [1] encoding for a CCITT
1988 X.509 [2]
> certificate profiled for use
with the U.S. Government's Digital
Signature
> Standard (DSS) [3].
>
> This profile aligns with the
base standards and profile
references
> listed below.  It is intended to
provide guidelines for those
developing
> software that will be used to
issue and use DSS certificates. 
This is
> to insure that DSS-specific
certificate information will be
handled
> consistently throughout the
public key infrastructure.
>
>         X.509 (1993) | ISO/IEC
9594-8
>         Amendment 1 to ITU Rec.
X.509 (1993) | ISO/IEC 9594-8 :
1995
>         DoD Secure Data Network
System (SDNS) SDN.702 Revision 2.7
: 1994
>         USPS Postal ECS X.509
Certificate and CRL Profile, Rev.
0.5.: 1996
>
>
>
-----------------------------

Xref subject next

draft-ietf-ipsec-icmp-fail-01.txt creates a small security hole.

In particular, it defines a ICMP 'decryption failed' message, which leaks a
little information about an encrypted datagram.

Let me use the standard DES-CBC transform as an example: the last encrypted
block contains padding, padding-length, and payload-type.  The padding-length
may be as large as 255 to hide the length of the plaintext payload.  I claim
this length can be recovered by taking advantage of the ICMP failure messages.

Here's the attack.  Take a long DES-CBC-ESP encrypted IP datagram, for which
you want to know the true length of the payload.  Delete all the ciphertext
blocks except the last N blocks (and set the IV to be the N+1 to last
ciphertext block), send the resulting datagram, and check whether you get a
ICMP 'decryption failed' error.  If the padding-length byte was greater than
8N-2, you will receive a 'decryption failed' error (because presumably the
receiver will send a 'decryption failed' ICMP error when the decrypted
padding-length value is greater than the length of the encrypted payload).
If the padding-length is at most 8N-2, the decryption will succeed (although
some nonsense bits will be sent up to the transport protocol's port-- no harm
done).  A binary search over N will quickly find the datagram's secret length
(plus or minus 8 bytes or so).

So this cut-and-paste replay attack on DES-CBC, and its interaction with the
ICMP failure draft, opens a minor security weakness: an active attacker can
recover the length of the plaintext payload without too much effort.  (What
other scarier, subtler interactions are out there?  Eek.)

A fix?  One fix is to never use DES-CBC without authentication, I suppose.

>            SKIP extension for Perfect Forward Secrecy (PFS)
>                   <draft-ietf-ipsec-skip-pfs-00.txt>
>This document describes an optional extension specifying how to use an
>ephemeral Diffie-Hellman exchange in conjunction with the SKIP protocol
>in order to provide perfect forward secrecy for situations where forward
>secrecy is necessary.

Anonymity is also offered. (Or will be, after modification)

>In addition a new type of Master Key-ID (MKID) type is defined here, to
>indicate the use of ephemeral master keys. In addition to perfect
>forward secrecy, principal anonymity is also supported in the context of
>the ephemeral certificate exchange.

How about using 'NSID' instead of 'MKID type' ?

>2.  Cryptographic Description of Ephemeral Certificate Exchange
>
>Cryptographic Notation used for describing Ephemeral Certificates:
>
>Note: All exponentiations (e.g. g^x) are mod p. The mod p reduction is
>assumed, and is omitted for the sake of brevity.
>
>g^x:            Ephemeral Diffie-Hellman public value of initiator (I)
>g^y:            Ephemeral Diffie-Hellman public value of responder (J)
>g^i:            Certified long-term Diffie-Hellman value of initiator
>g^j:            Certified long-term Diffie-Hellman value of responder
>Cert_I:         Long-Lived Certificate of initiator, containing value g^i
>Cert_J:         Long-Lived Certificate of responder, containing value g^j
>{Message}K:     Message authenticated with a Message Authentication Code
>                (MAC) computed using key K
>[Message]K:     Message encrypted using key K
>EMKID_J_I:      Ephemeral Master Key-ID used in packets from J to I
>EMKID_I_J:      Ephemeral Master Key-ID used in packets from I to J
>
>The ephemeral certificate exchange is described using the
>notation above as follows:
>
>I->J: { g^x, g, p, [Cert_I]g^xj, EMKID_J_I}Kij
>J->I: { g^y, g, p, [Cert_J]g^xj, EMKID_J_I, EMKID_I_J}Kij

I see two problems with this exchange. One has already been pointed out by 
Bill Sommerfeld: 

>The problem is that the certificate is encrypted with a key g^xj which
>has an ephemeral public component and a long-term private component.
>If the long-term DH secret key `j' is later compromised, an attacker
>than then decrypt both [Cert_I] and [Cert_J] and figure out who the
>parties to the exchange really are.

The other (not so immediate) problem is the employment of authentication 
using Kij on the outmost level. An atacker having a bunch of ressources, who 
can lay hands on either one of the secret value 'i' or 'j', can then go and 
combine the value with the public value of a probable partner. He can verify 
his guess by simply recalculating the authentication. If it matches, he has 
found the partners.

Both problems can easily be fixed, if we allow for a 3-pass exchange. I am 
aware that this complicates the issue of key establishment, but if somebody 
wants PFS and anonymity bad enough, he will have to pay the price, e.g.:

I->J: g^x, g, p, Cookie_1
J->I: {g^y, g, p, [Cert_J, EMKID_I_J, Cookie_1, Cookie_2}Kij]g^xy
I->J: [{g^x, g, p, Cert_I, EMKID_J_I, Cookie_2}Kij]g^xy

Cookie_1 & _2 allow I & J to check that the peer really holds Kij, and is 
not an impostor reusing some old messages. I admitt that I just reinvented 
the wheel, for a 'full' solution see e.g. page 5 of the current Oakley draft 
;-) But I believe the exchange presented above is sufficient for the special 
case SKIP PFS key exchange needs. 

>The values EMKID_I_J and EMKID_J_I refer to the ephemeral
>Master Key-ID to be used in SKIP packets sent from I to J
>and J to I, respectively. I picks the ephemeral MKID to
>be used in packets sent from J to I, and J picks the
>ephemeral MKID to be used in packets sent from I to J.

As a distinct namespace is defined for the EMKIDs, you _must_ define the 
size of these new key IDs. I suggest using 32 bit.

>The encryption of each principal's certificate using g^xj is optional.
>It is used to provide anonymity of the parties involved in the
>ephemeral exchange. In case anonymity is not desired or necessary
>(e.g. node to node communications) the encryption using g^xj may
>be omitted.

Change this to g^xy

>3.
>
>"Cert MAC Alg" identifies the MAC algorithm which is used to compute a
>MAC over the certificate contents. The scope of the MAC computation is
>the entire certificate, with the MAC field treated as zero filled for
>the purposes of the MAC computation.

Always if a MAC is present, it must be encrypted usig an g^xy derived key, 
if anonymity is to be provided.

>
>The "Validity Interval" specifies how long the ephemeral master key
>derived from this exchange should be used for. This value is in seconds.
>A responder MAY choose a different value for this field than the
>initiator, in which case the actual validity interval for this master
>key is the minimum of the two values in the exchange. At the end of the
>validity interval, the ephemeral master key and the all associated
>secret information is destroyed by both the responder and the initiator.
>A new exchange may be initiated either subsequent or prior to the expiry
>of the ephemeral master key, in case there is still encrypted traffic
>that needs to be sent in PFS mode.

Here lies another small problem: It is not clear when the interval *starts*. 
Provided that the time of the participating systems is not vulnerable to 
attack, it might be better to use 'Expires at (seconds GMT since xxx)', or 
'Expires at SKIP N=xxx'. 

Perhaps it could also be defined that if a new key exchange using the same 
EMKID is initiated, the old keying material is droppped. Or an authenticated 
ICMP message could be defined that has the meaning 'drop all ephemeral 
keying material partaining to me'.


>When I receives an ephemeral certificate, it uses the value EMKID_J_I to
>locate the request for which this is the corresponding response. A non-
>zero EMKID_I_J field indicates that this a response to an ephemeral
>certificate request initiated by I, as opposed to a new certificate
>exchange initiated by J.
> .P
 ^^^^

>7.  Security Considerations
>
>The topic of this memo is security.

My word. ;-) 

Section 7 currently holds negligible content. You could add a discussion of 
advantages / disadvantages against pure SKIP?


I hope my abovementioned protocol & arguments are valid. Comments anyone?

Friendly greetings,
        
        Germano


p.s. Concerning key separation issues: As Hugo suggested some months ago, it 
would be wise to use different keying material for different crypt & auth 
algs in SKIP. How about adding the two algorithm numbers to the key 
speration process?

I have a few comments on the draft:

1.  What is the representation of the actual subjectPublicKey? Given
    the use of the DoD algorithm identifier, I assume it's the one from
    the Mosaic documentation, ie. version number + type + privileges +
    the actual key.  All that's needed for commercial use is the actual
    key.  If you're only conveying the actual key, you can't very well
    use the DoD identifier, since it implies a different structure.
    I suggest using the representation in ANSI X9.57, which is just
    an INTEGER.  OIDs are:

    algorithm OBJECT IDENTIFIER ::=
       { iso(1) identified-organization(3) oiw(14) secsig(3)
      algorithm(2) }
    dsa OBJECT IDENTIFIER ::= { algorithm 12 }
    dsaWithSHA-1 OBJECT IDENTIFIER ::= { algorithm 27 }


2.  All of the parameters and signature fields are conveyed as OCTET
    STRINGs.  Are these big-endian integers?  If so they could be
    conveyed as ASN.1 INTEGERs per X9.57; this only changes the tags,
    not the actual data within the fields.  X9.57 uses the following:

         DSAParameters ::= SEQUENCE {
             modulusLength     INTEGER,     -- length of p in bits
             prime1            INTEGER,     -- modulus p
             prime2            INTEGER,     -- modulus q
      base        INTEGER }    -- base g

 DSASignature ::= SEQUENCE {
     r  INTEGER,
     s  INTEGER }


Regards,
Rich

Xref subject next

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.


       Title     : DSS Profile for X.509 Certificates
       Author(s) : John Kennedy, John Marchioni
       Filename  : draft-ietf-ipsec-dss-cert-00.txt
       Pages     : 3
       Date      : 02/24/1996

This document describes the ASN.1 encoding for an CCITT 1988 X.509
certificate profiled for use with the NIST Digital Signature Standard
(DSS).

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-dss-cert-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-dss-cert-00.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-dss-cert-00.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: <19960225113743.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-dss-cert-00.txt

--OtherAccess
Content-Type:   Message/External-body;
	name="draft-ietf-ipsec-dss-cert-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960225113743.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.


       Title     : DSS Profile for X.509 Certificates
       Author(s) : John Kennedy, John Marchioni
       Filename  : draft-ietf-ipsec-dss-cert-00.txt
       Pages     : 3
       Date      : 02/24/1996

This document describes the ASN.1 encoding for an CCITT 1988 X.509
certificate profiled for use with the NIST Digital Signature Standard
(DSS).

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-dss-cert-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-dss-cert-00.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-dss-cert-00.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: <19960225113743.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-dss-cert-00.txt

--OtherAccess
Content-Type:   Message/External-body;
	name="draft-ietf-ipsec-dss-cert-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960225113743.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous

> From: David A Wagner 
> draft-ietf-ipsec-icmp-fail-01.txt creates a small security hole.
>
> In particular, it defines a ICMP 'decryption failed' message, which leaks a
> little information about an encrypted datagram.
>
> Let me use the standard DES-CBC transform as an example: the last encrypted
> block contains padding, padding-length, and payload-type.  The padding-length
> may be as large as 255 to hide the length of the plaintext payload.  I claim
> this length can be recovered by taking advantage of the ICMP failure messages.
>
Thank you for the excellent analysis.

However, in order to make network protocols work in a user environment,
we need error feedback mechanisms for the protocols.


> Delete all the ciphertext
> blocks except the last N blocks (and set the IV to be the N+1 to last
> ciphertext block),
> ...
> A fix?  One fix is to never use DES-CBC without authentication, I suppose.
>
As that is the fix for several other problems, I certainly recommend it.
Indeed, it is already recommended in the RFC.

Another more specific fix is to use the 32-bit IV facility, instead of
the 64-bit.  That prevents setting the IV (above).  I will be
recommending this at the LA IETF meeting.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject next

--NextPart

This announcement is a retransmission.

A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.


       Title     : The ESP DES-CBC plus MD5 Transform
       Author(s) : P. Metzger, W. Simpson, D.A. Wagner
       Filename  : draft-simpson-esp-des1md5-01.txt
       Pages     : 16
       Date      : 02/25/1996

This document describes use of DES-CBC for privacy, plus MD5 for integrity,
in the IP Encapsulating Security Payload (ESP).

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-simpson-esp-des1md5-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-simpson-esp-des1md5-01.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-simpson-esp-des1md5-01.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: <19960225131738.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-simpson-esp-des1md5-01.txt

--OtherAccess
Content-Type:   Message/External-body;
	name="draft-simpson-esp-des1md5-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960225131738.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous

--NextPart

This announcement is a retransmission.

A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.


       Title     : The ESP DES-CBC plus MD5 Transform
       Author(s) : P. Metzger, W. Simpson, D.A. Wagner
       Filename  : draft-simpson-esp-des1md5-01.txt
       Pages     : 16
       Date      : 02/25/1996

This document describes use of DES-CBC for privacy, plus MD5 for integrity,
in the IP Encapsulating Security Payload (ESP).

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-simpson-esp-des1md5-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-simpson-esp-des1md5-01.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-simpson-esp-des1md5-01.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: <19960225131738.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-simpson-esp-des1md5-01.txt

--OtherAccess
Content-Type:   Message/External-body;
	name="draft-simpson-esp-des1md5-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19960225131738.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

Xref subject previous
Xref subject next

At 01:35 PM 2/24/96 GMT, William Allen Simpson wrote:
>Gentlefolk,
>
>I propose that we officially remove the recommendation for Sensitivity
>Labels from RFC-1825, for several reasons:
>
Sensitivity labels.  What an interesting concept.  Seems like I was just in
a discussion about them.  Oh yes that was at the EMail security meeting were
it was shown that only MSP has'm and the others are going to need them.

But is for secure 'objects' and we are dealing with secure 'streams', right?

So what is the role of sensitivity for streams?  An interesting question for
sure one that is not jelling right now.

Do the labels map to those in MSP?  The docs are all there, put up by Spyrus.


Robert Moskowitz
Chrysler Corporation
(810) 758-8212

IPSEC Implementation Survey 
 
Name of Implementation:  ETHZ / ENskip  
Security Protocols: SKIP (draft 6), limited AH & ESP (SPI=1)
Security Transforms: ESP-DES, ESP-3DES, ESP-IDEA, ESP-RC4, AH-MD5
    (some of these transforms are not yet standarized)
Key Management: only via SKIP, (manual, X.509 and 'DH public value' keying).
    (plus non-standardized PFS)
Lineage of Code: Works under Solaris 2.4+, IRIX, NetBSD, Nextstep.
Location of Source Code:  ftp://ftp.tik.ee.ethz.ch/pub/packages/skip
    (X.509 and PFS not yet publicly available)
Point of Contact: skip@tik.ee.ethz.ch

Xref subject previous
Xref subject next

At 12:42 AM 2/24/96, Paul A Vixie wrote:
>In article <9602232014.AA15345@edisto.watson.ibm.com>,
>edie@watson.ibm.com ("Edie E. Gunter") writes:
>>   The complexity I'd like to avoid is that of DNS as a whole --
>>   duplication of function in multiple RRs and over-engineering
>>   solutions to simple problems.
>
>Me, too.  Since a SIG(NULL) does what EXP would do, and since SIG(NULL)
>is much easier to implement than SIG(*), I see no reason for EXP.  I see
>EXP as unnecessary complexity for a system whose comparitive simplicity
>has been its biggest reason for success.

Well, beauty is in the eyes of the beholder.

SIG(NULL) was invented to accommodate the needs of dynamic update that
wanted an expire without security.  Frankly, I don't know why, but there's
more of them than there are of me, so C'est la Vie.

However, I do not support SIG(NULL), I have never supported SIG(NULL), and
I never will support SIG(NULL).  It's hard enough convincing people what is
secure and what's not, when there is security and when there isn't, and
we're only going to confuse the issue further by providing a security
enhancement to DNS with absolutely no security whatsoever.  It's totally
ludicrous.

Dynamic update should have done EXP in the first place.  In fact, SIG
should use EXP instead of having it in the SIG RR; that's the only reason I
relented in my argument against SIG(NULL).  People did not want to slow
down DNSSEC by waiting for EXP so we needed a transition state.

Jim

----------------------------------------------------------------------------
James M. Galvin                                               galvin@eit.com
VeriFone/EIT, PO Box 220, Glenwood, MD 21738                 +1 410.795.6882

Xref subject previous
Xref subject next

> Dynamic update should have done EXP in the first place.  In fact, SIG
> should use EXP instead of having it in the SIG RR; that's the only reason I
> relented in my argument against SIG(NULL).  People did not want to slow
> down DNSSEC by waiting for EXP so we needed a transition state.

agreed.

randy

add ipsec

Xref subject previous
Xref subject next

Someone here said that the expiration in a SIG pertains to me signature,
whereas the expiration in an EXP pertains to EXP's RRset.  If that's
right, then the solutions spaces are disjoint and we should progress both.

Xref subject previous
Xref subject next

% Gentlefolk,
% 
% I propose that we officially remove the recommendation for Sensitivity
% Labels from RFC-1825, for several reasons:
% 
%  A) Although there are many (> 6) interoperable implementations of
%     RFC-1828 and RFC-1829, none of them implement Sensitivity Labels.

At least 2 do implement sensitivity labels.

%  B) Since RFC-1828 and RFC-1829 are more than ready to go to Draft
%     Standard, but interoperability of Sensitivity Labels has not been
%     demonstrated, by RFC-1602 we MUST remove Sensitivity Labels from our
%     official WG documents.

RFC-1828 and RFC-1829 are NOT ready to go to Draft Standard.  In
fact, they CANNOT go to Draft Standard because RFC-1825 through RFC-1827
are not ready to move forward.  

Further, RFC-1829 is known to be vulnerable to active attacks.
 
%  C) Sensitivity Labels are ill-defined.

Hardly.  See RFC-1108.

%  D) Commercial vendors have not found a demand for Sensitivity Labels.

Also untrue.

The set of workstation vendors that implement Sensitivity Labels includes
HP, DEC, IBM, Sun and the set of router vendors includes at least Cisco
and Network Systems.

% Then, you have not followed the Standards Process in RFC-1602.  The time
% for updating them is upon us.

False.  We are NOT required to move them forward at the first opportunity
to do so.  There is no process violation in waiting until things are
ready to move forward.
 
Ran
rja@cisco.com

Xref subject previous
Xref subject next

> From: Ran Atkinson 
> % I propose that we officially remove the recommendation for Sensitivity
> % Labels from RFC-1825, for several reasons:
> %
> %  A) Although there are many (> 6) interoperable implementations of
> %     RFC-1828 and RFC-1829, none of them implement Sensitivity Labels.
>
> At least 2 do implement sensitivity labels.
>
This is distinctly odd.  Although this message seems to be a reply to my
message, the relevant request is deleted and not answered.  Instead, we
have proof by assertion.  Repeating a claim does not make it so....

 A) Although there are many (> 6) interoperable implementations of
    RFC-1828 and RFC-1829, none of them implement Sensitivity Labels.
 ...

> From: Ran Atkinson 
>   There are at least 2 independent implementations of RFC-1825 that include
> support for sensitivity labels.
>
Please indicate which implementations?

And if you cite NRL, please detail commands for manual configuration of
the security association that implement the feature.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

> From: Ran Atkinson 
> %  C) Sensitivity Labels are ill-defined.
>
> Hardly.  See RFC-1108.
>
I re-read RFC-1108, just to make sure my memory wasn't utterly failing,
and I found this statement at the very top, in the title:

                       U.S. Department of Defense
               Security Options for the Internet Protocol

How does that apply to commercial implementations?

How does that apply to international implementations?

                                ----

Moreover, these are examples of facilities for "explicit" labels, rather
than "implicit" labels (indicated per SPI) used for IP Security.

I find that the application of these labels are used for
particular objectives (from RFC-1108 page 2):

   This option is used by end systems and intermediate systems of an
   internet to:

        a.  Transmit from source to destination in a network standard
        representation the common security labels required by computer
        security models,

        b.  Validate the datagram as appropriate for transmission from
        the source and delivery to the destination,

        c.  Ensure that the route taken by the datagram is protected to
        the level required by all protection authorities indicated on
        the datagram.  In order to provide this facility in a general
        Internet environment, interior and exterior gateway protocols
        must be augmented to include security label information in
        support of routing control.

What Internet routing protocols support this routing control?

How exactly are the proposed IP Security Sensitivity Labels used in
"network layer" routing without this routing control?

                                ----

See also RFC-1457, which complains that there is no standard network
label format, discusses translation problems, and examines the current
status of labels in the protocol stack (including IEEE and ISO).

Indeed, RFC-1457 recommendations appear to indicate that implicit labels
are best applied at the link and transport layers, not the network layer.

                                ----

Again, the RFC-1825 Sensitivity Label recommendations were misguided and
ill-defined, and implementation experience has shown that we have no
need of them.

I urge the WG to clearly indicate that they should be removed.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

> Someone here said that the expiration in a SIG pertains to me signature,
> whereas the expiration in an EXP pertains to EXP's RRset.  If that's
> right, then the solutions spaces are disjoint and we should progress both.

There's just this one funny little quirk to be resolved.  DNSSEC
specifies that when the SIG expires, the covered RRs in effect
go away (they're no longer provided in query responses and don't
appear in a zone transfer.)  I think the idea here was that
secure servers don't give out unauthenticated data. ??  The net
then is that when the SIG expires, the covered RRset also expires.

Of course, if Jim wants to revamp DNSSEC to remove/redesign this
"feature" and have the security stuff work with a new EXPIRE RR,
as has been suggested/implied here, that's a different matter.

Edie

Xref subject previous

> Security Working Group                                         J. Hughes
> Request for Comments: DRAFT                        Network Systems Corp.
>                                                            February 1996
> 
> 
>      Combined DES-CBC, MD5 and Replay Prevention Security Transform

So let me first thank you for spending your time to draft a transform
which includes confidentiality & integrity & replay protection in ESP!

Unfortunately, your current text has some serious flaws (though I think
they can be fixed within your basic framework).  I'll explain.


First, you use unkeyed MD5 for integrity protection.  This is altogether
insufficient (even though the MD5 digest is encrypted).  I've included an
attack at the bottom of this email if you want more details.

You need to use *keyed* MD5 for integrity; use one of the MD5 MACs that
is detailed in the AH ipsec RFCs.  (HMAC looks ideal.)

The MD5 MAC should cover everything in the ESP header and afterwards that
it can; in particular, it should protect the SPI and the IV (which you
don't have it doing currently).

You might consider placing the MD5 MAC output at the beginning of the
encrypted data, rather than the end: that way it will have an additional
IV-like randomizing influence.


Second, the replay protection mechanism you describe is insufficient:
it requires a counter to be increasing.  Since IP datagrams frequently
arrive out-of-order, you'll be dropping an awful lot of packets.  Instead,
the receiver needs some sort of window for sequence numbers.  (Steve Kent
suggested a simple scheme along these lines.)

I do like the idea of the 32 bit session specific nonce in the replay
protection field.  Good!

You should mention that there will be significant difficulties in getting
replay protection to work well in the case of multiple senders per SPI.
(One hack which might work if there are just a few senders is to give
each sender a different 32 bit session specific nonce.)  I don't know of
any good way to handle many-sender replay protection; leave that issue
for the future, I suppose.


Third, now there will be key scheduling issues.  Since the MD5 MAC will
be keyed, we will need two keys.  DON'T use the same key for both MD5 and
DES; this is a horrible idea.  (I'll elaborate on why if you like.)  The
MD5 & DES keys should be chosen independently.

Since security associations typically only allow one transform key to be
associated with them (in the implementations I've seen), you'll need a way
to specify the MD5 & DES keys from the transform key.

One simple solution is to have a 56+128 = 184 bit transform key: use the
first 56 bits of the transform key as the DES key, and the last 128 bits as
the MD5 key.  You'll have to be very careful to warn people to make sure
those bits are independent, though-- this solution might be tempting fate
a bit.

A more sophisticated & safer solution is to have a 128 bit transform key,
and then specify a simple key schedule to generate the DES & MD5 keys, e.g.
	MD5-key = MD5("md5mac" || transform-key)
	DES-key = MD5("descbc" || transform-key).

You should probably include a little note to implementors who are tempted
to make an export-weakened version of this transform, as well: though that
should be highly discouraged, such implementors should take care to only
reveal bits of the DES-key in the Espionage Enabling Field, and MUST NOT
reveal bits of the transform-key or the MD5-key.


I've been thinking about these issues a lot; in fact, I think I wrote
some text for a possible transform along these lines a while ago...it might
still be floating around somewhere.  But don't get the wrong idea: I'm not
criticizing your draft because of some "not invented here" syndrome-- I
just happened to have thought a lot about this stuff already, and would
like to help get it right.

Thanks for taking the time to work on this transform!  I hope this note
will help you improve its security.



P.S.  Here's an example of an attack on unkeyed MD5, as used for integrity
protection.  I think there's more discussion of these topics in Tsudik's
paper on hash-based MACs (which is even available on the web somewhere!).

If I want to get you to sign a message M, then I calculate
	X = M || md5(M) || M'
for any M', get you to sign X, and receive
	DES-CBC(X || md5(X))
	= DES-CBC(M || md5(M) || M' || md5(X)).
Now remember that I can trim from the end of DES-CBC to short messages;
so trim off the encrypted M' & md5(X) blocks, to get
	DES-CBC(M || md5(M))
which is a forged signed & encrypted version of M.

There are probably sharper attacks; but this should be enough to convince
you that an unkeyed function is unsuitable for use as a MAC.

     Greetings,
     
     Thought some people on this list would be interested in the on-line 
     test we're undertaking this week.  Ten vendors implementing IPSec in 
     their products will be doing an interoperability test.  We'll be 
     posting the results as they come in.  You can see them at www.rsa.com.
     
     Regards,
     
     Tim Matthews

Xref subject previous
Xref subject next

> 
> > From: Ran Atkinson 
> > %  C) Sensitivity Labels are ill-defined.
> >
> > Hardly.  See RFC-1108.
> >
> I re-read RFC-1108, just to make sure my memory wasn't utterly failing,
> and I found this statement at the very top, in the title:
> 
>                        U.S. Department of Defense
>                Security Options for the Internet Protocol
> 
> How does that apply to commercial implementations?
> 
> How does that apply to international implementations?
> 
>                                 ----


Check out the newly emerging security label standards - NIST's
"Standard Security Label" (SSL) and the DoD version "Common Security
Label" (CSL) [MIL-STD-2045-48501].  These were adapted/extended from
the IPSO (RFC-1108) and the Common IPSO (CIPSO).  The SSL and the CSL
were carefully harmonized - in other words, they say the same things.
So, here we have what will be a security label standard applicable to
the civil/commercial world as well as the military community.


> 
> Moreover, these are examples of facilities for "explicit" labels, rather
> than "implicit" labels (indicated per SPI) used for IP Security.
> 


But why should "explict" labels be precluded?  There are times when
they are explicitly needed (see below).


> I find that the application of these labels are used for
> particular objectives (from RFC-1108 page 2):
> 
>    This option is used by end systems and intermediate systems of an
>    internet to:
> 
>         a.  Transmit from source to destination in a network standard
>         representation the common security labels required by computer
>         security models,
> 
>         b.  Validate the datagram as appropriate for transmission from
>         the source and delivery to the destination,
> 
>         c.  Ensure that the route taken by the datagram is protected to
>         the level required by all protection authorities indicated on
>         the datagram.  In order to provide this facility in a general
>         Internet environment, interior and exterior gateway protocols
>         must be augmented to include security label information in
>         support of routing control.
> 
> What Internet routing protocols support this routing control?
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
None deployed, but have you heard of "policy-based" routing?

Besides, policy routing is only one issue.  Nothing precludes the use
of IP security option labels that could be checked by a packet's
receipient to determine whether the packet is within an acceptable
classification range.  This is a *very* useful feature when multiple
sensitivity systems are connected together via firewalls or other high
assurance guards.  For example, presume a multilevel system containing
both proprietary and non-proprietary data.  Only non-proprietary data
may cross the boundary of the firewall/guard and flow out.  The MLS
system could employ sensitivity labels to provide a basis on which the
firewall/guard can easily permit/deny datagrams flowing across its
boundary.  Many cludges have been put together because of a lack of
systems that can support sensitivity labels.

> How exactly are the proposed IP Security Sensitivity Labels used in
> "network layer" routing without this routing control?

The routing controls are only one piece of the puzzle.  What precludes
anyone from using this in the future (e.g., with policy-based
routing)?  There is at least one large site that I've been involved
with that could have effectively used sensitivity labels on connections if
their installed routers could have dealt with the labels without a
major performance penalty (which seemed to be a problem with the
particular vendor rather than the technical issue of filtering based
on security label - other vendors claimed to have no such performance
penalties in using IPSO).

> See also RFC-1457, which complains that there is no standard network
> label format, discusses translation problems, and examines the current
> status of labels in the protocol stack (including IEEE and ISO).

But this will be overcome by the SSL/CSL

> 
> Indeed, RFC-1457 recommendations appear to indicate that implicit labels
> are best applied at the link and transport layers, not the network layer.

The age-old problem with network layer labels (e.g., IPSO) is that
they could not be protected if the network layer itself was not
protected (i.e., not encrypted).  As long as there is a means to provide
label integrity, the label could be at any layer.

> 
> Again, the RFC-1825 Sensitivity Label recommendations were misguided and
> ill-defined, and implementation experience has shown that we have no
> need of them.

Talk to the Compartmented Workstation (CMW) vendors and the Trusted
Systems Interoperability Group (TSIG).  From TSIG documentation:

	" In order for two MLS systems to communicate securely, two
	  kinds of information must be exchanged:

		* Information, such as user identities, that users
		  themsevles can establish thorugh something that they
		  are, know or posess; and

		* Information, such as sensitivity labels, which users
		  themselves cannot establish but which trusted
		  systems must establish for them."

Obviously, there is at least one group of communicating systems that
*do* have a need for sensitivity labels!

> I urge the WG to clearly indicate that they should be removed.

I urge that they remain.

> 
> Bill.Simpson@um.cc.umich.edu
>           Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
> 


Howard Weiss

 ________________________________________________________________________
|                                                                        |
|  Howard Weiss                            phone (410) 381-9400 x201     |
|  SPARTA, Inc.                                  (301) 621-8145 x201 (DC)|
|  9861 Broken Land Parkway, suite 300     fax:  (410) 381-5559          |
|  Columbia, MD 21046                      email: hsw@columbia.sparta.com|
|________________________________________________________________________|

Xref subject previous
Xref subject next


Howard Weiss writes:
> > Moreover, these are examples of facilities for "explicit" labels, rather
> > than "implicit" labels (indicated per SPI) used for IP Security.
> 
> But why should "explict" labels be precluded?  There are times when
> they are explicitly needed (see below).

The explicit labels are not precluded. They are handled automatically
by the IPsec layer -- if a packet has a security label, it is
preserved and handled just fine. We are talking about the key
management layer, is not responsible for per packet explicit labeling,
only implicit labeling of the SPI.

Perry

Xref subject next


Please ignore this mailing list test ...

Xref subject next


 
 
Mr. Simpson, 
 
As a chairman of an Internet Engineering Task Force (IETF) working group I 
find myself in the difficult position of interpreting consensus as a means to 
mediate the activities of our committee.  So, as a chairman (one of two) of 
the IP Security (IPSEC) working group, I must inform you of the consensus of 
the committee regarding your participation in this working group and the 
status of your submittals to this committee.  There is strong consensus in the 
IPSEC working group that your behavior in this committee is unacceptable.  
There is strong consensus that your ongoing diatribe on the mailing list is 
detrimental to the progress of the working group.  You continue to ignore 
direct requests by the chairs to edit specifications that you have submitted, 
so none of documents submitted by you to IPSEC reflect the working group 
consensus. 
 
Consensus does not belong to the individual with the loudest voice or the 
fastest typing fingers.  You loudly declare group acceptance for documents 
that you submit, but offend, insult and ignore those that comment on these 
specifications.  Your attempts to control the editing of working group 
specifications does not improve or expedite the creation of good technical 
documents, but can only be viewed as the self serving promotion of your own 
business interests and ego. 
 
Editors for a working group specification should not be allowed to select 
themselves by being the first to publish, but rather should be selected as the 
best individual to document a technical topic.  You have taken advantage of 
flaws in the Internet process to subvert the orderly progression of technical 
ideas.  By rushing to publish a document under your own name you ignore the 
contributions of others, and claim squatters rights on the technical domain of 
others. 
 
The design for the key management protocol Photuris was created by Phil Karn. 
Phil's consistent effort and valuable technical contributions have lead to our 
current IPSEC consensus on a "hybrid Diffie-Hellman STS-like" cryptographic 
mechanism.  In December, you (Bill Simpson) were "fired" as Phil's supporting 
editor for the "Photuris" specification.  You refused to edit the document to 
meet working group consensus and refused to step down as Phil's assistant in 
the documentation process.   You asserted that you were an "author" of the 
Photuris specification and not an "editor".  In this context you threatened 
both individuals and the IETF with a lawsuit if you were "removed".  To avoid 
using any text that you might have generated, the chairs of the IPSEC working 
group have encouraged Hillary Orman to become the editor for the IPSEC key 
exchange specification.  Her excellent effort has resulted in the 
draft-ietf-ipsec-oakley-00.txt specification.  This specification is intended 
to meet the working group direction for a "hybrid Differ-Hellman STS-like" 
cryptographic mechanism.  Your affiliation with the Photuris specification has 
resulted in a document that lacks clarity and group acceptance.  I strongly 
encourage you to reexamine the "help" that you are giving to Mr. Karn. 
 
The "security transform" specifications in the IPSEC committee have also 
suffered from your "authorship".  An editor, Jim Hughes, has been selected to 
edit working group specifications on the IPSEC security transforms.  His first 
Internet Draft on this topic has been submitted and other transforms (IDEA, 
triple-DES, or others) will follow soon.  I am confident that these documents 
will reflect the contributions and expert ice of the whole committee. 
 
Your belligerent and disruptive behavior in the IPSEC working group is not the 
first case of your misbehavior in Internet working groups.  At least three 
other working groups have had to censure your participation.  You consistently 
insult and intimidate members of Internet committees and manipulate the IETF 
to promote your own interests over those of the working groups. 
 
The interaction of the IETF by electronic mail has created a unique form of 
committee interaction that replaces meeting halls with e-mail lists, votes 
with consensus and membership with subscription.  Disruptive behavior in any 
forum is unacceptable and the IETF will be forced by your actions to 
investigate suitable disciplinary actions in our network community.  If this 
were a "physical" meeting run by Robert's Rules of Order, we could vote to 
have you expelled from the meeting.  As chairman, I wish that we could 
"banish" you from our list and I am confident that a very large majority of 
the IPSEC mailing list would approve.   
 
In summary Mr. Simpson, your continued work on the Photuris specification, 
security transform specifications and your ongoing diatribes on this mailing 
list are detrimental to the progress of the IPSEC working group.  I request 
that you abstain from making pronouncements on working group goals and group 
consensus.  I suggest that you apologize to the working group and severely 
limit your postings to the IPSEC mailing list. 
 
 
 
 
Paul A. Lambert 
 
IPSEC Co-Chair 
 

Xref subject previous


Please ignore this mailing list test ...

Xref subject previous
Xref subject next


 
The following nine individuals and vendors have responded to the IPSEC 
implementation survey. 
 
 ERPIPSEC 
 ETHZ / ENskip 
 IBM 
 JI 
 KA9Q NOS 
 Morning Star SecureConnect 
 Network Systems BorderGuard and Security Router 
 NRL   
 Sun ICG 
 TimeStep PERMIT 
 USC/ISI 
 
The results of this first survey (as of February 26, 1996) are provided below. 
 
_______________________________________________________________________ 
 
Name of Implementation:   ERPIPSEC, BELLCORE, Antonio Fernandez  
Security Protocols:       ESP, AH 
Security Transforms:      ESP-DES, AH-MD5_128,64,32 
Key Management:           manual 
Location of Source Code:  proprietary 
Point of Contact:         Antonio Fernandez,  
                          afa@bellcore.com 
 
_______________________________________________________________________ 
 
Name of Implementation:   ETHZ / ENskip   
Security Protocols:       SKIP (draft 6), limited AH & ESP (SPI=1) 
Security Transforms:      ESP-DES, ESP-3DES, ESP-IDEA, ESP-RC4, AH-MD5 
                           (some of these transforms are  
                            not yet standarized) 
Key Management:           only via SKIP, (manual, X.509 and  
                           'DH public value' keying). 
                           (plus non-standardized PFS) 
Lineage of Code:          Works under Solaris 2.4+, IRIX, NetBSD, Nextstep. 
Location of Source Code:  ftp://ftp.tik.ee.ethz.ch/pub/packages/skip 
                           (X.509 and PFS not yet publicly available) 
Point of Contact:         skip@tik.ee.ethz.ch 
 
_______________________________________________________________________ 
 
Name of Implementation:   IBM 
Security Protocols:       ESP, AH, both tunnel and transport mode 
Security Transforms:      ESP-DES (32-bit and 64-bit IV), keyed-MD5, 
                           new keyed-MD5 proposed by Hugo 
Key Management :          Manual+Fast Key Refreshment>, 
                           SKEME (in progress), Photuris (in Progress) 
Lineage of Code:          IBM Proprietary, about 10k to 15K lines 
                           (rough estimate, including ESP,  
                           AH, and Key Management). 
Location of Source Code:  Proprietary 
Point of Contact:         pau@yktvmv.vnet.ibm.com 
 
_______________________________________________________________________ 
 
Name of Implementation:   JI 
Security Protocols:       ESP, AH, Protocol-4 encapsultation 
Security Transforms:      ESP-DES, AH-MD5 
Key Management:           manual, Photuris; PF_ENCAP keying i/f, 
                           PF_ROUTE extensionsl  
Lineage of Code:          Written from scratch,  
                           entirely in Greece, for BSD/OS 2.0,  
Location of Source Code: ji's home machine 
                          The promised end-January-96 release  
                          is not ready yet; it should be (freely) available 
                          from ftp.ripe.net RSN. 
Point of Contact:        ji@hol.gr 
 
_______________________________________________________________________ 
 
Name of Implementation:  KA9Q NOS 
Security Protocols:      ESP, AH 
Security Transforms:     ESP-DES & ESP-DES3, each with 0,32 and 64-bit IVs; 
                          keyed MD5 
Key Management:          manual 
Lineage of Code:         scratch 
Location of Source Code: Not yet released. Will release soon,  
                          modulo export rules 
Point of Contact:        karn@unix.ka9q.ampr.org 
 
________________________________________________________________________ 
 
Name of Implementation:  Morning Star SecureConnect 
Security Protocols:      ESP, AH 
Security Transforms:     ESP-DES, AH-MD5 
Key Management:          manual 
Lineage of Code:         scratch 
Location of Source Code: proprietary 
Point of Contact:        Karl Fox 
                           
_______________________________________________________________________ 
 
Name of Implementation:  Network Systems BorderGuard and Security Router 
Security Protocols:      Proprietary 
Security Transforms:     Des, Idea, 3DES, NSC1 (proprietary),  
                          MD5, Replay, D-H and RSA 
Key Management:          Proprietary 
Lineage of Code:          scratch 
Location of Source Code: proprietary 
Point of Contact:        Ted Doty  
                           
 
________________________________________________________________________ 
 
Name of Implementation:   NRL   
Security Protocols:       ESP, AH -- for BOTH IPv4 and IPv6 
Security Transforms:      ESP-DES, AH-MD5  
Key Management:           manual,  
                          PF_KEY interface for key management daemons  
Lineage of Code:          derived from and portable to 4.4-Lite BSD 
Location of Source Code:  ftp://ftp.ripe.net/ipv6/nrl/IPv6_domestic.tar.gz 
                            for the September 1995 alpha release. 
                          January 1996 alpha-2 release is not yet at an  
                            ftp site, but should appear soon in the  
                            protected "US-only" archives at ftp.c2.org.  
Point of Contact:         ipv6-bugs@cs.nrl.navy.mil 
 
_______________________________________________________________________ 
 
Name of Implementation:   Sun ICG 
Security Protocols:       ESP, AH, proprietary 
Security Transforms:      ESP-DES, ESP-DES3, AH/KEYED MD5 
Key Management:           SKIP 
Lineage of Code:           
Location of Source Code:  http://skip.incog.com 
Point of Contact:         markson@incog.com 
 
_______________________________________________________________________ 
 
Name of Implementation:   TimeStep PERMIT 
Security Protocols:       ESP, AH, proprietary 
Security Transforms:      ESP-DES 
Key Management:           proprietary, manual 
Lineage of Code:          from scratch 
Location of Source Code:  proprietary 
Point of Contact:         Stephane Lacelle 
                          slacelle@timestep.com 
 
_______________________________________________________________________ 
 
Name of Implementation:   USC/ISI 
Security Protocols:       IPv4 AH  
Security Transforms:      null, Internet checksum, MD5, proprietary 
                            null and Internet checksum  
                            for performance measurement 
Key Management:           Statically configured keys  
                          implementation for performance measurement only 
Lineage of Code:          SunOS 4.1.3, using "from scratch" and code 
                          adapted from the NRL IPv6 BSDI implementation 
Location of Source Code:  to be announced in March  
Point of Contact:         Joe Touch, 
                          touch@isi.edu 
 
  

Xref subject previous
Xref subject next

Count me as a supporter of sensitivity labels.  Indeed, I've raised the
issue in the past, when I pointed out the desirability for a mechanism
by which hosts can inform encrypting routers of their ipsec needs.  That
is, if my own host is doing encryption, I can easily tell it to use 3DES
or DES or ROT13 or what have you.  If the encryptor is a separate box, be
it a router or even a bump-in-the-cord encryptor, I need something going
over the wire.  Sensitivity labels are just one example of this, and not
the only one.

Xref subject next

The suggestion has been made that we should have an optional traffic type header.
That is, we need something that will disclose protocol and port numbers.  The
purpose would be (a) to permit traffic measurements, and (b) to permit routers
to optimize their handling of certain kinds of traffic.  (And yes, it's optional,
in case traffic analysis is your foe.)

Neither IPv6 flows nor IPv4 traffic types are a substitute.  Apart from the fact that
the former isn't here yet and the latter isn't used, they just don't disclose
enough information.  But if you're engineering a network, you need to know these
things.  To give just one example, the amount of http traffic to particular places
can be used to justify or refute the need for an organizational Web proxy.

As a strawman proposal, let me propose the following header format:


	u_char	next_proto;
	u_char	this_proto;
	short	pad;
	u_short	src_port;
	u_short	dst_port;

Arguably, pad should be length, in which case we could have two optional
fields:

	struct	in_addr	src_host, dst_host;

to account for tunnel mode.  (Tunnel mode is useful even if you're not trying
to hide the host names.)

An alternate mechanism would be to define new transforms; if nothing else,
that would avoid adding yet another header to the protocol type namespace.
It would also be simpler to implement; the obvious ways to do this in a
BSD-derived kernel or a streams-based kernel just don't work very well.

If there's enough interest (and, of course, not too much opposition), I'll
volunteer to write a draft RFC.

Xref subject previous
Xref subject next


--Boundary-3510150-0-0

 
Our new mail list system (ipsec@tis.com) retransmits messages in a manner that 
removes the originators name (at least for the info displayed by my e-mail 
system).  Most messages arrive as "from: ipsec-request@neptune.tis.com". 
 
If messages are not "signed", they usually appear anonymous to me.  This may 
be a useful feature, but if you want attribution for your note please add your 
name in a signature line. 
 
 
Thanks, 
 
Paul 
 
palamber@us.oracle.com 



--Boundary-3510150-0-0
Content-Type: message/rfc822

Date: 26 Feb 96 22:44:47
From:"ipsec-request@neptune.tis.com" 
To: ipsec@tis.com
Subject: traffic type header
Cc: braden@isi.edu,minshall@ipsilon.com
X-Orcl-Application: Mmdf-Warning:   Parse error in original version of preceding line at neptune.TIS.COM
X-Orcl-Application: Sender:  ipsec-request@neptune.tis.com
X-Orcl-Application: Precedence:  bulk


The suggestion has been made that we should have an optional traffic type header.
That is, we need something that will disclose protocol and port numbers.  The
purpose would be (a) to permit traffic measurements, and (b) to permit routers
to optimize their handling of certain kinds of traffic.  (And yes, it's optional,
in case traffic analysis is your foe.)

Neither IPv6 flows nor IPv4 traffic types are a substitute.  Apart from the fact that
the former isn't here yet and the latter isn't used, they just don't disclose
enough information.  But if you're engineering a network, you need to know these
things.  To give just one example, the amount of http traffic to particular places
can be used to justify or refute the need for an organizational Web proxy.

As a strawman proposal, let me propose the following header format:


	u_char	next_proto;
	u_char	this_proto;
	short	pad;
	u_short	src_port;
	u_short	dst_port;

Arguably, pad should be length, in which case we could have two optional
fields:

	struct	in_addr	src_host, dst_host;

to account for tunnel mode.  (Tunnel mode is useful even if you're not trying
to hide the host names.)

An alternate mechanism would be to define new transforms; if nothing else,
that would avoid adding yet another header to the protocol type namespace.
It would also be simpler to implement; the obvious ways to do this in a
BSD-derived kernel or a streams-based kernel just don't work very well.

If there's enough interest (and, of course, not too much opposition), I'll
volunteer to write a draft RFC.


--Boundary-3510150-0-0--

Xref subject previous
Xref subject next


--Boundary-3510176-0-0

 
Oops, 
 
>The following nine individuals and vendors have responded to the IPSEC  
>implementation survey.  
 
Make that: 
 
   The following eleven.... 
 
I suspect that there are other implementations.  Any other implementations 
obviously must not be viable standards compliant products or they would be 
involved in the IETF process:-) 
 
Responses to the IPSEC survey are still solicited. 
 
 
Paul 
  
 
-------------------------------------------------------------- 
Paul Lambert                     Director of Security Products 
Oracle Corporation                       Phone: (415) 506-0370 
500 Oracle Parkway, Box 659410             Fax: (415) 413-2963 
Redwood Shores, CA  94065               palamber@us.oracle.com 
-------------------------------------------------------------- 
 
 
 
 
 I have received many requests for information on ipsec implementations. Our 
working group also needs to coordinate interoperability testing among 
ourselves.  To this end, would ipsec implementors please fill out the 
following survey and post your completed survey to the ipsec mailing list 
(ipsec@tis.com).  
 
  
Thanks in advance,  
  
Paul A. Lambert  
ipsec co-chair   
  
*************************** Attachement ******************** 
 
 
 
IPSEC Implementation Survey  
  
************************************************************   
Name of Implementation:     
Security Protocols:         
Security Transforms:        
Key Management:             
Lineage of Code:            
Location of Source Code:    
Point of Contact:           
************************************************************  
  
 



--Boundary-3510176-0-0
Content-Type: message/rfc822

Date: 26 Feb 96 19:23:08
From:"PALAMBER.US.ORACLE.COM" 
To: ipsec@tis.com
Subject: IPSEC Implementation Survey
Cc: swan-dev@rsa.com
X-Orcl-Application: Mime-Version:  1.0
X-Orcl-Application: Sender:  ipsec-request@neptune.tis.com
X-Orcl-Application: Precedence:  bulk



 
The following nine individuals and vendors have responded to the IPSEC 
implementation survey. 
 
 ERPIPSEC 
 ETHZ / ENskip 
 IBM 
 JI 
 KA9Q NOS 
 Morning Star SecureConnect 
 Network Systems BorderGuard and Security Router 
 NRL   
 Sun ICG 
 TimeStep PERMIT 
 USC/ISI 
 
The results of this first survey (as of February 26, 1996) are provided below. 
 
_______________________________________________________________________ 
 
Name of Implementation:   ERPIPSEC, BELLCORE, Antonio Fernandez  
Security Protocols:       ESP, AH 
Security Transforms:      ESP-DES, AH-MD5_128,64,32 
Key Management:           manual 
Location of Source Code:  proprietary 
Point of Contact:         Antonio Fernandez,  
                          afa@bellcore.com 
 
_______________________________________________________________________ 
 
Name of Implementation:   ETHZ / ENskip   
Security Protocols:       SKIP (draft 6), limited AH & ESP (SPI=1) 
Security Transforms:      ESP-DES, ESP-3DES, ESP-IDEA, ESP-RC4, AH-MD5 
                           (some of these transforms are  
                            not yet standarized) 
Key Management:           only via SKIP, (manual, X.509 and  
                           'DH public value' keying). 
                           (plus non-standardized PFS) 
Lineage of Code:          Works under Solaris 2.4+, IRIX, NetBSD, Nextstep. 
Location of Source Code:  ftp://ftp.tik.ee.ethz.ch/pub/packages/skip 
                           (X.509 and PFS not yet publicly available) 
Point of Contact:         skip@tik.ee.ethz.ch 
 
_______________________________________________________________________ 
 
Name of Implementation:   IBM 
Security Protocols:       ESP, AH, both tunnel and transport mode 
Security Transforms:      ESP-DES (32-bit and 64-bit IV), keyed-MD5, 
                           new keyed-MD5 proposed by Hugo 
Key Management :          Manual+Fast Key Refreshment>, 
                           SKEME (in progress), Photuris (in Progress) 
Lineage of Code:          IBM Proprietary, about 10k to 15K lines 
                           (rough estimate, including ESP,  
                           AH, and Key Management). 
Location of Source Code:  Proprietary 
Point of Contact:         pau@yktvmv.vnet.ibm.com 
 
_______________________________________________________________________ 
 
Name of Implementation:   JI 
Security Protocols:       ESP, AH, Protocol-4 encapsultation 
Security Transforms:      ESP-DES, AH-MD5 
Key Management:           manual, Photuris; PF_ENCAP keying i/f, 
                           PF_ROUTE extensionsl  
Lineage of Code:          Written from scratch,  
                           entirely in Greece, for BSD/OS 2.0,  
Location of Source Code: ji's home machine 
                          The promised end-January-96 release  
                          is not ready yet; it should be (freely) available 
                          from ftp.ripe.net RSN. 
Point of Contact:        ji@hol.gr 
 
_______________________________________________________________________ 
 
Name of Implementation:  KA9Q NOS 
Security Protocols:      ESP, AH 
Security Transforms:     ESP-DES & ESP-DES3, each with 0,32 and 64-bit IVs; 
                          keyed MD5 
Key Management:          manual 
Lineage of Code:         scratch 
Location of Source Code: Not yet released. Will release soon,  
                          modulo export rules 
Point of Contact:        karn@unix.ka9q.ampr.org 
 
________________________________________________________________________ 
 
Name of Implementation:  Morning Star SecureConnect 
Security Protocols:      ESP, AH 
Security Transforms:     ESP-DES, AH-MD5 
Key Management:          manual 
Lineage of Code:         scratch 
Location of Source Code: proprietary 
Point of Contact:        Karl Fox 
                           
_______________________________________________________________________ 
 
Name of Implementation:  Network Systems BorderGuard and Security Router 
Security Protocols:      Proprietary 
Security Transforms:     Des, Idea, 3DES, NSC1 (proprietary),  
                          MD5, Replay, D-H and RSA 
Key Management:          Proprietary 
Lineage of Code:          scratch 
Location of Source Code: proprietary 
Point of Contact:        Ted Doty  
                           
 
________________________________________________________________________ 
 
Name of Implementation:   NRL   
Security Protocols:       ESP, AH -- for BOTH IPv4 and IPv6 
Security Transforms:      ESP-DES, AH-MD5  
Key Management:           manual,  
                          PF_KEY interface for key management daemons  
Lineage of Code:          derived from and portable to 4.4-Lite BSD 
Location of Source Code:  ftp://ftp.ripe.net/ipv6/nrl/IPv6_domestic.tar.gz 
                            for the September 1995 alpha release. 
                          January 1996 alpha-2 release is not yet at an  
                            ftp site, but should appear soon in the  
                            protected "US-only" archives at ftp.c2.org.  
Point of Contact:         ipv6-bugs@cs.nrl.navy.mil 
 
_______________________________________________________________________ 
 
Name of Implementation:   Sun ICG 
Security Protocols:       ESP, AH, proprietary 
Security Transforms:      ESP-DES, ESP-DES3, AH/KEYED MD5 
Key Management:           SKIP 
Lineage of Code:           
Location of Source Code:  http://skip.incog.com 
Point of Contact:         markson@incog.com 
 
_______________________________________________________________________ 
 
Name of Implementation:   TimeStep PERMIT 
Security Protocols:       ESP, AH, proprietary 
Security Transforms:      ESP-DES 
Key Management:           proprietary, manual 
Lineage of Code:          from scratch 
Location of Source Code:  proprietary 
Point of Contact:         Stephane Lacelle 
                          slacelle@timestep.com 
 
_______________________________________________________________________ 
 
Name of Implementation:   USC/ISI 
Security Protocols:       IPv4 AH  
Security Transforms:      null, Internet checksum, MD5, proprietary 
                            null and Internet checksum  
                            for performance measurement 
Key Management:           Statically configured keys  
                          implementation for performance measurement only 
Lineage of Code:          SunOS 4.1.3, using "from scratch" and code 
                          adapted from the NRL IPv6 BSDI implementation 
Location of Source Code:  to be announced in March  
Point of Contact:         Joe Touch, 
                          touch@isi.edu 
 
  




--Boundary-3510176-0-0--

Xref subject previous
Xref subject next


I have carbon copied this message to the IESG. The text of the message
which inspired it has been placed at the end.

"PALAMBER.US.ORACLE.COM" writes:
> In summary Mr. Simpson, your continued work on the Photuris specification, 
> security transform specifications and your ongoing diatribes on this mailing 
> list are detrimental to the progress of the IPSEC working group.  I request 
> that you abstain from making pronouncements on working group goals and group 
> consensus.  I suggest that you apologize to the working group and severely 
> limit your postings to the IPSEC mailing list. 

Paul;

I must respectfully say that although I am not always the biggest fan
of Bill's tone of voice, and although I agree that he is frequently
more belligerent than many of us would like,

  1) I cannot accept the tone of your message
  2) I am strongly offended, as a member of this working group, by your
     choosing to air this matter in what I consider to be an extremely
     offensive way, and in public, and 
  3) it is not in your power as a chairman of a working group to
     censure or censor the members of the group in this manner, and it
     is improper of you to assert that you can do so, and it is
     furthermore improper for you to attempt to do so.

I have personally been the subject of your fiat reinterpretation of
the proper rules of procedure, as when you refused to allow the
initial drafts that were published (the contents of which were
ultimately adopted by the group) for the ipsec specification to be
called draft-ietf-ipsec, in direct contravention of the interpretation
of the rules for naming drafts that the POISED working group had
arrived at. That move was arbitrary and capricious, but I felt it was
unimportant so I chose not to pursue it, and the fact that the drafts
in question were ultimately adopted in spite of the active opposition
of the chair proved me right. You have demonstrated a tendancy towards
arbitrary and capricious actions as chair at other times, such as in
your unilateral changes to the group consensus of the Toronto IETF
meeting during the course of the San Jose IETF meeting, but again I
substantially ignored this as the Toronto proposal was adopted anyway,
in spite of your opposition, so I decided not to pursue the matter. I
will note, by the way, that it is rather unusual to have to constantly
get the work of the group around of the efforts of the chair to derail
it. This matter, however, cannot be left unpursued.

Regardless of who is fit to edit our drafts, and whether or not Bill
Simpson has been excessively beligerant, and whether Bill Simpson
should be the editor of the Photuris documents, it is not, as you
characterise it, the consensus of the working group that Bill Simpson
is deserving of the sort of unmitigated vitriol that you have showered
upon him, nor is it the consensus of the working group that one of our
most hard working members -- in spite of his rather spirited manner --
be censored by the chairman of the working group. Your statement, and
I quote:

> I request that you abstain from making pronouncements on working
> group goals and group consensus.  I suggest that you [...] severely
> limit your postings to the IPSEC mailing list.

constitutes a totally unacceptable attempt to silence a working group
member.

As a chairman of a