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 working group, you are, I am afraid, accountable to
a much higher standard of behavior, especially in your public
comportment, than any ordinary member of the working group would be.
In making statements of this form, you must exercise extreme care
because you are speaking as chair. The IETF process places substantial
powers in the hands of the chair of a working group to report
consensus and guide the actions of a working group, and as a result it
is necessary that the chair of a working group be observed to be fair,
diplomatic and worthy of the trust placed in him by the IETF
community. I believe that you have severely violated that trust and
ruptured all appearance of fairness.

You mention Robert's Rules of Order. I must note that IETF working
groups are not parliamentary bodies, do not vote, and are not subject
to the parliamentary law. We operate, as many bodies do, based on our
own customary procedure, developed over time via precedent and some
charters like RFC1602. Under our customs, which have, I will note, the
full force of a formal set of bylaws in most jurisdictions, your
behavior has been improper. If you disliked what Bill Simpson had to
say on the mailing lists, it was possible for you to ignore it. If you
disliked the document he was editing, you were free to propose a new
one, commission a new one, or write a new one. You have some power to
request that he await his turn to speak during in-person meetings and
use only a fair share of in-person time, but in general, you are not
permitted as chair to silence working group members. Your action in
requesting that Bill, in effect, remain silent, is wholely improper
under our precedents and our customary rules of procedure. You add
insult to injury by making your request in the form of an unmitigated
diatribe. You also violate our customs concerning due process.

According to that procedure, I must first bring this matter to the
attention of the area director, Jeff Schiller, and permit him to
examine the issue before formally requesting action on the part of the
IESG. However, please be clear that I fully intend to ask that
substantive action be taken in this matter. In my opinion, this sort
of behavior cannot be tolerated, and I fully intend to pursue this
matter to the furthest extent permitted under our rules of procedure.

Perry E. Metzger

Original message follows:

Received:  by mailsun2.us.oracle.com (8.7.1/37.8)
	id TAA06978; Mon, 26 Feb 1996 19:04:02 -0800 (PST)
Message-Id: <199602270304.TAA06978@mailsun2.us.oracle.com>
Date: 26 Feb 96 15:59:10 -0800
From: "PALAMBER.US.ORACLE.COM" 
To: bill.simpson@um.cc.umich.edu
Subject: Censure of Mr. Simpson
Cc: ipsec@TIS.COM
Mime-Version: 1.0
Sender: ipsec-request@neptune.tis.com
Precedence: bulk


 
 
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 
 

In message <199602270304.TAA06978@mailsun2.us.oracle.com>, "PALAMBER.US.ORACLE.
COM" writes:
>
>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.  

Is there such consensus ? Excuse my doubts. Exactly *HOW* did you decide that
the WG felt that way ? It's been 2.5 months since the last IETF meeting, and
you've pretty much kept silent on this matter during this time. So either
you met a large percentage of the WG (again, excuse my doubts), you received
lots of protest mail (in which case i'd like to take a look at them, headers
and other ID stripped if necessary), you just kept silent so far (why ?), or
you just decided there is consensus.

>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. 
> 
I believe the matter of the SLs was/is under discussion ? In this matter at
least, my opinion is very much like Bill's; i also believe there are others
who want to discuss the issue, rather than let the chair(s) enforce a
decision (myself, i believe SLs should not concern us).

>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. 
> 
Offend ? Insult ?
I'll admit Bill is not the easiest person to persuade to do a change in a
draft he's editing, but more often that not he's accepted my (and at least
another person's) corrections/modifications.

I've also found your mail offensive and quite insulting; certainly not the
kind of mail i'd expect from a WG chair. The language is quite extreme, to say
the least.

>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" 

While i do believe Hillary is a very suitable editor, i STRONGLY (and i can't
possibly emphasize that) object to the way you remove Bill from the process.

>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. 
> 
That is for Phil to say.

>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. 
> 
Would you care to be more specific on how the security transform specifications
have suffered ? The new draft is far from perfect (actually, i consider it
several steps backwards); nothing that can't be fixed, but....

>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. 
> 
Care to back this statement on "promoting his own interests" ?

>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.   
> 
WHAT ?!?
I'm not overly familiar with what a WG chair can do, but i'm fairly certain
this is one of the things he can't (or shouldn't).

>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. 
> 
Apologize for having a loud voice, ignoring the chair in favour of discussion
within the WG and filling our mailboxes ?
I'd like to hear what Ran has to say.
-Angelos

Xref subject previous
Xref subject next

smb@research.att.com writes:
> Count me as a supporter of sensitivity labels.

Me too. Enough of reasons were given here for me to repeat them.
-- 
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-

Xref subject previous
Xref subject next


IPSEC Implementation Survey 
 
 
Name of Implementation: Raptor Systems
Security Protocols: ESP, AH, both tunnel and transport modes
Security Transforms: ESP-DES (32-bit and 64-bit IV), keyed-MD5 
Key Management:  manual 
Lineage of Code: proprietary
Location of Source Code: proprietary 
Point of Contact: jkraemer@raptor.com 

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

IPSEC Implementation Survey
Name of Implementation:	  NIST/NSA ESP/AH Implementation
Security Protocols:	  ESP, AH
Security Transforms:	  ESP-DES, AH-MD5, AH-SHA, and various others
Key Management: 	  manual, PF_SADB interface
			  for key management daemons
Lineage of Code:	  derived from BSD platforms.
			  Successful installation on
			  BSD/OS, NetBSD, FreeBSD, and DTOS
Location of Source Code:  Public distribution within the US
			  expected March 1996.
Point of Contact:	  glenn@snad.ncsl.nist.gov

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

Xref subject previous
Xref subject next

smb@research.att.com writes:
> Count me as a supporter of sensitivity labels.

uri@watson.ibm.com writes: 
> Me too. Enough of reasons were given here for me to repeat them.

I strongly agree also- for the same reasons.

- Cynthia

Xref subject next

> From: Ran Atkinson 
> %  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

Why not?  After all, they have the implementations required by
RFC-1602, page 14:

         A specification from which at least two independent and
         interoperable implementations have been developed, and for
         which sufficient successful operational experience has been
         obtained, may be elevated to the "Draft Standard" level.

We have existence proff that the specifications are specified with
sufficient clarity to be implemented internationally!


> fact, they CANNOT go to Draft Standard because RFC-1825 through RFC-1827
> are not ready to move forward.
>
RFC-1825 through -1827 are only advancable by experience on -1828 and
RFC-1829 -- not the other way around!  The former are dependent on
implementations of the latter.

And you did promise revisions to your RFCs which have not appeared.
But, that shouldn't stop the forward progress of the others....


> Further, RFC-1829 is known to be vulnerable to active attacks.
>
I do not understand.  I have seen no new references to attacks on
RFC-1829 mentioned on this list since the RFCs were published.

The only attack that I am aware of is that described to us by Steve
Bellovin last April.  It is clearly referenced in the Security
Considerations section, as is the use of AH to prevent the attack.

Are you now substituting your personal judgement for both WG consensus
and IETF consensus?


> % 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.
>
Why should they wait for other (tardy) drafts, on which advancement they
are not dependent?

The implementors desire an expeditious and stable specification.

And yes, delaying the Standards Process indefinitely is a process
violation in and of itself.  That's one of the reasons we have target
times, in both Standards Process and the WG Charter....

Is it your personal position that only WG Chair(s) (the royal "We") are
"permitted" to ask the WG for an advance on the standards track, and the
rest of us must patiently await their pleasure?

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

While I'm thinking about it, we also have sufficient experience with SHA
and 3DES to move them from Experimental to Proposed.

According to RFC-1602, page 14:

                                              Typically, such a
         specification will be published initially with Experimental or
         Prototype status (see below), and moved to the standards track
         only after sufficient implementation or operational experience
         has been obtained.

There seems to be a strong interest in both specifications, and
implementations have appeared from Karn and NIST.

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

Forwarded message:

Xref subject previous
Xref subject next

  
 IPSEC Implementation Survey  
   
 ************************************************************   
 Name of Implementation:   Secure Computing's Sidewinder Firewall
 Security Protocols:       ESP, AH
 Security Transforms:      DES, MD5
 Key Management:           manual
 Lineage of Code:          BSD based
 Location of Source Code:  proprietary  
 Point of Contact:         Troy de Jongh (dejongh@sctc.com)
 ************************************************************  

-- 
Brett Nelson
Secure Computing Corp.
2675 Long Lake Road
Roseville, MN  55113


-- 
Brett Nelson
Secure Computing Corp.
2675 Long Lake Road
Roseville, MN  55113

Xref subject previous
Xref subject next

I have been privately asked not to reply in detail.  Thank you all for
your public and private support.

In support of Perry's refutation, I will note that this _personal_ animus
and _private_ determination of "consensus" was somehow arrived at
_before_ I submitted my very first "intentionally disruptive" draft to
this WG, as evidenced by following excerpt:

    From: Paul_Lambert-P15452@email.mot.com
    Date: 16 Jan 95 13:25:00 -0600
    To: Internet-Drafts@CNRI.Reston.VA.US
    Subject: Re: draft-ietf-ipsec-ah-00.txt
    Message-Id: 

    Dear Sirs,

    As working group co-chair of the IETF IP Security Working Group I am writing in
    regarding to four recently submitted Internet Drafts (I-D) from Bill Simpson
    and Perry Metzger.  The I-D guidelines indicate that you have some control over
    the naming of these documents.  The documents currently have been submitted as:

        draft-ietf-ipsec-esp-00.txt
        draft-ietf-ipsec-esp-des-cbc-00.txt
        draft-ietf-ipsec-ah-00.txt
        draft-ietf-ipsec-ah-md5-00.txt

    I would like to request that the names of these I-Ds not include "ietf-ipsec"
    and that the drafts be identified by the author of the document:

        draft-simpson-esp-00.txt
        draft-simpson-esp-des-cbc-00.txt
        draft-simpson-ah-00.txt
        draft-simpson-ah-md5-00.txt

    or  draft-metzger- ... etc.

    An editing team of six people is currently generating a single document that
    will cover the techniques contained in these drafts.  This document will be
    published this week and represents the "consensus" version of the above
    mechanisms.  Creating new "ipsec-esp" and "ipsec-ah" documents does not
    represent the working group direction or work items.

    The strength of the IETF process is based on allowing a diversity of
    contributions and opinions to be expressed through the I-Ds.  Bill and Perry
    are free to submit I-D drafts, but their current timing and approach is
    intentionally disruptive to the working group.

I will also note that no such "single document" was ever posted and may
never have existed.  The WG ultimately overturned the Chair's decision
in this matter.

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

At 5:24 PM 2/26/96, Edie E. Gunter wrote:
>> From Paul Vixie
>> 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.

I don't think a revamp/remove/redesign is necessary.  At least, a scenario
where there's a conflict is not immediately obvious to me.  It would help
me if someone who may be more knowledgeable about dynamic update could
identify one.

The expiration in the SIG RR indicate when the SIG expires.  A SIG RR
covers a particular type of other RR.  When the SIG expires the RRs are to
be removed from the DNS.

The expiration in the EXP RR covers a particular type of other RR.  When
that time is reached the RRs are to be removed from the DNS.

In either case, when the expiration time is reached the data is to be
considered unavailable and removed from the DNS.  I'm at a loss to identify
a time when I would want either the signature or the expiration to remain
valid when the other has been reached.

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 does not require any sort of SIG(NULL) or EXP RR.
That need was part of previous drafts, and is long, long gone.

Patton's draft is not security related or dynamic update related,
but rather is just a normal DNS extension.  I have no idea why it
is being discussed on dns-security.

--Boundary-3523924-0-0

Thanks Naganand, 
 
Paul 
-------------


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

Date: 27 Feb 96 08:53:16
From:"Naganand Doraswamy" 
To: palamber@us.oracle.com
Subject: IPSEC Implementation
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Version 2.0.3
X-Orcl-Application: Mime-Version:  1.0
X-Orcl-Application: Content-Type:  text/plain; charset="us-ascii"


Paul,

I will have working code by the end of the week. However, I thought I would
send this to you so that you could include this in the next update you send
on implementations.

Thanks,


IPSEC Implementation Survey 
 
Name of Implementation:  FTP Software
Security Protocols: AH and ESP
Security Transforms: ESP-DES, NULL, AH-MD5
Key Management: Manual
Lineage of Code: Written from scratch. Looked at NRL implementation.
Location of Source Code:  Proprietary
Point of Contact: naganand@ftp.com


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



--Boundary-3523924-0-0--

Xref subject previous
Xref subject next


>From:"Bob Rybicki "  
>To: PALAMBER@us.oracle.com 
>Subject: Re: IPSEC Implementation Survey  
>Cc: dotis@v-one.com,jswang@v-one.com,ttang@v-one.com 
> 
> 
> 
>Name of Implementation:   V-ONE SmartWall 
>Security Protocols:       ESP, AH  Tunnel and Transport modes, V-ONE 
>                                Mutual Authentication 
>Security Transforms:      ESP-DES, ESP-3DES, RC4, Stream-DES   
>Key Management:           Custom, manual 
>Lineage of Code:          NRL derived, BSD/OS 
>Location of Source Code:  proprietary  
>Point of Contact:         Jason Wang, jswang@v-one.com 
> 
> 
> 
> 
>V-ONE Corporation   "Security for a Connected World" 
>Bob Rybicki,  
>V.P. Business Development 
>Tel# 301-838-8900 
>Fax# 301-838-8909

Xref subject previous
Xref subject next

To the members of the IPSEC working group,

I am no longer active in this group, having moved on to other duties. However,
based on prior interactions with Mr. Simpson, I fully support the move by
Paul Lambert to attempt to bring order into the working group proceedings.
As evidence I hereby make public a post Mr. Simpson sent to me in regards
to in-band keying. I have retained a record of the prior email on this
topic, which I believe shows Mr. Simpson had no reason to adopt an insulting
and scurrilous writing style. It is interesting that Mr. Simpson's defender
in this controversy is Mr. Metzger.

Dan Nessett

======

Perry, will you please shut up on this issue.  If this fellow is such an
asshole that he can't read "for future use", and such an incompetent
that he can't write a draft on how to use one, then he deserves to sink
in his own shit.  He's just trying to piggyback on our work.

You, Ran, Jeff, Ted, Deering and I have all said "write a draft".

You are just dragging out the debate, by giving him a prompt to reply.
Just leave it alone.  Ignore him until he has a draft.  That's how we
work.


> From: Danny.Nessett@eng.sun.com (Dan Nessett)
>       the value of this field shall be 0x00000000.  The set of SAID values
>       in the range 0x00000001 through 0x000000FF are reserved for future
>       use.
>
> There is similar language in the ESP I-D. I read this to mean that the
> reserved values are "reserved," i.e., not to be used, since they may
> be used for some unspecified purpose in the future. If the security documents
> are modified to indicate an SAID value that is to mean, "using in-band
> keying," then what you say would be true. However, at present it is not.
>

Bill.Simpson@um.cc.umich.edu

Xref subject previous
Xref subject next

I find this entire debate to be a *personal* attack on Bill Simpson, and not 
an attack on his work based on its technical merits. This is simply 
unacceptable. I urge everybody involved to calm down and re-evaluate their 
positions.

I have stayed silent so far, but I think it is time I spoke up. Remember that 
we are primarily a *technical* group (and one in a very important area), and 
we cannot allow technical work to be hindered by personal animosity. 
Furthermore, whatever Mr. Simpson's failings may be (and I am not necessarily 
implying there are any), the behavior of a segment of this working group has 
far exceeded what would be considered acceptable, polite, and civilized. 
Name-calling and ad hominem attacks have no place here, and some people seem 
to have fogotten that. 
Besides, summarily rejecting someone's work because of that someone's alleged 
personality traits is, to say the least, detrimental to the progress of the 
group as a whole.

Mr. Nessett's mail is what prompted my involvement in this thread, so let me 
comment on a few points:

> [ Dan Nesset's message of "Tue, 27 Feb 1996 08:13:53 PST."      <199602271613.IAA18839@elrond.Eng.Sun.COM> ]

> To the members of the IPSEC working group,
> 
> I am no longer active in this group, having moved on to other duties. However,
> based on prior interactions with Mr. Simpson, I fully support the move by
> Paul Lambert to attempt to bring order into the working group proceedings.

So you are admitting that you do not know the particulars of this case, and 
that your reasons for wanting Mr. Simpson silenced are personal, not based on 
the technical merits of his work. Wonderful!

> As evidence I hereby make public a post Mr. Simpson sent to me in regards
> to in-band keying. I have retained a record of the prior email on this

Maybe my mailer ate it, but there is no date on that message. How recent is 
it? If it upset you so much, why didn't you bring it to the immediate 
attention of the group? Elementary good manners dictate that you do not make 
public a private piece of email without the author's consent. Is *your* proper 
behavior a function of other people's behavior? And in any case, I don't see a 
PGP (or other) signature. For all we know, you fabricated this.

> topic, which I believe shows Mr. Simpson had no reason to adopt an insulting
> and scurrilous writing style. 

I read the piece of mail. I cannot tell from it whether Mr. Simpson had a 
reason to adopt what you are calling "insulting and scurrilous." What I see is 
that you are making public a private piece of e-mail, an act which I (and many 
others, for that matter) consider unethical.


>                               It is interesting that Mr. Simpson's defender
> in this controversy is Mr. Metzger.

Your point being? You seem to be implying that there is something wrong about 
being defended by Mr. Metzger. Whatever your personal animosity towards Mr. 
Metzger may be, the fact that he is defending Mr. Simpson does not ipso facto 
imply that the defense should be considered invalid. 

> 
> Dan Nessett
> 

/ji

Xref subject previous
Xref subject next

>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.

That strikes me as the wrong thing to do.  Send the data, along with the
expired signature.  What's expired is the signature, not the data.  This
constitutes my first and only objection to DNSSEC, but since Edie had to
point it out to me, I'm not going to lodge it formally (I had my chance.)
-- 
Paul Vixie
La Honda, CA			"Illegitimibus non carborundum."

pacbell!vixie!paul

Xref subject previous
Xref subject next

On Wed, 28 Feb 1996, John Ioannidis wrote:

> I find this entire debate to be a *personal* attack on Bill Simpson, and not 
> an attack on his work based on its technical merits. This is simply 
> unacceptable. I urge everybody involved to calm down and re-evaluate their 
> positions.
> 
Right on target JI, and I fully agree with you

Antonio

Xref subject previous
Xref subject next

John,

        Let me add my support to Paul's censure of Bill, from the
perspective of someone who has been involved with the IPSEC WG from the
beginning, who has attended a number (though not all) of the Wg meetings,
and who reads most of the mail list traffic.  I dislike censuring in this
context, but I have to admit that Bill's actions in this WG have created a
situation that merits such action.

        Bill's interaction with people via email is almost always very rude
and intimidating.  I have been the target of some of Bill's tirades in
various contexts and have watched him "flame" many others on this and other
mailing lists.  This behavior has had a chilling effect on some people,
causing them to contribute less than they might otherwise.  The result is
detrimental to the advancement of work in any area and I think we have seen
the effects of that in this WG.  Several individuals have approached me
over the last couple of years and noted that they were deterred from
participating in mailing list exchanges becaue of the likelihood of rousing
Bill's ire.

        In another vein, Bill's work as a document editor has been a mixed
blessing.  The IETF relies on voulenteers to do the real work of standards
production and Bill's offer to write a document contributing to that work
is laudable.  However, the work of this group has suffered from very poor
documents in general and several members have cited Bill's documentation of
Photuris as an example of specification that does not facilitate
independent interoperable implementation.  Your individual experience to
the contrary, this complaint about Bill's writing still stands.  Moreover,
Bill's reluctance to make changes to documents based on direction from the
WG chairs raises serious questions as to his suitability as an editor for a
document of this sort.

        You suggest that personal animosity has no place in a technical
group such as this one, yet it is precisely Bill's personal attacks on
individuals that have caused the animosity and resulted in his censure.
Any standards activity is a social activity involving individuals with
differing technical and personal agendas.   A successful WG must integrate
these agendas to produce a documents that represent appropriate tradeoffs
arrived at via a technical and social process.  Bill's behavior has skewed
this process and this response from the WG chair is a response to this
behavior.

Steve

Xref subject previous
Xref subject next

Jim,

> I don't think a revamp/remove/redesign is necessary.  At least, a scenario
> where there's a conflict is not immediately obvious to me.  It would help
> me if someone who may be more knowledgeable about dynamic update could
> identify one.

Dynamic update doesn't need expiration.  I don't think there's a
problem there.

> The expiration in the SIG RR indicate when the SIG expires.  A SIG RR
> covers a particular type of other RR.  When the SIG expires the RRs are to
> be removed from the DNS.
>
> The expiration in the EXP RR covers a particular type of other RR.  When
> that time is reached the RRs are to be removed from the DNS.
>
> In either case, when the expiration time is reached the data is to be
> considered unavailable and removed from the DNS.  I'm at a loss to identify
> a time when I would want either the signature or the expiration to remain
> valid when the other has been reached.

What you've described here sounds reasonable. My original complaint
(over in namedroppers) against the EXPIRE RR, which got lost in all
the hubbub over NULL SIGs, was that if there were two ways for RR's to
be expired, how would the server decide which expiration time would win?
As a user, I don't want to go to the trouble to set up an EXPIRE RR
only to have a SIG expire earlier wiping out my data before I wanted
it to go. I'll need to know to set them both the same. ??  (An
implementation detail is how to resolve this with an offline zone
signing procedure.)

My other complaint (which also got lost in the fray) was against
having two different ways of treating the expired RR's.  DNSSEC says
when the SIG expires, the RR's are gone.  The EXPIRE spec suggests
that they may stay around and be used in dynamic update processing.
If the two different ways of treating expired data were allowed,
then this raises lots of questions.  If the EXPIRE time arrives
before the SIG time in secure DNS, then are the EXPIRE rules used
in handling the expired RRs?  And vice versa if the SIG time arrives
first?  If EXPIRE RRs are used in unsecure DNS, would we see
different results for the same database, same update, as in a
secure DNS?  It seems to me if there are 2 ways to expire data,
then what happens to that expired data should be the same using
either method of expiration.

Someone suggested that the EXPIRE RR would only be used in
unsecure DNS.  I haven't seen anything from the DNSSEC folks
to indicate it would be disallowed in secure DNS, however.

What I thought you (or was it someone else?) were suggesting in
earlier mail where it was mentioned having DNSSEC use an EXPIRE RR,
was that you would do something like remove the expiration time from
the SIG and *require* an EXPIRE RR for every SIG.  Then, the time
in the EXPIRE RR would indicate when the SIG would expire (of course,
since an EXPIRE covers an RR type I don't know if this would work.)
And then maybe DNSSEC would require EXPIRE RRs for the RRs the
SIG covers and it would require that those expiration times be
set the same as for the SIG.  Of course, this would all be
handled by software so managing it would not be a big deal.
It would, however, make the zone files much larger with all
these extra RR's.  That's the kind of redesign I thought was being
suggested.  Obviously, I misunderstood.  Now, I really don't
know what was meant by hinting DNSSEC could use the EXPIRE RR.

Sorry to be so longwinded...

Edie

Xref subject previous
Xref subject next


>  
>  So you are admitting that you do not know the particulars of this case, and 
>  that your reasons for wanting Mr. Simpson silenced are personal, not based on 
>  the technical merits of his work. Wonderful!

I believe my post was significant evidence that I do know the particulars of
this case. The censure of Mr. Simpson has nothing to do with the technical
merits of his work. It addresses his unacceptible behavior in the conduct
of IETF work.

>  > As evidence I hereby make public a post Mr. Simpson sent to me in regards
>  > to in-band keying. I have retained a record of the prior email on this
>  
>  Maybe my mailer ate it, but there is no date on that message. How recent is 
>  it? If it upset you so much, why didn't you bring it to the immediate 
>  attention of the group? Elementary good manners dictate that you do not make 
>  public a private piece of email without the author's consent. Is *your* proper 
>  behavior a function of other people's behavior? And in any case, I don't see a 
>  PGP (or other) signature. For all we know, you fabricated this.

Let me address your points in order. There was a date on the message, it was
Wed Mar 15 06:25:01 1995. I brought it to the attention of the IESG at the
time. If someone writes me a letter threating my life or the well being of my
family, I have no obligation to keep it private. In the same vein, if
someone is employing terrorist tactics to ensure his point of view prevails,
I have no obligation to keep these tactics private. For all you know the
complete record of this working group email list is fabricated. You don't
even know if Dan Nessett sent this message.

>  > topic, which I believe shows Mr. Simpson had no reason to adopt an insulting
>  > and scurrilous writing style. 
>  
>  I read the piece of mail. I cannot tell from it whether Mr. Simpson had a 
>  reason to adopt what you are calling "insulting and scurrilous." What I see is 
>  that you are making public a private piece of e-mail, an act which I (and many 
>  others, for that matter) consider unethical.

In regards to the ethics of divulging mail sent to me privately, see above.
If you believe there are any circumstances in which the writing style of
the message in question is excusable, then we have no basis for a continued
exploration of this topic.

>  
>  >                               It is interesting that Mr. Simpson's defender
>  > in this controversy is Mr. Metzger.
>  
>  Your point being? You seem to be implying that there is something wrong about 
>  being defended by Mr. Metzger. Whatever your personal animosity towards Mr. 
>  Metzger may be, the fact that he is defending Mr. Simpson does not ipso facto 
>  imply that the defense should be considered invalid. 
>  

The point is that Mr. Metzger's defense of Mr. Simpson may be biased. The
evidence for this is the statement by Mr. Simpson that "He's just trying to
piggyback on our work."

Dan Nessett

Xref subject previous
Xref subject next

In message <199602281605.IAA20108@elrond.Eng.Sun.COM>, Dan Nessett writes:
>
>I believe my post was significant evidence that I do know the particulars of
>this case. The censure of Mr. Simpson has nothing to do with the technical
>merits of his work. It addresses his unacceptible behavior in the conduct
>of IETF work.
>
Speaking for myself, the exerpt you sent didn't prove anything about your
knowledge of the case.

>Let me address your points in order. There was a date on the message, it was
>Wed Mar 15 06:25:01 1995. I brought it to the attention of the IESG at the
>time. If someone writes me a letter threating my life or the well being of my
>family, I have no obligation to keep it private. In the same vein, if
>someone is employing terrorist tactics to ensure his point of view prevails,
>I have no obligation to keep these tactics private. For all you know the
>complete record of this working group email list is fabricated. You don't
>even know if Dan Nessett sent this message.
>
Sending in public private communications without asking permission first sounds
like "terrorist" tactics to me.

>In regards to the ethics of divulging mail sent to me privately, see above.
>If you believe there are any circumstances in which the writing style of
>the message in question is excusable, then we have no basis for a continued
>exploration of this topic.
>
A lot can be said on this, but let's not open a can of worms.

>The point is that Mr. Metzger's defense of Mr. Simpson may be biased. The
>evidence for this is the statement by Mr. Simpson that "He's just trying to
>piggyback on our work."
>
Biased ? I guess cooperating with Mr. Simpson might make someone object to
another's views that it's impossible to work with him.

Again, this seems more like a personal attack than a well thought
action of a WG chair.
-Angelos

Xref subject previous
Xref subject next


Stephen Kent writes:
> The IETF relies on voulenteers to do the real work of standards
> production and Bill's offer to write a document contributing to that work
> is laudable.  However, the work of this group has suffered from very poor
> documents in general and several members have cited Bill's documentation of
> Photuris as an example of specification that does not facilitate
> independent interoperable implementation.  Your individual experience to
> the contrary, this complaint about Bill's writing still stands.

Are we angry with Bill for being rude, or are we angry with him
because he is a poor writer? I would hate to think that one could be
censured for being a poor writer. I will add, however, that in my
opinion Bill is a very good writer from an implementors perspective.


Perry

Xref subject previous

In message <199602282054.PAA16286@jekyll.piermont.com>, "Perry E. Metzger" writ
es:
>
>Are we angry with Bill for being rude, or are we angry with him
>because he is a poor writer? I would hate to think that one could be
>censured for being a poor writer. I will add, however, that in my
>opinion Bill is a very good writer from an implementors perspective.
>
I might add here that Bill has asked me a few (hundred) times if this part
of the Photuris draft is clear enough, or if that part needs refining. He
sent me a copy of the last 2 (or 3?) drafts a few days before they were
publically available, to check for errors - and i wasn't the only one.
-Angelos

Xref subject previous


smb@research.att.com writes:
> Count me as a supporter of sensitivity labels.

Me too. Sensitivity labels must be an attribute of a security association.

IEEE 802.10c already supports sensitivity labels.  ;)

Russ

Xref subject next

Ref:  Your note of Mon, 26 Feb 96 20:34:35 GMT (attached)

I suggest NOT moving forward RFC1828.

Let's replace that transform by the keyed-MD5 transform
of Bellare, Canetti and Krawczyk,
as described in draft-krawczyk-keyed-md5-01.txt.
(This function is now named HMAC).

This new transform has a strong cryptographic analysis supporting it.
The paper showing that (see below) has been presented in several
public forums (including RSA conference and MIT's crypto seminar),
and has been widely circulated to cryptographers and security experts in
the last two months. The feedback has been overwhelming positive
(no one objection to its security or analysis).

The proposal was warmly welcome in general when I presented it in Dallas'
IETF (only the authors of RFC1828 objected). It was in the meantime adopted
into a few other protocols. I know of two independent implementations for
use with IPSEC/AH.

I believe it has all the merits and formal requirements to become an RFC
and the DEFAULT transform for AH.

I would like this WG to make a decision in that regard.

Sincereley and unpolitically (;-)

Hugo

PS: for those who still didn't read the paper :-)

Bellare, M., Canetti, R., and Krawczyk, H., "Keyed Hash Functions and
Message Authentication".
http://www.research.ibm.com/security/keyed-md5.html

Clarification: the name HMAC as used in the paper does not appear
in the internet draft draft-krawczyk-keyed-md5-01.txt. However, the described
function is the same.

Xref subject previous
Xref subject next


hugo@watson.ibm.com writes:
> Ref:  Your note of Mon, 26 Feb 96 20:34:35 GMT (attached)
> 
> I suggest NOT moving forward RFC1828.
> 
> Let's replace that transform by the keyed-MD5 transform
> of Bellare, Canetti and Krawczyk,
> as described in draft-krawczyk-keyed-md5-01.txt.
> (This function is now named HMAC).

I have no problem with the idea of ultimately advancing the HMAC
transform to standard, especially after it has been out for a good
while and there has been additional opportunity for cryptographers to
attack it, but I disagree with the words "replace". As Paul's survey
reveals, many implementations currently implement 1828. Let us instead
speak of requiring this new superior transform rather than of
"replacing" the old one, which would imply, for example, that
identifiers for 1828 in key management protocols would have to point
at HMAC instead, which would result in interoperability problems.

Perry

Xref subject previous
Xref subject next


 
>but I disagree with the words "replace". As Paul's survey 
>reveals, many implementations currently implement 1828. 
 
There has been very strong support for the use of HMAC as the "standard" 
transform for AH.  A "change" of this mechanism sooner, rather than later, 
would limit the impact on implementors. 
 
 
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 
-------------------------------------------------------------- 
  

Xref subject previous
Xref subject next

Ref:  Your note of Thu, 29 Feb 1996 16:09:19 -0500 (attached)

Perry,

 >
 > I have no problem with the idea of ultimately advancing the HMAC
 > transform to standard, especially after it has been out for a good
 > while and there has been additional opportunity for cryptographers to
 > attack it, but I disagree with the words "replace". As Paul's survey
 > reveals, many implementations currently implement 1828. Let us instead
 > speak of requiring this new superior transform rather than of
 > "replacing" the old one, which would imply, for example, that
 > identifiers for 1828 in key management protocols would have to point
 > at HMAC instead, which would result in interoperability problems.

What I want is that implementations *do* move to this new function.
We are doing a lot of implementation work regarding IPSEC, and we talk
to many other implementation people involved with IPSEC.
The message is very clear: no one has any real problem to implement the
new transform, however they will not do that as long as there is another
one that is *officially* required by the IPSEC standard.

We need to find a way to break this loop. I don't care about the word
"replace" just about making clear that IPSEC-AH REQUIRES HMAC
(as the default implementation).

As a general note: if we can't modify the standards during the
standarization process why do we have that process in place.
Implementors need to know (and we know!) that changes will occur.
This particular one is easy to implement and upgrade.

If the decision is that it is too late to change the default algorithm
I would recommend this group to be even more careful on any decision about
moving any document to standards track.

Hugo

We are please to announce that the first Beta release of
TIS/DNSSEC is now available.  This version is a implementation
of the current DNSSEC draft and it is based on bind-4.9.3-REL,
it uses RSAREF, but you need to retrieve a copy from RSA.

We are actively seeking beta testers. 

We are also pleased to announce the FIRST secure zone,
sd-bogus.tis.com which is served from uranus.tis.com.

We are also making a DNSSEC enhanced version of DIG available,
in executable form for popular platforms. This version of dig is
extended to query sd-bogus and other secure servers.  There are
no export restrictions on the executables

For information on how to acquire TIS/DNSSEC retrieve the file
/pub/DNSSEC/README on the host ftp.tis.com via anonymous FTP,
for further instruction on how the get the TIS/DNSSEC
distribution.

The new dig a sunos4.x executable versions are 
	ftp:/ftp.tis.com/pub/DNSSEC/sdig.sunos4.gz 
Other versions will be made available as 
	ftp:/ftp.tis.com/pub/DNSSEC/sdig..gz 

If you have any questions or problems please send a note to
tisdnssec-support@tis.com.

If you compile the new dig on a popular platform that we do not have 
an executable for please let us know. 

Enjoy,

Olafur

Xref subject previous
Xref subject next


hugo@watson.ibm.com writes:
> We need to find a way to break this loop. I don't care about the word
> "replace" just about making clear that IPSEC-AH REQUIRES HMAC
> (as the default implementation).

Thats fine, so long as we don't speak of "replacing", and so long as
we take some time to allow people to examine the transform. I would
want to see some considerable time taken between the time that an HMAC
based RFC is issued and the time it is advanced. No personal slight
intended, Hugo, but I've learned at this point that the only way to
get certainty out of cryptographers is to wait a year or two for the
dust to settle thoroughly. I fully believe your statements that no one
who has seen your work has had any trouble with it, but recall that
similar statements were made the last time around -- it would be
better if we gave it some time. This isn't to say we should advance
something else in its place, you understand. It is just to say we
should be more carefull.

> As a general note: if we can't modify the standards during the
> standarization process why do we have that process in place.

We can alter what is standard. However, it is often bad to alter what
already exists. When SMTP got revised, an extensions mechanism was
created -- existing SMTPs weren't broken. Sometime soon it will be
required that SMTP implementations support ESMTP, but it will
doubtless be a long while before ESMTP is totally universal, if
ever.

Perry

Xref subject previous
Xref subject next

In message <199602292133.QAA26653@relay.tis.com>, you write:
>What I want is that implementations *do* move to this new function.
>We are doing a lot of implementation work regarding IPSEC, and we talk
>to many other implementation people involved with IPSEC.
>The message is very clear: no one has any real problem to implement the
>new transform, however they will not do that as long as there is another
>one that is *officially* required by the IPSEC standard.

	What is the patent status of this MAC function?

	(I don't think anyone would want to have an "oh, by the way" patent
problem)

								-Craig

Xref subject previous
Xref subject next

Ref:  Your note of Thu, 29 Feb 1996 18:16:57 -0500 (attached)


 > From: Craig Metz 
 >
 > In message <199602292133.QAA26653@relay.tis.com>, you write:
 > >What I want is that implementations *do* move to this new function.
 > >We are doing a lot of implementation work regarding IPSEC, and we talk
 > >to many other implementation people involved with IPSEC.
 > >The message is very clear: no one has any real problem to implement the
 > >new transform, however they will not do that as long as there is another
 > >one that is *officially* required by the IPSEC standard.
 >
 > 	What is the patent status of this MAC function?
 >
 > 	(I don't think anyone would want to have an "oh, by the way" patent
 > problem)
 >
 > 								-Craig

Thanks for asking. This construction has NOT been patented.
(I made this statement clear during the Dallas' IETF).

It is as free as any other keyed hash function (we heard in Dallas IETF
-- see minutes -- that Novel may have a patent on keyed hash functions
in general. I do not know any details or what the status of that is).

Hugo

Xref subject next

The last thing I feel like doing is stepping into the war over 1828, however I
do have a technical concern with regard to the specification of a compliant
implementation.  I apologise for missing the last call on this document, at
the time I was not involved in this area of standards.  This is purely a
technical clarification, I make no judgements about the appropriateness of the
protocol.

My issue is entirely based upon what I consider to be an inadequate
specification of the padding of the initial key.  To my "trained" implementors
eye, it's not at all clear from the RFC, and in fact, I had to speak to
someone who implemented it correctly at the bake-off who received additional
information from Bill.  (read: I looked at the NRL code)

The RFC does not mis-specify the method of padding, merely it specifies it
inadequately.  Given that with the additional information, the compliant
implementation became obvious, I would request the that the working group
insure the clarity of future revisions of 1828.

I think some simple pseudo-code would be enough, as long as the "revision" to
the RFC1323 MD5Final routine was *strongly* noted.

Given that the group seems to be in a war about 1828 and other recently
released drafts,  now is as good a time as any to nail down some technical
details.

Sigh,

Paul

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

Details:

My inadequate interpretation of 1828 caused the following code to be written
(the MD5 routines are the canonical ones from 1323):

/*
 * md5_rfc1828
 *
 * User-friendly way to compute keyed MD5 authentication information for
 * a chunk of data.
 *
 * Call it like this:
 *
 * char hash[MD5_LEN];
 * md5_rfc1828(message, msglength, key, strlen(key), hash, sizeof(hash));
 */

#define	FILL_LEN 64	/* 512 bit boundaries for fill */
#define	MOD_LEN	 56	/* pad key to bit 448 modulo 512 */

boolean
md5_rfc1828 (void *data,    int datalen,
	     char *key,     int keylen,
	     uchar *digest, int digestlen)
{
	static uchar padding[FILL_LEN] = { 0x80, 0 };

	MD5_CTX context;
	int padlen;

	if (digestlen < MD5_LEN)
	    return FALSE;

	padlen = keylen % FILL_LEN;
	padlen = padlen < MOD_LEN ? MOD_LEN - padlen
				  : (FILL_LEN+MOD_LEN) - padlen;

	MD5Init(&context);
	MD5Update(&context, key, keylen);
	MD5Update(&context, padding, padlen);
	MD5Update(&context, data, datalen);
	MD5Update(&context, key, keylen);
	MD5Final(digest, &context);

	return TRUE;
}

whereas the correct implementation would be:

boolean
md5_rfc1828 (void *data,    int datalen,
	     char *key,     int keylen,
	     uchar *digest, int digestlen)
{
	MD5_CTX context;

	if (digestlen < MD5_LEN)
	    return FALSE;

	MD5Init(&context);
	MD5Update(&context, key, keylen);
	RFC_1828_MD5Final(NULL, &context); /* do padding according to 1828 */

	MD5Update(&context, data, datalen);
	MD5Update(&context, key, keylen);
	MD5Final(digest, &context);

	return TRUE;
}

void
RFC_1828_MD5Final (unsigned char *digest,	/* message digest */
		   MD5_CTX *context)		/* context */
{
    unsigned char   bits[8];
    unsigned int    index, padLen;

    /* Save number of bits */
    Encode(bits, context->count, 8);

    /*
     * Pad out to 56 mod 64.
     */
    index = (unsigned int) ((context->count[0] >> 3) & 0x3f);
    padLen = (index < 56) ? (56 - index) : (120 - index);
    MD5Update(context, PADDING, padLen);

    /* Append length (before padding) */
    MD5Update(context, bits, 8);

|   if (digest) {		/* change to allow RFC1828 padding */
|	/* Store state in digest */
|	Encode(digest, context->state, 16);
|
|	/*
|	 * Zeroize sensitive information.
|	 */
|	MD5_memset((POINTER) context, 0, sizeof(*context));
|   }

}

Xref subject previous
Xref subject next

Ref:  Your note of Thu, 29 Feb 1996 16:54:52 -0500 (attached)

There is so much traffic in this list these days and I hate contributing
more but this may interest other people in addition to Perry.

Perry writes:

 > hugo@watson.ibm.com writes:
 > > We need to find a way to break this loop. I don't care about the word
 > > "replace" just about making clear that IPSEC-AH REQUIRES HMAC
 > > (as the default implementation).
 >
 > Thats fine, so long as we don't speak of "replacing", and so long as
 > we take some time to allow people to examine the transform. I would
 > want to see some considerable time taken between the time that an HMAC
 > based RFC is issued and the time it is advanced. No personal slight
 > intended, Hugo, but I've learned at this point that the only way to
 > get certainty out of cryptographers is to wait a year or two for the
 > dust to settle thoroughly. I fully believe your statements that no one

Waiting 1-2 years is unrealistic for IETF proposals.
However, I wish there was a more orderly scrutiny of security designs
for IETF protocols by cryptographers.

Photuris is a good example. It took me 6 drafts (from 03 to 09)
to convince Simpson to derive *independent* key bits for keyed-MD5 and DES.
Photuris still directly signs secret information which is a clearly wrong
cryptographic practice. Photuris confuses between MAC keys and data.
It does not handle key refreshment in a satisfactory way. It uses
unconstrained strings like SPI's as nonces, and incurs in some other
cryptographic sins. I didn't see where is the cryptographic community
that is inspecting this design.
It is actually very hard for cryptographers that are not directly involved
with this work to analyze these protocols in the implementation-oriented way
that they are written. They should be accompanied by a clear protocol
describing the basic flows and cryptographic rationale. But they are not.

What we did with HMAC is far more sound cryptographicaly as well as
for analysis, for presentation, and for exposure to cryptographers.

Moreover, notice that we have very clear proofs of security. That means that
there are no heuristics involved in the MAC construction except the minimal
and unavoidable assumptions that you need from MD5 (or your favorite
hash function). I wish I could always come with such strong arguments
for other cryptographic construction that I propose or use.

 > > As a general note: if we can't modify the standards during the
 > > standarization process why do we have that process in place.
 >
 > We can alter what is standard. However, it is often bad to alter what
 > already exists. When SMTP got revised, an extensions mechanism was
 > created -- existing SMTPs weren't broken. Sometime soon it will be
 > required that SMTP implementations support ESMTP, but it will
 > doubtless be a long while before ESMTP is totally universal, if
 > ever.

I repeat this very clearly. In my opinion (and I hope people will agree
and even say it ;-) NOW is the time to move to the new transform,
and, if possible, forget about the previous one.
Having two around will only create confusion and interoperability problems.


Hugo

Xref subject previous
Xref subject next

	 hugo@watson.ibm.com writes:
	 > We need to find a way to break this loop. I don't care about the wor
	d
	 > "replace" just about making clear that IPSEC-AH REQUIRES HMAC
	 > (as the default implementation).

	 Thats fine, so long as we don't speak of "replacing", and so long as
	 we take some time to allow people to examine the transform. I would
	 want to see some considerable time taken between the time that an HMAC
	 based RFC is issued and the time it is advanced. No personal slight
	 intended, Hugo, but I've learned at this point that the only way to
	 get certainty out of cryptographers is to wait a year or two for the
	 dust to settle thoroughly. I fully believe your statements that no one
	 who has seen your work has had any trouble with it, but recall that
	 similar statements were made the last time around -- it would be
	 better if we gave it some time. This isn't to say we should advance
	 something else in its place, you understand. It is just to say we
	 should be more carefull.

Of course, all along the unanimous opinion of the cryptographic theoreticians
has been that keyed hash functions were an unknown -- they weren't designed
to do that, and it wasn't clear that they were secure in this mode.  But
we went ahead anyway.

	 > As a general note: if we can't modify the standards during the
	 > standarization process why do we have that process in place.

	 We can alter what is standard. However, it is often bad to alter what
	 already exists. When SMTP got revised, an extensions mechanism was
	 created -- existing SMTPs weren't broken. Sometime soon it will be
	 required that SMTP implementations support ESMTP, but it will
	 doubtless be a long while before ESMTP is totally universal, if
	 ever.

Right.  And if ESMTP had been proposed way back when, before RFC821 was
officially blessed, it would have been a different matter.  If we're going
to change it, now is the time.  We should certainly use a different transform
number for HMAC, to make the transition easier, but we should have only
one full standard.

RFC1828 is a ``Proposed Standard''.  Let me quote from RFC1880, the current
instantiation of STD 1:

   4.1.3.  Proposed Standard Protocol

      These are protocol proposals that may be considered by the IESG
      for standardization in the future.  Implementation and testing by
      several groups is desirable.  Revision of the protocol
      specification is likely.

Note carefully:  revision is *likely*.  If we're going to change it, now is
the time -- after it goes to Draft, it's too late for fixes of this nature
(absent, say, the discovery of a feasible attack).

Xref subject previous
Xref subject next


"PALAMBER.US.ORACLE.COM" writes:
> >but I disagree with the words "replace". As Paul's survey 
> >reveals, many implementations currently implement 1828. 
>  
> There has been very strong support for the use of HMAC as the "standard" 
> transform for AH.  A "change" of this mechanism sooner, rather than later, 
> would limit the impact on implementors. 

Fine, but that doesn't necessarily mean "replace".

Perry

Xref subject previous

Paul Traina  writes:
> My issue is entirely based upon what I consider to be an inadequate
> specification of the padding of the initial key.
[...]
> The RFC does not mis-specify the method of padding, merely it specifies it
> inadequately.
[..]
> I think some simple pseudo-code would be enough, as long as the "revision"
> to the RFC1323 MD5Final routine was *strongly* noted.

(I went digging through a stack of papers before I realized you meant 1321 :)

OK, so essentially you seem to be suggesting a clarification (in the RFC) of
the following phrasing in Section 2 of 1828:

	"First, the variable length secret authentication key is filled
	to the next 512-bit boundary, using the same pad with length
	technique defined for MD5."

How about rephrasing it as:

	"...512-bit boundary, using the padding technique defined in 
	subsections 3.1 and 3.2 of the MD5 specification [RFC-1321]."

I think that makes the method clear, since the relevant parts of MD5Final
are conveniently separately numbered in 1321. Would pseudo-code still be
preferable in addition to (or instead of) rephrasing like this ?


Just to add fuel to the fire, I think the discussion of key length in 1828, 
subsection 1.1, could stand slight revision. In particular, I think the
last sentence

	"Longer keys are encouraged."

is ambiguous. Certainly, longer keys up to 128 bits in length should be 
encouraged versus shorter keys. But as I understand things, the security of 
this envelope construction is not increased by using a key with more than
128 bits of entropy, since MD5 only generates a 128-bit hash. (This is
already reflected to some extent in the 1828 Security Considerations section,
where the van Oorschot/Wiener MD5 supercollider is discussed.) If the key is 
only pseudorandom, however, then length(key) > 128 may be desirable to ensure 
at least 128 bits of entropy are present. 

The Security Considerations section already notes that the specification's 
security depends on the strength of MD5 and "the strength of the key". I am 
proposing a more explicit acknowledgement that keys longer than 128 bits are
only helpful under certain assumptions about their non-randomness, as a
result of the other two considerations.

-Lewis	 (until mid-May)

Xref subject previous
Xref subject next

In message <199602291926.OAA24213@relay.tis.com>, hugo@watson.ibm.com writes:
>I suggest NOT moving forward RFC1828.
>
>Let's replace that transform by the keyed-MD5 transform
>of Bellare, Canetti and Krawczyk,
>as described in draft-krawczyk-keyed-md5-01.txt.
>(This function is now named HMAC).

I, for one, agree; this transform seems better than the one we
currently have.
-Angelos

Xref subject previous
Xref subject next

At 13:36 29.2.96 -0800, you wrote:

>There has been very strong support for the use of HMAC as the "standard" 
>transform for AH.  A "change" of this mechanism sooner, rather than later, 
>would limit the impact on implementors. 

From an implementors standpoint, I fully agree. Now is the easiest time to
change the algorithm employed. Later will be harder, as implementations will
tend to proliferate. So this forum 'simply' needs to make up its mind if
it's appropriate to change from 'keyed MD5' to a new transform. 
HMAC certainly is not weaker than keyed MD5, and strong indications exist
that it is indeed stronger, so I for one would prefer to have HMAC in the RFC.

Germano

Xref subject previous
Xref subject next

Perry E. Metzger writes:
> > There has been very strong support for the use of HMAC as the "standard"
> > transform for AH.  A "change" of this mechanism sooner, rather than later,
> > would limit the impact on implementors.
> 
> Fine, but that doesn't necessarily mean "replace".

In light of what has already been said, I *strongly suggest* that
HMAC should *replace* the current MAC, with, as Steve proposes, a
different transform number. And it has to be done NOW.
-- 
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-

Xref subject previous
Xref subject next


hugo@watson.ibm.com writes:
> Waiting 1-2 years is unrealistic for IETF proposals.

Its not unrealistic to wait that long to advance to a high level
provided that the proposal is made into an RFC and a proposed standard
first so that people know it is standards track.

> However, I wish there was a more orderly scrutiny of security designs
> for IETF protocols by cryptographers.

The process is sometimes chaotic. However, it does, in the end,
usually work.

Perry

Xref subject previous
Xref subject next

Ref:  Your note of Fri, 01 Mar 1996 10:04:39 -0500 (attached)


 >
 > > However, I wish there was a more orderly scrutiny of security designs
 > > for IETF protocols by cryptographers.
 >
 > The process is sometimes chaotic. However, it does, in the end,
 > usually work.

Right. It works in 95% of the cases.
Security is exactly about the remaining 5%.

Hugo

 >
 > Perry

Xref subject next


Just to be clear, what I am proposing on HMAC is this:

1) We leave 1828 alone. We do not advance it further but we do not
   "replace" it, meaning new RFCs do NOT "supersede" it in the way a
   replacement would.
2) We publish an RFC as a proposed standard for HMAC.
3) We think of the HMAC transform not as a replacement for the
   existing transforms but as a new transform. Any key negotiation
   protocols that exist do not replace the meaning of "use the 1828
   transform" with using HMAC -- they think of HMAC as a new
   transform. I do not want the new RFC to "supersede" 1828 as a
   replacement RFC would. One of the reasons I'm strongly opinioned on
   this is that I expect this situation will occur over and over in
   the next decade -- we will discover something and want to replace
   what people are using. Right now we can fail to advance 1828 as
   part of this process, but in general what we are doing is creating
   NEW transforms, not REPLACING old ones. The new transforms are then
   encouraged to be "must implement".
4) We leave the HMAC RFC at proposed standard long enough for the crypto
   community to really get its teeth in. Being at proposed should be
   sufficient to encourage vendors to implement. I know Hugo would
   probably like it to advance to draft standard more quickly, but my
   gut instinct says "wait". Proofs are good, I fully believe Hugo is
   a good crypto guy and that his proofs are excellent, but this is
   engineering at this point, not math. Proposed standard should be
   sufficient for a while.
5) If we desire, we may issue a document clarifying 1828 for
   historical reasons, but we do this as an informational RFC.

Perry

Xref subject previous
Xref subject next

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

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

   Just to be clear, what I am proposing on HMAC is this:
   
   1) We leave 1828 alone. We do not advance it further but we do not
      "replace" it, meaning new RFCs do NOT "supersede" it in the way a
      replacement would.

Agreed, but see the comments to #5

   3) We think of the HMAC transform not as a replacement for the
      existing transforms but as a new transform. Any key negotiation
      protocols that exist do not replace the meaning of "use the 1828
      transform" with using HMAC -- they think of HMAC as a new
      transform. I do not want the new RFC to "supersede" 1828 as a
      replacement RFC would. 

This points out a weakness in the current IPSEC document structure.

Each key management method (ISAKMP, Photuris, SKIP, manual) has to
solve the exact same problem of "how do I name the transforms".  
The author of a new transform needs to allocate separate transform
id's for each different key management protocol.

If there was a common algorithm-id spec defined by the transform-level
architecture, the work needed to define new transforms and hook them
into the key management infrastructure would be somewhat simplified.

[I'd suggest starting with SKIP's algorithm id's because early
versions of SKIP have actually been deployed, but it looks to me that
the way SKIP handles algorithm id's makes handling combined
encryption/MAC/...  transforms messy.]

      One of the reasons I'm strongly opinioned on
      this is that I expect this situation will occur over and over in
      the next decade -- we will discover something and want to replace
      what people are using. Right now we can fail to advance 1828 as
      part of this process, but in general what we are doing is creating
      NEW transforms, not REPLACING old ones. The new transforms are then
      encouraged to be "must implement".

I'm in violent agreement with this..

   4) We leave the HMAC RFC at proposed standard long enough for the crypto
      community to really get its teeth in. Being at proposed should be
      sufficient to encourage vendors to implement. I know Hugo would
      probably like it to advance to draft standard more quickly, but my
      gut instinct says "wait". Proofs are good, I fully believe Hugo is
      a good crypto guy and that his proofs are excellent, but this is
      engineering at this point, not math. Proposed standard should be
      sufficient for a while.
   5) If we desire, we may issue a document clarifying 1828 for
      historical reasons, but we do this as an informational RFC.

Instead, why not:

	(a) in the HMAC draft suggest that implementors implement
	HMAC-MD5 (or whatever it's called) in addition to 1828

	(b) have the IESG relabel 1828 as "historic" when HMAC goes to
	PS or DS...

						- Bill




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

iQCVAwUBMTcyQVpj/0M1dMJ/AQEdfgP+K8VcZziZ6NUYyGy6GaL3/KtLvOV/Q7zV
WvzHPX77weOh6G2qvaQRmmDU15mih+U1mwEl7FZ/c5ZR2n+XFxL6t4tXiDRugX3G
U/PEXtoswpEZUshZ4L7cg6TVqox4U+xV+W3nmJLsBBoL+OZu5Tlt0K49iWE2pmm0
1dhBmEnacIY=
=Npz1
-----END PGP SIGNATURE-----

Xref subject previous
Xref subject next


hugo@watson.ibm.com writes:
>  > > However, I wish there was a more orderly scrutiny of security designs
>  > > for IETF protocols by cryptographers.
>  >
>  > The process is sometimes chaotic. However, it does, in the end,
>  > usually work.
> 
> Right. It works in 95% of the cases.
> Security is exactly about the remaining 5%.

I realize the process may seem like a problem to those who normally
work alone on a problem and then proceed to give a document to a set
of reviewers for orderly review, but it really isn't. Perhaps we need
to use some better tools (a trouble ticket system? I'm not joking) to
give people better confidence that edits aren't being dropped on the
floor, but the process *does* work in the end, even now.

Perry

Xref subject previous
Xref subject next

	 Just to be clear, what I am proposing on HMAC is this:

	 1) We leave 1828 alone. We do not advance it further but we do not
	    "replace" it, meaning new RFCs do NOT "supersede" it in the way a
	    replacement would.
	 2) We publish an RFC as a proposed standard for HMAC.
	 3) We think of the HMAC transform not as a replacement for the
	    existing transforms but as a new transform. Any key negotiation
	    protocols that exist do not replace the meaning of "use the 1828
	    transform" with using HMAC -- they think of HMAC as a new
	    transform. I do not want the new RFC to "supersede" 1828 as a
	    replacement RFC would. One of the reasons I'm strongly opinioned on
	    this is that I expect this situation will occur over and over in
	    the next decade -- we will discover something and want to replace
	    what people are using. Right now we can fail to advance 1828 as
	    part of this process, but in general what we are doing is creating
	    NEW transforms, not REPLACING old ones. The new transforms are then
	    encouraged to be "must implement".
	 4) We leave the HMAC RFC at proposed standard long enough for the cryp
	to
	    community to really get its teeth in. Being at proposed should be
	    sufficient to encourage vendors to implement. I know Hugo would
	    probably like it to advance to draft standard more quickly, but my
	    gut instinct says "wait". Proofs are good, I fully believe Hugo is
	    a good crypto guy and that his proofs are excellent, but this is
	    engineering at this point, not math. Proposed standard should be
	    sufficient for a while.
	 5) If we desire, we may issue a document clarifying 1828 for
	    historical reasons, but we do this as an informational RFC.

There's no problem with any of this.  But we need point 6 -- the status
of 1828 and HMAC as mandatory/recommended/elective etc.  What do we
tell people they MUST implement?  My own view is to make HMAC mandatory
and 1828 recommended -- and recommended only because there's already
a lot out there.

Xref subject previous
Xref subject next


smb@research.att.com writes, re my proposal:
> There's no problem with any of this.  But we need point 6 -- the status
> of 1828 and HMAC as mandatory/recommended/elective etc.  What do we
> tell people they MUST implement?  My own view is to make HMAC mandatory
> and 1828 recommended -- and recommended only because there's already
> a lot out there.

I agree fully with your amendment. This seems like "the right thing". 

Perry

Xref subject previous
Xref subject next

Perry E. Metzger writes:
> Just to be clear, what I am proposing on HMAC is this:
> 1) We leave 1828 alone. We do not advance it further but we do not
>    "replace" it, meaning new RFCs do NOT "supersede" it in the way a
>    replacement would.

I'm against. There are no reasons NOT to "supersede" 1828.

> 2) We publish an RFC as a proposed standard for HMAC.
> 3) We think of the HMAC transform not as a replacement for the
>    existing transforms but as a new transform.

Yes, certainly.

>    Any key negotiation
>    protocols that exist do not replace the meaning of "use the 1828
>    transform" with using HMAC -- they think of HMAC as a new
>    transform. I do not want the new RFC to "supersede" 1828 as a
>    replacement RFC would.

It is a question of what transform will be mandatory and what won't.
HMAC should be the mandatory one, for several good reasons.

>    ...........Right now we can fail to advance 1828 as
>    part of this process, but in general what we are doing is creating
>    NEW transforms, not REPLACING old ones. The new transforms are then
>    encouraged to be "must implement".

We are [or should be]  making the new transform "must implement" and
the old one - "optional". In my eyes it's either a "replace", or
very close to it. (:-)
-- 
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-

I will not be arriving until Tuesday midnight.  I HAVE to be home with the
family until after Purim.

ERGO I will miss both sessions, sorry.

I have been a bit overworked here to get my notes together on what I want
for the auto industry (yes I now have a much louder "voice" than in the
past), but I can convey that information on wednesday....

See you all then.

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref subject previous

In message <9603011844.AA42869@hawpub.watson.ibm.com>, you write:
>>    Any key negotiation
>>    protocols that exist do not replace the meaning of "use the 1828
>>    transform" with using HMAC -- they think of HMAC as a new
>>    transform. I do not want the new RFC to "supersede" 1828 as a
>>    replacement RFC would.
>
>It is a question of what transform will be mandatory and what won't.
>HMAC should be the mandatory one, for several good reasons.

	I guess I may be missing something. People are talking as if RFC-1828
is totally worthless and HMAC is the holy grail, yet I'm not seeing any real
data that justifies this conclusion.

	We know of no *feasable* attacks on RFC-1828, right? And how long have
cryptographers been playing with envelope MACs? Now, we have this new MAC. It
is probably better. It looks better to us. But it is still new enough that
we don't really know.

	Why the mad rush to replace RFC-1828 with HMAC as the mandatory
minimum? First, this obseletes all current implementations. Sure, it's not that
difficult to update this, but that doesn't mean you still don't have to do
the work and then go through testing cycles again. Second, we're moving from a
known to an unknown. How many people have implemented and tested HMAC-based AH?
I don't know of any, though the IBM people probably have.

	At the very least, it doesn't seem like a very good idea to change
RFC-1828's status until more people have *implemented* HMAC AH.

								-Craig

Xref subject previous
Xref subject next

> > As a general note: if we can't modify the standards during the
> > standarization process why do we have that process in place.
> 
> We can alter what is standard. However, it is often bad to alter what
> already exists. When SMTP got revised, an extensions mechanism was
> created -- existing SMTPs weren't broken. Sometime soon it will be
> required that SMTP implementations support ESMTP, but it will
> doubtless be a long while before ESMTP is totally universal, if
> ever.

But, in my understanding IPSEC does not "exist" yet in the same sense
as SMTP did.  It does not yet have a wide user base, just a few small
groups using various implementations.  I think it is probably early
enough to simply change the spec if it is otherwise justified.
(It may not be a bad idea to change the protocol number though if
confusion is likely.)

    Tatu

Xref subject previous
Xref subject next

I'm on the road, and don't have a lot of time to reply here:

> From: smb@research.att.com
> Of course, all along the unanimous opinion of the cryptographic theoreticians
> has been that keyed hash functions were an unknown -- they weren't designed
> to do that, and it wasn't clear that they were secure in this mode.  But
> we went ahead anyway.
>
Yes.  And we then learned that the "theoreticians" got it wrong.

Randall Atkinson (and Perry and myself and others) originally proposed
keying in the most simple and obvious way -- H[key,length,data].

After analysis, we now know that the originally proposed construct is
more secure than what the "theoreticians" repeatedly told us we needed
to change.  As demonstrated within 6 months by other more capable
theoreticians.

We made a mistake.  We made changes without 2 or 3 years of review.
We should never have given in to the pressure.

I remind you who prompted that change:

    Date: Tue, 24 Jan 95 18:40:52 EST
    From: hugo@watson.ibm.com
    To: bsimpson@MorningStar.Com, IPSEC@ans.net
    Cc: jis@mit.edu
    Subject: AH-MD5

    Just to break the *quiet* consenus: I personally would prefer to
    see a prepend+append MD5 for IP authentication.

    The reasons are a more robust security design, less plausible to
    suffer yet unknown vulnerabilities or implementation errors, at
    a very low cost compared to prepend only (notice that MD5, by definition,
    APPends the length of the information and I didn't see any claims
    that this causes any significant degradation in performance).

Think about his claims in the light of new evidence.


> Note carefully:  revision is *likely*.  If we're going to change it, now is
> the time -- after it goes to Draft, it's too late for fixes of this nature
> (absent, say, the discovery of a feasible attack).
>
In retrospect, let me apply the wisdom posted to this list, that
prompted Perry and I to make the change to H[key,data,key] rather than
Kaliski's proposal:

    Date: Tue, 14 Mar 95 15:28:27
    From: "Housley, Russ" 
    To: Hilarie Orman 
    Cc: ipsec@ans.net
    Subject: Re[2]: End of WG Last Call for AH+MD5 and ESP+DES+3DES

    Hilarie said:
         I think that MD5(key, text, key) may be more secure than the double
         hash. My understanding is that Kaliski's suggestion was based on the
         idea that MD5(text) might be a useful subfunction.  However, I'm
         uneasy at the idea of a possible cryptanalysis of MD5(foo,key); not a
         question I've seen examined before.

    MD5(key,data,key) is one of the few things we had concensus about.  Burt
    did not say that this was weak, rather he said that the other had more
    study behind it.

    I think that we should keep MD5(key,data,key) because it an be computed
    with one function invocation when implemented in hardware.
    MD5(MD5(data),key) will require two function invocations in hardware
    implementations.

We now know a very formal analysis shows an IMPRACTICAL attack on
H[key,data,key].  But, between the 2 choices, practicality was a
principle consideration.

That is one of the reasons that DES was chosen over 3DES as required to
implement.  Yes, we know it's weaker than we'd like.  But we _know_ the
weaknesses.  And it's strong enough for practical purposes.

Now, if we wait long enough, we might find even better choices.  We have
something that works.  There is no hurry!

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

> From: "Perry E. Metzger" 
> Subject: what I am proposing re HMAC
> 1) We leave 1828 alone. We do not advance it further but we do not
>    "replace" it, meaning new RFCs do NOT "supersede" it in the way a
>    replacement would.

Disagree.  We should advance to Draft Standard.  We have met the
requirements for Draft Standard.

> 2) We publish an RFC as a proposed standard for HMAC.

Disagree.  We should publish a proposed standard for NMAC, which has
supporting analysis from multiple researchers.

Oh, and I've already written the draft....

HMAC is merely conjectural, and is less efficient to implement than NMAC.

And HMAC derives its security from NMAC.  If anything, HMAC has a few
very specious assumptions.


> 3) We think of the HMAC transform not as a replacement for the
>    existing transforms but as a new transform. Any key negotiation
>    protocols that exist do not replace the meaning of "use the 1828
>    transform" with using HMAC -- they think of HMAC as a new
>    transform. I do not want the new RFC to "supersede" 1828 as a
>    replacement RFC would. One of the reasons I'm strongly opinioned on
>    this is that I expect this situation will occur over and over in
>    the next decade -- we will discover something and want to replace
>    what people are using. Right now we can fail to advance 1828 as
>    part of this process, but in general what we are doing is creating
>    NEW transforms, not REPLACING old ones.
>
Agreed!  Particularly with the latter.

> 4) We leave the HMAC RFC at proposed standard long enough for the crypto
>    community to really get its teeth in. Being at proposed should be
>    sufficient to encourage vendors to implement. I know Hugo would
>    probably like it to advance to draft standard more quickly, but my
>    gut instinct says "wait".

Agreed.

> 5) If we desire, we may issue a document clarifying 1828 for
>    historical reasons, but we do this as an informational RFC.
>
This is called an "applicability statement" and it is already provided
for in our standards process.  I have already begun writing it.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

> Date: Thu, 29 Feb 96 18:31:34 EST
> From: hugo@watson.ibm.com
> There is so much traffic in this list these days and I hate contributing
> more but this may interest other people in addition to Perry.
>
> Waiting 1-2 years is unrealistic for IETF proposals.
> However, I wish there was a more orderly scrutiny of security designs
> for IETF protocols by cryptographers.
>
> Photuris is a good example. It took me 6 drafts (from 03 to 09)
> to convince Simpson to derive *independent* key bits for keyed-MD5 and DES.

This is a patently false and misleading statement.

Since, until draft -09, AH and ESP always had different SPIs, they also
always had independently derived keys.

With the advent of the WG request this winter for the _complication_ of
having AH and ESP _share_ the same SPI, then the key schedule of ESP-DES
in Photuris was required to change.

A more _complicated_ design engendered a more _complicated_ keying
schedule.  No surprise there; these requests seem to avalanche.

I find it personally insulting that Hugo claims to have to teach us
simple and practical cryptographic features.

I will leave it to the rest of you to decide whether he is on track
about other "cryptographic sins".


> cryptographic sins. I didn't see where is the cryptographic community
> that is inspecting this design.

I have in hand a quote from another cryptographic analyst:
   "I am impressed with the thoroughness of the Photuris spec."

Thanks anyway....

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

> Randall Atkinson (and Perry and myself and others) originally proposed
> keying in the most simple and obvious way -- H[key,length,data].
> 
> After analysis, we now know that the originally proposed construct is
> more secure than what the "theoreticians" repeatedly told us we needed
> to change.  As demonstrated within 6 months by other more capable
> theoreticians.

Technical nitpick:

I assume you are claiming that recent attacks on the envelope method
show that it's less secure than H[key,length,data] ??  If so, you're
mistaken.  (Is this really important, anyhow?)

The collision-based attacks of Preneel & van Oorschot which apply to
the envelope method also apply to H[key,length,data] in exactly the
same way.  Furthermore, the comments of Kaliski & Robshaw apply to the
H[key,length,data] construction (which notably has no padding after
the key): short messages might be vulnerable to certain techniques,
such as linear cryptanalysis.  The envelope method in RFC1828 is
strengthened against the short-message concern.

We're seeing incremental improvements in hash-based MAC technology due
to research by the cryptographers-- that much is apparent, I think.

Apolitically yours,
-- Dave Wagner

Folks on this list might want to take a look at a paper by David Wagner
and myself: ftp://ftp.research.att.com/dist/smb/bisconf.ps.  It describes
an IPSEC implementation for MS-DOS.  Perhaps of more interest than the
paper itself are two subtle attacks on IPSEC modules, a fragmentation
attack and a routing attack.

		--Steve Bellovin

Xref subject previous
Xref subject next

> From: David A Wagner 
> I assume you are claiming that recent attacks on the envelope method
> show that it's less secure than H[key,length,data] ??  If so, you're
> mistaken.  (Is this really important, anyhow?)
>
Hmmm, we can put our heads together and compare at LA, but looking at
"MDx-MAC" proposition 4 (page 6), finding internal collisions, but no
key recovery (yet):
   /
  / 2/(s+1) * 2 ** 64           for H[key,length,data]
\/

versus "Two MAC" proposition 2 (page 5), with key recovery:
   /
  / 2 * 2 ** 64                 for H[key,data,key]
\/

Seems much weaker to me....


> Furthermore, the comments of Kaliski & Robshaw apply to the
> H[key,length,data] construction (which notably has no padding after
> the key): short messages might be vulnerable to certain techniques,
> such as linear cryptanalysis.

Actually, Atkinson's initial key was always padded (since 1993).
Although we argued about whether it should be to 128-bits or 512-bits.
The consideration was always for efficiency, however; promoted block
alignment for IPng and allowed precomputation.

And as you may remember, Metzger and I were whipsawed back and forth on
the key padding issue by the crypto-theoreticians for several months!
I can refer you to messages from Colin Plumb, Eric Rains, Burt Kaliski,
Russ Housley, Hilary Orman, Rich Schroeppel, and of course the
ubiquitous IBM trio of Amir, Hugo and Uri.


> The envelope method in RFC1828 is
> strengthened against the short-message concern.
>
Yes.  And I thank you for the contribution.  But the reason that it was
so easily accepted was it fit with precomputation, and was easy to code!


> We're seeing incremental improvements in hash-based MAC technology due
> to research by the cryptographers-- that much is apparent, I think.
>
Yes.  I don't see any reason to leap off to yet another transform
without considerable validation by multiple analysts.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

Who else, besides Bill, thinks that we should go with the current transforms
instead of HMAC?

Xref subject previous
Xref subject next


The following telegraphic presentation attempts at summing up our relevant
knowledge, accumulated during the past year or two, on the use of keyed hash
functions as MACs. I hope it will help in clarifying the current discussion.

I will consider the following schemes:

 *  The "prepend key and length" scheme, PKL(msg) = Hash(key,length,msg)
 *  The "envelope" scheme, ENV(msg) = Hash(key,pad,msg,key)
 *  The HMAC scheme, HMAC(msg)  = Hash(key,pad1, Hash(key,pad2,msg))
 *  The NMAC scheme, NMAC(msg) =  Hash_key1 (Hash_key2(msg))
    (This last scheme is similar to HMAC, with the exceptions that
     it uses two keys instead of one, and puts the keys in the IV of
     the hash function instead of in the first part of the input.)


I) No feasible attack is currently known against any of these schemes.
If this is satisfactory then any of the above schemes will do.
However, one may want to have a better assurance than that for a standard.
Thus, attempts have been made to gain further assurance in the security
of schemes by proving statements of the sort: "If the underlying hash 
function enjoys property X then scheme Y is a good MAC".
The weaker property X is, the more assurance we have in the security of
scheme Y. I am not aware of any other method for gaining assurance
in the security of a MAC scheme based on cryptographic hash functions.

II) The only claim I know, of the sort described above, regarding PKL and ENV
is: "If the compression function of the underlying hash function
is pseudorandom then PKL and ENV are good MACs".

This was the first statement of this sort that was proven, regarding any scheme;
thus at the time ENV and PKL gave the best assurance. However,
Pseudorandomness is quite a strong assumption.


III)  On the more recently proposed NMAC scheme one can show that
"If the hash function is collision-free (in a very weak sense)
and the compression function is a good MAC on 512-bit messages then NMAC
is a good MAC".
Here the required properties of the hash function are much weaker
than pesudorandomness. In fact, they are quite minimal in the sense that
if they are not satisfied by some hash function then it is hard to imagine
that this hash function can be used to genrate MACs in any way at all.
In particular, this is the best security guarantee known for a hash-based MAC.

However, NMAC has the drawbacks that it uses two keys rather than one
and that it requires a small change in the code  of the hash function
(i.e., putting the keys in the IV). Thus HMAC was proposed as a compromise.
HMAC uses only one key and requires no change in the code of the hash
function. However, an additional "mixing" property of the compression
function is assumed. Still, the combined assumptions on the hash function
are near-minimal and in particular much weaker than those of (II).

In short, out of the schemes that use a single 128-bit key and do not
change the code of the underlying hash function, HMAC provides
the strongest assurance in its security.

I must say that, given that all these schemes are of comparable efficiency,
I find it hard to imagine why the forum would want to adopt a scheme
that provides weaker assurance than HMAC.


Ran Canetti

Xref subject previous


  *> From smb@research.att.com Mon Feb 26 19:49:50 1996
  *> From: smb@research.att.com
  *> To: ipsec@tis.com
  *> Subject: traffic type header
  *> Cc: braden@ISI.EDU, minshall@ipsilon.com
  *> Date: Mon, 26 Feb 96 22:44:47 EST
  *> Content-Length: 1551
  *> X-Lines: 36
  *> 
  *> 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 (c) support integrated services, in particular RSVP.

Bob Braden

At 13:15 7.1.96 -0800, you wrote:
>I will offer just a technical observation or two speaking only for myself.  
>
>ANY hybrid Diffie-Hellman scheme can provide Perfect Forward Secrecy.  
>Your mention of one-time pads was entirely extraneous.  Moreover, there 
>is a lot of experience with deployed systems indicating the Hybrid 
>Diffie-Hellman is not too expensive computationally or otherwise impractical.

By now I have recovered Diffies paper, and done some more hunting for
literature. But sincerly I found no **definition** of the term 'perfect
forward secrecy', anywhere. Do you have a reference at hand, which
introduces this term? Otherwise I feel like defining it myself. And the
expression 'perfect' is a very dangerous one ;-) which really leads to OTPs. 
Certainly I agree with you, hybrid DH _is_ practical. It's just not a
perfect solution.

>Second, as near as I can tell, none of the current drafts meet _all_ of the
>WG requirements.  Hence, your misunderstanding that this is about SKIP
>(hint: the questions are NOT specific to SKIP) is not well founded.

Well, one learns ;-) I sometimes have the impression that the
non-progression of the different standards is not wholedly based due to
technical reasons. From an idealistic point of view (let's call it Secure
Internet) I want IPSEC to move on. I do not care if it moves into the
Photuris direction, Oakley, SKIP, or all of them at the same time, as long
has we finally get some progress. Compared to the initial WG schedule IPSEC
is about one year (or more?) late... Then naturally I have some personal
preferences, but I believe I need not elaborate on those ;->> -- and they
are not exactly relevant in the standardisation process.

I definitvely have a problem with the working group requirements. They - let
me exagerate - do NOT exist. What we have is a collage of emails and
proceedings, which contain partially colliding requirements. Also this
inexistant list has mutated more than once or twice. I fear most people that
'know' the WG requirements and talk about them on the mailing list, have
views of their own as to what these requirements are. I would really enjoy
seeing a list, perhaps even stating which draft satisfies which
requirements. Naturally this is no easy task, and as I am not even able to
bring out a little transorm (sigh) draft in time, I will not volunteer to do
this.


Well, sorry for this rather longish mail, perhaps I will now sleep better.


Talk to you soon,

        Germano

Xref subject next


Some comments on the proposals for MAC constructions:

> *  The "prepend key and length" scheme, PKL(msg) = Hash(key,length,msg)
> *  The "envelope" scheme, ENV(msg) = Hash(key,pad,msg,key)
> *  The HMAC scheme, HMAC(msg)  = Hash(key,pad1, Hash(key,pad2,msg))
> *  The NMAC scheme, NMAC(msg) =  Hash_key1 (Hash_key2(msg))

For the first two of these schemes, we know that there is a reduction
to the pseudo-randomness of the underlying compression function (PKL ENV);
For the NMAC:  "we know that if the hash function is collision-free 
(for a secret IV) and the compression function is a good MAC on 512-bit 
messages then NMAC is a good MAC".
For HMAC, we need an additional mixing property of the compression function.

You forgot to mention MDx-MAC (see the Crypto'95 paper of Paul van Oorschot
and myself), for which there exist a security proof based on the 
pseudo-randomness of the underlying compression function which is keyed
in both the IV and the message input. 


All these reductions are very nice from a theoretical standpoint 
(really a good piece of work). However, as a practical cryptanalyst, 
I have the following remarks:

1. very little cryptanalysis has been done on MD4 and MD5; nevertheless,
   some quite good results have been obtained already (from the 
   cryptanalyst's point of view).

2. no work at all has been done on properties of MD5 when part of the input 
   is a secret key.

3. it is even not obvious at all where to put this key: which part of 
   the input is the "natural" place to put it? 
   (in my humble opinion, it should be put in every part of the input,
    but this is based on my intuition). 

4. for all of these there exists a forgery attack which is unrealistic if 
   the underlying function (with the same parameters) is really strong; 
   for the first two schemes, this (unrealistic) attack allows for key 
   recovery rather than forgery.  However, no one has yet analyzed how much 
   this can be improved if MD5 is used as underlying function.

In view of all of this, for all of you who want to use any of these 
constructions based on MD5, I recommend to be very careful and take the 
most conservative one you can afford. 

I wonder how many of you would be prepared to use any of these schemes
if the US government had proposed them... (sorry, couldn't resist).

The good news is that you can make many mistakes, since there are 
only very few cryptanalysts, and their time is very scarce (there are 
many algorithms). That means it can take many years before they find the 
time to try to break any of these schemes. 
It's up to you to decide whether you can ignore their warnings.

Good luck.   

Bart Preneel


PS Below some more details (for those of you who want to know):

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

1.  Up till now very little cryptanalysis has been performed on MD4 and MD5 
(compared to for example the amount of work on DES). I believe the total 
effort is less than 1 personyear.
MD4 was badly broken (research effort of about 5 manmonths; collisions in 
1 second on a PC), and it can be anticipated based on this that collisions 
will be found for MD5 in the next 12 to 24 months.  The main issue is just
to find a few competent people who want to spend a sufficient amount of time.

2. Up till now NO work has been done on the evaluation of the compression 
function of MD5 as a pseudo-random function. 

Some people claim that the fact that the compression function of MD5 is 
a MAC or a pseudorandom function is a design criterion for MD5. 
In my opinion it is at best a by-product of the design, and a by-product 
which _never_ has been checked for.  The reason for this is that usually 
MD5 is not used with secret input, but only with known/chosen inputs.
The only property which has been evaluated and which approximates this
is preimage resistance: if you are given the complete output, find a preimage.

What is required for a MAC are properties of the compression function for 
which _part_ of the input is fixed and secret; one then is allowed to
look at many outputs for chosen values of the remaining inputs.
As far as I know, there is only one class of concrete primitives which
have been checked for such a property, namely  ...block ciphers.
(unfortunately they are slower and cannot be exported).
The properties required are totally different from collision resistance 
or one-wayness: for example, the existence of probabilistic linear 
relations between part of the input (where you have put the key) and 
the output could lead to linear cryptanalysis of MD5; such an attack would
not change anything to the security of the hash function as a collision
resistant or (second) preimage resistant function.

3. it is even not obvious at all where to put this key: which part of 
   the input is the "natural" place to put it? 

If one uses MD5 as a MAC or as a pseudorandom function, you have to insert
the key somewhere. In my humble opinion, there is no obvious place to do this;
if you look at MD5 as a block cipher, the message input would be the key, 
and the IV would be the plaintext. 
NMAC enters the key in the IV, and the [BCK] paper contains
the following claim: "As it turns out, the latter approach
has some significant analytical advantages".

Moreover, if you one would design a hash function according to the
Merkle-Damgaard principle, i.e., derive the collision resistance of the 
hash function from that of the compression function (such as Snefru of Merkle), 
there would be no distinction between the IV and the message input. So it is 
quite confusing to me that putting the key in the IV input can have 
analytical advantages.

The fact that there is no obvious place to put the key, is the reason why
in MDx-MAC the key is put both in the IV and in the message input.
The idea behind this is that since the compression function is not designed
to hide any of its inputs in the way which a pseudo-random function should,
the key should be involved in _every_ input.
I agree that this is not a security proof, but in my opinion it is
a sound design principle.

4. for all of these schemes there exists a forgery attack which is unrealistic if 
   the underlying function (with the same parameters) is really strong; 
   for the first two schemes, this (unrealistic) attack allows for key 
   recovery rather than forgery.  However, no one has yet analyzed how much 
   this can be improved if MD5 is used as underlying function.

Since the time of cryptanalysts is scarce, and our knowledge of 
cryptographic algorithms is limited, we often have to rely on 
certificational weaknesses. For example MD5 has as certificational 
weakness that its compression function is not collision resistant,
and the construction of RFC 1828 has as certificational weakness that 
an unrealistic forgery attack can be extended to an unrealistic key 
recovery attack.  For me as a cryptographer this would be sufficient 
to never use RFC1828 based on MD5.

And the fact that the attack for any compression function takes $2^{66}$ 
chosen texts does not mean that this could not be improved for MD5..


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

Xref subject previous

Ref:  Your note of Mon, 4 Mar 1996 00:43:27 +0100 (attached)

Bart Preneel writes:

> In view of all of this, for all of you who want to use any of these
> constructions based on MD5, I recommend to be very careful and take the
> most conservative one you can afford.

Agreed. Given that this group has decided to go with an MD5-based MAC,
we got to be careful and cautious.
This is the exact reason why we came up with HMAC and propose it as a
default MAC for AH: it is (among all studied candidates) the one scheme
to require the least assumptions on MD5 in order for the resultant
MAC to be secure (yet it requires no performance degradation or changes
to MD5).

Hugo

Xref subject next


[personal opinion]

  I think the WG should seriously consider moving both RFC-1828 and
RFC-1829 to Historic.  Hugo's HMAC transform should be seriously
considered to be moved to Proposed Standard and replace RFC-1828
as the mandatory-to-implement AH transform.  Similarly, Jim Hughes'
DES+MD5+replay-protection ESP transform should be reviewed/edited
and then seriously considered to be moved to Proposed Standard
and replace RFC-1829 as the mandatory-to-implement ESP transform.

[WG chair speaking]
  This is precisely the correct time to consider these kinds of 
significant technical changes to the IPsec transforms.

  Because RFC-1825 thru RFC-1827 are not yet ready to be considered
for advancement to Draft Standard, RFC-1828 and RFC-1829 cannot yet
be considered for advancement to Draft Standard in any event.  Any
appeals of this decision should be made directly to the Security AD
and should NOT clutter this list further.

  In general, if one believes the chair(s) have made a meaningful
incorrect process decision the correct procedure is to appeal to
the Security AD.  The Security AD is empowered to overrule the
chair(s) of the WG.

Ran
rja@cisco.com

This is just a recap of what I said at the IPSEC mtg Monday night for those
that weren't there or those who missed the URLs.

cisco is making available a reference implementation of ISAKMP with OAKLEY
extensions.  We plan to make this available mid April or earlier.  The
implementation works with the NRL PF Key socket and runs on BSD 4.4
platforms such as BSDi, NetBSD and FreeBSD.  It should port to other OSes
easily as it runs entirely in user space.

We plan to do interoperability testing over the net between our
implementation, the NSA implementation (to be available soon from MIT, I'm
told) and the implementation from the Brittish Defense Research Agency.
Others are welcome and encouraged to join in.

The implementation is free in source code form and we have purchased
licensing that allows it to be copied and used in commercial or
non-commercial products without royalties.  The intent is to move things in
the IPSEC forward by making code available and as unrestricted as possible.
The exact license will be online shortly after I get back to San Jose on
our anonymous ftp site.  The README file in:
	ftp://ftp.cisco.com/isakmp-oakley/README
will have the exact location of the license and other files including
instructions for downloading the code.

A mailing list has been set up for discussions and announcements relatng to
our implementation.  The list is isakmp-oakley@cisco.com and you can add
yourself by sending email to majordomo@cisco.com with the line
	subscribe isakmp-oakley
in the body of the message.  The mailing list is being archived in the same
anonymous ftp directory.

Of course, access to our code is limited to sites in the US and Canada.

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 subject previous


Perry:

I agree with Hugo.  Replace is the correct action.

Russ


______________________________ Reply Separator _________________________________
Subject: (IMPORTANT) Call for AH-MD5 and ESP-DES to move forward
Author:  hugo@watson.ibm.com at internet
Date:    2/29/96 4:22 PM


Ref:  Your note of Thu, 29 Feb 1996 16:09:19 -0500 (attached)

Perry,

 >
 > I have no problem with the idea of ultimately advancing the HMAC
 > transform to standard, especially after it has been out for a good
 > while and there has been additional opportunity for cryptographers to 
 > attack it, but I disagree with the words "replace". As Paul's survey
 > reveals, many implementations currently implement 1828. Let us instead 
 > speak of requiring this new superior transform rather than of
 > "replacing" the old one, which would imply, for example, that
 > identifiers for 1828 in key management protocols would have to point 
 > at HMAC instead, which would result in interoperability problems.

What I want is that implementations *do* move to this new function.
We are doing a lot of implementation work regarding IPSEC, and we talk 
to many other implementation people involved with IPSEC.
The message is very clear: no one has any real problem to implement the 
new transform, however they will not do that as long as there is another 
one that is *officially* required by the IPSEC standard.

We need to find a way to break this loop. I don't care about the word 
"replace" just about making clear that IPSEC-AH REQUIRES HMAC
(as the default implementation).

As a general note: if we can't modify the standards during the 
standarization process why do we have that process in place. 
Implementors need to know (and we know!) that changes will occur. 
This particular one is easy to implement and upgrade.

If the decision is that it is too late to change the default algorithm
I would recommend this group to be even more careful on any decision about 
moving any document to standards track.

Hugo

Olafur Gudmundsson writes:
 > We are please to announce that the first Beta release of
 > TIS/DNSSEC is now available.  This version is a implementation
 > of the current DNSSEC draft and it is based on bind-4.9.3-REL,
 > it uses RSAREF, but you need to retrieve a copy from RSA.
 > 
 > We are actively seeking beta testers. 
I have installed  a WEB page that allows you retrieve both 
TIS/DNSSEC and RSAREF. 
        http://www.tis.com/docs/Research/iip/dnssec.html 
 
        Olafur 
 

Xref subject previous

At 10:41 PM 3/1/96 +0200, Tatu Ylonen wrote:
>
>But, in my understanding IPSEC does not "exist" yet in the same sense
>as SMTP did.  It does not yet have a wide user base, just a few small
>groups using various implementations.  I think it is probably early
>enough to simply change the spec if it is otherwise justified.
>(It may not be a bad idea to change the protocol number though if
>confusion is likely.)

I should point out that TELNET went through a similar problem; right now I
forget the option, envirnoment, I think.  They did it wrong, big time, and
there were already implementations, and Borman had to carefully architect
the movement to the 'right' way.

You have it much easier.  with a new transform # and a clear statement that
HMAC is the required transform with the old one perhaps 'historical'

Let's do a last call on HMAC, please.  As a consumer I expect you all to do
this.


Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref subject previous

At 11:55 PM 3/3/96 -0800, Ran Atkinson wrote:
>
>[personal opinion]
>
>  I think the WG should seriously consider moving both RFC-1828 and
>RFC-1829 to Historic.  Hugo's HMAC transform should be seriously
>considered to be moved to Proposed Standard and replace RFC-1828
>as the mandatory-to-implement AH transform.  Similarly, Jim Hughes'
>DES+MD5+replay-protection ESP transform should be reviewed/edited
>and then seriously considered to be moved to Proposed Standard
>and replace RFC-1829 as the mandatory-to-implement ESP transform.

I agree, personally.  With my IAB hat on, this is the process we should follow.


Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref subject previous
Xref subject next

The currrent dnssec contemplates that all RRs in a zone would have SIGs that
all expire at the same time.  In that case, really the whole zone is either
there or not.  With dynamic update, you are more likely to get SIGs with
different expiration dates. 

SIG expiring should certainly wipe out an RR in a cache but it is not at all
clear to me that it should drop out of a zone and cause the AXFR sig to fail. 
So I think authoritative servers should keep it in the zone. 

I don't think any EXP RR should repilace the expiration field in the SIG RR. 
I just dont see the need to add a lot of EXP RRs and make SIG calculation
more complex by including the EXP RR when signing. 

Donald

On Wed, 28 Feb 1996, Paul A Vixie wrote:

> Date: Wed, 28 Feb 1996 01:21:52 -0800 (PST)
> From: Paul A Vixie 
> To: dns-security@TIS.COM
> Subject: Re: Expires RR proposal
> 
> >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.
> 
> That strikes me as the wrong thing to do.  Send the data, along with the
> expired signature.  What's expired is the signature, not the data.  This
> constitutes my first and only objection to DNSSEC, but since Edie had to
> point it out to me, I'm not going to lodge it formally (I had my chance.)
> -- 
> Paul Vixie
> La Honda, CA			"Illegitimibus non carborundum."
> 
> pacbell!vixie!paul
> 

=====================================================================
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
Xref subject next

>SIG expiring should certainly wipe out an RR in a cache but it is not at all
>clear to me that it should drop out of a zone and cause the AXFR sig to fail. 
>So I think authoritative servers should keep it in the zone. 

I agree...it seems that an expired SIG RR means that the data is no longer
secured, not that it's invalid.  Otherwise, how can you tell the difference
between insecure and secured data?  Donald suggests sending the expired SIG
with an answer...I'd prefer that the SIG disappear and the answer come back
as unsigned (completely insecure, not just used-to-be secured).

	Walt

Xref subject next

        I have a couple questions about the goals for the revised ESP
that includes integrity and replay protection.

1) Is the new ESP suppose to eliminate the need for the AH transform?
   - If so, the current draft does not provide any integrity checks
     on the IP header, so an attacker can modify those fields in
     transit.  Maybe that is not considered to be a threat.
   - If not, then a secuure implementation that includes both AH
     and ESP will have to perform two MD5 digests on the payload.
     That is a 33% performance hit for large packets [with the
     original AH-ESP, the payload is scanned once for the AH digest
     and once for the DES-CBC, the new ESP-DES-CBC-MD5 requires
     an additional scan of MD5 on the plaintext payload].

2) Do ESP packets need to be self describing in terms of the features
   they support (e.g., whether replay protection is included)?
   The current design assumes that the SPI determines all the
   required features.

                --Bob

Xref subject previous
Xref subject next


>1) Is the new ESP suppose to eliminate the need for the AH transform?
>   - If so, the current draft does not provide any integrity checks
>     on the IP header, so an attacker can modify those fields in
>     transit.  Maybe that is not considered to be a threat.
>   - If not, then a secuure implementation that includes both AH
>     and ESP will have to perform two MD5 digests on the payload.
>     That is a 33% performance hit for large packets [with the
>     original AH-ESP, the payload is scanned once for the AH digest
>     and once for the DES-CBC, the new ESP-DES-CBC-MD5 requires
>     an additional scan of MD5 on the plaintext payload].
>
The new ESP transform does not eliminate AH. AH is still useful in cases
where you dont need to encrypt the data. Also, you may have may only perfrom
AH and not ESP for export.

>2) Do ESP packets need to be self describing in terms of the features
>   they support (e.g., whether replay protection is included)?
>   The current design assumes that the SPI determines all the
>   required features.
>

From what I understand talking to the editors, it is still not decided
whether replay protection is mandatory or optional. There should be some
discussion on this in the mailing list.

Regards,

--Naganand

Xref subject next

Now that we're heading toward individual do-everything transforms
rather than layered orthogonal functions, the concept of separate AH
and ESP protocols seems a bit awkward.  Consider a different protocol,
perhaps called `Security Transform', that might look like this:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Security Parameters Index (SPI)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Transform ID          |    Length     |  Next Header  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Optional Transform Data                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Transforms could be layered if desired.  The length field would make
it easy to parse even if you didn't understand a particular transform
type.  All of our code would become simpler, and the RSVP folks would
love this more uniform format.

The Next Header field would be slightly problematic; encrypting
transforms would want to obscure it somehow (perhaps destroying it
after storing a copy down in the opaque area) while not obscuring
portions of the Optional Transform Data field such as initialization
vectors.

I know it's pretty late in the game to begin talking about something
like this, but it only recently became appropriate because of the
recent change in attitudes toward combined transforms.
--
Karl Fox, servant of God, employee of Morning Star Technologies
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221    +1 614 451 1883

Xref subject previous
Xref subject next


baldwin writes:
>         I have a couple questions about the goals for the revised ESP
> that includes integrity and replay protection.
> 
> 1) Is the new ESP suppose to eliminate the need for the AH transform?

No, not at all. It was intended all the way back to the origins of the
current proposal that ESP would be able to contain arbitrary opaque
transforms.

> 2) Do ESP packets need to be self describing in terms of the features
>    they support (e.g., whether replay protection is included)?
>    The current design assumes that the SPI determines all the
>    required features.

You answered your own question -- the ESP packets are totally opaque,
and no information other than the SPI is needed.

Perry

Xref subject previous
Xref subject next


Karl Fox writes:
> Now that we're heading toward individual do-everything transforms
> rather than layered orthogonal functions, the concept of separate AH
> and ESP protocols seems a bit awkward.

ESP is not the "encrypting protocol". It is the OPAQUE protocol. The
idea always was that AH was there to provide for non-opaque
encapsulated packets in which it was possible to determine what the
contents were without understanding the SPI, and ESP was always
intended to provide for any combination of
(encryption/authentication/replay/etc) that did not need to be
transparent.

Perry

Xref subject previous


  
>From:     baldwin 
>1) Is the new ESP suppose to eliminate the need for the AH transform? 
 
No.  Requirements were identified for an authentication only protocol, 
especially in the IPv6 environment.  These requirements could be reexamined, 
but are a separate issue from combining confidentiality and integrity in a 
single ESP transform. 
 
 
>  - If so, the current draft does not provide any integrity checks 
>     on the IP header, so an attacker can modify those fields in 
>     transit.  Maybe that is not considered to be a threat. 
 
First no not so, we are not eliminating AH. Integrity checks can be provided 
if required on the IP header using AH. 
 
 
>   - If not, then a secure implementation that includes both AH 
>     and ESP will have to perform two MD5 digests on the payload. 
>     That is a 33% performance hit for large packets [with the 
>     original AH-ESP, the payload is scanned once for the AH digest 
>     and once for the DES-CBC, the new ESP-DES-CBC-MD5 requires 
>     an additional scan of MD5 on the plaintext payload]. 
 
True, an end-system would be foolish to request unnecessary extra 
encapsulations.  The situation you describe could occur in various tunneling 
scenarios that should be supported.  For example using ESP end-to-end and AH 
between firewalls that are carrying the end-to-end ESP. 
 
>2) Do ESP packets need to be self describing in terms of the features 
>   they support (e.g., whether replay protection is included)? 
 
No, this has not been the design paradigm for ESP.  It is much more efficient 
for processing and bits on the wire to have implicit definitions. 
 
>  The current design assumes that the SPI determines all the 
>   required features. 
 
Yes. 
 
 
 
 
Paul 
 
-------------------------------------------------------------- 

Xref subject previous
Xref subject next

>   I agree...it seems that an expired SIG RR means that the data is no longer
>   secured, not that it's invalid.  Otherwise, how can you tell the difference
>   between insecure and secured data?  Donald suggests sending the expired SIG
>   with an answer...I'd prefer that the SIG disappear and the answer come back
>   as unsigned (completely insecure, not just used-to-be secured).

At DNSIND today, MAP presented his EXP proposal and the consensus of those
present was that it would not address DHCP's needs.  We're going to pursue
a different angle.  SIG(NULL) will disappear from the next DNSSEC document.
Future DNS expiry discussions will take place on namedroppers@internic.net.
-- 
Paul Vixie
La Honda, CA			"Illegitimibus non carborundum."

pacbell!vixie!paul

Xref subject previous



Name of Implementation:   Gemini Trusted Security Firewall-Guard (GTFW-GD)
Security Protocols:       1. IPSec (ESP,AH): Public-Private
                          2. IPCSO & IPSec: Private-Private
                             (IP Crypto-Seal Option)
                             (Integrity, Authentication, Confidentiality)
Security Transforms:      DES, Key MD5, Trusted Crypto-Seals
Key Management:           1. Manual for Trusted Public-Private Internetwork
                          2. A1 Trusted Distribution Key Management Extended
                             for Trusted Private-Private Internetwork
                          3. Customized
Lineage of Code:          1. Trusted Software
                          2. Platform: GTFW-GD on Gemini Trusted Network
                             Processor with Integrated Encryption 
                             certified at Class A1
Location of Source Code:  Proprietary
Point of Contact:         Dr. Tien F. Tao, tft@main.geminisecure.com

Xref subject next



--============_-1385786828==_============
Content-Type: text/plain; charset="us-ascii"

Enclosed below is the proposed updated charter for this working group.  It
includes the secure dynamic update task we started at the Winter IETF.
Comments and suggestions for improvement are hereby solicited.  I will
submit this or its revision to the area director and secretariat next
friday, March 15.

Thanks,

Jim



--============_-1385786828==_============
Content-Type: text/plain; name="dnssec-charter-new.txt"; charset="us-ascii"
Content-Disposition: attachment; filename="dnssec-charter-new.txt"


Domain Name System Security (dnssec)
------------------------------------

 Charter

 Current status: active working group

 Chair(s):
     James Galvin 

 Security Area Director(s):
     Jeffrey Schiller  

 Mailing lists:
     General Discussion:dns-security@tis.com
     To Subscribe:      dns-security-request@tis.com
     Archive:           ftp://ftp.tis.com/pub/lists/dns-security

Description of Working Group:

The Domain Name System Security Working Group (DNSSEC) will ensure
enhancements to the secure DNS protocol to protect the dynamic update
operation of the DNS.  Specifically, it must be possible to detect the
replay of update transactions and it must be possible to order update
transactions.  Clock synchronization should be addressed as well as all
of the dynamic update specification.

Some of the issues to be explored and resolved include

o scope of creation, deletion, and updates for both names and zones

o protection of names subject to dynamic update during zone transfer

o scope of KEY resource record for more specific names in wildcard scope

o use of or relationship with proposed expiration resource record

One essential assumption has been identified: data in the DNS is
considered public information.  This assumption means that discussions
and proposals involving data confidentiality and access control are
explicitly outside the scope of this working group.

Goals and Milestones:

Spring 96 Working draft for secure dynamic update
Summer 96 Revised draft for secure dynamic update
Winter 96 Submit proposal for ensuring security of dynamic update of DNS
	  to the IESG for consideration as a Proposed Standard



--============_-1385786828==_============
Content-Type: text/plain; charset="us-ascii"

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



--============_-1385786828==_============--

Xref subject previous
Xref subject next

Perry E. Metzger writes:
> 
> Karl Fox writes:
> > Now that we're heading toward individual do-everything transforms
> > rather than layered orthogonal functions, the concept of separate AH
> > and ESP protocols seems a bit awkward.
> 
> ESP is not the "encrypting protocol". It is the OPAQUE protocol.

My apologies; it's fairly easy to miss that point, since RFC 1827
mentions encryption and decryption 64 times while only mentioning
`opaque' twice in a fairly minor way in the syntax section.

> The idea always was that AH was there to provide for non-opaque
> encapsulated packets in which it was possible to determine what the
> contents were without understanding the SPI, and ESP was always
> intended to provide for any combination of
> (encryption/authentication/replay/etc) that did not need to be
> transparent.

So will these forthcoming authentication+opacity transforms
authenticate the outermost IP header the way AH does?  If they don't,
won't we have to use AH anyway and thereby authenticate the packet
twice?  If they do, then it looks like RFC 1827 will have to have some
significant changes to allow the transform to operate on the
encapsulating IP headers.  For example, section 4.1, `ESP in
Tunnel-mode' says to discard the outside cleartext headers, and
section 4.3, `Authentication', says

   Some transforms provide authentication as well as confidentiality and
   integrity.

It then goes on to talk exclusively about how to use AH in combination
with ESP.
-- 
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



--============_-1385786801==_============
Content-Type: text/plain; charset="us-ascii"

Enclosed below is a draft of the minutes of the Spring IETF 1996 meeting.
Suggestions to improve, corrections, and omissions are hereby solicited.  I
will submit either the draft below or its revision in approximately one
week: friday, March 15.

Thanks,

Jim



--============_-1385786801==_============
Content-Type: text/plain; name="dnssec-minutes.txt"; charset="us-ascii"
Content-Disposition: attachment; filename="dnssec-minutes.txt"


Minutes of the DNS Security Working Group
Spring IETF 1996


The working group met during one meeting period with the following
agenda:

	Charter Review
	Secure DNS Status
		document
		implementation
	Requirements Review
	Dynamic Update Discussion

A revised Charter that included the secure dynamic update task was
presented to the working group for review.  A revision will be posted to
the mailing list for final review prior to submission to the Area
Director and Secretariat for approval and posting.

The secure DNS specifications (draft-ietf-dnssec-secext-09.txt and
draft-ietf-dnssec-as-map-03.txt) are currently in IETF Last Call.  The
IESG will make its decision during its next regularly scheduled meeting;
the documents are expected to be advanced to Proposed Standard.

Trusted Information Systems (TIS) announced the availability of their
beta implementation of the DNS security enhancements.  It is available
for anonymous FTP to U.S. and Canadian sites.  Retrieve the file
ftp://ftp.tis.com/pub/DNSSEC/README for more details.  Beta testers are
requested to contact tisdnssec-support@tis.com for more information.

Prior to beginning the secure dynamic update discussion a review of the
requirements for it, as agreed at the last meeting, was presented.  The
requirements are:

	must detect replay of transactions
	must be able to order transactions
	must address clock synchronization
	should address all of current dynamic update specification

Donald Eastlake presented an overview of the secure dynamic update draft
(draft-ietf-dnssec-update-00.txt) he has proposed.  Since no significant
discussion resulted information about implementations was requested, to
which TIS committed to beginning its implementation of the proposal
soon.  A caution was offered about deploying secure dynamic update given
the lack of experience we have with insecure dynamic update.  However,
the Security Area Director was quick to point out he considered this a
feature.  The reason is because more often than not the security area
finds itself retrofitting security into a protocol, a process that is
usually imperfect and unnecessarily constrains the integration.

The meeting closed with the working group agreeing to wait until the
summer IETF before deciding whether to advance the current proposal.
Waiting will permit TIS to begin its implementation and evaluate the
completeness of the specification.



--============_-1385786801==_============
Content-Type: text/plain; charset="us-ascii"

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



--============_-1385786801==_============--

Xref subject previous
Xref subject next

There's a lot that needs to be rethought.  I could quite easily be
persuaded that we shouldn't, that we should simply decree that ESP
must be used only in conjunction with AH -- we've got to get this stuff
deployed ASAP.  One small change -- the addition of replay protection --
does seem to be needed, though.

> So will these forthcoming authentication+opacity transforms
> authenticate the outermost IP header the way AH does?  If they don't,

As David Wagner and I have pointed out before, in most contexts there's
little reason to authenticate the outer header.  Fields are either (a)
constant, in which case there's no reason to authenticate them, (b) too
variable, such as the checksum, (c) hop-by-hop (TTL), or (d) bound to
the key, in which case why bother.

Xref subject previous
Xref subject next


Karl Fox writes:
> So will these forthcoming authentication+opacity transforms
> authenticate the outermost IP header the way AH does?

You bring up an interesting question. Perhaps they should. This is a
matter for discussion.

Perry

Xref subject previous
Xref subject next

All data in a secure zone is supposed to be secured.  You can only get 
insecure data from insecure zones.  I was only suggesting sending expired 
SIGs and the data they cover in zone transfers to avoid invalidataing the 
possibly pre-computed AXFR signature.

Allowing any unsigned answer from a secure zone totally destorys all 
security.  Any corrupt server can then answer anything it wants by just 
leaving out the SIGs.  If you permit RRs with expired info to appear in 
any sort of reply (zone transfer for regular query), it is absolutely 
essential that the expired SIGs accompany it (unless its truncated in 
which case it can be obtained by a separate query).

Dobnald

On Thu, 7 Mar 1996 lazear@gateway.mitre.org wrote:

> Date: Thu, 07 Mar 96 09:47:08 -0500
> From: lazear@gateway.mitre.org
> To: "Donald E. Eastlake 3rd" 
> Cc: dns-security@tis.com, lazear@gateway.mitre.org
> Subject: Re: Expires RR proposal 
> 
> >SIG expiring should certainly wipe out an RR in a cache but it is not at all
> >clear to me that it should drop out of a zone and cause the AXFR sig to fail. 
> >So I think authoritative servers should keep it in the zone. 
> 
> I agree...it seems that an expired SIG RR means that the data is no longer
> secured, not that it's invalid.  Otherwise, how can you tell the difference
> between insecure and secured data?  Donald suggests sending the expired SIG
> with an answer...I'd prefer that the SIG disappear and the answer come back
> as unsigned (completely insecure, not just used-to-be secured).
> 
> 	Walt
> 

=====================================================================
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
Xref subject next

>Allowing any unsigned answer from a secure zone totally destorys all 
>security.  Any corrupt server can then answer anything it wants by just 
>leaving out the SIGs.  If you permit RRs with expired info to appear in 
>any sort of reply (zone transfer for regular query), it is absolutely 
>essential that the expired SIGs accompany it (unless its truncated in 
>which case it can be obtained by a separate query).
>
>Donald

Yes.  That's fine.  I don't think expired SIGs should cause automatic
zone updates; expired SIGs are part of the zone like anything else, and
they should be sent in answer along with the data they used to cover.
Secure resolvers should ignore the data if the accompanying signature
is unavailable (through truncation and failed query) or expired.

RRs should _not_ disappear, or appear to disappear, when their SIG expires.
-- 
Paul Vixie
La Honda, CA			"Illegitimibus non carborundum."

pacbell!vixie!paul

Xref subject next

For the past several years, this WG (and others such as SIP, SIPP, and
IPng, and other protocol designers such as SSL) strongly supported
orthogonality between the Authentication and Encapsulation (both privacy
and compression) facilities.

Recently, the WG chairs (without any stimulating WG comments) have tried
to move the WG toward a non-orthogonal all-in-one approach for ESP.

Last week, Ran Atkinson stood at the microphone, and stated (without
elaboration) that his previous support for an orthogonal approach was "a
serious mistake".

I ask, what was the mistake?

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Sorry to address the list, but just following the instructions in
"ftp.tis.com/pub/DNSSEC/Readme."

It seem that TIS' usual convention of hiding the floating subdir until you
respond to an ITAR notice is working here...but the README file does not
tell me what to do other than "get the file
/pub/DNSSEC/dist/dndsec-2d722a/dnssec-beta.1.tgz,"
which results in "file not found."  I assume "2d722a" is an old floater.

Where is the key to answer the question that will get me the floating subdir?

--Jim--

<< Jim Sanders, Staff Scientist - Transaction Security                     >>
<< Network Applications Services, Tandem Computers Incorporated            >>
<< Voice: 408-285-4192, FAX: 408-285-2380, Email: sanders_james@tandem.com
>>

Xref subject previous
Xref subject next

"Donald E. Eastlake 3rd" writes:
 > All data in a secure zone is supposed to be secured.  You can only get 
 > insecure data from insecure zones. 
Not quite true. 
Zone for example, can not sign the NS records of subzones.
If a server for the zone is NOT a secondary for the subzone then it will 
return the NS records without SIGs. 
Same goes for zone KEY records, they are not supposed to be signed by
the zone, if zone is missing .PARENT file then the KEY will be 
returned without signatures. 
In both these cases the records are supposed to be signed by someone else. 
Zone has the choice of not signing select other records, for example
informational records within signing scope of delegated keys. 

 >                                     I was only suggesting sending expired 
 > SIGs and the data they cover in zone transfers to avoid invalidataing the 
 > possibly pre-computed AXFR signature.
 > 
 > Allowing any unsigned answer from a secure zone totally destorys all 
 > security. Any corrupt server can then answer anything it wants by just 
 > leaving out the SIGs. 
I disagree, corrupt server can return any data it want, 
it can lie about the existence/content of any records it is asked about.
DNSSEC can prove that the data with SIGs a server returned is valid, 
but DNSSEC can not prevent a malicious server from trying to lie to you.
If you want strong protection against a subverted server, 
you need to check more than one source. 

 >                       If you permit RRs with expired info to appear in 
 > any sort of reply (zone transfer for regular query), it is absolutely 
 > essential that the expired SIGs accompany it (unless its truncated in 
 > which case it can be obtained by a separate query).

 > 
 > =====================================================================
 > 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
 > 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Olafur Gudmundsson		ogud@tis.com
(410)-442-0039 x400  489-4688 FAX (Baltimore Numbers)
http://www.tis.com/docs/Research/iip/dnssec.html

Xref subject previous

> From: smb@research.att.com
> Date: Sat, 09 Mar 96 14:48:32 EST
>
> There's a lot that needs to be rethought.  I could quite easily be
> persuaded that we shouldn't -- we've got to get this stuff
> deployed ASAP.

I'm with Bellovin on this.  I don't think we need a non-orthogonal
transform (even though I've written a draft).

The deployed AH-MD5 + ESP-DES is adequate.

> that we should simply decree that ESP
> must be used only in conjunction with AH

We already did, when the ESP transform doesn't provide integrity!!!

In addition to the numerous references in RFC-1825, -1826, and -1827,
RFC-1829 (ESP-DES) clearly states:

   The usual (ICMP, TCP, UDP) transport checksum can detect
   this attack, but on its own is not considered cryptographically
   strong.  In this situation, user or connection oriented integrity
   checking is needed [RFC-1826].

And you promised to write up a more thorough analysis of your attack....


> One small change -- the addition of replay protection --
> does seem to be needed, though.
>
Why?  Doesn't the underlying transport _already_ protect against replay?

That is, TCP and ICMP already protect themselves against replay.

So, you are recommending that the next version of -1826 provide a replay
prevention mechanism?  We've discussed this before, but Atkinson was
opposed.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

	 For the past several years, this WG (and others such as SIP,
	 SIPP, and IPng, and other protocol designers such as SSL)
	 strongly supported orthogonality between the Authentication
	 and Encapsulation (both privacy and compression) facilities.

	 Recently, the WG chairs (without any stimulating WG comments)
	 have tried to move the WG toward a non-orthogonal all-in-one
	 approach for ESP.

	 Last week, Ran Atkinson stood at the microphone, and stated
	 (without elaboration) that his previous support for an
	 orthogonal approach was a serious mistake".

	 I ask, what was the mistake?

While not completely worthless, ESP without both integrity protection
and replay prevention is significantly weakened in many real environments.
We therefore have a situation where ESP must be used in conjunction with
AH, and no document saying so.  Worse yet, we're paying the overhead
price for a new header twice.

I'm planning on writing an RFC explaining this, but I won't be able to
get to it till next week, most likely -- I have other writing committments
to finish up first.

Xref subject previous
Xref subject next


William Allen Simpson writes:
> For the past several years, this WG (and others such as SIP, SIPP, and
> IPng, and other protocol designers such as SSL) strongly supported
> orthogonality between the Authentication and Encapsulation (both privacy
> and compression) facilities.
> 
> Recently, the WG chairs (without any stimulating WG comments) have tried
> to move the WG toward a non-orthogonal all-in-one approach for ESP.

I must admit that I actually somewhat agree with the all-in-one
approach. In Toronto, when the current formats were produced, we
agreed that we needed separate AH and ESP transforms not because one
would handle authentication and the other encryption, but because AH
was needed to provide a transparent encapsulation while ESP would
provide an opaque encapsulation. The reasons we had for permitting ESP
transforms to include any combination of encryption, authentication
and integrity checking was partially because this would save a
substantial number of bits on the wire for slow links. Our notion
initially was that we were cutting the gordion knot of which
particular services were to be provided by leaving most of that to the
transform documents, permitting transforms that essentially did
anything, and simply specifying a method (the SPI) for determining
which transform was in use.

This is not to say that only all-in-one transforms should exist, but I
think there is indeed a place for them some of the time.

Perry

Xref subject previous
Xref subject next

> From: smb@research.att.com
> We therefore have a situation where ESP must be used in conjunction with
> AH, and no document saying so.

Hmmm, perhaps I am mistaken, but as I have already quoted the "documents
saying so" in a previous message, do I need to quote them again?

Why do you think that the documents don't say so?  Is there a suggestion
you could make to improve the text?


> Worse yet, we're paying the overhead
> price for a new header twice.
>
True.  That was the tradeoff for orthogonality.  It was 8 bytes for AH.

But, if we also require AH for message origin authentication, while ESP
provides integrity, we haven't saved anything.  As noted by Bob Baldwin
last week, we have a bigger hit for processing costs, too.

So, which do you prefer?  33% slower processing???

Look folks, we discussed this all last year.  We knew about the cut and
paste attack before we wrote the documents.  We referenced the Bellovin
presentation in the documents.

The "mistake" that Atkinson made MUST be something else that we didn't
already know about.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next


--Boundary-3762205-0-0

 
 
Mr. Simpson 
 
Your comments are out of line! 
 
>Recently, the WG chairs (without any stimulating WG comments) have tried 
>to move the WG toward a non-orthogonal all-in-one approach for ESP. 
 
There is a very clear consensous for a mandatory transform with ESP that 
contains both confidentiality and integrity.   
 
I have no bias to drive the specifications toward anything but to complete the 
best specification capturing the requirements and consensus of the working 
group.  While you may find long exchanges of rhetoric stimulating, most the 
working group have better ways to spend their free time. 
 
Please direct your delusions of intrigue to other venues.  If your comments 
have any purpose besides inflating the count of messages on this list 
containing your return address, please rephrase them as specific technical 
recommendations. 
 
 
 
 
 
Paul A. Lambert 
 
IPSEC Co-Chair 
 



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

Date: 11 Mar 96 22:07:45
From:"William Allen Simpson " 
To: ipsec@tis.com
Subject: AH and ESP Orthogonality
X-Orcl-Application: Sender:  ipsec-request@neptune.tis.com
X-Orcl-Application: Precedence:  bulk


For the past several years, this WG (and others such as SIP, SIPP, and
IPng, and other protocol designers such as SSL) strongly supported
orthogonality between the Authentication and Encapsulation (both privacy
and compression) facilities.

Recently, the WG chairs (without any stimulating WG comments) have tried
to move the WG toward a non-orthogonal all-in-one approach for ESP.

Last week, Ran Atkinson stood at the microphone, and stated (without
elaboration) that his previous support for an orthogonal approach was "a
serious mistake".

I ask, what was the mistake?

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2


--Boundary-3762205-0-0--

Xref subject previous
Xref subject next


William Allen Simpson writes:
> Look folks, we discussed this all last year.  We knew about the cut and
> paste attack before we wrote the documents.

Actually, we didn't during the initial drafts, and we were discussing
combined transforms as long ago as Toronto, though we didn't envision
making them mandatory at the time.

Anyway, lets just consider the situation on its current technical
merits, and not try to figure out who said what when...

Perry

Xref subject next

I agree that there are merits performing integrity along with encapsulation.
The only problem I see with it is that there will be deployments for IPSEC
in the very near future and most of the the implementations have implemented
RFC's 1828 and 1829. We definitely cannot stop this as many customers have
been asking for it.

This may cause configuration problems for old implementation (implementing
only 1829) to interoperate with the newer implementation which may support
both 1829 and the new transform. Can we allocated numbers to the transforms
as most of the key management protocols do so that configuring with manual
keying is simplified?

--Naganand

Xref subject previous
Xref subject next

> From: "Perry E. Metzger" 
> William Allen Simpson writes:
> > Look folks, we discussed this all last year.  We knew about the cut and
> > paste attack before we wrote the documents.
>
> Actually, we didn't during the initial drafts,

Ah, Perry, but I beg to differ.  We knew about general cut and paste
against CBC _long_ before we wrote the drafts.  It is a "feature" of
CBC itself.

Atkinson always had words in his drafts about the need for integrity.
There was always a strong consensus for providing integrity.

Bellovin merely described a specific scenario last April where cut and
paste was a problem, and integrity was required.  We added words to that
effect to our documents.


> and we were discussing
> combined transforms as long ago as Toronto, though we didn't envision
> making them mandatory at the time.
>
Yes, we were!  And we _decided_ as a WG _not_ to use them, that
orthogonality was better!


> Anyway, lets just consider the situation on its current technical
> merits, and not try to figure out who said what when...
>
My point is that we are rehashing old arguments, and undermining the
good work and deployment that this WG generated.

There has been no demonstrated need to eliminate orthogonality, and
worse, it has been shown to be computationally problematic.

What is the NEW attack, that we had not previously considered, that
would require a removal of orthogonality?

What was Atkinson's "serious mistake"?

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

Bill,

        Having orthogonal transformations was not necessarily a bad idea,
but there are benefits to having a better division of responsibility
between AH and ESP.  For example, the current definition of AH is messy
because either AH covers the entirity of an IP datagram (minus mutuable IP
header fields) or it covers just upper layer protocols.  The distinction is
a function of where AH appears relative to ESP.  Several of us would prefer
a verison of AH that applied to the whole datagram (as described above),
period.

        ESP, if it omits integrity and authenticity facilities, creates a
potential need for the embeded use of AH.  However, if one were to redefine
ESP to include optional authentication and integrity facilities, then there
would be no need to embed AH when the required services spanned those now
provided separately.  This would be more efficient from a bandwidth
standpoint, since a single header (ESP) could embody the fields necessary
for this larger set of services.  As it stands, ESP is a shell and all the
detail is added in each transform defintion.  This is unfortunate from a
document structuring standpoint.  It might be preferable if ESP defined
optional, variable length fields for carrying the necessary data to support
confidentiality and authentication and integrity.  The specific fields used
for a given SA would be defined at SA establishment, nailing this down for
efficient per-packet processing.  The result would be to make transform
definition documents more modular.

        Several folks, including yours truly, have expressed a desire to
add an anti-replay feature into the IPSEC suite.  This could be useful in
either AH or ESP, or both.  The motivation is to process and drop replayed
datagrams at an encrypting router, prior to letting them into a local net
environment.  (At a host this doesn't offer as much protection from a
denial of service perspective, so it is most attractive in the context I
cited.)    This is a reasonable service to offer either in the context of
AH or ESP.  The former is especially appropriate if AH is used as an outer
layer of protection that is stripped off at a firewall (perhaps with an
inner ESP layer that goes all the way to the destination host), and the
latter is especially appropriate of an ESP layer (used in tunnel mode) is
stripped off at the firewall, with no inner layer IPSEC.  The observation
that anti-replay is a reasonable feature for both AH and ESP further
motivates the creation of a single header that can provide all of the
services of AH and ESP, or any subset of the services.

        I disagree with Perry about opacity being an important feature of
ESP.  I participated in the Toronto WG meetings and hallway discussions and
I don't reacall opacity as a big deal, but I'm getting older so maybe my
memory ain't what it should be ;-).  In fact, I don't like the fact that
the ESP spec is so detail-free and I'm not convinced that we can't have a
header that allows for a wide range of combinations of confidentiality,
integrity/authenticity, and anti-replay mechanisms, all of which can be
optional, combined in a mix-and-match fashion.  I think that a new header,
providing such a set of features, might be what we should aim for.

Steve

Xref subject previous
Xref subject next


William Allen Simpson writes:
> > From: "Perry E. Metzger" 
> > William Allen Simpson writes:
> > > Look folks, we discussed this all last year.  We knew about the cut and
> > > paste attack before we wrote the documents.
> >
> > Actually, we didn't during the initial drafts,
> 
> Ah, Perry, but I beg to differ.  We knew about general cut and paste
> against CBC _long_ before we wrote the drafts.  It is a "feature" of
> CBC itself.

Actually, Bellovin came up with it in the hallway at Danvers outside
the terminal room. I was there when it happened. We had suspicions
that it was bad long before, but we didn't "know".

Again, however, this is history. Lets try to focus on what is best at
the moment, and not on what is historical.

> My point is that we are rehashing old arguments, and undermining the
> good work and deployment that this WG generated.

I don't think that we need to undermine anything, especially if we
declare the new transforms to be just that, *new* and better
transforms. Thats why I am against the notion of "replacement" and
want us to think instead in terms of things being "new and
improved". As I've said for a long time, our understanding of these
things gets refined with time and we have to expect to be coming up
with new transforms for new algorithims every few years for the rest
of the lifetime of the net. We should get used to it.

Perry

Xref subject previous
Xref subject next

ASIDE:
	I'm deliberately ignoring the notes to the IPsec list that focus on
"history" or "personal issues" rather than technology.  My silence does NOT
imply that I agree with others' views of history or that I agree with the
words that others are putting in my mouth.  Mainly, I'm focusing on writing
IP code.  I prefer writing IP code to playing rhetorical games with history
or personal issues.

In article <9603121331.AA17052@MAILSERV-H.FTP.COM> Naganand wrote:
>I agree that there are merits performing integrity along with encapsulation.
>The only problem I see with it is that there will be deployments for IPSEC
>in the very near future and most of the the implementations have implemented
>RFC's 1828 and 1829. We definitely cannot stop this as many customers have
>been asking for it.

	I don't think anyone has suggested that anyone stop deploying those
transforms, though it seems likely that at least RFC-1829 will move off the
standards-track to Historic status eventually.  It might later become the
case that some new transform would be mandatory-to-implement in lieu of
RFC-1829, but this could be addressed by adding support for an additional
transform whilst not removing support for the RFC-1829 transform -- if an
implementer chose to do such.

>This may cause configuration problems for old implementation (implementing
>only 1829) to interoperate with the newer implementation which may support
>both 1829 and the new transform. Can we allocated numbers to the transforms
>as most of the key management protocols do so that configuring with manual
>keying is simplified?

	I believe that more or less any publicly documented transform
should be allocated its own "transform identifier" by each of the various
key management proposals.  I specifically asked the ISAKMP authors to add
transform identifiers for the current Experimental transforms so that nodes
that choose to use those transforms can use ISAKMP for key mgmt.

NOTE: I have not fully grok'd Perry's anxiety over the word "replace" and
don't want to get into that here and now because it doesn't seem terribly
productive here and now.

	I will note that in my view if RFC-1829 were replaced on the
standards-track by an ESP DES-CBC+MD5+Replay transform, this would mean
that the replacement ESP DES-CBC+MD5+Replay transform would be allocated a
new "transform identifier" (i.e. transform identifier that is different
from the one that would remain allocated for RFC-1829).  I use "replace" in
the context of what the mandatory-to-implement transform would be rather
than in the context of what is meant by a particular "transform identifier"
number.

	This is just a matter of good protocol engineering.  If a transform
changes in a material way, then it needs a new published specification and
it needs a new "transform identifier".  We will probably continue to add
new and better transforms forever in the future as technology advances.
Implementers who don't design/build with the assumption that new transforms
will eventually come will probably regret it later on.

Bottom Line:	Naganand and others with similar concerns should not
		worry about this particular issue.  Key mgmt draft authors
		should allocate transform identifiers for each stable
		openly-published transform (An Internet-Draft is, by
		definition, not considered stable but an RFC is stable).

Ran
rja@cisco.com

Xref subject previous

> From: Naganand Doraswamy 
> The only problem I see with it is that there will be deployments for IPSEC
> in the very near future and most of the the implementations have implemented
> RFC's 1828 and 1829. We definitely cannot stop this as many customers have
> been asking for it.
>
I agree.


> This may cause configuration problems for old implementation (implementing
> only 1829) to interoperate with the newer implementation which may support
> both 1829 and the new transform. Can we allocated numbers to the transforms
> as most of the key management protocols do so that configuring with manual
> keying is simplified?
>
Well, I don't particularly like numbers for manual configuration, and
the RFC numbers can change as the documents are progressed along
standards track.

The way I'm doing it is by naming:

        MD5E            AH with MD5 "envelope"
        MD5N            AH with MD5 "nested"
        SHA1E           AH with SHA1 "envelope"
        SHA1N           AH with SHA1 "nested"
        DES1IV32        ESP with Single DES with 32-bit IV
        DES1IV64        ESP with Single DES with 64-bit IV
        DES3IV32        ESP with Triple DES with 32-bit IV
        DES3IV64        ESP with Triple DES with 64-bit IV

Make sense to you?

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    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: Stephen Kent 
>         Having orthogonal transformations was not necessarily a bad idea,
> but there are benefits to having a better division of responsibility
> between AH and ESP.

I agree.


> For example, the current definition of AH is messy
> because either AH covers the entirity of an IP datagram (minus mutuable IP
> header fields) or it covers just upper layer protocols.  The distinction is
> a function of where AH appears relative to ESP.  Several of us would prefer
> a verison of AH that applied to the whole datagram (as described above),
> period.
>
I understand.  You raised this last year.  But, other analysts prefered
the AH "inside" ESP approach.  So, there was no agreement.  Instead,
a flexible mechanism was defined, and the orthogonality allowed both
approaches.

Indeed, the chairs dictated to Jim Hughes in his DES+MD5 draft that the
MD5 apply to the "inside" plaintext, rather than the "outside"
ciphertext.  There were objections raised from the WG, such as Karn.
Outside allows detection of modification sooner, rather than after DES.

As you may remember, I'm an "outy" myself.


> It might be preferable if ESP defined
> optional, variable length fields for carrying the necessary data to support
> confidentiality and authentication and integrity.  The specific fields used
> for a given SA would be defined at SA establishment, nailing this down for
> efficient per-packet processing.  The result would be to make transform
> definition documents more modular.
>
The result would be to make the transform documents much more difficult
to understand and implement.  The WG rejected the variable fields
approach yet _again_ last week.

Instead, we nail down the specific _transforms_ at SA establishment.

Same result, easier to implement, easier to verify.


>         Several folks, including yours truly, have expressed a desire to
> add an anti-replay feature into the IPSEC suite.  This could be useful in
> either AH or ESP, or both.

I'm included in that "several folks".  We discussed this last year, and
again in January of this year.  It's in our latest ESP revision, and in
Photuris Extensions.  But, as you may remember Atkinson's message:

    Date: Thu, 22 Feb 1996 12:29:13 -0800
    Message-Id: <199602222029.MAA00276@puli.cisco.com>

    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.

So, the chairs are rather vehemently against adding replay protection,
even as a negotiated option.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

Bill,

Some refinements on our dicussion:

>I understand.  You raised this last year.  But, other analysts prefered
>the AH "inside" ESP approach.  So, there was no agreement.  Instead,
>a flexible mechanism was defined, and the orthogonality allowed both
>approaches.
>
>Indeed, the chairs dictated to Jim Hughes in his DES+MD5 draft that the
>MD5 apply to the "inside" plaintext, rather than the "outside"
>ciphertext.  There were objections raised from the WG, such as Karn.
>Outside allows detection of modification sooner, rather than after DES.


AH applied to the whole datagram is useful and a necessary facility,
whether provided by the current form of AH or some other header.  However,
the inside version of AH, applying only to upperlayer protocols, is
redundant if one defines ESP transforms that provide the same features.
That is why I would suggest that we redefine AH (or define another header)
that has one, well-defined scope.


>> It might be preferable if ESP defined
>> optional, variable length fields for carrying the necessary data to support
>> confidentiality and authentication and integrity.  The specific fields used
>> for a given SA would be defined at SA establishment, nailing this down for
>> efficient per-packet processing.  The result would be to make transform
>> definition documents more modular.
>>
>The result would be to make the transform documents much more difficult
>to understand and implement.  The WG rejected the variable fields
>approach yet _again_ last week.
>
>Instead, we nail down the specific _transforms_ at SA establishment.
>
>Same result, easier to implement, easier to verify.

I don't agree with your characterization of the tradeoffs here.  One header
that permitted various combinations of security services, would be more
complex than our existing headers and an individual transform such as
single DES with 64-bit IV.  However, as more transforms are added, each one
tends to duplicate significant pieces of previously defined transforms.
Moreover, when the transform includes not just one algorithm, but a
combination of algorithms (e.g., DES and MD5) and algorithm parameters, the
resulting set of documents gets pretty big in a hurry.  general
interoperability requires either that everyone uses just the default
transform, or that all implementations support many transforms, many with
very small differences from one another.

It isn't clear to me that there are significant differences in supporting
various transforms (as currently defined) vs. supporting a single header
type with optional, discretely variable length fields.  An implementor
still has to deal with some default subset of algorithms and combinations,
and then decide what optional ones also will be supported.  I'd like to
think that the result would be better modularity in the transform
definitions, although you clearly believe that the opposite will result.  I
guess those who would like to see this approach will have to try to write
the appropriate documents to see how it works out.

As for the cited message from Ran re the Photuris spec, I'm not sure I can
distinguish between criticism directed at those documents and the more
general issue of inclusion of anti-replay features in IPSEC.

Steve

Xref subject previous

In article <5053.wsimpson@greendragon.com> Bill Simpson wrote:

>    Date: Thu, 22 Feb 1996 12:29:13 -0800
>    Message-Id: <199602222029.MAA00276@puli.cisco.com>
>
>    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.
>
>So, the chairs are rather vehemently against adding replay protection,
>even as a negotiated option.

Bill,

  Not true.  The chairs are opposed to a key management protocol changing
the specification of material that is outside the scope of that key
management protocol specification.  Any attempt by any key management
specification to change the specifications contained in RFC-1825 thru
RFC-1827 is out of order.  Key management proposals MUST conform with
RFC-1825 through RFC-1827 and MUST NOT alter those specifications.

  Changes to RFC-1825 through RFC-1827 may be made only by the working
group as a whole.  If such changes are to be made, they will be reflected
in the revisions of RFC-1825 through RFC-1829 (which I will prepare in I-D
form presently).  If replay protection is added, then the key management
proposals can be modified to reflect that change afterwards.

Ran
rja@cisco.com

Xref subject previous

On Mon, 11 Mar 1996, Olafur Gudmundsson wrote:

> Date: Mon, 11 Mar 96 17:43:38 EST
> From: Olafur Gudmundsson 
> To: "Donald E. Eastlake 3rd" 
> Cc: ogud@tis.com, dns-security@tis.com
> Subject: Re: Expires RR proposal 
> 
> "Donald E. Eastlake 3rd" writes:
>  > All data in a secure zone is supposed to be secured.  You can only get 
>  > insecure data from insecure zones. 
> Not quite true. 
> Zone for example, can not sign the NS records of subzones.
> If a server for the zone is NOT a secondary for the subzone then it will 
> return the NS records without SIGs. 
> Same goes for zone KEY records, they are not supposed to be signed by
> the zone, if zone is missing .PARENT file then the KEY will be 
> returned without signatures. 
> In both these cases the records are supposed to be signed by someone else. 
> Zone has the choice of not signing select other records, for example
> informational records within signing scope of delegated keys. 

You are correct.  Non-authoritative data isn't signed.

>  >                                     I was only suggesting sending expired 
>  > SIGs and the data they cover in zone transfers to avoid invalidataing the 
>  > possibly pre-computed AXFR signature.
>  > 
>  > Allowing any unsigned answer from a secure zone totally destorys all 
>  > security. Any corrupt server can then answer anything it wants by just 
>  > leaving out the SIGs. 
> I disagree, corrupt server can return any data it want, 
> it can lie about the existence/content of any records it is asked about.
> DNSSEC can prove that the data with SIGs a server returned is valid, 
> but DNSSEC can not prevent a malicious server from trying to lie to you.
> If you want strong protection against a subverted server, 
> you need to check more than one source. 

What I should have said is that if the same data can sometimes appear 
securely signed and sometimes not when being fetched from a secure
zone from a security compliant server, then allowing the unsigned version 
opens you to accepting these lies.  On of the reasons for the NXT RR is 
so that you get something back signed even for non-exitent names and 
types...

>  >                       If you permit RRs with expired info to appear in 
>  > any sort of reply (zone transfer for regular query), it is absolutely 
>  > essential that the expired SIGs accompany it (unless its truncated in 
>  > which case it can be obtained by a separate query).

This was my main point.  If data is supposed to be signed, then you can't 
accept an unsigned statement that it has expired, you need a signed 
statement.

>  > =====================================================================
>  > 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
>  > 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Olafur Gudmundsson		ogud@tis.com
> (410)-442-0039 x400  489-4688 FAX (Baltimore Numbers)
> http://www.tis.com/docs/Research/iip/dnssec.html

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 next


All,

  The misrepresentations in the notes below are unproductive and
unwarranted.  The ongoing personal attacks on the chairs and other members
of the WG from Bill Simpson are not acceptable behavior in this or any
other IETF WG.  In future, notes that contain personal attacks will be
ignored in toto by the chairs.  If Bill keeps up his current behavior, we
suggest putting all incoming mail from Bill into /dev/null using a kill
file or other similar mechanism.  We suggest that others on the list ignore
the entire contents of all notes containing personal attacks and simply
don't respond to them or their author.

  It is entirely unproductive to focus on perceptions of history.  Instead
the discussions should focus on the technical issues before us so that
forward progress can be made.  Discussions about history, who said what
when to whom and so on cannot be objectively confirmed and only cause
confusion, contention and divisiveness. They are not productive.

  As to what Ran has said or what Ran believes, Bill's assertions are quite
false.  Ran is fairly confused as to how Bill came to his misperception of
the facts.  Ran's comments quoted below about the inappropriateness of
Bill's draft to alter the AH specification clearly indicates that it is a
problem of scoping.  AH/ESP specification changes MUST NOT be attempted by
any key management proposal.  Rather, the key management proposals MUST
conform to the AH/ESP specs.  If the WG later decides to modify the AH/ESP
specs at some time, then the key management specs can be correspondingly
modified at that future time.

  The WG chairs understand from the LA IETF meeting that keyed integrity on
the protected data of the ESP header is part of the mandatory ESP
transform.  Similarly, it is our understanding that implementation of
support for replay protection as part of ESP is mandatory.  Finally,
understanding that WG consensus is that the RFC-1829 transform should be
obsoleted on the standards track by a new ESP transform.  The new transform
will have a new transform identifier so as to avoid confusion with
RFC-1829.  The WG chairs have assigned the Document Editor position for
that new ESP transform to Jim Hughes.  The new transform will correct these
deficiencies in RFC-1829.  Once that new transform moves to Proposed
Standard, RFC-1829 will move to HISTORIC status and leave the standards
track.

  RFC-1825 through RFC-1828 are not yet able to be considered for
advancement to Draft Standard under IETF rules because of the cross
dependencies among each other and with the ESP transform.  They can be
considered for advancement once the new ESP transform has been at Proposed
Standard for 6 months and has at least 2 interoperable implementations.

  As none of the current Key Management proposals currently meet WG
requirements (though all could be modified to meet WG requirements), none
can proceed to Last Call or onto the Standards Track at this time.

  It is the prerogative of Working Group Chairs to decide who may edit
documents for their working group.

  Bill Simpson's behavior is incompatible with the requirements of Document
Editor for documents to be considered by the IPSEC Working Group for the
IETF Standards Track. Documents edited by Bill will not be considered by
the Chairs for consideration in the IPSEC Working Group. This does not
preclude others from listing Bill as co-author on documents in which he has
made significant technical contributions.

Randall Atkinson

rja@inet.org
Co-Chair, IP Security WG

PS:  Any complaints about this note should be directed at the Security AD,
	Jeff Schiller .

[Quoted notes follow]

----------------------------------------------------------------------
From: wsimpson@greendragon.com (William Allen Simpson)
To: ipsec@TIS.COM
Subject: AH and ESP Orthogonality
Message-ID: <5041.wsimpson@greendragon.com>
Date: 11 Mar 96 22:07:45 GMT

For the past several years, this WG (and others such as SIP, SIPP, and
IPng, and other protocol designers such as SSL) strongly supported
orthogonality between the Authentication and Encapsulation (both privacy
and compression) facilities.

Recently, the WG chairs (without any stimulating WG comments) have tried
to move the WG toward a non-orthogonal all-in-one approach for ESP.

Last week, Ran Atkinson stood at the microphone, and stated (without
elaboration) that his previous support for an orthogonal approach was "a
serious mistake".

I ask, what was the mistake?

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
----------------------------------------------------------------------
From: wsimpson@greendragon.com (William Allen Simpson)
To: ipsec@TIS.COM
Subject: Re: Alternative transform encapsulation scheme
Message-ID: <5040.wsimpson@greendragon.com>
Date: 11 Mar 96 21:42:41 GMT
Lines: 43

> From: smb@research.att.com
> Date: Sat, 09 Mar 96 14:48:32 EST
>
> There's a lot that needs to be rethought.  I could quite easily be
> persuaded that we shouldn't -- we've got to get this stuff
> deployed ASAP.

I'm with Bellovin on this.  I don't think we need a non-orthogonal
transform (even though I've written a draft).

The deployed AH-MD5 + ESP-DES is adequate.

> that we should simply decree that ESP
> must be used only in conjunction with AH

We already did, when the ESP transform doesn't provide integrity!!!

In addition to the numerous references in RFC-1825, -1826, and -1827,
RFC-1829 (ESP-DES) clearly states:

   The usual (ICMP, TCP, UDP) transport checksum can detect
   this attack, but on its own is not considered cryptographically
   strong.  In this situation, user or connection oriented integrity
   checking is needed [RFC-1826].

And you promised to write up a more thorough analysis of your attack....


> One small change -- the addition of replay protection --
> does seem to be needed, though.
>
Why?  Doesn't the underlying transport _already_ protect against replay?

That is, TCP and ICMP already protect themselves against replay.

So, you are recommending that the next version of -1826 provide a replay
prevention mechanism?  We've discussed this before, but Atkinson was
opposed.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
----------------------------------------------------------------------
From: wsimpson@greendragon.com (William Allen Simpson)
To: ipsec@TIS.COM
Subject: Re: AH and ESP Orthogonality
Message-ID: <5044.wsimpson@greendragon.com>
Date: 12 Mar 96 00:26:58 GMT
Lines: 33

> From: smb@research.att.com
> We therefore have a situation where ESP must be used in conjunction with
> AH, and no document saying so.

Hmmm, perhaps I am mistaken, but as I have already quoted the "documents
saying so" in a previous message, do I need to quote them again?

Why do you think that the documents don't say so?  Is there a suggestion
you could make to improve the text?


> Worse yet, we're paying the overhead
> price for a new header twice.
>
True.  That was the tradeoff for orthogonality.  It was 8 bytes for AH.

But, if we also require AH for message origin authentication, while ESP
provides integrity, we haven't saved anything.  As noted by Bob Baldwin
last week, we have a bigger hit for processing costs, too.

So, which do you prefer?  33% slower processing???

Look folks, we discussed this all last year.  We knew about the cut and
paste attack before we wrote the documents.  We referenced the Bellovin
presentation in the documents.

The "mistake" that Atkinson made MUST be something else that we didn't
already know about.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
----------------------------------------------------------------------
From: wsimpson@greendragon.com (William Allen Simpson)
To: ipsec@TIS.COM
Newsgroups: cisco.external.ietf.ipsec
Subject: Re: AH and ESP Orthogonality
Message-ID: <5048.wsimpson@greendragon.com>
Date: 12 Mar 96 13:25:54 GMT
Lines: 45

> From: "Perry E. Metzger" 
> William Allen Simpson writes:
> > Look folks, we discussed this all last year.  We knew about the cut and
> > paste attack before we wrote the documents.
>
> Actually, we didn't during the initial drafts,

Ah, Perry, but I beg to differ.  We knew about general cut and paste
against CBC _long_ before we wrote the drafts.  It is a "feature" of
CBC itself.

Atkinson always had words in his drafts about the need for integrity.
There was always a strong consensus for providing integrity.

Bellovin merely described a specific scenario last April where cut and
paste was a problem, and integrity was required.  We added words to that
effect to our documents.


> and we were discussing
> combined transforms as long ago as Toronto, though we didn't envision
> making them mandatory at the time.
>
Yes, we were!  And we _decided_ as a WG _not_ to use them, that
orthogonality was better!


> Anyway, lets just consider the situation on its current technical
> merits, and not try to figure out who said what when...
>
My point is that we are rehashing old arguments, and undermining the
good work and deployment that this WG generated.

There has been no demonstrated need to eliminate orthogonality, and
worse, it has been shown to be computationally problematic.

What is the NEW attack, that we had not previously considered, that
would require a removal of orthogonality?

What was Atkinson's "serious mistake"?

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
----------------------------------------------------------------------
From: wsimpson@greendragon.com (William Allen Simpson)
To: ipsec@TIS.COM
Newsgroups: cisco.external.ietf.ipsec
Subject: Re: AH and ESP Orthogonality
Message-ID: <5053.wsimpson@greendragon.com>
Date: 12 Mar 96 18:15:56 GMT
Lines: 67

> From: Stephen Kent 
>         Having orthogonal transformations was not necessarily a bad idea,
> but there are benefits to having a better division of responsibility
> between AH and ESP.

I agree.


> For example, the current definition of AH is messy
> because either AH covers the entirity of an IP datagram (minus mutuable IP
> header fields) or it covers just upper layer protocols.  The distinction is
> a function of where AH appears relative to ESP.  Several of us would prefer
> a verison of AH that applied to the whole datagram (as described above),
> period.
>
I understand.  You raised this last year.  But, other analysts prefered
the AH "inside" ESP approach.  So, there was no agreement.  Instead,
a flexible mechanism was defined, and the orthogonality allowed both
approaches.

Indeed, the chairs dictated to Jim Hughes in his DES+MD5 draft that the
MD5 apply to the "inside" plaintext, rather than the "outside"
ciphertext.  There were objections raised from the WG, such as Karn.
Outside allows detection of modification sooner, rather than after DES.

As you may remember, I'm an "outy" myself.


> It might be preferable if ESP defined
> optional, variable length fields for carrying the necessary data to support
> confidentiality and authentication and integrity.  The specific fields used
> for a given SA would be defined at SA establishment, nailing this down for
> efficient per-packet processing.  The result would be to make transform
> definition documents more modular.
>
The result would be to make the transform documents much more difficult
to understand and implement.  The WG rejected the variable fields
approach yet _again_ last week.

Instead, we nail down the specific _transforms_ at SA establishment.

Same result, easier to implement, easier to verify.


>         Several folks, including yours truly, have expressed a desire to
> add an anti-replay feature into the IPSEC suite.  This could be useful in
> either AH or ESP, or both.

I'm included in that "several folks".  We discussed this last year, and
again in January of this year.  It's in our latest ESP revision, and in
Photuris Extensions.  But, as you may remember Atkinson's message:

    Date: Thu, 22 Feb 1996 12:29:13 -0800
    Message-Id: <199602222029.MAA00276@puli.cisco.com>

    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.

So, the chairs are rather vehemently against adding replay protection,
even as a negotiated option.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
----------------------------------------------------------------------

Xref subject next

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

CYLINK Corporation
March 14, 1996


The following is a copy of an announcement I made in the IPSEC
and PKIX working group sessions at IETF Los Angeles.  In response to 
numerous requests, I am posting a copy of the announcement to the 
applicable IETF working group mailing lists.

-John Kennedy, CYLINK


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

CYLINK'S SUPPORT FOR OPEN PUBLIC KEY STANDARDS

EXISTING AND PROSPECTIVE CYLINK LICENSEES OF THE STANFORD PUBLIC 
KEY PATENTS MAY SUPPLEMENT THEIR LICENSES IN ACCORDANCE WITH THE 
FOLLOWING STATEMENT.:


ATTACHMENT "A"


STATEMENT OF PATENT POSITION

Cylink Corporation, through its wholly owned subsidiary Caro-Kann 
Corporation, holds exclusive sublicensing rights to the following 
U.S. patents owned by the Leland Stanford Junior University:

	Cryptographic Apparatus and Method 
	("Hellman-Diffie")......................... No. 4,200,770

	Public Key Cryptographic Apparatus and Method
	("Hellman-Merkle").............  No. 4,218,582 

In order to promote the widespread use of these inventions 
from Stanford University and adoption of the [Name IETF Standard] 
reference by the IETF community, [Name of Licensee] has acquired
the right under its sublicense from Cylink to offer the [Name IETF
Standard] reference implementation to all third parties on a royalty free
basis.  

This royalty free privilege is limited to use of the [Name IETF 
Standard] reference implementation in accordance with proposed,
pending or approved IETF standards, and applies only when used with
Diffie- Hellman key exchange, the Digital Signature Standard, or any other 
public key techniques which are publicly available for commercial
use on a royalty free basis.  Any use of the [Name IETF Standard] reference
implementation which does not satisfy these conditions and incorporates 
the practice of public key may require a separate patent license
to the Stanford Patents which must be negotiated with Cylink's
subsidiary, Caro-Kann Corporation.  


For additional licensing information please contact:

	Robert Fougner
	Director of Licensing
	CYLINK Corporation
	910 Hermosa Court
	Sunnyvale, CA  94086
	(408) 735-5893

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

Xref subject previous
Xref subject next

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

CYLINK Corporation
March 14, 1996


The following is a copy of an announcement I made in the IPSEC
and PKIX working group sessions at IETF Los Angeles.  In response to 
numerous requests, I am posting a copy of the announcement to the 
applicable IETF working group mailing lists.

-John Kennedy, CYLINK


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

CYLINK'S SUPPORT FOR OPEN PUBLIC KEY STANDARDS

EXISTING AND PROSPECTIVE CYLINK LICENSEES OF THE STANFORD PUBLIC 
KEY PATENTS MAY SUPPLEMENT THEIR LICENSES IN ACCORDANCE WITH THE 
FOLLOWING STATEMENT.:


ATTACHMENT "A"


STATEMENT OF PATENT POSITION

Cylink Corporation, through its wholly owned subsidiary Caro-Kann 
Corporation, holds exclusive sublicensing rights to the following 
U.S. patents owned by the Leland Stanford Junior University:

	Cryptographic Apparatus and Method 
	("Hellman-Diffie")......................... No. 4,200,770

	Public Key Cryptographic Apparatus and Method
	("Hellman-Merkle").............  No. 4,218,582 

In order to promote the widespread use of these inventions 
from Stanford University and adoption of the [Name IETF Standard] 
reference by the IETF community, [Name of Licensee] has acquired
the right under its sublicense from Cylink to offer the [Name IETF
Standard] reference implementation to all third parties on a royalty free
basis.  

This royalty free privilege is limited to use of the [Name IETF 
Standard] reference implementation in accordance with proposed,
pending or approved IETF standards, and applies only when used with
Diffie- Hellman key exchange, the Digital Signature Standard, or any other 
public key techniques which are publicly available for commercial
use on a royalty free basis.  Any use of the [Name IETF Standard] reference
implementation which does not satisfy these conditions and incorporates 
the practice of public key may require a separate patent license
to the Stanford Patents which must be negotiated with Cylink's
subsidiary, Caro-Kann Corporation.  


For additional licensing information please contact:

	Robert Fougner
	Director of Licensing
	CYLINK Corporation
	910 Hermosa Court
	Sunnyvale, CA  94086
	(408) 735-5893

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

Xref subject previous
Xref subject next

>----------------------------------------------------------------------------
>
>CYLINK Corporation
>March 14, 1996
>
>
>The following is a copy of an announcement I made in the IPSEC
>and PKIX working group sessions at IETF Los Angeles.  In response to 
>numerous requests, I am posting a copy of the announcement to the 
>applicable IETF working group mailing lists.
>
>-John Kennedy, CYLINK
>
>
>----------------------------------------------------------------------------
>
>CYLINK'S SUPPORT FOR OPEN PUBLIC KEY STANDARDS
>
>EXISTING AND PROSPECTIVE CYLINK LICENSEES OF THE STANFORD PUBLIC 
>KEY PATENTS MAY SUPPLEMENT THEIR LICENSES IN ACCORDANCE WITH THE 
>FOLLOWING STATEMENT.:
>
>
>ATTACHMENT "A"
>
>
>STATEMENT OF PATENT POSITION
>
>Cylink Corporation, through its wholly owned subsidiary Caro-Kann 
>Corporation, holds exclusive sublicensing rights to the following 
>U.S. patents owned by the Leland Stanford Junior University:
>
>	Cryptographic Apparatus and Method 
>	("Hellman-Diffie")......................... No. 4,200,770
>
>	Public Key Cryptographic Apparatus and Method
>	("Hellman-Merkle").............  No. 4,218,582 
>
>In order to promote the widespread use of these inventions 
>from Stanford University and adoption of the [Name IETF Standard] 
>reference by the IETF community, [Name of Licensee] has acquired
>the right under its sublicense from Cylink to offer the [Name IETF
>Standard] reference implementation to all third parties on a royalty free
>basis.  
>
>This royalty free privilege is limited to use of the [Name IETF 
>Standard] reference implementation in accordance with proposed,
>pending or approved IETF standards, and applies only when used with
>Diffie- Hellman key exchange, the Digital Signature Standard, or any other 
>public key techniques which are publicly available for commercial
>use on a royalty free basis.  Any use of the [Name IETF Standard] reference
>implementation which does not satisfy these conditions and incorporates 
>the practice of public key may require a separate patent license
>to the Stanford Patents which must be negotiated with Cylink's
>subsidiary, Caro-Kann Corporation.  
>
>
>For additional licensing information please contact:
>
>	Robert Fougner
>	Director of Licensing
>	CYLINK Corporation
>	910 Hermosa Court
>	Sunnyvale, CA  94086
>	(408) 735-5893
>
>----------------------------------------------------------------------------



How does this apply to a non-profit organization (such as a university)
that wants to make a "reference implementation" of an IETF protocol (that
uses Diffie-Hellman) freely available?  Under the RSAREF license, I
think this was possible, but has this changed things?

					Dave

--
David B. Johnson                      E-mail: dbj@cs.cmu.edu
Assistant Professor                   Home page: http://www.cs.cmu.edu/~dbj
Computer Science Department           Phone: (412) 268-7399
Carnegie Mellon University            Fax: (412) 268-5576
5000 Forbes Avenue
Pittsburgh, PA  15213-3891

Xref subject previous

>----------------------------------------------------------------------------
>
>CYLINK Corporation
>March 14, 1996
>
>
>The following is a copy of an announcement I made in the IPSEC
>and PKIX working group sessions at IETF Los Angeles.  In response to 
>numerous requests, I am posting a copy of the announcement to the 
>applicable IETF working group mailing lists.
>
>-John Kennedy, CYLINK
>
>
>----------------------------------------------------------------------------
>
>CYLINK'S SUPPORT FOR OPEN PUBLIC KEY STANDARDS
>
>EXISTING AND PROSPECTIVE CYLINK LICENSEES OF THE STANFORD PUBLIC 
>KEY PATENTS MAY SUPPLEMENT THEIR LICENSES IN ACCORDANCE WITH THE 
>FOLLOWING STATEMENT.:
>
>
>ATTACHMENT "A"
>
>
>STATEMENT OF PATENT POSITION
>
>Cylink Corporation, through its wholly owned subsidiary Caro-Kann 
>Corporation, holds exclusive sublicensing rights to the following 
>U.S. patents owned by the Leland Stanford Junior University:
>
>	Cryptographic Apparatus and Method 
>	("Hellman-Diffie")......................... No. 4,200,770
>
>	Public Key Cryptographic Apparatus and Method
>	("Hellman-Merkle").............  No. 4,218,582 
>
>In order to promote the widespread use of these inventions 
>from Stanford University and adoption of the [Name IETF Standard] 
>reference by the IETF community, [Name of Licensee] has acquired
>the right under its sublicense from Cylink to offer the [Name IETF
>Standard] reference implementation to all third parties on a royalty free
>basis.  
>
>This royalty free privilege is limited to use of the [Name IETF 
>Standard] reference implementation in accordance with proposed,
>pending or approved IETF standards, and applies only when used with
>Diffie- Hellman key exchange, the Digital Signature Standard, or any other 
>public key techniques which are publicly available for commercial
>use on a royalty free basis.  Any use of the [Name IETF Standard] reference
>implementation which does not satisfy these conditions and incorporates 
>the practice of public key may require a separate patent license
>to the Stanford Patents which must be negotiated with Cylink's
>subsidiary, Caro-Kann Corporation.  
>
>
>For additional licensing information please contact:
>
>	Robert Fougner
>	Director of Licensing
>	CYLINK Corporation
>	910 Hermosa Court
>	Sunnyvale, CA  94086
>	(408) 735-5893
>
>----------------------------------------------------------------------------



How does this apply to a non-profit organization (such as a university)
that wants to make a "reference implementation" of an IETF protocol (that
uses Diffie-Hellman) freely available?  Under the RSAREF license, I
think this was possible, but has this changed things?

					Dave

--
David B. Johnson                      E-mail: dbj@cs.cmu.edu
Assistant Professor                   Home page: http://www.cs.cmu.edu/~dbj
Computer Science Department           Phone: (412) 268-7399
Carnegie Mellon University            Fax: (412) 268-5576
5000 Forbes Avenue
Pittsburgh, PA  15213-3891

Xref subject next

IPsec members,
        I have just submitted two informational RFCs to the Internet 
Engineering Task Force that specify how the high performance RC5 cipher can 
be used to add privacy to packets transmitted over the Internet.  These two 
documents were developed by RSA Data Security Inc. and TimeStep 
Corporation.  They are being submitted for review by the security working 
groups of the IETF.  They are currently available from RSA's web and FTP 
sites.
        The first document describes the RC5 cipher in sufficient detail to 
create interoperable implementations.  It is titled "The RC5, RC5-CBC, 
RC5-CBC-Pad, and RC5-CTS Algorithms" by Bob Baldwin and Ronald Rivest and is 
available via ftp://ftp.rsa.com/pub/rc5/draft-rsadsi-rc5-00.txt.  The other 
document describes how to use the RC5-CBC cipher to encrypt IP packets 
following the framework defined by the IP Security Working Group of the 
IETF.  It is titled "The ESP RC5 Transform" and is available via: 
ftp://ftp.rsa.com/pub/rc5/draft-rsadsi-esp-rc5-00.txt.
        Please address comments and suggestions to baldwin@rsa.com or
to ipsec@ans.net.
                --Bob Baldwin

Xref subject previous

At 11:46 AM 3/13/96 -0800, Ran Atkinson wrote:
>
>  As none of the current Key Management proposals currently meet WG
>requirements (though all could be modified to meet WG requirements), none
>can proceed to Last Call or onto the Standards Track at this time.
>
Dear colleagues:

Well you all know what I mean.

I am sitting in the weekly AIAG (automotive industry action group) ANX
meeting.  I have given them an update of last week's events.

Bottom line:

I have been instructed to craft an AIAG letter placing a goal of this summer
for "a" standard key management protocol.  This will be the position of the
whole automotive industry, not just one OEM.  This letter will go to the lot
of you and your senior management (for at least those companies that do
major business with the auto industry).

Many of you know my personal feelings.  I have listened to your debates for
some time now.  At times I have wanted to say, "children, children...", but
I have not as I respect each of your technical abilities.  In this area, I
recognize that I am just the student.  Now all of you as the 'teachers' had
better come together, quickly.

If any special meetings are needed, within limits I can be available to
attend (please avoid friday's and weekends, my family is up in arms about my
extended absences ;) ).

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref subject previous
Xref subject next

In article <9602148268.AA826853770@snail.rsa.com>,
	 Bob Baldwin baldwin@rsa.com wrote:

>        I have just submitted two informational RFCs to the Internet 
>Engineering Task Force that specify how the high performance RC5 cipher can 
>be used to add privacy to packets transmitted over the Internet.  

FYI: 	
	A previous conversation via email with Bob Baldwin seems to
indicate that RSADSI claims intellectual property rights on RC5 in some
countries.  


Ran
rja@cisco.com

Xref subject previous
Xref subject next


Ran Atkinson writes:
> In article <9602148268.AA826853770@snail.rsa.com>,
> 	 Bob Baldwin baldwin@rsa.com wrote:
> 
> >        I have just submitted two informational RFCs to the Internet 
> >Engineering Task Force that specify how the high performance RC5 cipher can 
> >be used to add privacy to packets transmitted over the Internet.  
> 
> 	A previous conversation via email with Bob Baldwin seems to
> indicate that RSADSI claims intellectual property rights on RC5 in some
> countries.  

I'm curious as to whether these are being published as drafts or not;
Baldwin lists these as "informational RFCs" rather than as "internet
drafts".

Perry

Xref subject previous
Xref subject next

At 05:36 PM 3/14/96 PST, baldwin wrote:
>IPsec members,
>        I have just submitted two informational RFCs to the Internet 
>Engineering Task Force that specify how the high performance RC5 cipher can 
>be used to add privacy to packets transmitted over the Internet.  

This is the second time in the week that I have heard 'RC5', and have not
heard it mentioned before this.

I realize that many things happen in the crypto field that I do not see
right away, but how recent is the introduction of RC5 to the broader crypto
community?

What review has it had?

I ASSUME that it is a symetrical cypher; what are typical key lengths?  And
the strength of the cypher for a key length compared to other cyrphers: DES,
IDEA, RC2, RC4, etc.

Is the code in the draft sufficient for a full study?  Is this thus a major
deviation to RSA's handling of cyphers (compared to RC4, say).

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref subject previous
Xref subject next

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

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

   At 05:36 PM 3/14/96 PST, baldwin wrote:
   >IPsec members,
   >        I have just submitted two informational RFCs to the Internet 
   >Engineering Task Force that specify how the high performance RC5 cipher can
      
   >be used to add privacy to packets transmitted over the Internet.  
   
   This is the second time in the week that I have heard 'RC5', and have not
   heard it mentioned before this.
   
   I realize that many things happen in the crypto field that I do not see
   right away, but how recent is the introduction of RC5 to the broader crypto
   community?

~1995 or thereabouts.  This is a *very* new cipher, so it's not
something I'd actually want to implement or use until it's had a
lot more shakeout time.

See Ron Rivest's publications web page:

	http://theory.lcs.mit.edu/~rivest/publications.html

which contains:

	The RC5 Encryption Algorithm by Ronald L. Rivest. (To appear in
	Proceedings of the 1994 Leuven Workshop on Algorithms (Springer).) 

which is a link to:

	http://theory.lcs.mit.edu/~rivest/rc5.ps

The source code included in the paper is "(C) 1995 RSA Data Security
Inc.".



					- Bill


   




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

iQCVAwUBMU2hAVpj/0M1dMJ/AQEpsgP+I2pvNx2bKdJjwMwNEbCwveKFAZspXSfH
mFZ2kn8qL5+IGUoCHToA9bV69kdcfR5ThXWOHvU+YOD44xF718dkwmXli85op0r+
R0k9pCAR0DwNFJkw6drUpF0i6fv6oB20x2XCYH/XIfdaUpq/52VPqb7id0whFnH/
8dVcspd9pew=
=hYgq
-----END PGP SIGNATURE-----

Xref subject previous
Xref subject next


Robert Moskowitz writes:
> I realize that many things happen in the crypto field that I do not see
> right away, but how recent is the introduction of RC5 to the broader crypto
> community?

Fairly recent. RC5 is a proprietary algorithm owned by (who else) RSA
Data Security Inc.

> What review has it had?

A little; not what I'd call "strong review" the way that, say, 3DES
has had. I don't want to demean its creators, but in general one wants
to let these things be examined for quite a while before one trusts
them.

Perry

Xref subject previous
Xref subject next

> From: Bill Sommerfeld 
> 
>    At 05:36 PM 3/14/96 PST, baldwin wrote:
>    >IPsec members,
>    >        I have just submitted two informational RFCs to the Internet 
>    >Engineering Task Force that specify how the high performance RC5 cipher can
>       
>    >be used to add privacy to packets transmitted over the Internet.  
>    
>    This is the second time in the week that I have heard 'RC5', and have not
>    heard it mentioned before this.
>    
>    I realize that many things happen in the crypto field that I do not see
>    right away, but how recent is the introduction of RC5 to the broader crypto
>    community?
> 
> ~1995 or thereabouts.  This is a *very* new cipher, so it's not
> something I'd actually want to implement or use until it's had a
> lot more shakeout time.
> 

FYI - the algorithm is based on data-dependent rotates.
Not to beat a dead horse, but rotates can take anywhere
from 3-5 operations on a RISC (which typically don't
have rotates), and data-dependent rotates can double that.

Joe
----------------------------------------------------------------------
Joe Touch - touch@isi.edu		    http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM       http://www.isi.edu/atomic2/
USC / Research Assistant Prof.                http://www.isi.edu/lsam/

Xref subject previous
Xref subject next


Bill Sommerfeld writes:
>    I realize that many things happen in the crypto field that I do
>    not see right away, but how recent is the introduction of RC5 to
>    the broader crypto community?
> 
> ~1995 or thereabouts.  This is a *very* new cipher, so it's not
> something I'd actually want to implement or use until it's had a
> lot more shakeout time.

Just for context for everyone, the RSA DSI folks are (or at least,
were) attempting to push this thing they call S/WAN, which is
basically IPsec using RC5 to make it into something proprietary that
RSA DSI has a patent on and thus gets royalties for. It doesn't have
any real advantages to anyone other than RSA DSI, which has an obvious
stake in its widespread deployment...


Perry

Xref subject previous

Hearing no comments on the draft minutes I have submitted them to the
secretariat for posting to the IETF online directories and inclusion in the
proceedings.

Thanks,

Jim

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

Xref subject previous

Hearing no comments on the proposed charter I have submitted it as an
update to the IETF online directories.

Thanks,

Jim

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

Xref subject previous


 
Bob, 
 
 
>Is this thus a major deviation to RSA's handling of  
>cyphers (compared to RC4, say). 
 
Major, maybe.  Different, yes: 
 
 Algorithm       Intellectual Property Protection 
------------------------------------------------------- 
 RC4             Trade Secret 
 RC5             Patent (applied for?) 
 IDEA            Patent 
 DES             Open 
  
 
Does anyone have the patent numbers for RC5 and IDEA? 
 
 
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 
-------------------------------------------------------------- 
  

Xref subject next

>  I realize that many things happen in the crypto field that I do not see
>  right away, but how recent is the introduction of RC5 to the broader crypto
>  community?

Was being distributed on the net in 1994; published Dr. Dobb's
Journal, January 1995

>  What review has it had?

See Crypto '95 proceedings; Kaliski has a paper about it.

>  Is the code in the draft sufficient for a full study?

Yes, it's a very short algorithm, full source code is available, and
it's probably easier to understand it by reading the code than a
description of it.

Xref subject previous
Xref subject next

In a galaxy far, far away, perry@piermont.com said:
> Just for context for everyone, the RSA DSI folks are (or at least,
> were) attempting to push this thing they call S/WAN, which is
> basically IPsec using RC5 to make it into something proprietary that
> RSA DSI has a patent on and thus gets royalties for. It doesn't have
> any real advantages to anyone other than RSA DSI, which has an obvious

  For a little more context: the RSA folks got most of the firewall vendors
together last August to discuss RSA DSI and firewalls. We had a problem: we
needed to interoperate on virtual private network technology, particularly
when it came to road-warrior notebooks. We agreed that swipe and SKIP were
interesting, but that the firewall vendors had to implement something that
the PC/Mac stack vendors were going to implement. 
  Thus S/WAN was born. Just take the then current ipsec, nail some parameters
down, and take the first step.
  The various vendors didn't really have anyone that they felt could coordinate
their efforts. While RSA Data Systems isn't a dis-interested party, at least
they are non-firewall-vendor aligned: we know what their interests are. 

-- 
      mcr@milkyway.com       |     ">Milkyway 
Networks Corporation
   Michael C. Richardson     |   Makers of the Black Hole firewall 
 Senior Research Specialist  | info@milkyway.com for BlackHole questions
 Home: 
.html">mcr@sandelman.ocunix.on.ca. 

Xref subject previous
Xref subject next

At 10:33 AM 3/18/96 -0800, touch@ISI.EDU wrote:

>> ~1995 or thereabouts.  This is a *very* new cipher, so it's not
>> something I'd actually want to implement or use until it's had a
>> lot more shakeout time.
>> 
>
>FYI - the algorithm is based on data-dependent rotates.
>Not to beat a dead horse, but rotates can take anywhere
>from 3-5 operations on a RISC (which typically don't
>have rotates), and data-dependent rotates can double that.

Joe,

Sorry for my inability to parse your words, but

Are you saying that:

A) RC5 is not high performance on a RISC

or

B) RC5 is relatively easy to brute strength attack on a RISC.

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref subject previous
Xref subject next

In a galaxy far, far away, : Mon, 18 Mar 1996 16:08:28 EST
> swIPe was a long dead experiment. SKIP is a key management protocol,
> which fits in the same place in the stack as Photuris or Oakley.

  This was August 1995. Vendors wanted to interoperate *soon*
  swIPe was on the list because it was out there.
  SKIP as implemented by SunScreen (not IPsec based) was also out there.
  Neither had any likelyhood of being found on a 4Mb 486/33 running Win3.11.

> We already had perfectly good IPsec transforms written and in place,
> by the way.

  Yes. Which is why the other "options" were quickly discarded.

> The only difference I can see between IPsec and S/WAN is that S/WAN
> uses RC5 instead of something like 3DES. Can you correct me on this?

  The original "spec" said MD5 and DES. RSA quickly added RC5. Whether or
not anyone actually tested that I don't remember.

> The IETF, perhaps?

  :-)

  That was my suggestion actually. In the end, we (Milkyway Networks) didn't
have the scheduling flexibility to come up with anything to test. Our current
VPN is Entrust based. 


-- 
      mcr@milkyway.com       |     ">Milkyway Networks Corporation
   Michael C. Richardson     |   Makers of the Black Hole firewall 
 Senior Research Specialist  | info@milkyway.com for BlackHole questions
 Home: ">mcr@sandelman.ocunix.on.ca. 

Xref subject previous
Xref subject next

*** Reply to note of 03/18/96 14:06                                            
From the desk of:                                                              
   IBM Internal Use Only                                                       
SUBJECT: Re: ESP transform with RC5                                            
                                                                               
Re: absence of rotate on RISC processors                                       
                                                                               
Do you mean that an encryption algorithm must not be chosen which              
uses rotates because RISC processors don't have them, and everyone             
knows it?                                                                      
(dead horse - argued to death, well decided )                                  
                                                                               
This is not well decided.  Its invalid.  The RS6000 / PowerPC has              
single instruction variable count rotates which work in a single cycle.        
This cycle is likely to be overlapped with something else like I/O             
and disappear.                                                                 
                                                                               
Even other superscalar RISC processors which do not could still                
parallelize the sub-operations to some extent and overlap them                 
with I/O.                                                                      
                                                                               
The pentium and 486 have rotate instructions but they are many                 
cycle instructions. Presumably they don't use a barrel shifter.                
                                                                               
                                    regards,                                   
                                                                               
                                      Oscar Strohacker                         
                                                                               
                                                                               
Advisory Engineer/Scientist                                                    
Data Compression Systems Architecture                                          
IBM Microelectronics Division                                                  
11400 Burnet Road                                                              
Austin Texas 78758                                                             
                                                                               
o (512) 838-4077      f (512) 838-7004         Internet: stroh @ vnet.ibm.com  
                                                                               

Xref subject previous
Xref subject next

> From: Robert Moskowitz 
> Subject: Re: ESP transform with RC5
> 
> At 10:33 AM 3/18/96 -0800, touch@ISI.EDU wrote:
> 
> >> ~1995 or thereabouts.  This is a *very* new cipher, so it's not
> >> something I'd actually want to implement or use until it's had a
> >> lot more shakeout time.
> >> 
> >
> >FYI - the algorithm is based on data-dependent rotates.
> >Not to beat a dead horse, but rotates can take anywhere
> >from 3-5 operations on a RISC (which typically don't
> >have rotates), and data-dependent rotates can double that.
> 
> Joe,
> 
> Sorry for my inability to parse your words, but
> 
> Are you saying that:
> 
> A) RC5 is not high performance on a RISC

This.
 
I suspect it is just "not high performance", period.

Joe
----------------------------------------------------------------------
Joe Touch - touch@isi.edu		    http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM       http://www.isi.edu/atomic2/
USC / Research Assistant Prof.                http://www.isi.edu/lsam/

Xref subject previous
Xref subject next

In a galaxy far, far away, : Mon, 18 Mar 1996 16:44:04 EST
> >   This was August 1995. Vendors wanted to interoperate *soon*
> 
> August 1995 was after the IPsec documents had gone to RFC (indeed, the
> documents are dated August, 1995). They had long since been in last

  Again, I'm reporting what was discussed. I don't think the timing of the
RFCs has much to do with what has been implemented and what has not been
implemented.
  Why was swIPe on the table? I believe that TIS and Raptor have firewalls
out their in the field running it.
  Why was SKIP on the table (and yes, there *is* a pre-IPsec version)? Sun
was there talking about it. They *said* there were two versions that that
the IPsec version was being worked on as they spoke.

> Actually it wasn't out there any longer; it had more or less been
> informally withdrawn long before, after the Toronto IETF as I
> recall. It was just an experiment.

  S/WAN is *not* a proposed IETF standard. It is a set of parameters that 
explains how to interoperate *today*. We could have picked swIPe, for instance.

> Why did they have a "spec" at all when we had RFC's 1825-1829 already
> out? This all strikes me as odd.

  The 'spec' is says what S/WAN is going to test. I'd call it a "test spec" 
more than a design spec.
  I don't recall discussion about RC4 or RC5 from other than RSA people. But,
again, we were pretty clear about what there interests were.

Xref subject previous
Xref subject next


Michael Richardson writes:
>   For a little more context: the RSA folks got most of the firewall vendors
> together last August to discuss RSA DSI and firewalls. We had a problem: we
> needed to interoperate on virtual private network technology, particularly
> when it came to road-warrior notebooks. We agreed that swipe and SKIP were
> interesting, but that the firewall vendors had to implement something that
> the PC/Mac stack vendors were going to implement. 

Er, there is perhaps a misperception here.

swIPe was a long dead experiment. SKIP is a key management protocol,
which fits in the same place in the stack as Photuris or Oakley.

We already had perfectly good IPsec transforms written and in place,
by the way.

>   Thus S/WAN was born. Just take the then current ipsec, nail some parameters
> down, and take the first step.

The only difference I can see between IPsec and S/WAN is that S/WAN
uses RC5 instead of something like 3DES. Can you correct me on this?

>   The various vendors didn't really have anyone that they felt could
> coordinate their efforts.

The IETF, perhaps?

Perry

Xref subject previous
Xref subject next


 
Perry, 
 
Please be fair. 
 
>No fee for the use of the patent in free software,  
>for example, and they don't attempt to assert  
>rights when they have none.  RSA hasn't shown the 
>same sort of behavior. 
 
RSA to their credit has published RSAREF for free non-commercial usage. 
 
The IETF process must support the definition of technologies that can be 
produced by vendors for a profit.  Selecting technologies that have no fee for 
free software limits the creation of "commercial" software. 
 
While we all may not like to pay for patented technologies, this mailing list 
is not an appropriate forum to attack companies attempting to make money on 
their inventions.  Where we can in the standards process we should avoid 
patented technologies.  Where patents are unavoidable or provide significant 
advantages the working group they are acceptable only when available with a 
"reasonable" and non-exclusive license. 
 
 
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 
-------------------------------------------------------------- 
  

Xref subject previous
Xref subject next


I want to make it clear in advance that I'm not trying to be hostile
here. E-Mail often removes niceties like facial expression. I'm more
trying to figure out what was going on at RSA DSI than anything else.

Michael Richardson writes:
> In a galaxy far, far away, : Mon, 18 Mar 1996 16:08:28 EST
> > swIPe was a long dead experiment. SKIP is a key management protocol,
> > which fits in the same place in the stack as Photuris or Oakley.
> 
>   This was August 1995. Vendors wanted to interoperate *soon*

August 1995 was after the IPsec documents had gone to RFC (indeed, the
documents are dated August, 1995). They had long since been in last
call and were very stable. You have apparently been misinformed about
the timing of our efforts.

>   swIPe was on the list because it was out there.

Actually it wasn't out there any longer; it had more or less been
informally withdrawn long before, after the Toronto IETF as I
recall. It was just an experiment.

>   SKIP as implemented by SunScreen (not IPsec based) was also out there.

Actually SKIP *is* IPsec based (though I've had interoperation
disputes with the SKIP people).

> > We already had perfectly good IPsec transforms written and in place,
> > by the way.
> 
>   Yes. Which is why the other "options" were quickly discarded.
> 
> > The only difference I can see between IPsec and S/WAN is that S/WAN
> > uses RC5 instead of something like 3DES. Can you correct me on this?
> 
>   The original "spec" said MD5 and DES.  RSA quickly added RC5.

Why did they have a "spec" at all when we had RFC's 1825-1829 already
out? This all strikes me as odd.

Perry

Xref subject previous
Xref subject next

> From: stroh@vnet.ibm.com
> Re: absence of rotate on RISC processors                                       
> Do you mean that an encryption algorithm must not be chosen which   
> uses rotates because RISC processors don't have them, and everyone            > knows it?                                                                     
> (dead horse - argued to death, well decided )

No. Only that variable-count rotates are not one-cycle opcodes
on many processors, and that their use can substantially affect
performance of the algorithm.
                             
> This is not well decided.  Its invalid.  The RS6000 / PowerPC has          
> single instruction variable count rotates which work in a single cycle.       

SPARC and MIPS don't. Alphas do, but only for 32-bit operands
(by doubling the data and shifting it within 64-bit registers).
                        
> Even other superscalar RISC processors which do not could still   
> parallelize the sub-operations to some extent and overlap them  
> with I/O.

Only if the computation is I/O intensive. Authentication and
encryption algorithms tend to be compute-intensive, and the
one's I've had a chance to look at are also highly linear.
The result is that the computations don't overlap at all, and that
the number of clocks per basic operation affects the overall
algorithm performance.

The Sigcomm paper on MD5 ('95) indicated ways to design algorithms
which could be computationally efficient, both in hardware and
in software. Data-dependent rotates are not one of those ways.

Joe


                                                                 >                                                                               
> The pentium and 486 have rotate instructions but they are many              
> cycle instructions. Presumably they don't use a barrel shifter.          
----------------------------------------------------------------------
Joe Touch - touch@isi.edu		    http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM       http://www.isi.edu/atomic2/
USC / Research Assistant Prof.                http://www.isi.edu/lsam/

Xref subject previous
Xref subject next

	 The IETF process must support the definition of technologies that
	 can e produced by vendors for a profit.

Since this is an informational RFC in any event, it doesn't matter
much.  RFC 1602 puts certain restrictions on standards-track RFCs;
it says nothing whatsoever about patents and non-standards documents.

It's also worth noting that RC5 poses some interesting technical issues.
For example, it is parameterized, and none of the key management mechanisms
we are considering seem to support that.  Possibly, the parameters could
be encoded as part of the key -- but we're moving down a track in which
keys are true-random numbers.  Besides, it may be necessary to negotiate
some of the parameters under certain circumstances -- some folks may only
have 40-bit RC5 implementations available to them, for the usual obvious
reasons.

Xref subject previous
Xref subject next


 
>From:     Michael Richardson 
<.... 
>  Again, I'm reporting what was discussed. 
<... stuff removed 
> Why was swIPe on the table? 
<  ... etc. .. 
 
I am not sure where the discussion is going in trying to examine the history 
of IP layer security mechanisms and proposals.  The technology represents many 
years of research and our Internet focus is often myopic in viewing only the 
free software or mailing list posted efforts. 
 
The original ARPA work was started in the late 70's.  Public specifications 
were available for SP3 in 1988 for IP security complete with a key management 
protocol (KMP).  NLSP circa 1991 is an international specification (derived 
from SP3) with many implementations in Europe.  Commercial implementations 
based on SP3 and NLSP started to appear in 1992.  swIPe was one of the first 
free implementations posted and so was adopted quickly by some vendors.  
Significant "commercial" vendor interest did not appear until last year with 
many Firewall and router vendors backing the use of IP layer security. 
 
To my knowledge, all of the S/WAN testing has been directed at the "baseline" 
definitions of AH and ESP.  These are DES and MD5 based encapsulations.  
Additional algorithms, like RC5, have been added by vendors for "extra credit" 
(aka perception of market benefits). 
 
ESP with RC5 will be an Informational RFCs.  ESP-RC5 will not be a "baseline" 
mechanism since the consensus of the group for a long time has been to use DES 
as the "mandatory" algorithm for confidentiality. 
 
 
Paul

Xref subject next

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

Monday, March 18, 1996

Bill:
        I have considered your request to remove the chairs of the
IPSEC Working Group. I have taken this matter seriously and have
consulted with many people about what they believe is happening in the
Working Group. I have also been attending most of the face to face
meetings myself and read the mailing list, so I have my own
observations as well.

My Findings:

o Chairing the IPSEC Working Group is a difficult job. There are
  competing proposals, differing views of the requirements (mostly in
  terms of how important various requirements are), and investment made
  by proposal submitters.

o You have in the past made significant technical contributions to the
  IPsec standards.  Your technical abilities are considerable when you
  choose to use them and you are always an active participant.

o Your behavior in the working group has been less than professional.
  You tend to dominate any discussion that interests you. You do not
  respect the prerogative of the chair(s) to facilitate the working
  group.

o Your behavior causes many people to become intimidated and unwilling
  to contribute their ideas when you are present. You tend to dominate
  any discussion that interests you so that other people's useful
  technical inputs are drowned out or otherwise impeded.

Other:

        I have also had people report to me that you have threatened
them with lawsuits and otherwise used intimidation tactics when other
avenues of argument were not available to you. Furthermore I interpret
your message to the Working Group on 3/14/96 as an attempt to
intimidate the chairs and Working Group by making your appeal to me
public and threatening to continue to appeal until some body finds in
your favor.

        Remember the motto: "Rough consensus and running code." Rough
consensus does not mean a consensus that Bill Simpson will always
agree with. By threatening appeals, lawsuits and by just plain
shouting people down, you are not participating in a consensus
process. You are in violation of the Spirit of the IETF process, in my
opinion.

Therefore I Conclude:

        I can find no reason to believe that the Working Group Chairs
should be removed on the basis of your appeal. In fact I have
discovered that the Working Group chairs have often gone out of their
way to ensure that they were as fair as possible to you and your
proposals.

        Furthermore I agree with the Working Group chairs that your
behavior has been unacceptable. I interpret Paul's use of the word
"fire" to convey to the Working Group members that you have no special
status in the working group and members do not have to pay any
particular attention to you.

        I would go so far as to add that as long as your behavior
continues to be unacceptable, members of the working group should feel
free to ignore you, consensus can well be reached without you.

        I am sorry that it had to come to this. I believe that you
have a strong technical background and good insights. However your
talent is wasted if you cannot work and communicate in a civilized
manner.

        At this point you have two choices. You can either appeal my
decision to the IESG if you so choose or you can alter your behavior
and become a contributing productive member of the IPSEC working group
and the IETF as a whole. The choice is yours.

                                -Jeff Schiller
                                Area Director for Security
                                Internet Engineering Steering Group
                                Internet Engineering Task Force

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

iQCVAwUBMU4/88UtR20Nv5BtAQGsDQP/YeWGDQLcNnNGSQRyaxGei2yf6XA5pBGz
up7asMKORhbYtM+cQTvF07RbCKslZc9pcUwH9E4i0O4CnY4m3OFx9uvI4rKwcIP1
Csb22Lkd2BwnbV7+732vkkFA4lNHuiDML1NCU5lQaBH43iXXmJklFLpjF1AMsHpc
gbJnFc2bbtY=
=Owey
-----END PGP SIGNATURE-----

Xref subject next

Last month, Qualcomm filed with the State Department an application to
export my IP Security (ESP) code for KA9Q NOS to Singapore.

Our stated purpose was to encrypt an Internet "tunnel" between
Qualcomm's US facilities and our office in Singapore, which is staffed
by two US citizens. We stated that the software would be used solely
for this purpose and would not be transferred to anyone else.

Our application indicated that the software in question supported both
single and triple DES.

On March 11, the Office of Defense Trade Controls returned our application
stamped "RETURNED WITHOUT ACTION". The following form was attached:

					United States Department of State
					Bureau of Political-Military Affairs
					Office of Defense Trade Controls

					Washington, DC 20520-0602
					MAR 11 1996 [stamped]

IN REPLY REFER TO
DTC CASE - 664149

The enclosed application has been voided and is being RETURNED WITHOUT
ACTION for the reasons indicated below:

_X_1. Submit a new application including all required background and
      documentation. Do not return the enclosed application.

[25 other unchecked items omitted. These referred mainly to administrative
problems like "you used the wrong form", "you didn't file enough copies
of the supporting technical data", etc.

_X_27. Please submit another license [sic] once your software has been
       modified so that it no longer contains triple DES.  Please specify
       object code only on your license application.

					[signed]
					Darlene Staniszewski
					Licensing Officer
					(703) 875-5677

[end of form]

So there you have it. NSA makes good on its threat to ANSI X9 that
triple DES would not be exportable.

This was a case where keeping strong crypto out of the hands of
terrorists and unfriendly governments was clearly not at issue. It
dealt strictly with the ability of a US corporation to defend its
international operations against against industrial espionage. Or,
perhaps more to the point, espionage by the NSA.

Certainly seems like a good argument in favor of the Leahy bill to me.

One mildly interesting thing about this form letter response is that
item 27 appeared to be part of the standard form -- it wasn't typed
into an "other" field of an existing form. Perhaps they added it to
the word processing file for this one occasion. Or perhaps they deny
triple DES exports so regularly that they now have a standard form
item to deal with it.

Phil Karn

Xref subject previous
Xref subject next

At 03:01 PM 3/18/96 -0500, Michael Richardson wrote:
>
>  For a little more context: the RSA folks got most of the firewall vendors
>together last August to discuss RSA DSI and firewalls. We had a problem: we
>needed to interoperate on virtual private network technology, particularly
>when it came to road-warrior notebooks. We agreed that swipe and SKIP were
>interesting, but that the firewall vendors had to implement something that
>the PC/Mac stack vendors were going to implement. 
>  Thus S/WAN was born. Just take the then current ipsec, nail some parameters
>down, and take the first step.
>  The various vendors didn't really have anyone that they felt could coordinate
>their efforts. While RSA Data Systems isn't a dis-interested party, at least
>they are non-firewall-vendor aligned: we know what their interests are. 

This, of course, is of key interest to the auto industry.  We need this sort
of interoperability on a fairly large scale.  This is why I have been active
in the IPSEC wg, in case you haven't guessed ;)

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref subject previous
Xref subject next

At 11:20 PM 3/18/96 -0800, Phil Karn wrote:
>
>So there you have it. NSA makes good on its threat to ANSI X9 that
>triple DES would not be exportable.
>
>This was a case where keeping strong crypto out of the hands of
>terrorists and unfriendly governments was clearly not at issue. It
>dealt strictly with the ability of a US corporation to defend its
>international operations against against industrial espionage. Or,
>perhaps more to the point, espionage by the NSA.

This raises an interesting question WRT RC5 and smb's note.

Can RC5 parameters be set so that it reaches 3DES strength, and if so, if
the keying protocol allows for full parameter control, might NSA do the same
with RC5 as it is doing to 3DES?  Or specify that the keying protocol lock
down a certain set of RC5 parameters?

OOOps, what have I done?  The NSA watchers of this list (not meaning Mark
and his fellows, but the 'other side') way now go off and have to figure
this all out  :)



Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref subject previous
Xref subject next

At 06:42 PM 3/18/96 EST, smb@research.att.com wrote:
>
>It's also worth noting that RC5 poses some interesting technical issues.
>For example, it is parameterized, and none of the key management mechanisms
>we are considering seem to support that.  Possibly, the parameters could
>be encoded as part of the key -- but we're moving down a track in which
>keys are true-random numbers.  Besides, it may be necessary to negotiate
>some of the parameters under certain circumstances -- some folks may only
>have 40-bit RC5 implementations available to them, for the usual obvious
>reasons.

Seems that an RC4 ESP would have a simliar need?  Of course, I'd suspect
that only RSA would submit an RC4 ESP and they have already moved on to 5...

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref subject previous
Xref subject next

>Can RC5 parameters be set so that it reaches 3DES strength, and if so, if
>the keying protocol allows for full parameter control, might NSA do the same
>with RC5 as it is doing to 3DES?  Or specify that the keying protocol lock
>down a certain set of RC5 parameters?

RC5 is a stream cipher that allows for variable length keys.  I would guess
that RC5 using 40-bit (or less) keys would be exportable, but greater than
40 bits would not.  That's what's been done for other ciphers that employ
variable length keys.

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

Xref subject next

        Here is a short section from the informational RFC on
the RC5 cipher.  It seems to answer many of the questions we have
seen posted to the list.
                --Bob


1. Executive Summary

This document defines three ciphers with enough detail to ensure 
interoperability between different implementations.  The first cipher is 
the raw RC5 block cipher.  The RC5 cipher takes a fixed size input block 
and produces a fixed sized output block using a transformation that depends 
on a key.  The second cipher, RC5-CBC, is the Cipher Block Chaining (CBC) 
mode for RC5.  It can process messages whose length is a multiple of the 
RC5 block size.  The third cipher, RC5-CBC-Pad, includes padding in the CBC 
mode to allow it to process inputs of any byte length.

The RC5 cipher was invented by Professor Ronald L. Rivest of the 
Massachusetts Institute of Technology in 1994.  It is a very fast and 
simple algorithm that is parameterized by the block size, the number of 
rounds, and key length.  These parameters can be adjusted to meet different 
goals for security, performance, and exportability.

A patent application has been filed for the RC5 cipher.  The terms RC5, 
RC5-CBC, RC5-CBC-Pad and assorted variations on these are trademarks.

I fully realize the IETF aversion to ISO standards (including my own),
but I need to ask anyway .....

Does anyone know of any systems that implement standard security
audit trails as specified in ISO/IEC 10164-8, 1993 (Information
Technology - Open Systems Interconnection - Systems Management - Part
8: Security Audit Trail Function (ITU-T X.740)?

Thanks,

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|
|________________________________________________________________________|

        For those interested in the security of RC5.  Here is the
section from the RC5 description document.
                --Bob

9. Security Considerations

The RC5 cipher is relatively new so critical reviews are still being 
performed.  However, the cipher's simple structure makes it easy to analyze 
and hopefully easier to assess its strength.  Reviews so far are very 
promising.

Early results [1] suggest that for RC5 with a 64 bit block size (32 bit 
word size), 12 rounds will suffice to resist linear and differential 
cyptanalysis.  The 128 bit block version has not been studied as much as 
the 64 bit version, but it appears that 16 rounds would be an appropriate 
minimum.  Block sizes less than 64 bits are academically interesting but 
should not be used for cryptographic security.  Greater security can be 
achieved by increasing the number of rounds at the cost of decreasing the 
throughput of the cipher.

The length of the secret key helps determine the cipher's resistance to 
brute force key searching attacks.  A key length of 128 bits should give 
adequate protection against brute force key searching by a well funded 
opponent for a couple decades [7].  For RC5 with 12 rounds, the key setup 
time and data encryption time are the same for all key lengths less than 
832 bits, so there is no performance reason for choosing short keys.  For 
larger keys, the key expansion step will run slower because the user key 
table, LL, will be longer than the expanded key table, S.  However, the 
encryption time will be unchanged since it is only a function of the number 
of rounds.

To comply with export regulations it may be necessary to choose keys that 
only have 40 unknown bits.  A poor way to do this would be to choose a 
simple 5 byte key.  This should be avoided because it would be easy for an 
opponent to pre-compute key searching information.  Another common 
mechanism is to pick a 128 bit key and publish the first 88 bits.  This 
method may be weak because it reveals a large number of the entries in the 
user key table, LL, and the key expansion algorithm was not designed to 
resist attacks when most of LL is known.  A better way to conform to the 40 
bit rule is to pick a seed value of 128 bits, publish 88 bits of this seed, 
run the entire seed through a hash function like MD5 [4], and use the 128 
bit output of the hash function as the RC5 key.

In the case of 40 unknown key bits with 88 known key bits (i.e., 88 salt 
bits) there should still be 12 or more rounds for the 64 bit block version 
of RC5, otherwise the value of adding salt bits to the key is likely to be 
lost.

The lifetime of the key also influences security.  For high security 
applications, the key to any 64 bit block cipher should be changed after 
encrypting 2**32 blocks (2**64 blocks for a 128 bit block cipher). For the 
case of 64 bit blocks, this rule would recommend changing the key after 
2**40 (i.e. 10**12) bytes are encrypted.  See Schneier [6] page 183 for 
further discussion.   

References

[1] Kaliski, Burton S., and Yinqun Lisa Yin, "On Differential and Linear 
Cryptanalysis of the RC5 Encryption Algorithm", In Advances in Cryptology - 
Crypto '95, pages 171-184, Springer-Verlag, New York, 1995.

[2] Rivest, Ronald L., "The RC5 Encryption Algorithm", In Proceedings of 
the Second International Workshop on Fast Software Encryption, pages 86-96, 
Leuven Belgium, December 1994.

[3] Rivest, Ronald L., "RC5 Encryption Algorithm", In Dr. Dobbs Journal, 
number 226, pages 146-148, January 1995.

[4] Rivest, Ronald L., "The MD5 Message-Digest Algorithm", RFC 1321.

[5] RSA Laboratories, "Public Key Cryptography Standards (PKCS)", RSA Data 
Security Inc.  See ftp.rsa.com.

[6] Schneier, Bruce, "Applied Cryptography", Second Edition, John Wiley and 
Sons, New York, 1996.

[7] Business Software Alliance, Matt Blaze et al., "Minimum Key Length for 
Symmetric Ciphers to Provide Adequate Commercial Security", 
http://www.bsa.org/bsa/cryptologists.html.

Xref subject next

        One reason for using RC5 in an ESP is to get higher performance.
Here are some performance numbers comparing DES and RC5 when encrypting
1024 byte blocks on a 100MHz Pentium and a 200MHz DEC Alpha.  Both numbers
come from RSADSI's BSAFE 3.0 cryptography toolkit.  The DES implementation
in BSAFE 3.0 is a slight variation of Eric Young's libdes software and is
used with his permission.
        DES uses a 56 bit key.  The RC5 version measured below uses
a 128 bit key, 12 rounds of the inner loop, and like DES, is a 64 bit
block cipher.

                        90 MHz Pentium          200 MHz DEC Alpha
DES Key Setup              17 MicroSeconds         16 MicroSeconds
RC4 Key Setup              57 MicroSeconds        138 MicroSeconds
RC5 Key Setup              48 MicroSeconds         26 MicroSeconds

DES Encrypt               8.0 MegaBits/Sec       10.6 MegaBits/Sec
RC4 Encrypt              65.6 MegaBits/Sec       34.4 MegaBits/Sec
RC5 Encrypt              26.3 MegaBits/Sec       24.5 MegaBits/Sec

                --Bob

Xref subject previous
Xref subject next

Robert Moskowitz says:
> >So there you have it. NSA makes good on its threat to ANSI X9 that
> >triple DES would not be exportable.
>
> This raises an interesting question WRT RC5 and smb's note.
> Can RC5 parameters be set so that it reaches 3DES strength, and if so, if
> the keying protocol allows for full parameter control, might NSA do the same
> with RC5 as it is doing to 3DES?  Or specify that the keying protocol lock
> down a certain set of RC5 parameters?

1. Since the number of rounds can be as large as 255 and the same is true
   for the key length, probably RC5 can approach 3DES strength, further 
   analysis pending.

2. It seems obvious, that no software will be licensed, unless the
   institution in question can provide guarantees that the
   limit on number of rounds and length of key are
   unmodifiable. If such a guarantee is not 
   satisfactory, I'd expect the license
   to be denied.

> OOOps, what have I done?  The NSA watchers of this list (not meaning Mark
> and his fellows, but the 'other side') way now go off and have to figure
> this all out  :)

(:-)
-- 
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-

Xref subject previous
Xref subject next

> Date: Tue, 19 Mar 1996 00:08:20 -0500
> From: "Jeffrey I. Schiller" 
>         I have considered your request to remove the chairs of the
> IPSEC Working Group. I have taken this matter seriously and have
> consulted with many people about what they believe is happening in the
> Working Group. I have also been attending most of the face to face
> meetings myself and read the mailing list, so I have my own
> observations as well.
>...
>         I can find no reason to believe that the Working Group Chairs
> should be removed on the basis of your appeal.

Thank you for your decision on my Feb 11 request, with additional issues
raised Feb 14, Feb 15, Mar 5, and Mar 10.  However, despite your
"serious" research, you have based the decision on (at least) two errors
of fact:

>         I have also had people report to me that you have threatened
> them with lawsuits and otherwise used intimidation tactics when other
> avenues of argument were not available to you.

Perhaps you could give more detail on these apocryphal and anonymous
charges?

> Furthermore I interpret
> your message to the Working Group on 3/14/96 as an attempt to
> intimidate the chairs and Working Group by making your appeal to me
> public and threatening to continue to appeal until some body finds in
> your favor.
>
Perhaps you could specify what message to the Working Group?  I cannot
find any message from me to the WG on or near that date.

Since you failed to answer _any_ of the specifics raised in my appeal,
and both of your negative findings are factually unsupported, I will
appeal to the IESG as a whole, pursuant to our Standards Process.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next


Derrell Piper writes:
> RC5 is a stream cipher that allows for variable length keys.

I believe RC5 is actually a block cipher.

Perry

Xref subject previous
Xref subject next


Robert Moskowitz writes:
> This raises an interesting question WRT RC5 and smb's note.
> 
> Can RC5 parameters be set so that it reaches 3DES strength,

If it can be, you can bet it can't be exported. We can't answer that
question, however, because we haven't studied RC5 long enough to have
anything like a reasonable answer.

However, I don't see what the problem is. If you need IPSec for your
overseas plants, buy from the Swiss or the Israelis or someone else
who isn't stopped at the border. There are lots of overseas vendors
for this stuff, so there is no reason to worry.

Perry