Xref subject previous

In message <01I2ZGQYFXIA000EV2@FRCU.EUN.EG>, ERI2@frcu.eun.eg writes
>
>Hello every body
>
>   I am looking for references which describe the operation of Kerberos in
>several domains. I will be very grateful if someone could help me.
>
>
Try looking at :

http://www.es.net/pub/esnet-doc/auth-and-security

This is a report on the use of Kerberos within a multi-realm
environment.  Other documents in the same location provide general
information on Kerberos.

--
------------------------------------------------------------------------- 
David Rogers                            Email:  drogers@drsec.demon.co.uk
OpenVision Technologies Ltd                     daver@openv.co.uk
Yorktown House, 8 Frimley Road          Tel:    +44 (0) 1276 683060
Camberley, Surrey, UK  GU15 3HS         Fax:    +44 (0) 1276 683755
-------------------------------------------------------------------------

We are pleased to announce that the first release of ISAKMP is now
available. It is based on draft-ietf-ipsec-isakmp-04 which was
distributed prior to the Los Angeles IETF. The software can be
downloaded from:

	http://web.mit.edu/network/isakmp

We would like to thank MIT for providing the anonymous FTP service and,
specifically, Jeff Schiller for assisting in this process.

Douglas Maughan
Mark Schertler

Xref subject next

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.                                                               

       Title     : Photuris Schemes and Privacy Protection                 
       Author(s) : P. Karn, W. Simpson
       Filename  : draft-simpson-photuris-schemes-00.txt
       Pages     : 9
       Date      : 04/18/1996

Photuris is an experimental session-key management protocol intended for 
use with the IP Security Protocols (AH and ESP).  Extensible Exchange 
Schemes are provided to enable future implementation changes without 
affecting the basic protocol.  An important improvement in security is 
provided by protecting exchanges with encryption.                          

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-photuris-schemes-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-simpson-photuris-schemes-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 (193.205.245.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-photuris-schemes-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: <19960418141116.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-simpson-photuris-schemes-00.txt

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

Content-Type: text/plain
Content-ID: <19960418141116.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.                                                               

       Title     : Photuris Schemes and Privacy Protection                 
       Author(s) : P. Karn, W. Simpson
       Filename  : draft-simpson-photuris-schemes-00.txt
       Pages     : 9
       Date      : 04/18/1996

Photuris is an experimental session-key management protocol intended for 
use with the IP Security Protocols (AH and ESP).  Extensible Exchange 
Schemes are provided to enable future implementation changes without 
affecting the basic protocol.  An important improvement in security is 
provided by protecting exchanges with encryption.                          

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-photuris-schemes-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-simpson-photuris-schemes-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 (193.205.245.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-photuris-schemes-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: <19960418141116.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-simpson-photuris-schemes-00.txt

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

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

--OtherAccess--

--NextPart--

Xref: Re: IETF Draft for ESP with stream ciphers Ran Atkinson
Xref subject next

Hello everybody,

some time ago, Marcel (Waldvogel) and I have submitted an internet draft,
which gives a proposal on how 'Encapsulated Security Payload' can be
implemented for stream ciphers, at the same time offering mechanisms for
replay protection.

Now we would be very interested in the opinion of the IPSEC working group,
and possible other readers. Is 'esp-stream' of interest? What do the members
and chairs think about the fitness of this document? If it is relevant,
perhaps we could move it into the 'draft-ietf-ipsec-*' name domain? We are
also very much looking forward to technical comments...

Friendly greetings,

        Germano

p.s. the doucment is online as draft-caronni-esp-stream-00.txt, or as
     http://www.tik.ee.ethz.ch/~skip/esp-stream.txt

Xref: Re: Routing Header info of IPng against traffic analysis?  Perry E. Metzger
Xref subject next

Hi

As I was working through the IPng specifications, I realized that
no options are implemented to prevent traffic analysis in IPsec.

Could the Routing Header information been set up that the list of 
intermediate nodes changes when the system setting provide a
list of alternative routing paths? An error condition could arise
similar to the definition in the fragmentation header, if not all
packets are received to complete reassembly of the message within 60 
seconds (a long time but I think this would be a reasonable waiting
time if you are concerned about traffic analysis).

This would prevent most attempts to traffic analysis and complete
the good IPsec spec.

I am looking forward to your comments

greetings

Reto

------------------------------------------------------------------
at the George Washington University, Washington DC
reto@seas.gwu.edu 

Xref: Re: Routing Header info of IPng against traffic analysis? Ran Atkinson
Xref subject previous
Xref subject next


Reto Haeni writes:
> As I was working through the IPng specifications, I realized that
> no options are implemented to prevent traffic analysis in IPsec.
> 
> Could the Routing Header information been set up that the list of 
> intermediate nodes changes when the system setting provide a
> list of alternative routing paths? An error condition could arise
> similar to the definition in the fragmentation header, if not all
> packets are received to complete reassembly of the message within 60 
> seconds (a long time but I think this would be a reasonable waiting
> time if you are concerned about traffic analysis).

Changing routing paths isn't sufficient to prevent traffic analysis.

Stopping traffic analysis is fairly complicated and beyond the scope
of the IPSec work...

.pm

Xref: ports in the clear... Greg Minshall
Xref: Re: Routing Header info of IPng against traffic analysis?  Perry E. Metzger
Xref subject previous
Xref subject next

Reto Haeni wrote:
% As I was working through the IPng specifications, I realized that
% no options are implemented to prevent traffic analysis in IPsec.

In article <199604221819.OAA18138@jekyll.piermont.com> Perry wrote:
>Changing routing paths isn't sufficient to prevent traffic analysis.
>
>Stopping traffic analysis is fairly complicated and beyond the scope
>of the IPSec work...

It is not clear to me that it is feasible to prevent traffic analysis
anywhere above the link layer.  Folks really interested in this might want
to consult [VK85] for relevant background material.

Ran
rja@cisco.com

Xref subject previous

In article <2.2.32.19960421223444.006e30f8@ktik0.ethz.ch> Germanno wrote:

>some time ago, Marcel (Waldvogel) and I have submitted an internet draft,
>which gives a proposal on how 'Encapsulated Security Payload' can be
>implemented for stream ciphers, at the same time offering mechanisms for
>replay protection.
>
>Now we would be very interested in the opinion of the IPSEC working group,
>and possible other readers. Is 'esp-stream' of interest? 

The main issue with the current draft is that it does not specify a
particular stream algorithm.  An ESP transform MUST specify a particular
algorithm as part of the transform so that when key management negotiates
use of that transform, both sides know which algorithm to use.

So perhaps my fundamental request is that this be edited into a transform
for a specific algorithm or possibly for two specific algorithms (with some
note that each algorithm would need its own "transform identifier" for key
management use.

It is NOT the case that the current spec works for all stream algorithms,
for example the "Stream Offset" as currently defined will not work when
more than 64 bits of crypto-sync are needed for some algorithm.  While
algorithm-independence is important for the base AH and ESP specs, it
should not be a goal for a transform document since transform documents are
supposed to specify how to use a single particular crypto algorithm with AH
or ESP.

>What do the members and chairs think about the fitness of this document? 

As an ordinary person, my take on this is that it has limited applicability
and should probably become an Experimental RFC or Informational RFC.  I do
not know the patent status of SEAL in various countries, but IETF practice
is to avoid standardising patented techniques when unpatented techniques
(e.g. DES CFB) exist.

Given the existence of fairly fast DES code (e.g. Karn's i386 assembly) and
commercial high-speed DES chips, I'm not sure that this particular tradeoff
of speed for less security is one that I'd be making.

I would want MD5 (or equivalent) integrity/authentication to be added to
the transform because we know that strong integrity/authentication is
needed to obtain commercial-grade security.  I'm aware of MD5 code in
software that does better than OC-3 rate now on a commercial 64-bit RISC
processor.  I'm also aware of MD5 hardware that is well above OC-3 rates.
In general, I do not agree with all of the conclusions of RFC-1810 because
of private discussions I've had with employees of National Semiconductor
(these discussions actually date back prior to my arrival at cisco).

>If it is relevant, perhaps we could move it into the 'draft-ietf-ipsec-*' 
>name domain? 

Only if the WG decides it should be a standards-track document.  It is not
yet clear to me that there is anything like consensus that this draft
should be on the standards-track.

I've been told from above that we should not be standardising any transform
that is vulnerable to published attacks.  The WG in LA made it clear that
RFC-1828 and RFC-1829 should be replaced-on-the-standards-track with new
transforms having improved security properties.  So I'd view addition of
MD5 (or similar, SHA would be fine with me personally) integrity/
authentication to be needed before this draft goes anywhere.

Ran
rja@cisco.com

Xref subject next


Greg Minshall  wrote:
% Did i mention my desire to expose the source and destination TCP/UDP ports 
% (via some new fields in the IPSEC header) when doing encryption?

Yes.  You've mentioned this several times.  My answers remain the same.

You'll shoud concentrate on convincing everyone else first, 
because there is ZERO chance I'll be convinced to open up the ports
and ULP identifier with ESP.

% There are lots of reasons, from bean counting ("what % of the internet 
% traffic is web traffic?")

So add a counter for encrypted traffic.  Not a good argument.
 
% to firewalls 

Should be implementing IPsec anyway.  Most firewalls are becoming encrypting
firewalls already.  Not a good argument.

% to "best effort QoS" (make telnet port low latency; 
% make ftp data port high throughput).

Use RSVP instead.  See the RSVP+IPsec draft for how to make it work.

Your unstated reason is that it relates to how the Ipsilon product works
and that won't persuade me either.  

Nothing says that users must use encryption.  If they choose to do so,
then they ought not have their ports and ULP identifier in cleartext.

Ran
rja@inet.org

Xref: Re: ports in the clear...  Greg Minshall
Xref subject previous
Xref subject next

> There are lots of reasons, from bean counting ("what % of the
> internet traffic is web traffic?") to firewalls to "best effort QoS"
> (make telnet port low latency; make ftp data port high throughput).

Using port numbers for quality of service is The Wrong Way To Do It.
The TOS (Type of Service) field is for this, and it reveals much less
other information.

Attaching type of service semantics to port numbers makes adding new
services extremely painful, because it is impossible to control their
routing priority.  IPTOS is much more flexible, extensible, and
scalable.  Almost all machines already set IPTOS in outgoing packets
according to the type of the service.

    Tatu

Xref: ports in the clear... Tatu Ylonen
Xref: Re: ports in the clear...  Perry E. Metzger
Xref subject previous
Xref subject next

> It is not clear to me that it is feasible to prevent traffic analysis
> anywhere above the link layer.  Folks really interested in this might want
> to consult [VK85] for relevant background material.

Did i mention my desire to expose the source and destination TCP/UDP ports 
(via some new fields in the IPSEC header) when doing encryption?

There are lots of reasons, from bean counting ("what % of the internet traffic 
is web traffic?") to firewalls to "best effort QoS" (make telnet port low 
latency; make ftp data port high throughput).

Greg

Xref: Re: ports in the clear...  Greg Minshall
Xref subject previous
Xref subject next


Greg Minshall  wrote:
% Did i mention my desire to expose the source and destination TCP/UDP ports 
% (via some new fields in the IPSEC header) when doing encryption?

Yes.  You've mentioned this several times.  My answers remain the same.

You'll shoud concentrate on convincing everyone else first, 
because there is ZERO chance I'll be convinced to open up the ports
and ULP identifier with ESP.

% There are lots of reasons, from bean counting ("what % of the internet 
% traffic is web traffic?")

So add a counter for encrypted traffic.  Not a good argument.
 
% to firewalls 

Should be implementing IPsec anyway.  Most firewalls are becoming encrypting
firewalls already.  Not a good argument.

% to "best effort QoS" (make telnet port low latency; 
% make ftp data port high throughput).

Use RSVP instead.  See the RSVP+IPsec draft for how to make it work.

Your unstated reason is that it relates to how the Ipsilon product works
and that won't persuade me either.  

Nothing says that users must use encryption.  If they choose to do so,
then they ought not have their ports and ULP identifier in cleartext.

Ran
rja@inet.org

Xref subject previous
Xref subject next

Tatu,

Actually, the poor IP TOS field has an inglorious history of having been 
somewhat useless.  The original definition never had very much use.  The more 
current separation of precedence, etc., may have a bit more utility, though 
the fact that it is set at the end station (and, therefore, of dubious 
correctness) is a bit troubling.  (You might look at Christian Huitema's 
"Routing in the Internet", section 3.3.2, for a *very* brief discussion.)  
(The canonical danger is an e'mail program that advertises "i'll get your mail 
there faster than that other e'mail program", and then doing that by setting 
bits in TOS.)

*One* advantage of looking at port numbers is that it scales, to some degree.  
It also *may* reflect closer to what is actually going on (i.e., this really 
*is* a telnet session; unless, of course, the two ends are conspiring).  (For 
some of the background, you might want to look at Floyd, S., and Jacobson, V., 
Link-sharing and Resource Management Models for Packet Networks. IEEE/ACM 
Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995.)

(But, you are right, by doing this, when you field a new "application", you 
need to add new administrative configuration information to routers.)

Sorry, though, for highjacking ipsec for *this* more packet management 
discussion.

Greg

Xref subject previous
Xref subject next

Ran,

> Your unstated reason is that it relates to how the Ipsilon product works
> and that won't persuade me either.  

Foo.  I'm fairly principled; my discomfort with hiding the port numbers 
predates Ipsilon.  (But, you are right that this would also make some of our 
stuff easier in operational networks.)  [But, maybe you didn't mean this 
statement to be for public consumption?]

> Nothing says that users must use encryption.  If they choose to do so,
> then they ought not have their ports and ULP identifier in cleartext.

I guess i don't know any argument from first principles that says what should, 
and what shouldn't, be in the clear (except that it's clear that people want 
their telnet passwords and their payroll data, etc., to be encrypted).  If, 
for example, ports and ULP were in the IPng header (sort of like in XNS), then 
one might not think of encrypting them (thinking of them as part of the 
"address").

Greg

Xref: Re: ports in the clear...  Michael Richardson
Xref subject previous
Xref subject next

Believe it or not, you'd be surprised how many bean counters there
are in this world. People want to account for data flows.

- paul

At 03:43 PM 4/22/96 -0700, Greg Minshall wrote:

>Did i mention my desire to expose the source and destination TCP/UDP ports 
>(via some new fields in the IPSEC header) when doing encryption?
>
>There are lots of reasons, from bean counting ("what % of the internet traffic 
>is web traffic?") to firewalls to "best effort QoS" (make telnet port low 
>latency; make ftp data port high throughput).
>
>Greg
>

Xref: Re: clear ports  Greg Minshall


I did not intend to impune Greg Minshall's character in my earlier note.
He had been open in previous face-to-face discussions (e.g. in the hallways
at USENIX) about the advantages of open ports for the Ipsilon product. He
says his concerns about open ports predate Ipsilon and I take him at his
word on that.

If the user didn't want the ports and transport-layer covered up, then the
user would have used an upper-layer security service (e.g. PEM, PGP, SSL,
whatever) instead of IPsec.  Uncovering the ports within the context of
IPsec is unwise and contrary to the intent of the IPsec work.

Ran
rja@inet.org

Xref subject previous
Xref subject next

Paul,

	I understand that there are folks who want to count packets.
However, the _purpose_ of using IPsec is to make it difficult for an
adversary to know what is going on.  If a user has turned on IPsec for his
traffic, its because the user does not want this information in the clear,
else the user would have used upper-layer security services instead of
IPsec.

Ran
rja@cisco.com

Xref subject previous
Xref subject next

Completely understood. I was stating the obvious.  :-/

- paul

At 07:11 PM 4/22/96 -0700, Ran Atkinson wrote:

>Paul,
>
>	I understand that there are folks who want to count packets.
>However, the _purpose_ of using IPsec is to make it difficult for an
>adversary to know what is going on.  If a user has turned on IPsec for his
>traffic, its because the user does not want this information in the clear,
>else the user would have used upper-layer security services instead of
>IPsec.
>
>Ran
>rja@cisco.com
>
>
>

Xref subject previous
Xref subject next

>>	I understand that there are folks who want to count packets.
>> However, the _purpose_ of using IPsec is to make it difficult for an
>> adversary to know what is going on.  If a user has turned on IPsec for his
>> traffic, its because the user does not want this information in the clear,
>> else the user would have used upper-layer security services instead of
>> IPsec.

If bean counters want to count traffic, they could always use encrypting
firewalls.  I agree with Ran; don't comprimise the security of the protocol
for bean counters (which is the only "real" argument I've seen).

Brad

--
Brad Wilson, Crucial Software     crucial@ix.netcom.com    +1 (810) 620-9803
Custom software engineering services for Microsoft Windows NT and Windows 95

Xref subject previous
Xref subject next


Greg Minshall writes:
> Did i mention my desire to expose the source and destination TCP/UDP ports 
> (via some new fields in the IPSEC header) when doing encryption?

Unfortunately, that conflicts with the desire many others have to
reduce the amount of traffic analysis that can be done. It also has
the problem that there is no way for a traffic monitor to know what
kind of ESP transform is being used and thus which portion of the ESP
header to look in -- since the only thing constant across ESP
transforms is the 32 bit SPI header, it is very hard indeed to know
you are using a transformt that exposes anything.

At this point, given the extensive implementations out in the field,
changing everything for everyone might be hard.

The reason for AH was, of course, to have "exposed" datagrams that
were authenticated.

There may be some other ways to achieve the QoS goal you have,
though...

.pm

Xref subject previous


Ran Atkinson writes:
> In article <199604221819.OAA18138@jekyll.piermont.com> Perry wrote:
> >Stopping traffic analysis is fairly complicated and beyond the scope
> >of the IPSec work...
> 
> It is not clear to me that it is feasible to prevent traffic analysis
> anywhere above the link layer.

I tend to agree that you need link opacity to do serious traffic
analysis prevention, although I believe you could do partial work with
cover traffic and such. However, what we are talking about is now a
very complicated subject for research, not something for this working
group to be doing. I believe you and I are in violent agreement on
this.

Perry

Xref subject previous
Xref subject next

--===_-1_Tue_Apr_23_11:47:13_EDT_1996
Content-Type: text/plain; charset=us-ascii

In a galaxy far, far away, : Mon, 22 Apr 1996 21:05:39 EDT
> Believe it or not, you'd be surprised how many bean counters there
> are in this world. People want to account for data flows.

  If people want to account for traffic flow, then they should reject
attempts to send encrypted packets through. 
  Simple. 
  The whole point of encrypted traffic flow is to keep information private. 
Otherwise, people who want privacy will just build tunnels, there will be no
port numbers to see, and the bean counters will just be back where they 
started, only they'll be paying an extra IP header per packet.
  The existence of ESP headers will not likely cause all the traffic to
become encrypted. I doubt AH headers will be that common for typical 
http access. HTTP is expensive enough as it is...
  If you want to count bytes, then buy a device that supports IPsec. Firewalls
are examples of such a device. 
  I proposed one method that a firewall could interact with IPsec in 
draft-richardson-ipsec-aft-00.txt. I'm less convinced that this is the way to 
do it now than a month ago, though.


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


--===_-1_Tue_Apr_23_11:47:13_EDT_1996
Content-Type: application/pgp-signature

-----BEGIN PGP MESSAGE-----
Version: 2.6.2i

iQBVAwUBMXz7gBUFVvYhcjNpAQF/FwIAhC7aigpXUqoGFQ6NJXUAtqeVUJr5Pt64
rJAShgN0txxEldJNbCBQVbq8KxSzIloCCWdBbFbPeKqDwr9LsP6U4w==
=gt0Q
-----END PGP MESSAGE-----

--===_-1_Tue_Apr_23_11:47:13_EDT_1996--

 
FYI, 
 
>This is to confirm two session of IPSEC as follows: 
> 
>        Tuesday, June 25 at 1530 (opposite dhc, rolc) 
>        Wednesday, June 26 at 1530 (opposite agentx, dhc) 
 
 
Individuals requesting time on the agenda should send Ran and myself e-mail 
(rja@cisco.com, palamber@us.oracle.com). 
 
 
 
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 
-------------------------------------------------------------- 
  

  It looks like maybe I typo'd the other day.  Perhaps I should have said 
[VK83], which is cited in more detail in RFC-1825, among other places.

Ran
rja@cisco.com

The tentative schedule for IPsec in Montreal is:

        Tuesday, June 25 at 1530 (opposite dhc, rolc)
        Wednesday, June 26 at 1530 (opposite agentx, dhc)

Folks with proposed agenda items should email their proposals to both
Paul Lambert  and me  and we'll
try to put together an agenda.  

Ran
rja@cisco.com

Xref: Re: clear ports  Perry E. Metzger
Xref subject next

Ran,

> If the user didn't want the ports and transport-layer covered up, then the
> user would have used an upper-layer security service (e.g. PEM, PGP, SSL,
> whatever) instead of IPsec.  Uncovering the ports within the context of
> IPsec is unwise and contrary to the intent of the IPsec work.

I guess i'm not convinced that a priori it is necessary to require that ESP 
cover up the protocol/ports.  I think that in many many cases, what people are 
trying to keep private is the payload of the transport data (eg, passwords, 
payroll data, etc.).  I think that in some cases, traffic analysis (at the 
level of ports/protocol) is something people want to protect.

Below is (what i believe to be) the IPSEC charter; i don't believe that it 
answers the question "to encrypt ports/protocol or not to encrypt 
ports/protocol?".

Additionally, i suspect that the effort required to design, develop, and 
deploy IPSEC is going to make it widely used in the place of things such as 
TELNET encryption, FTP encryption, SSL, etc.  I.e., it is going to solve all 
these problems, it is there (and, hopefully, ubiquitous), and people will use 
it.

Cheers,

Greg
----
Rapid advances in communication technology have accentuated the need for 
security in the Internet. The IP Security Protocol Working Group (IPSEC) will 
develop mechanisms to protect client protocols of IP. A security protocol in 
the network layer will be developed to provide cryptographic security services 
that will flexibly support combinations of authentication, integrity, access 
control, and confidentiality. 

The protocol formats for the IP Authentication Header (AH) and IP 
Encapsulating Security Payload (ESP) will be independent of the cryptographic 
algorithm. The preliminary goals will specifically pursue host-to-host 
security followed by subnet-to-subnet and host-to-subnet topologies. 

Protocol and cryptographic techniques will also be developed to support the 
key management requirements of the network layer security. The Internet Key 
Management Protocol (IKMP) will be specified as an application layer protocol 
that is independent of the lower layer security protocol. The protocol will 
initially support public key-based techniques. Flexibility in the protocol 
will allow eventual support of Key Distribution Centers (KDC), such as are 
used by Kerberos.

Xref: Re: clear ports  Greg Minshall
Xref subject previous
Xref subject next

Greg Minshall wrote:

>> I guess i'm not convinced that a priori it is necessary to require that ESP 
>> cover up the protocol/ports.

...

>> Below is (what i believe to be) the IPSEC charter; i don't believe that it 
>> answers the question "to encrypt ports/protocol or not to encrypt 
>> ports/protocol?".

...

>> The IP Security Protocol Working Group (IPSEC) will 
>> develop mechanisms to protect client protocols of IP.

This certainly sounds like "protecting protocol and port" information.  At
the very least, it would seem that there is a strong desire to protect these
things, regardless of whether or not the actual words "encrypt ports and
protocols" are present in the very short summary that you point to.

Brad

--
Brad Wilson, Crucial Software     crucial@ix.netcom.com    +1 (810) 620-9803
Custom software engineering services for Microsoft Windows NT and Windows 95

Xref subject previous
Xref subject next

enough!  i agree, tail between my legs, that, in fact, "protect client 
protocols of IP" is certainly most reasonably read as protecting ports (which, 
in general, i still believe to be at least worrisome and, possibly, a mistake)!

Xref subject next


 
Greg,  
  
>I guess i'm not convinced that a priori it is necessary to require that ESP   
>cover up the protocol/ports.   
  
ESP is simple because it "encapsulates" the payload. Exposing port numbers is 
a very bad idea because it violates implementation layering, it violates some 
security policies, it is transport layer specific, etc.  QOS is another issue 
and could be addressed in a variety of ways.  
  
If you have requirements for a better encapsulation protocol over TCP, would 
ESP over TCP work?  
  
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


Greg Minshall writes:
> I guess i'm not convinced that a priori it is necessary to require
> that ESP cover up the protocol/ports.  I think that in many many
> cases, what people are trying to keep private is the payload of the
> transport data (eg, passwords, payroll data, etc.).

1) Lots of our users are going to be interested in preventing detailed
   port and protocol information from being seen. Conservative
   security design says "hide everything you don't absolutely need to
   expose". I can think of excellent reasons that one doesn't want
   protocol and port information on the wire in the general case --
   that could give away very valuable traffic analysis information
   which can be used to help break a security system, for example.
2) Our current design would be very hard to change in this regard. ESP
   was designed to be fully opaque, and there is no way for an
   observer to know what the transform used on an ESP packet is,
   because the only indicator of all that stuff is a prenegotiated 32
   bit number.
3) I personally don't want this information leaking if I'm the guy
   sending the packets. Long term paranoia from the security
   consulting world has leaked into my psyche. If I don't need to
   expose information, and I don't know how it could be used to attack
   me, I don't want it out. Just because I can't think of a use for
   information offhand doesn't mean it won't be exploited -- indeed,
   the history of this field shows that it most certainly *will* be
   exploited at some point.

.pm

Xref subject previous
Xref subject next

> From ipsec-request@neptune.tis.com Tue Apr 23 19:27:54 1996
> Date: 23 Apr 96 18:55:19 -0700
> From: "PALAMBER.US.ORACLE.COM" 
> To: ipsec@tis.com
> Subject: ESP over TCP?
>  
> Greg,  
...
> ESP is simple because it "encapsulates" the payload. Exposing port numbers is 
> a very bad idea because it violates implementation layering, it violates some 
...
> Paul  

Why is implementation layering good?

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

> From: Greg Minshall 
> I guess i'm not convinced that a priori it is necessary to require that ESP
> cover up the protocol/ports.  I think that in many many cases, what people are
> trying to keep private is the payload of the transport data (eg, passwords,
> payroll data, etc.).  I think that in some cases, traffic analysis (at the
> level of ports/protocol) is something people want to protect.
>
While it is true that very few folks are really worried about traffic
analysis, it might be possible that breaking the session-keys could use
information about what protocol header is inside the encrypted data, to
look for regular patterns.  So, it is probably best to hide that
information.

Meanwhile, I think your problem model can be easily solved (from my
meager understanding of your product) by thinking about the two major
cases: firewall virtual private networks, and client/server.

 1) Firewall VPNs will look to your product very much like a single
    flow.  The packet sizes might change, but in general the forwarding
    will be identical on every packet.  Should be a fast decision for
    you.

    I doubt there are many firewalls using TOS, but it is certainly
    possible, and you could cue off that for different services.  But I
    would expect that the firewalls have already done the WFQ and such
    for their own users, and you won't be able to add much value.

 2) For client to server and vice versa, you have 2 routing clues; the
    addresses (of course) and the SPIs.  Different users will have
    different SPIs.  Each telnet or FTP will have a different SPI.

    The SPI behaves very much like a port pair, albeit you don't know
    for what services.  If you are looking at characteristics of the
    flows, the TOS associated with the SPI might help here, too.


> Below is (what i believe to be) the IPSEC charter; i don't believe that it
> answers the question "to encrypt ports/protocol or not to encrypt
> ports/protocol?".
>
Well, I wouldn't put too much faith in that charter.  Look at the dates
for completion....

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

I've been quite busy of late in too many venues.  I am on a plane heading
home from DC where I explained to a bunch of interesting people what the
auto industry will need in security (I am now the chair of the AIAG security
work group, thanks people for educating me, I'm really dangerous now ;).

My general feeling is expose as little as possible and damn the bean
counters.  This is true for real time security like in IPSec and hopefully
at some point with object security (S/MIME and MSP flunk the test it seems).
I do not want someone to figure out that a particular multicast session is a
CAD virtual reality process (yeah, I'm going to need all of this with
multicast too) based on the port number that every competitor uses for this,
as sometimes we are partners.  ARGH!

End-to-end will be needed, but the firewalls will be in the way, so IPSec
will have some real challenges; at trusted firewall that maintains the
secure channel on each side?  Oh boy.

I think I just got myself a life time job, anyone want to trade? :)

Oh, I had a site visit to ISUZU and they use Net10, just like Chrysler and
Ford dealers do and I think one other OEM.  So end-to-end will be interesting.

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref: Re: SKIP status Ran Atkinson

I would like some feedback  on the status of SKIP, ie:

- what is its status? likely to go to RFC?

- where is it likely to be used? eg. Does it have a different
range of applications than photuris or do the two protocols
do the same thing and therefore the market will decide what
to use and where?

Anybody response would be greatly appreciated.

Thanks
jeff

In article <3039866563.1.p01152@psilink.com> Jeff Pickering wrote:
>I would like some feedback  on the status of SKIP, ie:
>
>- what is its status? 

This is an "official" response in my role as co-chair of the IPsec WG.

	SKIP is currently a set of Internet-Drafts.  It is one of 2
proposals under active consideration for possible publication as Proposed
Standard RFCs for key management.

The two proposals under active consideration are:
	SKIP
	ISAKMP with Oakley extensions (ISAKMP+Oakley)

	SKIP and ISAKMP+Oakley each have freely distributable
implementations of the most recent drafts in progress.  Each has resolved
the issue of the Diffie-Hellman patent in precisely the same way.  Each has
support from at least one major vendor.

	A third proposal, known as Photuris, is not currently under active
consideration for standards-track RFC because its editor has repeatedly
refused to edit that document to conform to WG consensus.

	At the LA IETF meeting in March, Jeff Schiller (Security Area
Director) took a straw poll on key management.  There was nothing close to
consensus behind any of the proposals at that time.  The IETF requires that
there be rough consensus in the WG _before_ a proposal can go to Proposed
Standard RFC.  It is unclear when such consensus will emerge, so the RFCs
are being published as Experimental status so that more experience can be
obtained.

>- likely to go to RFC?

	Several of the SKIP documents, the ISAKMP document, and the Oakley
document are all going to become Experimental RFCs (not standards-track) in
the near term (most are already in the queue at the RFC Editor and will
appear whenever the RFC Editor gets to them).

	It is VERY important to recall that many RFCs are not
standards-track and hence publication as an RFC does not necessarily mean
anything.  The widely deployed Internet protocols (e.g. TCP, IP, UDP) are
all standards-track RFCs, so the status of the RFC does make some
difference in the probable deployment.

Ran
rja@inet.org
Co-Chair, IPsec WG

Xref subject previous

Joe,

        Implementation layering is advantageous to the extent that it
allows easier retrofitting of new protocols, especially encapsulation
protocols like ESP.  The downside of implementation layering is potentially
poorer performance vs. implementations that cross layer boundaries to
reduce buffer copying, etc.

Steve

Xref: Re: draft-ietf-ipsec-esp-des-md5-01.txt  Bill Sommerfeld
Xref subject next







Security Working Group                               IPsec Working Group
Request for Comments: DRAFT                            J. Hughes, Editor
                                                              April 1996
                                                   Expires in Six months


    Combined DES-CBC, HMAC and Replay Prevention Security Transform
                   <draft-ietf-ipsec-des-md5-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@tis.com) or to the editor.

   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 and optionally,
   authentication, integrity and replay prevention into a single packet
   format.

   This document is the result of significant work by several major
   contributors and the IPsec working group as a whole. These
   contributors, cited later in this document, provided many of the key
   technical details summarized in this document.







Hughes                                                          [Page 1]





RFC DRAFT                                                     April 1996


Discussion

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

   The valid combinations of this transformation are summarized below.

         Name              Description
         --------          --------------
         esp-DES-IV32      Privacy Tunnel (32 IV)
         esp-DES-IV64      Privacy Tunnel (64 IV)
         esp-DES-HMAC-RP   DES, HMAC, Replay (Mandatary transform)


   The combinations of transformations are negotiated at key
   establishment time such as described in ISA/KMP [Maughan96] and
   Oakley [Orman96]. To conform with this RFC, of the 3 transforms
   documented in this RFC, only esp-DES-HMAC-RP shall be implemented.


Packet Format

   There are 3 slightly different packet formats.

Format with 32 bit IV (esp-DES-IV32)

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Security Parameters Index (SPI)                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             IV                                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
 |                                                               |   ^
 ~                      Payload Data                             ~   |
 |                                                               |  DES
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  CBC
 |               |         Padding (0-7 bytes)                   |   |
 +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
 |                               |  Pad Length   | Payload Type  |   v
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---











Hughes                                                          [Page 2]





RFC DRAFT                                                     April 1996


Format with a 64 bit IV:

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Security Parameters Index (SPI)                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                        64 bit IV                              +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
 |                                                               |   ^
 ~                      Payload Data                             ~   |
 |                                                               |  DES
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  CBC
 |               |         Padding (0-7 bytes)                   |   |
 +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
 |                               |  Pad Length   | Payload Type  |   v
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---

Format with DES, HMAC and replay (esp-DES-HMAC-RP) (This is the Mandatary
transform)

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


Security Parameters Index


   This field is negotiated at key setup and shall not be 0 [RFC-1825]







Hughes                                                          [Page 3]





RFC DRAFT                                                     April 1996


Initialization Vector


   IV for the first block is either formed from the replay field or from
   a 32 or 64 bit IV field. The section on replay describes the
   calculation of the IV when the replay field is present.

   If a 64 bit IV is used, the entire 64 bits are the IV.

   If a 32 bit IV is used, the 32 bit IV and its compliment are then
   concatenated to form the 64 bit IV and that is them XORed by the IV
   key.



Replay Prevention


   Replay Prevention is an unsigned 32 bit up counter starting at a
   value of 1.

   The replay field is also used to create the IV for the first block of
   ciphertext.  This is accomplished by concatenating the SPI and the
   replay field and XORing this against 64 bits of IV key material (see
   section on keys). The resulting 64 bits are the IV.

   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. If more than 2^32 packets are transmitted, the counter will
   alias back to the initial value.  Counter wrapping shall be
   considered a replay attack.

   At the receiving point, the replay value is assured to be increasing.
   The implementation may accept of out of order packets. The number of
   packets wiling to accept out of order is an implementation detail. If
   a "out of order window" is supported, the implementation shall ensure
   that any and all packets accepted out of order are guaranteed not to
   have arrived before. That is, the implementation will accept any
   packet at most once.

   An example may allow the most recent 32 packets to be allowed to
   arrive out of order. That is, these 32 packets can arrive in any
   sequence relative to each other except that these packets are
   guaranteed to arrive only once.

   Other window sizes are optional, both larger and smaller.

   Appendix A has actual code that implement a 32 packet replay window



Hughes                                                          [Page 4]





RFC DRAFT                                                     April 1996


   and a test routine to show how it works.


Payload


   The payload contains data that is described by the payload type
   field. This is a byte length field that can end on any boundary
   within a word.


Padding


   Shall contains the number of pad bytes to fill the space between the
   end of the payload and the "pad length" field so that the "payload
   type" field ends on a double word boundary.

   Padding bytes man be initialized with random data.

   More than the minimum bytes necessary to achieve a double word
   boundary may inserted provided that the total number of bytes added
   are less than 255.


Pad Length


   Shall contain an unsigned number of bytes of padding. A value of 0
   means there was no padding and that the byte immediately preceding
   the Pad Length field is the last byte of the payload.


Payload Type


   Describes what the payload is. The values are described in:

     ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers












Hughes                                                          [Page 5]





RFC DRAFT                                                     April 1996


HMAC Residual


   The HMAC residual is a 128 bit residue described in [Krawczyk96].
   This covers the SPI, replay, payload, padding, pad length, payload
   type.

   HMAC is a keyed algorithm and shall use the HMAC key as described in
   the section on keys.


Key Material


   The key material for the transform is provided by key management
   protocol. These bits will be hashed down so that the quality of the
   bits do not need to have 100% entropy.

   There are 4 keys. The key management key "K", the "DES Key", the "IV
   key" and the "HMAC key". The key provided by the key management layer
   is K.  All the other keys are derived from that key.

   Let MD5(x|y) describes taking the residual x concatenated with y.
   Let Truncate(x,n) takes the first n bits from x and discards the
   rest.

   DES Key   = Truncate(MD5( DPad | K ),64)
   IV Key    = Truncate(MD5( IPad | K ),64)
   HMAC Key  =          MD5( HPad | K )

   where each _Pad is 512 bit string.

   DPad = 0x5C repeated 64 times.
   IPad = 0xAC repeated 64 times.
   HPad = 0x53 repeated 64 times.

   The 16 byte intermediate residuals can be precalculated from these
   constants.

   This method will work with key material from the key server of any
   size, caveat emptor.










Hughes                                                          [Page 6]





RFC DRAFT                                                     April 1996


Security Considerations


   The claims of privacy, integrity, authentication, and optional replay
   prevention are made in this draft. I will not try to diagram all the
   security considerations. A good text is [Schneier95].

   Privacy is provided by DES-CBC [Schneier95].

   Integrity is provided by HMAC [Krawczyk96].

   Authentication is provided since only the source and destination know
   the HMAC key. If the HMAC is correct, it proves that it must have
   been added by the source, since only the source knows the HMAC key.

   Replay prevention is provided by the combination of a constantly
   increasing count, the SPI and the HMAC key. The integrity of the
   replay field is provided by the HMAC.

   There are active attacks to esp-DES-IV32 and esp-DES-IV64 which can
   (in certain circumstances) compromise the confidentiality of messages
   encrypted under the DES privacy transform, when no message integrity
   protection is in use [Bellovin96].

   The ESP-DES-HMAC-RP transform described in this draft is immune to
   this active attack. (AH [RFC-1826], in some modes, can also provide
   immunity to this attack [Bellovin96].)




References


   [Bellovin96] Bellovin, S., "Problem Areas for the IP Security
   Protocols", AT&T Research,
   ftp://ftp.research.att.com/dist/smb/badesp.ps, July, 1996.

   [Krawczyk96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC-MD5:
   Keyed-MD5 for Message Authentication",
  /draft-ietf-ipsec-> http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec-
   hmac-md5-00.txt, March, 1996

   [Maughan96] Maughan, D., Schertler, M. Internet Security Association
   and Key Management Protocol (ISAKMP)
  /draft-ietf-ipsec-> http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec-
   isakmp-04.txt, February, 1996




Hughes                                                          [Page 7]





RFC DRAFT                                                     April 1996


   [Orman96] Orman, H., "The Oakley Key Determination Protocol",
  /draft-ietf-ipsec-> http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec-
   oakley-00.txt, February, 1996.

   [RFC-1825] Atkinson, R, "Security Architecture for the Internet
   Protocol", ftp://ds.internic.net/rfc/rfc1825.txt, August 1995.

   [RFC-1826] Atkinson, R, "IP Authentication Header",
   ftp://ds.internic.net/rfc/rfc1826.txt, August 1995.

   [Schneier95] Schneier, B., "Applied Cryptography Second Edition",
   John Wiley & Sons, New York, NY, 1995.  ISBN 0-471-12845-7





Acknowledgements


   This document is the result of significant work by several major
   contributors. They include (in alphabetical order):

        Robert W. Baldwin
        
        RSA Labs.

        Kevin Kingdon
        
        RSA Labs

        Hugo Krawczyk
        
        IBM Corporation

        Perry Metzger
        
        Piermont Information Services

        Bill Simpson
        
        Computer Systems Consulting Services

        David A Wagner
        
        University of California at Berkeley





Hughes                                                          [Page 8]





RFC DRAFT                                                     April 1996


   In addition, the contributions of the entire IPSEC Working Group are
   acknowledged.

   The IPsec working group can be contacted through the chairs:

        Ran Atkinson
        
        Cisco Systems

        Paul Lambert
        
        Oracle Corporation


Editor's Address


   James P. Hughes
   
   Network Systems Corporation































Hughes                                                          [Page 9]





RFC DRAFT                                                     April 1996


Appendix A


   This is a routine that implements a 32 packet window. This is
   intended on being an implementation sample.


#include 
#include 
typedef unsigned long u_long;

enum {
    ReplayWindowSize = 32
};

u_long bitmap = 0;          /* session state - must be 32 bits */
u_long lastSeq = 0;         /* session state */

/* Returns 0 if packet disallowed, 1 if packet permitted */
int ChkReplayWindow(u_long seq);

int ChkReplayWindow(u_long seq) {
    u_long diff;

    if (seq == 0) return 0; /* first == 0 or wrapped */
    if (seq > lastSeq) {    /* new larger sequence number */
        diff = seq - lastSeq;
        if (diff < ReplayWindowSize) { /* In window */
            bitmap <<= diff;
            while (diff > 1) bitmap &= ~(1 << --diff);
            bitmap |= 1;    /* set bit for this packet */
        } else bitmap = 1;  /* This packet has a "way larger" */
        lastSeq = seq;
        return 1;           /* larger is good */
    }
    diff = lastSeq - seq;
    if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
    if (bitmap & (1 << diff)) return 0; /* this packet already seen */
    bitmap |= (1 << diff);  /* mark as seen */
    return 1;               /* out of order but good */
}










Hughes                                                         [Page 10]





RFC DRAFT                                                     April 1996


char string_buffer[512];
#define STRING_BUFFER_SIZE sizeof(string_buffer)

int main() {
    int result;
    u_long last, current, bits;

    printf("Input initial state (bits in hex, last msgnum):0);
    if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
    sscanf(string_buffer, "%lx %lu", &bits, &last);
    if (last != 0)
    bits |= 1;
    bitmap = bits;
    lastSeq = last;
    printf("bits:%08lx last:%lu0, bitmap, lastSeq);
    printf("Input value to test (current):0);

    while (1) {
        if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
        sscanf(string_buffer, "%lu", ¤t);
        result = ChkReplayWindow(current);
        printf("%-3s", result ? "OK" : "BAD");
        printf(" bits:%08lx last:%lu0, bitmap, lastSeq);
    }
    return 0;
}

























Hughes                                                         [Page 11]





RFC DRAFT                                                     April 1996


Appendix B, Sample Packet Format


   This appendix contains sample packets for use by implementors checking the
   their implementations. This is not intended to be a
   complete test, but it intended to be a single data point.

   The keys used in this example are:

         DES Key   =  12345678  9abcdef0
         IV Key    =  87654321  0fedcba9
         HMAC Key  =  01020304  05060708  090a0b0c  0d0e0f10


      Sample packet format in mode esp-DES-IV64 (Privacy Tunnel (64 IV))

      Offset Field      Data                encoded packet
      00    SPI                             00000100
      04    IV                              45454545
      08                                    a6a6a6a6
      0c    data       11111111             2a7440e8
      10               22222222             182aaace
      14               33333333             5709748b
      18               44444444             2b73fd63
      1c               00000000             4da53aea
      1c    Pad        00000604             d2b2c83b


      Sample packet format in mode esp-DES-HMAC-RP (DES, HMAC, Replay
      (Mandatary transform).

      Offset Field      Data                encoded packet
      00    SPI                             00000100
      04    Replay                          00000001
      08    data       11111111             885da058
      0c               22222222             c548a6f4
      10               33333333             f1576af7
      14               44444444             eadcc0f0
      18               00000000             7d7ad17a
      1c    Pad        00000604             9284ed5a
      20   HMAC                             d6e8a3f2
      24                                    bfebd36e
      28                                    aa0cf05f
      2c                                    ac278b32







Hughes                                                         [Page 12]



jim

Security Working Group                               IPsec Working Group
Request for Comments: DRAFT                            J. Hughes, Editor
                                                              April 1996
                                                   Expires in Six months


    Combined DES-CBC, HMAC and Replay Prevention Security Transform
                   <draft-ietf-ipsec-des-md5-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@tis.com) or to the editor.

   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 and optionally,
   authentication, integrity and replay prevention into a single packet
   format.

   This document is the result of significant work by several major
   contributors and the IPsec working group as a whole. These
   contributors, cited later in this document, provided many of the key
   technical details summarized in this document.







Hughes                                                          [Page 1]





RFC DRAFT                                                     April 1996


Discussion

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

   The valid combinations of this transformation are summarized below.

         Name              Description
         --------          --------------
         esp-DES-IV32      Privacy Tunnel (32 IV)
         esp-DES-IV64      Privacy Tunnel (64 IV)
         esp-DES-HMAC-RP   DES, HMAC, Replay (Mandatary transform)


   The combinations of transformations are negotiated at key
   establishment time such as described in ISA/KMP [Maughan96] and
   Oakley [Orman96]. To conform with this RFC, of the 3 transforms
   documented in this RFC, only esp-DES-HMAC-RP shall be implemented.


Packet Format

   There are 3 slightly different packet formats.

Format with 32 bit IV (esp-DES-IV32)

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Security Parameters Index (SPI)                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             IV                                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
 |                                                               |   ^
 ~                      Payload Data                             ~   |
 |                                                               |  DES
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  CBC
 |               |         Padding (0-7 bytes)                   |   |
 +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
 |                               |  Pad Length   | Payload Type  |   v
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---











Hughes                                                          [Page 2]





RFC DRAFT                                                     April 1996


Format with a 64 bit IV:

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Security Parameters Index (SPI)                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                        64 bit IV                              +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
 |                                                               |   ^
 ~                      Payload Data                             ~   |
 |                                                               |  DES
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  CBC
 |               |         Padding (0-7 bytes)                   |   |
 +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
 |                               |  Pad Length   | Payload Type  |   v
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---

Format with DES, HMAC and replay (esp-DES-HMAC-RP) (This is the Mandatary
transform)

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


Security Parameters Index


   This field is negotiated at key setup and shall not be 0 [RFC-1825]







Hughes                                                          [Page 3]





RFC DRAFT                                                     April 1996


Initialization Vector


   IV for the first block is either formed from the replay field or from
   a 32 or 64 bit IV field. The section on replay describes the
   calculation of the IV when the replay field is present.

   If a 64 bit IV is used, the entire 64 bits are the IV.

   If a 32 bit IV is used, the 32 bit IV and its compliment are then
   concatenated to form the 64 bit IV and that is them XORed by the IV
   key.



Replay Prevention


   Replay Prevention is an unsigned 32 bit up counter starting at a
   value of 1.

   The replay field is also used to create the IV for the first block of
   ciphertext.  This is accomplished by concatenating the SPI and the
   replay field and XORing this against 64 bits of IV key material (see
   section on keys). The resulting 64 bits are the IV.

   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. If more than 2^32 packets are transmitted, the counter will
   alias back to the initial value.  Counter wrapping shall be
   considered a replay attack.

   At the receiving point, the replay value is assured to be increasing.
   The implementation may accept of out of order packets. The number of
   packets wiling to accept out of order is an implementation detail. If
   a "out of order window" is supported, the implementation shall ensure
   that any and all packets accepted out of order are guaranteed not to
   have arrived before. That is, the implementation will accept any
   packet at most once.

   An example may allow the most recent 32 packets to be allowed to
   arrive out of order. That is, these 32 packets can arrive in any
   sequence relative to each other except that these packets are
   guaranteed to arrive only once.

   Other window sizes are optional, both larger and smaller.

   Appendix A has actual code that implement a 32 packet replay window



Hughes                                                          [Page 4]





RFC DRAFT                                                     April 1996


   and a test routine to show how it works.


Payload


   The payload contains data that is described by the payload type
   field. This is a byte length field that can end on any boundary
   within a word.


Padding


   Shall contains the number of pad bytes to fill the space between the
   end of the payload and the "pad length" field so that the "payload
   type" field ends on a double word boundary.

   Padding bytes man be initialized with random data.

   More than the minimum bytes necessary to achieve a double word
   boundary may inserted provided that the total number of bytes added
   are less than 255.


Pad Length


   Shall contain an unsigned number of bytes of padding. A value of 0
   means there was no padding and that the byte immediately preceding
   the Pad Length field is the last byte of the payload.


Payload Type


   Describes what the payload is. The values are described in:

     ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers












Hughes                                                          [Page 5]





RFC DRAFT                                                     April 1996


HMAC Residual


   The HMAC residual is a 128 bit residue described in [Krawczyk96].
   This covers the SPI, replay, payload, padding, pad length, payload
   type.

   HMAC is a keyed algorithm and shall use the HMAC key as described in
   the section on keys.


Key Material


   The key material for the transform is provided by key management
   protocol. These bits will be hashed down so that the quality of the
   bits do not need to have 100% entropy.

   There are 4 keys. The key management key "K", the "DES Key", the "IV
   key" and the "HMAC key". The key provided by the key management layer
   is K.  All the other keys are derived from that key.

   Let MD5(x|y) describes taking the residual x concatenated with y.
   Let Truncate(x,n) takes the first n bits from x and discards the
   rest.

   DES Key   = Truncate(MD5( DPad | K ),64)
   IV Key    = Truncate(MD5( IPad | K ),64)
   HMAC Key  =          MD5( HPad | K )

   where each _Pad is 512 bit string.

   DPad = 0x5C repeated 64 times.
   IPad = 0xAC repeated 64 times.
   HPad = 0x53 repeated 64 times.

   The 16 byte intermediate residuals can be precalculated from these
   constants.

   This method will work with key material from the key server of any
   size, caveat emptor.










Hughes                                                          [Page 6]





RFC DRAFT                                                     April 1996


Security Considerations


   The claims of privacy, integrity, authentication, and optional replay
   prevention are made in this draft. I will not try to diagram all the
   security considerations. A good text is [Schneier95].

   Privacy is provided by DES-CBC [Schneier95].

   Integrity is provided by HMAC [Krawczyk96].

   Authentication is provided since only the source and destination know
   the HMAC key. If the HMAC is correct, it proves that it must have
   been added by the source, since only the source knows the HMAC key.

   Replay prevention is provided by the combination of a constantly
   increasing count, the SPI and the HMAC key. The integrity of the
   replay field is provided by the HMAC.

   There are active attacks to esp-DES-IV32 and esp-DES-IV64 which can
   (in certain circumstances) compromise the confidentiality of messages
   encrypted under the DES privacy transform, when no message integrity
   protection is in use [Bellovin96].

   The ESP-DES-HMAC-RP transform described in this draft is immune to
   this active attack. (AH [RFC-1826], in some modes, can also provide
   immunity to this attack [Bellovin96].)




References


   [Bellovin96] Bellovin, S., "Problem Areas for the IP Security
   Protocols", AT&T Research,
   ftp://ftp.research.att.com/dist/smb/badesp.ps, July, 1996.

   [Krawczyk96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC-MD5:
   Keyed-MD5 for Message Authentication",
  /draft-ietf-ipsec-> http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec-
   hmac-md5-00.txt, March, 1996

   [Maughan96] Maughan, D., Schertler, M. Internet Security Association
   and Key Management Protocol (ISAKMP)
  /draft-ietf-ipsec-> http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec-
   isakmp-04.txt, February, 1996




Hughes                                                          [Page 7]





RFC DRAFT                                                     April 1996


   [Orman96] Orman, H., "The Oakley Key Determination Protocol",
  /draft-ietf-ipsec-> http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec-
   oakley-00.txt, February, 1996.

   [RFC-1825] Atkinson, R, "Security Architecture for the Internet
   Protocol", ftp://ds.internic.net/rfc/rfc1825.txt, August 1995.

   [RFC-1826] Atkinson, R, "IP Authentication Header",
   ftp://ds.internic.net/rfc/rfc1826.txt, August 1995.

   [Schneier95] Schneier, B., "Applied Cryptography Second Edition",
   John Wiley & Sons, New York, NY, 1995.  ISBN 0-471-12845-7





Acknowledgements


   This document is the result of significant work by several major
   contributors. They include (in alphabetical order):

        Robert W. Baldwin
        
        RSA Labs.

        Kevin Kingdon
        
        RSA Labs

        Hugo Krawczyk
        
        IBM Corporation

        Perry Metzger
        
        Piermont Information Services

        Bill Simpson
        
        Computer Systems Consulting Services

        David A Wagner
        
        University of California at Berkeley





Hughes                                                          [Page 8]





RFC DRAFT                                                     April 1996


   In addition, the contributions of the entire IPSEC Working Group are
   acknowledged.

   The IPsec working group can be contacted through the chairs:

        Ran Atkinson
        
        Cisco Systems

        Paul Lambert
        
        Oracle Corporation


Editor's Address


   James P. Hughes
   
   Network Systems Corporation































Hughes                                                          [Page 9]





RFC DRAFT                                                     April 1996


Appendix A


   This is a routine that implements a 32 packet window. This is
   intended on being an implementation sample.


#include 
#include 
typedef unsigned long u_long;

enum {
    ReplayWindowSize = 32
};

u_long bitmap = 0;          /* session state - must be 32 bits */
u_long lastSeq = 0;         /* session state */

/* Returns 0 if packet disallowed, 1 if packet permitted */
int ChkReplayWindow(u_long seq);

int ChkReplayWindow(u_long seq) {
    u_long diff;

    if (seq == 0) return 0; /* first == 0 or wrapped */
    if (seq > lastSeq) {    /* new larger sequence number */
        diff = seq - lastSeq;
        if (diff < ReplayWindowSize) { /* In window */
            bitmap <<= diff;
            while (diff > 1) bitmap &= ~(1 << --diff);
            bitmap |= 1;    /* set bit for this packet */
        } else bitmap = 1;  /* This packet has a "way larger" */
        lastSeq = seq;
        return 1;           /* larger is good */
    }
    diff = lastSeq - seq;
    if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
    if (bitmap & (1 << diff)) return 0; /* this packet already seen */
    bitmap |= (1 << diff);  /* mark as seen */
    return 1;               /* out of order but good */
}










Hughes                                                         [Page 10]





RFC DRAFT                                                     April 1996


char string_buffer[512];
#define STRING_BUFFER_SIZE sizeof(string_buffer)

int main() {
    int result;
    u_long last, current, bits;

    printf("Input initial state (bits in hex, last msgnum):0);
    if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
    sscanf(string_buffer, "%lx %lu", &bits, &last);
    if (last != 0)
    bits |= 1;
    bitmap = bits;
    lastSeq = last;
    printf("bits:%08lx last:%lu0, bitmap, lastSeq);
    printf("Input value to test (current):0);

    while (1) {
        if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
        sscanf(string_buffer, "%lu", ¤t);
        result = ChkReplayWindow(current);
        printf("%-3s", result ? "OK" : "BAD");
        printf(" bits:%08lx last:%lu0, bitmap, lastSeq);
    }
    return 0;
}

























Hughes                                                         [Page 11]





RFC DRAFT                                                     April 1996


Appendix B, Sample Packet Format


   This appendix contains sample packets for use by implementors checking the
   their implementations. This is not intended to be a
   complete test, but it intended to be a single data point.

   The keys used in this example are:

         DES Key   =  12345678  9abcdef0
         IV Key    =  87654321  0fedcba9
         HMAC Key  =  01020304  05060708  090a0b0c  0d0e0f10


      Sample packet format in mode esp-DES-IV64 (Privacy Tunnel (64 IV))

      Offset Field      Data                encoded packet
      00    SPI                             00000100
      04    IV                              45454545
      08                                    a6a6a6a6
      0c    data       11111111             2a7440e8
      10               22222222             182aaace
      14               33333333             5709748b
      18               44444444             2b73fd63
      1c               00000000             4da53aea
      1c    Pad        00000604             d2b2c83b


      Sample packet format in mode esp-DES-HMAC-RP (DES, HMAC, Replay
      (Mandatary transform).

      Offset Field      Data                encoded packet
      00    SPI                             00000100
      04    Replay                          00000001
      08    data       11111111             885da058
      0c               22222222             c548a6f4
      10               33333333             f1576af7
      14               44444444             eadcc0f0
      18               00000000             7d7ad17a
      1c    Pad        00000604             9284ed5a
      20   HMAC                             d6e8a3f2
      24                                    bfebd36e
      28                                    aa0cf05f
      2c                                    ac278b32







Hughes                                                         [Page 12]

Xref subject previous
Xref subject next

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

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

quoting from the draft:

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

      The combinations of transformations are negotiated at key
      establishment time such as described in ISA/KMP [Maughan96] and
      Oakley [Orman96]. To conform with this RFC, of the 3 transforms
      documented in this RFC, only esp-DES-HMAC-RP shall be
      implemented.

Ok, is integrity protection mandatory or not?

My impression (and please correct me if I'm wrong) was that the
consensus of the WG at the LA IETF was that privacy without integrity
was too dangerous to implement; however, this draft is internally
inconsistant about whether integrity is mandatory, and specifies
transforms which it says should not be implemented.

What's changed?

					- Bill




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

iQCVAwUBMYZLtFpj/0M1dMJ/AQFV2QP9FTCQ0W9OmUjcr9ZUsDtliflNMca4SEeg
7r+Gdd0D24KPaJji24FHZdf/JpM45mrlGYf4AzsQ9gBbLN2+uyinqVH4K9F1QQ5X
5sgUVrCC+ylq4uVMTak55f48Pq3pBmOKv+8jaeoULOgGD3WPi1YVHyG8IOZkSyB/
zMlgCYfKAho=
=YX9J
-----END PGP SIGNATURE-----

Xref subject previous
Xref subject next

Is there any security reason as to why we ae XORing the IV key when we use
32 bit IV and replay protection and not when using IV lenght of 64 bits. If
there is none, then I would suggest that we make it uniform and either XOR
with IV key for all transform or dont do it for any transform.

Thanks,

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

Network Working Group                                   M. Oehler (NSA)
                                                        R. Glenn (NIST)
Internet Draft                                          May 1, 1996


           HMAC-MD5 IP Authentication with Replay Prevention
                 <draft-ietf-ipsec-ah-hmac-md5-00.txt>


Status of This Memo

   Distribution of this memo is unlimited.

   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 not appropriate to use Internet Drafts as
   reference material, or to cite them other than as a ``working draft''
   or ``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)
      ds.internic.net (US East Coast)
      ftp.isi.edu (US West Coast)
      munnari.oz.au (Pacific Rim)

Abstract

   This document describes a keyed-MD5 transform to be used in
   conjunction with the IP Authentication Header [RFC-1826]. The
   particular transform is based on [HMAC-MD5].  An option is also
   specified to guard against replay attacks.











Oehler, Glenn                                                   [Page 1]

INTERNET DRAFT                May 1, 1996          Expires November 1996


Contents

   1.  Introduction...................................................3
   1.1    Keys........................................................3
   1.2    Data Size...................................................4
   2.  Packet Format..................................................4
   2.1    Replay Prevention...........................................4
   2.2    Authentication Data Calculation.............................5
   3.  Security Considerations........................................6
   ACKNOWLEDGMENTS....................................................6
   REFERENCES.........................................................6
   CONTACTS...........................................................6







































Oehler, Glenn                                                   [Page 2]

INTERNET DRAFT                May 1, 1996          Expires November 1996


1. Introduction

   The Authentication Header (AH) [RFC-1826] provides integrity and
   authentication for IP datagrams. The transform specified in this
   document uses a keyed-MD5 mechanism [HMAC-MD5].  The mechanism uses
   the (key-less) MD5 hash function [RFC-1321] which produces a message
   authentication code. When combined with an AH Key, authentication
   data is produced. This value is placed in the Authentication Data
   field of the AH [RFC-1826]. This value is also the basis for the data
   integrity service offered by the AH protocol.

   To provide protection against replay attacks, a Replay Prevention
   field is included as a transform option.  The Security Parameters
   Index (SPI) [RFC-1825] is used to determine whether this option is
   included in the AH.

   Familiarity with the following documents is assumed: "Security
   Architecture for the Internet Protocol" [RFC-1825], "IP
   Authentication Header" [RFC-1826], and "HMAC-MD5: Keyed-MD5 for
   Message Authentication" [HMAC-MD5].

1.1 Keys

   The "AH Key" is used as a shared secret between two communicating
   parties.  The Key is not a "cryptographic key" as used in a
   traditional sense. Instead, the AH key (shared secret) is hashed with
   the transmitted data and thus, assures that an intervening party
   cannot duplicate the authentication data.

   Even though an AH key is not a cryptographic key, the rudimentary
   concerns of cryptographic keys still apply. Consider that the
   algorithm and most of the data used to produce the output is known.
   The strength of the transform lies in the singular mapping of the key
   (which needs to be strong) and the IP datagram (which is known) to
   the authentication data.  Thus, implementations should, and as
   frequently as possible, change the AH key. Keys need to be chosen at
   random, or generated using a cryptographically strong pseudo-random
   generator seeded with a random seed. [HMAC-MD5]

   There is no mandated key size for the HMAC-MD5 transform.
   Implementations must support a key length of any size, except zero.
   It is advised that keys be chosen as the length of the hash output,
   or 128-bits for MD5. For other key lengths, the following concerns
   must be considered.

   A key length of zero is prohibited and implementations should provide
   an alert, since the authentication data would be identical to that of
   MD5, solely.  Less than 16 bytes is strongly discouraged as it would



Oehler, Glenn                                                   [Page 3]

INTERNET DRAFT                May 1, 1996          Expires November 1996


   decrease the security strength of the function.  Keys longer than 16
   bytes are acceptable, but the extra length would not significantly
   increase the function strength. A longer key may be advisable if the
   randomness of the key is suspect.  MD5 operates on 64-byte blocks.
   Keys longer than 64 bytes are first hashed using MD5.  The resulting
   hash is then used to calculate the authentication data.

1.2 Data Size

   MD5 produces a 128-bit value which is used as the authentication
   data.  It is naturally 64 bit aligned and thus, does not need any
   padding for machines with native double words.

2. Packet Format

        +---------------+---------------+---------------+---------------+
        | Next Header   | Length        |           RESERVED            |
        +---------------+---------------+---------------+---------------+
        |                              SPI                              |
        +---------------+---------------+---------------+---------------+
        +                     Replay Prevention  (optional)             |
        +---------------+---------------+---------------+---------------+
        |                                                               |
        +                     Authentication Data                       |
        |                                                               |
        +---------------+---------------+---------------+---------------+
         1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

   The Next Header, RESERVED, and SPI fields are specified in [RFC-
   1826].  The Length field is the length of the Replay Prevention field
   and the Authentication Data in 32-bit words.

2.1 Replay Prevention

   The Replay Prevention field is a 32 bit value used to guarantee that
   each packet exchanged between two parties is different.  This field
   is similar to the one specified in [ESP-DES-MD5].  The SPI is used to
   determine whether or not the field is included in the packet (i.e. if
   it is not included, the header will have the SPI directly followed by
   the Authentication Data).  Without this field it is possible to
   attack a system by retransmitting packets.

   The 32-bit field is an up counter starting at a value of 1.

   The secret shared 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.




Oehler, Glenn                                                   [Page 4]

INTERNET DRAFT                May 1, 1996          Expires November 1996


   Upon receipt, the replay value is assured to be increasing.  The
   implementation may accept of out of order packets. The number of
   packets to accept out of order is an implementation detail. If a "out
   of order window" is supported, the implementation shall ensure that
   any and all packets accepted out of order are guaranteed not to have
   arrived before. That is, the implementation will accept any packet at
   most once.

   [ESP-DES-MD5] provides example code that implements a 32 packet
   replay window and a test routine to show how it works.

2.2 Authentication Data Calculation

   The authentication data is the output of the authentication algorithm
   (MD5).  This value is calculated over the entire IP datagram. Fields
   within the datagram that are variant during transit and the
   authentication data field itself, must contain all zeros [RFC-1826].
   The Replay Prevention field if present, is included in the
   calculation.

   The definition and reference implementation of MD5 appears in [RFC-
   1321].  Let 'text' denote the data to which HMAC-MD5 is to be applied
   and K be the message authentication secret key shared by the parties.

   We define two fixed and different strings ipad and opad as follows
   (the 'i' and 'o' are mnemonics for inner and outer):
                  ipad = the byte 0x36 repeated 64 times
                  opad = the byte 0x5C repeated 64 times.
   To compute HMAC-MD5 over the data `text' we perform
                         MD5(K XOR opad, MD5(K XOR ipad, text))
   Namely,
          (1) append zeros to the end of K to create a 64 byte string
              (e.g., if K is of length 16 bytes it will be appended with 48
              zero bytes 0x00)
          (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step
              (1) with ipad
          (3) append the data stream 'text' to the 64 byte string resulting
              from step (2)
          (4) apply MD5 to the stream generated in step (3)
          (5) XOR (bitwise exclusive-OR) the 64 byte string computed in
              step (1) with opad
          (6) append the MD5 result from step (4) to the 64 byte string
              resulting from step (5)
          (7) apply MD5 to the stream generated in step (6) and output
              the result

      This computation is described in more detail, along with example
      code and performance improvements, in [HMAC-MD5].



Oehler, Glenn                                                   [Page 5]

INTERNET DRAFT                May 1, 1996          Expires November 1996


3. Security Considerations

   The security of this transform depends heavily on the strength of MD5
   and the associated secret key.  [HMAC-MD5] contains a detailed
   discussion on the strengths and weaknesses of MD5.

Acknowledgments

   This document is largely based on text written by Hugo Krawczyk.  The
   format used was derived from work by William Simpson and Perry
   Metzger.  The text on replay prevention is derived directly from work
   by Jim Hughes.

References


   [RFC-1825]    R. Atkinson, "Security Architecture for the Internet
                 Protocol", RFC-1852, Naval Research Laboratory, July 1995.
   [RFC-1826]    R. Atkinson, "IP Authentication Header",
                 RFC-1826, August 1995.
   [RFC-1828]    P. Metzger, W. A. Simpson, "IP Authentication using Keyed MD5",
                 RFC-1828, August 1995.
   [RFC-1321]    R. Rivest, "The MD5 Message-Digest Algorithm",
                 RFC-1321, April 1992.
   [HMAC-MD5]    H. Krawczyk, M. Bellare, R. Canetti, "HMAC-MD5: Keyed-MD5
                 for Message Authentication", Internet Draft, March, 1996.
   [ESP-DES-MD5] J. Hughes, "Combined DES-CBC, MD5, and Replay Prevention
                 Security Transform", Internet Draft, April, 1996.


Contacts

   Michael J. Oehler
   National Security Agency
   Atn: R23, INFOSEC Research and Development
   9800 Savage Road
   Fort Meade, MD 20755

   mjo@tycho.ncsc.mil

   Robert Glenn
   NIST
   Building 820, Room 455
   Gaithersburg, MD 20899

   rob.glenn@nist.gov





Oehler, Glenn                                                   [Page 6]


Network Working Group                                   S. Chang (NIST)
                                                        R. Glenn (NIST)
                                                        May 1, 1996
Internet Draft


           HMAC-SHA IP Authentication with Replay Prevention
                 <draft-ietf-ipsec-ah-hmac-sha-00.txt>


Status of This Memo

   Distribution of this memo is unlimited.

   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 not appropriate to use Internet Drafts as
   reference material, or to cite them other than as a ``working draft''
   or ``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)
      ds.internic.net (US East Coast)
      ftp.isi.edu (US West Coast)
      munnari.oz.au (Pacific Rim)

Abstract

   This document describes a keyed-SHA transform to be used in
   conjunction with the IP Authentication Header [RFC-1826]. The
   particular transform is based on [HMAC-MD5].  An option is also
   specified to guard against replay attacks.










Chang, Glenn                                                    [Page 1]

INTERNET DRAFT                May 1, 1996          Expires November 1996


Contents

   1.  Introduction...................................................3
   1.1    Keys........................................................3
   1.2    Data Size...................................................4
   2   Packet Format..................................................4
   2.1    Replay Prevention...........................................4
   2.2    Authentication Data Calculation.............................5
   3.  Security Considerations........................................6
   ACKNOWLEDGMENTS....................................................6
   REFERENCES.........................................................6
   CONTACTS...........................................................6







































Chang, Glenn                                                    [Page 2]

INTERNET DRAFT                May 1, 1996          Expires November 1996


1. Introduction

   The IP Authentication Header (AH) provides integrity and
   authentication for IP datagrams [RFC-1826]. The transform specified
   in this document uses a keyed-SHA mechanism based on [HMAC-MD5].  The
   mechanism uses the (key-less) SHA hash function [FIPS-180-1] which
   produces a message authentication code. When combined with an AH Key,
   authentication data is produced. This value is placed in the
   Authentication Data field of the AH [RFC-1826]. This value is also
   the basis for the data integrity service offered by the AH protocol.


   To provide protection against replay attacks, a Replay Prevention
   field is included as a transform option.  The Security Parameters
   Index (SPI) [RFC-1825] is used to determine whether this option is
   included in the AH.

   Familiarity with the following documents is assumed: "Security
   Architecture for the Internet Protocol" [RFC-1825], "IP
   Authentication Header" [RFC-1826], and "HMAC-MD5: Keyed-MD5 for
   Message Authentication" [HMAC-MD5].

1.1 Keys

   The "AH Key" is used as a shared secret between two communicating
   parties.  The Key is not a "cryptographic key" as used in a
   traditional sense. Instead, the AH key (shared secret) is hashed with
   the transmitted data and thus, assures that an intervening party
   cannot duplicate the authentication data.

   Even though an AH key is not a cryptographic key, the rudimentary
   concerns of cryptographic keys still apply. Consider that the
   algorithm and most of the data used to produce the output is known.
   The strength of the transform lies in the singular mapping of the key
   (which needs to be strong) and the IP datagram (which is known) to
   the authentication data.  Thus, implementations should, and as
   frequently as possible, change the AH key. Keys need to be chosen at
   random, or generated using a cryptographically strong pseudo-random
   generator seeded with a random seed. [HMAC-MD5]

   There is no mandated key size for the HMAC-SHA transform.
   Implementations must support a key length of any size, except zero.
   It is advised that keys be chosen as the length of the hash output,
   or 160-bits for SHA. For other key lengths, the following concerns
   must be considered.

   A key length of zero is prohibited and implementations should provide
   an alert, since the authentication data would be identical to that of



Chang, Glenn                                                    [Page 3]

INTERNET DRAFT                May 1, 1996          Expires November 1996


   SHA, solely.  SHA operates on 64-byte blocks.  Keys longer than 64
   bytes are first hashed using SHA.  The resulting hash is then used to
   calculated the authentication data.

1.2 Data Size

   SHA generates a message digest of 160 bits, which is automatically
   aligned on a 32-bit word boundary. However, some implementations may
   require 64-bit alignment of the IP headers, in which case, 32 zero
   bits are appended as padding to the SHA output. The length of the
   Authentication Data, specified in the Length field of the AH in 32-
   bit words, should include the padding bits. Therefore, an
   implementation that appends a 32-bit padding to the SHA output will
   have a length of six 32-bit words.  The padded bits are ignored at
   the receiving end.

2. Packet Format

        +---------------+---------------+---------------+---------------+
        | Next Header   | Length        |           RESERVED            |
        +---------------+---------------+---------------+---------------+
        |                              SPI                              |
        +---------------+---------------+---------------+---------------+
        |                     Replay Prevention (optional)              |
        +---------------+---------------+---------------+---------------+
        |                                                               |
        +                     Authentication Data                       |
        |                                                               |
        +---------------+---------------+---------------+---------------+
         1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

   The Next Header, RESERVED, and SPI fields are specified in [RFC-
   1826]. The Length field is the length of the Replay Prevention field
   and the Authentication Data in 32-bit words.

2.1 Replay Prevention

   The Replay Prevention field is a 32 bit value used to guarantee that
   each packet exchanged between two parties is different.  This field
   is similar to the one specified in [ESP-DES-MD5].  The SPI is used to
   determine whether or not the field is included in the packet (i.e. if
   it is not included, the header will have the SPI directly followed by
   the Authentication Data).  Without this field it is possible to
   attack a system by retransmitting packets.

   The 32-bit field is an up counter starting at a value of 1.

   The secret shared key must not be used for a period of time that



Chang, Glenn                                                    [Page 4]

INTERNET DRAFT                May 1, 1996          Expires November 1996


   allows the counter to wrap, that is, to transmit more than 2^32
   packets using a single key.

   Upon receipt, the replay value is assured to be increasing.  The
   implementation may accept of out of order packets. The number of
   packets to accept out of order is an implementation detail. If a "out
   of order window" is supported, the implementation shall ensure that
   any and all packets accepted out of order are guaranteed not to have
   arrived before. That is, the implementation will accept any packet at
   most once.

   [ESP-DES-MD5] provides example code that implements a 32 packet
   replay window and a test routine to show how it works.

2.2 Authentication Data Calculation

   The computation of the 160-bit SHA digest is described
   in [FIPS-180-1].  The digest is calculated over
   the entire IP datagram. Fields within the datagram that are variant
   during transit and the authentication data field itself, must contain
   all zeros prior to the computation [RFC-1826].
   The Replay Prevention field, if present, is included in the calculation.

   To compute HMAC-SHA over the data 'text', the following is calculated:

       SHA (K XOR epad, SHA (K XOR ipad, text))

   where 'K' denotes the secret key shared by the parties, and 'epad', 'ipad'
   denotes a fixed string for internal and external padding respectively. The
   two strings are:

       ipad = the byte 0x36 repeated 64 times,
       epad = the byte 0x5C repeated 64 times.

   The calculation of the authentication data consists of the following steps:

   (1) append zeros to the end of K to create a 64 byte string (e.g., if K is
       of length 20 bytes it will be appended with 44 zero bytes 0x00)
   (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with
       ipad
   (3) concatenate to the 64 byte string resulting from step (2) the data
       stream 'text'
   (4) apply SHA to the stream generated in step (3)
   (5) XOR the 64 byte string computed in step (1) with epad
   (6) concatenate to the 64 byte string resulting from step (5) the SHA result
       of step (4)
   (7) apply SHA to the stream generated in step (6)
   (8) Pad to 64-bit boundary if necessary for word alignment



Chang, Glenn                                                    [Page 5]

INTERNET DRAFT                May 1, 1996          Expires November 1996


   A similar computation is described in more detail, along with example
   code and performance improvements, in [HMAC-MD5].
3. Security Considerations

   The security provided by this transform is based on the strength of
   SHA and the associated secret key.  At this time there are no known
   cryptographic attacks against SHA [SCHNEIER]. The 160-bit digest
   makes SHA more resistant to brute force attacks than MD4 and MD5
   which produce a 128-bit digest.

Acknowledgments

This document is largely based on text written by Hugo Krawczyk.  The
format used was derived from work by William Simpson and Perry Metzger.
The text on replay prevention is derived directly from work by Jim
Hughes.

References


   [RFC-1825]    R. Atkinson, "Security Architecture for the Internet Protocol",
                 RFC-1825, August 1995.
   [RFC-1826]    R. Atkinson, "IP Authentication Header",
                 RFC-1826, August 1995.
   [RFC-1828]    P. Metzger, W. A. Simpson, "IP Authentication using Keyed MD5",
                 RFC-1828, August 1995.
   [HMAC-MD5]    H. Krawczyk, M. Bellare, R. Canetti, "HMAC-MD5: Keyed-MD5
                 for Message Authentication", Internet Draft, March, 1996.
   [FIPS-180-1]  NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
   [SCHNEIER]    B. Schneier, "Applied Cryptography Protocols, Algorithms, and
                 Source Code in C", John Wiley & Sons, Inc. 1994.
   [ESP-DES-MD5] J. Hughes, "Combined DES-CBC, MD5, and Replay Prevention
                 Security Transform", Internet Draft, April, 1996.

Contacts

   Shu-jen Chang
   NIST
   Building 820, Room 456
   Gaithersburg, MD 20899

   shu-jen.chang@nist.gov

   Robert Glenn
   NIST
   Building 820, Room 455
   Gaithersburg, MD 20899




Chang, Glenn                                                    [Page 6]

INTERNET DRAFT                May 1, 1996          Expires November 1996


   rob.glenn@nist.gov


















































Chang, Glenn                                                    [Page 7]


Xref subject next

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

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

   James, I would suggest in the esp-DES-HMAC-RP transform, the source and
   destination addresses of the IP packet (which will carry the IPSEC payload)
   be included in the HMAC computation to provide a sense of direction. These
   addresses do not have to appear in the actual packet transmitted.
   
   This is to provide some defense against reflection attacks. I think this
   is necessary since it is likely the same set of keys will be used in
   both directions.

Huh?

All of the proposed key mgmt protocols I've looked at in any detail
generate different keys (and different SPI's) in each direction.

					- Bill




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

iQCVAwUBMYaNrFpj/0M1dMJ/AQGOmwP9ECO7L+FKXkVKpka3W2Up8notvGI/JLjN
pZ1N/Uyypb8x0jWDfeDW9DBZswWkmOeBZNkH7lXQc3oLUzadZvCV2jUAO+fahWCy
ipMK+ZgPC+Vp6MXji1QyesHQSABJ1xgtH7q6KHtTmtesePTGS6XiUpWgopq7dITQ
521B2uYhX/A=
=P2Vk
-----END PGP SIGNATURE-----

Xref: Re: draft-ietf-ipsec-des-md5-00.txt  Bill Sommerfeld
Xref subject next

James, I would suggest in the esp-DES-HMAC-RP transform, the source and
destination addresses of the IP packet (which will carry the IPSEC payload)
be included in the HMAC computation to provide a sense of direction. These
addresses do not have to appear in the actual packet transmitted.

This is to provide some defense against reflection attacks. I think this
is necessary since it is likely the same set of keys will be used in
both directions.

I must admit I am not sure if it is possible for some routers to change
the source/destination addresses during transmission.


Regards, Pau-Chen

Xref: Re: draft-ietf-ipsec-des-md5-00.txt  Hilarie Orman
Xref subject previous
Xref subject previous
Xref subject next

I think Paul has raised a significant point that may be obvious to some, but is 
not obvious to me and is also not obvious from reading this document or from 
reading Oakley.

Paul@Watson.ibm.com wrote
>    James, I would suggest in the esp-DES-HMAC-RP transform, the source and
>    destination addresses of the IP packet (which will carry the IPSEC payload)
>    be included in the HMAC computation to provide a sense of direction. These
>    addresses do not have to appear in the actual packet transmitted.
> 
>    This is to provide some defense against reflection attacks. I think this
>    is necessary since it is likely the same set of keys will be used in
>    both directions.

I agree that reflection attacks need to be considered. Including the IP address 
is something that seems to be version forward dangerous (IPv7). I would suggest 
that different keys for each irection would be a better way to defend reflection 
attacks.

My assumption has been that there will be different keys in each direction, 
and...

Bill Sommerfeld wrote:
> All of the proposed key mgmt protocols I've looked at in any detail
> generate different keys (and different SPI's) in each direction.

in reading Oakley again, this did not seem to be discussed.

I would really hope that we do not need to do two complete sets of D-H/RSA to set 
up a FDX connection? 

If Oakley creates one key and the esp is to create a FDX session, then we should 
be deriving 2 sets of keys, one for each direction. This would also require the 
esp to know which end of the connection that it is so that the derivation can be 
inversely symetrical.

I need some comments here? Hillary?

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     : HMAC-MD5 IP Authentication with Replay Prevention       
       Author(s) : M. Oehler, R. Glenn
       Filename  : draft-ietf-ipsec-ah-hmac-md5-00.txt
       Pages     : 6
       Date      : 04/30/1996

This document describes a keyed-MD5 transform to be used in conjunction 
with the IP Authentication Header [RFC-1826]. The particular transform is 
based on [HMAC-MD5].  An option is also specified to guard against replay 
attacks.                                                                   

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-00.txt

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

Content-Type: text/plain
Content-ID: <19960430143416.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     : HMAC-SHA IP Authentication with Replay Prevention       
       Author(s) : S. Chang, R. Glenn
       Filename  : draft-ietf-ipsec-ah-hmac-sha-00.txt
       Pages     : 7
       Date      : 04/30/1996

This document describes a keyed-SHA transform to be used in conjunction 
with the IP Authentication Header [RFC-1826]. The particular transform is 
based on [HMAC-MD5].  An option is also specified to guard against replay 
attacks.                                                                   

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-00.txt

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

Content-Type: text/plain
Content-ID: <19960430143310.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     : HMAC-SHA IP Authentication with Replay Prevention       
       Author(s) : S. Chang, R. Glenn
       Filename  : draft-ietf-ipsec-ah-hmac-sha-00.txt
       Pages     : 7
       Date      : 04/30/1996

This document describes a keyed-SHA transform to be used in conjunction 
with the IP Authentication Header [RFC-1826]. The particular transform is 
based on [HMAC-MD5].  An option is also specified to guard against replay 
attacks.                                                                   

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-00.txt

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

Content-Type: text/plain
Content-ID: <19960430143310.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     : HMAC-MD5 IP Authentication with Replay Prevention       
       Author(s) : M. Oehler, R. Glenn
       Filename  : draft-ietf-ipsec-ah-hmac-md5-00.txt
       Pages     : 6
       Date      : 04/30/1996

This document describes a keyed-MD5 transform to be used in conjunction 
with the IP Authentication Header [RFC-1826]. The particular transform is 
based on [HMAC-MD5].  An option is also specified to guard against replay 
attacks.                                                                   

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-00.txt

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

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

--OtherAccess--

--NextPart--

Xref: Re: draft-ietf-ipsec-des-md5-00.txt Ran Atkinson
Xref subject previous
Xref subject next

Hi, this msg is a response to David's, Bill's and James's msgs.

I do agree using uni-directional keys is a better solution. It is also
easy to do, as David pointed out in his msg. In fact, we have been using 
it for a while in our lab and (soon to be) in our product.

My problem is that I don't see uni-directional keys being made mandatory
in RFC1825, ISAKMP draft 4 nor Oakley draft. I may have misread them.
If any body sees it, please kindly point it to me.

Thank you.

Regards, Pau-Chen 

Xref subject previous
Xref subject next

> quoting from the draft:
> 
>       This draft describes a combination of privacy and optionally,
>       authentication, integrity and replay prevention into a single packet
>       format.
> 
> and later:
> 
>       The combinations of transformations are negotiated at key
>       establishment time such as described in ISA/KMP [Maughan96] and
>       Oakley [Orman96]. To conform with this RFC, of the 3 transforms
>       documented in this RFC, only esp-DES-HMAC-RP shall be
>       implemented.
> 
> Ok, is integrity protection mandatory or not?

The text here seems to be clumbsy.

> My impression (and please correct me if I'm wrong) was that the
> consensus of the WG at the LA IETF was that privacy without integrity
> was too dangerous to implement; however, this draft is internally
> inconsistant about whether integrity is mandatory, and specifies
> transforms which it says should not be implemented.
> 
> What's changed?

Nothing has "changed". If anything my text is less than clear.

The mandetory transform is des-hmac. It is optional to not have the integrity 
and not to have replay. 

As Bellovan has stated, DES-CBC without integrity has several vulnerabilties, 
but that does not eliminate the viabilitiy of a des-only transform for 
performance sensitive solutions that understand these vulnerabilities and 
make an informed decision that the elimination of the hmac is not a problem. 

Suggested text for the above 2 paragraphs will be welcome.

Is Ran's text replacent better?

jim

Xref subject previous
Xref subject next

Pau,

  RFC-1825 has always said that an IPsec Security Association is
unidirectional, not bidirectional.  Keys are one element of an IPsec
Security Association.  So my reading of RFC-1825 is that it already says
that a key will normally be unidirectional.  In general, folks should
keep in mind that a Security Association contains a lot more than key
material.

  If you think that this needs to be made more clear, then I have no
problems with clarifying the text when the other editorial changes get made
to 1825-1827 (these are coming soon, but I haven't yet made the accumulated
editorial changes).  Once I get the editorial changes in hand made, new
I-Ds will go out so that people can review the I-Ds and remind me of
whichever changes need to be made but have not yet been made.

Ran
rja@cisco.com

Xref subject previous

Naganand Doraswamy wrote:
> 
> Is there any security reason as to why we ae XORing the IV key when we use
> 32 bit IV and replay protection and not when using IV lenght of 64 bits. 

The reason the XOR was added to the replay/IV creation is to defend against a 
codebook attack of early blocks assuming that the SPI is not a random number...

The reason for adding the XOR to the 32 bit IV was to prevent a birthday/codebook 
attack on the first 65K packets... This is not a significant attack, but one that 
is simple to cover...

Frankly, I had not thought about doing this for the 64 bit version.... I see little 
value in doing it, but it does not hurt?

Here is a note from an early draft that I used to explain the change.

   [Note, The IV32 procedure is a change from the esp-des-cbc. XORing by
   the IV key prevents a birthday/codebook attack on the first block.
   Inverting the second half does not mitigate the birthday/codebook
   attack.]

> If there is none, then I would suggest that we make it uniform and either XOR
> with IV key for all transform or dont do it for any transform.

this is OK by me. Comments from the Gallery?

jim

Xref subject previous
Xref subject next

pau@watson.ibm.com wrote:
> 
> Hi, this msg is a response to David's, Bill's and James's msgs.
> 
> I do agree using uni-directional keys is a better solution. It is also
> easy to do, as David pointed out in his msg. In fact, we have been using
> it for a while in our lab and (soon to be) in our product.

I was trying to avoid the product label, but NSC has product experiance with 
asymetric keys.

> My problem is that I don't see uni-directional keys being made mandatory
> in RFC1825, ISAKMP draft 4 nor Oakley draft. I may have misread them.
> If any body sees it, please kindly point it to me.

I can add this to the esp, just like dumbing the keys up was. 

After thinking aobut it, I just need something, anything to break a tie for 
picking a forward and a reverse direction. A flag as to if I am the initiator 
or responder? IP address? Lower SPI? Anyway, if there is a way, I can dumb-up a 
few more keys for directionality?

Comments?

Xref subject previous
Xref subject next

Here's my view.  Oakley doesn't set IPSEC SPI keys per se --- ISAKMP
does this.  And ISAKMP will need to define how it derives each SPI key
from the Oakley keying material.  Prepending a counter to the keying
material and hashing would seem the obvious answer ... a "0" for one
direction, "1" for the other, higher numbers for deriving keys for a
"block of SPIs".

Xref subject previous
Xref subject next

Ran, thank you very much for the explanation. RFC1825 does say that
an SPI and a destination address uniquely identifies an SA. I think
it would be better to explicitly state this "uni-directional" nature
of an SA.

Regards, Pau-Chen

> From: Ran Atkinson 
> Message-Id: <199605011637.JAA17389@puli.cisco.com>
> To: pau@watson.ibm.com
> Subject: Re: draft-ietf-ipsec-des-md5-00.txt
> In-Reply-To: <9605011423.AA20212@secpwr.watson.ibm.com>
> Organization: cisco Systems, Inc., Menlo Park, Ca.
> Cc: ipsec@TIS.COM
> Sender: ipsec-approval@neptune.tis.com
> Precedence: bulk
> Content-Length: 808
> Status: RO
> 
> Pau,
> 
>   RFC-1825 has always said that an IPsec Security Association is
> unidirectional, not bidirectional.  Keys are one element of an IPsec
> Security Association.  So my reading of RFC-1825 is that it already says
> that a key will normally be unidirectional.  In general, folks should
> keep in mind that a Security Association contains a lot more than key
> material.
> 
>   If you think that this needs to be made more clear, then I have no
> problems with clarifying the text when the other editorial changes get made
> to 1825-1827 (these are coming soon, but I haven't yet made the accumulated
> editorial changes).  Once I get the editorial changes in hand made, new
> I-Ds will go out so that people can review the I-Ds and remind me of
> whichever changes need to be made but have not yet been made.
> 
> Ran
> rja@cisco.com
> 

  Cisco Systems is pleased to announce the release of their ISAKMP daemon.
This software distribution is being made available free of charge for any
commercial or non-commercial use to advance ISAKMP as a solution to
Internet Key Management.

  To software can be downloaded by telneting to port 7600 on ftp-eng.cisco.com
and following the directions from there. 

  This daemon uses the PF_KEY Key Management API to register with a
kernel which has implemented this API and the surrounding key management
infrastructure. The NRL IPsec software distribution (currently bundled with
IPv6) is such an implementation. Security associations negotiated by the
ISAKMP daemon are inserted into the kernel's key engine and are available
for use by its AH/ESP security mechanisms. To facilitate use of this ISAKMP 
daemon, the NRL distribution is also being made available on ftp-eng
using the telnet procedure described above.

  Cisco's daemon is based on ISAKMP draft version 5 and utilizes features from
the Oakley Key Determination Protocol draft version 1. 

  This distribution comes with a cryptographic library from Cylink Corporation.
Cylink has granted Cisco the right to offer this library-- source code to
the Diffie-Hellman key exchange, the Digital Signature Standard, and the
Digital Encryption Standard-- to all third parties on a royalty-free basis
for use only with this ISAKMP reference implementation.

  A mailing list for problems, bug fixes, porting changes, and general
discussion of ISAKMP and Oakley has been established: isakmp-oakley@cisco.com 
(majordomo@cisco.com for admin requests).

Xref: Re: draft-ietf-ipsec-des-md5-00.txt  Angelos D. Keromytis
Xref: Re: draft-ietf-ipsec-des-md5-00.txt Ran Atkinson
Xref subject previous
Xref subject next


hughes@hughes.network.com wrote :


> .....

> I can add this to the esp, just like dumbing the keys up was. 
> 
> After thinking aobut it, I just need something, anything to break a tie for 
> picking a forward and a reverse direction. A flag as to if I am the initiator 
> or responder? IP address? Lower SPI? Anyway, if there is a way, I can dumb-up a 
> few more keys for directionality?
> 
> Comments?
> 


For now, I am using addresses. But addresses may not work if NAT
(network address translation) is used. SPI may be a candiate, but
the two sides may choose the same SPI value. Perhaps this problem
should be resolved at IKMP layer rather than at IPSEC layer ?
The only thing the IKMP layer needs to do is to give IPSEC layer
a 1-bit flag to indicate direction.

I know that  and  pairs
can be used to derive 2 uni-directional keys. But can IPSEC assumes
cookies will always be used ?


Regards, Pau-Chen

Xref subject previous
Xref subject next

In message <9605012213.AA21306@secpwr.watson.ibm.com>, pau@watson.ibm.com write
s:
>
>For now, I am using addresses. But addresses may not work if NAT
>(network address translation) is used. SPI may be a candiate, but
>the two sides may choose the same SPI value. Perhaps this problem
>should be resolved at IKMP layer rather than at IPSEC layer ?
>The only thing the IKMP layer needs to do is to give IPSEC layer
>a 1-bit flag to indicate direction.
>
>I know that  and  pairs
>can be used to derive 2 uni-directional keys. But can IPSEC assumes
>cookies will always be used ?
>
Anything on the packet that is not covered by an AH (or equivalent)
header cannot be used for creating two keys. My feeling is that this
is a KMP layer "problem". And then, i always opt for the greatest
flexibility, which in this case means that the KMP should load each
SPI/address/key tupple separately (maybe massively, but the key would
be explicitly specified). Might make life easier in the future. And
it's simpler too (or seems so).
-Angelos

Xref subject previous

In article <9605012213.AA21306@secpwr.watson.ibm.com> Pau wrote:

>For now, I am using addresses. But addresses may not work if NAT
>(network address translation) is used. 

For what its worth, NAT is increasingly commonplace in the deployed Internet.

>SPI may be a candiate, but the two sides may choose the same SPI value. 

Hence, SPI is probably not a good general solution.

>Perhaps this problem
>should be resolved at IKMP layer rather than at IPSEC layer ?

Yes.  IKMP layer functions need to create an _entire_ IPsec Security
Association (not just the key) and put that into place on both sides of the
session.  The IPsec layer only deals with whole IPsec Security Associations
that have already been created either manually or dynamically (just the
key alone is not sufficient and doesn't conform with the RFCs).

>The only thing the IKMP layer needs to do is to give IPSEC layer
>a 1-bit flag to indicate direction.

False.  IKMP must give the IPsec layer an _entire_ IPsec Security
Association, not just a key and a direction bit.  In fact, a direction bit
probably is not part of the explicit Security Association.  Direction is
clear from the Security Association because the Security Association
contains the destination address as one of its component.

>I know that  and  pairs
>can be used to derive 2 uni-directional keys. But can IPSEC assumes
>cookies will always be used ?

It is not clear to me what you mean by "IPsec" in the above text.

Ran
rja@cisco.com

Folks, I must apologize for bringing this issue up.

After thinking it over again, it seems to me that this problem is
naturally solved by the key management protocol.

If the KMP is designed to generate 2 uni-directional SA's with different
key values in one round, then there is no problem. If it is designed to
generate only 1 uni-directional SA in one round, then another round is
necessary to generate an SA for the other direction.

Again, sorry for the mix-up on my part.

Regards, Pau-Chen

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     : Combined DES-CBC, HMAC and Replay Prevention 
                   Security Transform                                               
       Author(s) : J. Hughes
       Filename  : draft-ietf-ipsec-esp-des-md5-01.txt
       Pages     : 12
       Date      : 04/30/1996

This draft describes a combination of privacy and optionally, 
authentication, integrity and replay prevention into a single packet 
format.                     
                                               
This document is the result of significant work by several major 
contributors and the IPsec working group as a whole. These contributors, 
cited later in this document, provided many of the key technical details 
summarized in this document.                                               

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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-des-md5-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 (193.205.245.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-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: <19960430111952.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-esp-des-md5-01.txt

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

Content-Type: text/plain
Content-ID: <19960430111952.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 IP Security Protocol Working 
Group of the IETF.                                                         

       Title     : Combined DES-CBC, HMAC and Replay Prevention 
                   Security Transform                                               
       Author(s) : J. Hughes
       Filename  : draft-ietf-ipsec-esp-des-md5-01.txt
       Pages     : 12
       Date      : 04/30/1996

This draft describes a combination of privacy and optionally, 
authentication, integrity and replay prevention into a single packet 
format.                     
                                               
This document is the result of significant work by several major 
contributors and the IPsec working group as a whole. These contributors, 
cited later in this document, provided many of the key technical details 
summarized in this document.                                               

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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-des-md5-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 (193.205.245.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-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: <19960430111952.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-esp-des-md5-01.txt

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

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

--OtherAccess--

--NextPart--

The recent draft announcement of ISAKMP and Oakley refer to version 04 and
00 respectively. However, the Cisco code that was released mentions that the
implementations are based on drafts 05 and 01 for ISAKMP and Oakley
respectively. Can someone give me pointers to the latest drafts and send
mail to the mailing stating when these will be available as internet-drafts?

Thanks,

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

Xref: Re: MD5 considered insecure? Uri Blumenthal
Xref: Re: MD5 considered insecure?  Bill Sommerfeld
Xref subject next

Steve,

  Thanks very much for sharing that paper with us.  Its quite short,
but very interesting reading.

Everyone,

  In my own personal mind, it raises the question of how we should proceed
on the AH transforms.  Possible options for the WG to consider include
at least these:
  - Make both HMAC MD5 and HMAC SHA-1 mandatory-to-implement
  - Make HMAC MD5 optional-to-implement and HMAC SHA-1 mandatory-to-implement 

  One question I have is whether it would be sensible to substitute HMAC SHA-1
for HMAC MD5 in the ESP "DES-CBC HMAC MD5 Replay" transform.  What do folks
think is best ?

  I'm hoping to see some discussion on the list about how to proceed after
folks have had the time to read and digest the material Steve has passed
along.

Ran
rja@inet.org

Xref: Re: MD5 considered insecure? Ran Atkinson
Xref subject previous
Xref subject next

There is reason to suspect that MD5 will not be secure for very much
longer.  Enclosed below, with permission, is a short note by Hans Dobbertin
on a partial cryptanalysis of MD5.  We should seriously consider making
SHA and/or RIPEMD-160 a mandatory-to-implement transform as well, in my
opinion.


		--Steve Bellovin

P.S.  My thanks to David Wagner for showing me this paper.
----
%!PS-Adobe-2.0
%%Creator: dvipsk 5.58a Copyright 1986, 1994 Radical Eye Software
%%Title: md5-compress.dvi
%%Pages: 2
%%PageOrder: Ascend
%%BoundingBox: 0 0 596 842
%%DocumentPaperSizes: a4
%%EndComments
%DVIPSCommandLine: dvips md5-compress
%DVIPSParameters: dpi=300, compressed, comments removed
%DVIPSSource:  TeX output 1996.05.02:1222
%%BeginProcSet: texc.pro
/TeXDict 250 dict def TeXDict begin /N{def}def /B{bind def}N /S{exch}N
/X{S N}B /TR{translate}N /isls false N /vsize 11 72 mul N /hsize 8.5 72
mul N /landplus90{false}def /@rigin{isls{[0 landplus90{1 -1}{-1 1}
ifelse 0 0 0]concat}if 72 Resolution div 72 VResolution div neg scale
isls{landplus90{VResolution 72 div vsize mul 0 exch}{Resolution -72 div
hsize mul 0}ifelse TR}if Resolution VResolution vsize -72 div 1 add mul
TR[matrix currentmatrix{dup dup round sub abs 0.00001 lt{round}if}
forall round exch round exch]setmatrix}N /@landscape{/isls true N}B
/@manualfeed{statusdict /manualfeed true put}B /@copies{/#copies X}B
/FMat[1 0 0 -1 0 0]N /FBB[0 0 0 0]N /nn 0 N /IE 0 N /ctr 0 N /df-tail{
/nn 8 dict N nn begin /FontType 3 N /FontMatrix fntrx N /FontBBox FBB N
string /base X array /BitMaps X /BuildChar{CharBuilder}N /Encoding IE N
end dup{/foo setfont}2 array copy cvx N load 0 nn put /ctr 0 N[}B /df{
/sf 1 N /fntrx FMat N df-tail}B /dfs{div /sf X /fntrx[sf 0 0 sf neg 0 0]
N df-tail}B /E{pop nn dup definefont setfont}B /ch-width{ch-data dup
length 5 sub get}B /ch-height{ch-data dup length 4 sub get}B /ch-xoff{
128 ch-data dup length 3 sub get sub}B /ch-yoff{ch-data dup length 2 sub
get 127 sub}B /ch-dx{ch-data dup length 1 sub get}B /ch-image{ch-data
dup type /stringtype ne{ctr get /ctr ctr 1 add N}if}B /id 0 N /rw 0 N
/rc 0 N /gp 0 N /cp 0 N /G 0 N /sf 0 N /CharBuilder{save 3 1 roll S dup
/base get 2 index get S /BitMaps get S get /ch-data X pop /ctr 0 N ch-dx
0 ch-xoff ch-yoff ch-height sub ch-xoff ch-width add ch-yoff
setcachedevice ch-width ch-height true[1 0 0 -1 -.1 ch-xoff sub ch-yoff
.1 sub]/id ch-image N /rw ch-width 7 add 8 idiv string N /rc 0 N /gp 0 N
/cp 0 N{rc 0 ne{rc 1 sub /rc X rw}{G}ifelse}imagemask restore}B /G{{id
gp get /gp gp 1 add N dup 18 mod S 18 idiv pl S get exec}loop}B /adv{cp
add /cp X}B /chg{rw cp id gp 4 index getinterval putinterval dup gp add
/gp X adv}B /nd{/cp 0 N rw exit}B /lsh{rw cp 2 copy get dup 0 eq{pop 1}{
dup 255 eq{pop 254}{dup dup add 255 and S 1 and or}ifelse}ifelse put 1
adv}B /rsh{rw cp 2 copy get dup 0 eq{pop 128}{dup 255 eq{pop 127}{dup 2
idiv S 128 and or}ifelse}ifelse put 1 adv}B /clr{rw cp 2 index string
putinterval adv}B /set{rw cp fillstr 0 4 index getinterval putinterval
adv}B /fillstr 18 string 0 1 17{2 copy 255 put pop}for N /pl[{adv 1 chg}
{adv 1 chg nd}{1 add chg}{1 add chg nd}{adv lsh}{adv lsh nd}{adv rsh}{
adv rsh nd}{1 add adv}{/rc X nd}{1 add set}{1 add clr}{adv 2 chg}{adv 2
chg nd}{pop nd}]dup{bind pop}forall N /D{/cc X dup type /stringtype ne{]
}if nn /base get cc ctr put nn /BitMaps get S ctr S sf 1 ne{dup dup
length 1 sub dup 2 index S get sf div put}if put /ctr ctr 1 add N}B /I{
cc 1 add D}B /bop{userdict /bop-hook known{bop-hook}if /SI save N @rigin
0 0 moveto /V matrix currentmatrix dup 1 get dup mul exch 0 get dup mul
add .99 lt{/QV}{/RV}ifelse load def pop pop}N /eop{SI restore userdict
/eop-hook known{eop-hook}if showpage}N /@start{userdict /start-hook
known{start-hook}if pop /VResolution X /Resolution X 1000 div /DVImag X
/IE 256 array N 0 1 255{IE S 1 string dup 0 3 index put cvn put}for
65781.76 div /vsize X 65781.76 div /hsize X}N /p{show}N /RMat[1 0 0 -1 0
0]N /BDot 260 string N /rulex 0 N /ruley 0 N /v{/ruley X /rulex X V}B /V
{}B /RV statusdict begin /product where{pop product dup length 7 ge{0 7
getinterval dup(Display)eq exch 0 4 getinterval(NeXT)eq or}{pop false}
ifelse}{false}ifelse end{{gsave TR -.1 .1 TR 1 1 scale rulex ruley false
RMat{BDot}imagemask grestore}}{{gsave TR -.1 .1 TR rulex ruley scale 1 1
false RMat{BDot}imagemask grestore}}ifelse B /QV{gsave newpath transform
round exch round exch itransform moveto rulex 0 rlineto 0 ruley neg
rlineto rulex neg 0 rlineto fill grestore}B /a{moveto}B /delta 0 N /tail
{dup /delta X 0 rmoveto}B /M{S p delta add tail}B /b{S p tail}B /c{-4 M}
B /d{-3 M}B /e{-2 M}B /f{-1 M}B /g{0 M}B /h{1 M}B /i{2 M}B /j{3 M}B /k{
4 M}B /w{0 rmoveto}B /l{p -4 w}B /m{p -3 w}B /n{p -2 w}B /o{p -1 w}B /q{
p 1 w}B /r{p 2 w}B /s{p 3 w}B /t{p 4 w}B /x{0 S rmoveto}B /y{3 2 roll p
a}B /bos{/SS save N}B /eos{SS restore}B end
%%EndProcSet
TeXDict begin 39158280 55380996 1000 300 300 (md5-compress.dvi)
@start /Fa 43 124 df<130413181330136013C013801201EA0300A21206120E120C12
1C1218A212381230A21270A21260A312E0A35AA51260A31220123012107E0E267B9B10>
40 D<134013601320133013101318AB1338A21330A21370A2136013E013C0A212011380
120313001206A25A5A12105A5A5A0D267F9B10>I<121812381278123812081210A21220
A212401280050B7D830C>44 DI<137CEA0186EA03031206
000C1380121CA21238A338700700A4EAE00EA35BA213185BEA60606C5A001FC7FC11187C
9714>48 D<1308131813301370EA01F0EA0E70EA00E0A4EA01C0A4EA0380A4EA0700A45A
EAFFE00D187C9714>I<13031480EB0700A3130EA35BA213185BA25B5B13C6EA018EEA03
0EEA021C120412081210EA7FB838807F8038003800A25BA41360111F7F9714>52
D<38030180EBFF0013FCEA022048C7FCA45AEA0BE0EA0C181208EA001CA412201270485A
EA8030EA40705BEA2180001EC7FC11187C9714>I<131EEB6180EA0180EA03031206000E
C7FC5A12181238EA39F0EA7218EA740CEA780E127012F012E0A35BA2EA60385BEA30C0EA
1F8011187C9714>I<1206120F121E120C1200A81230127812F0126008107C8F0C>58
D<1420146014E0A2130114F0EB0270A213041308A21310A213201340A2EB8038EBFFF838
0100381202A25AA25A121838FE01FF181A7E991D>65 D67 D<3803FFF83800700E80809038E00180A315C0EA01
C0A43903800380A3150048485AA2140E140C000E131C5C5C5C381C0380D8FFFEC7FC1A1A
7D991D>I<0003B5FC380070071403140113E0A43801C080A313C13803FF001381A3EA07
02EB0004A21408120E1418141014304813E0B5FC181A7D991A>I<0003B5FC3800700714
03140113E0A43801C080A313C13803FF001381A3EA070290C7FCA3120EA4121EEAFFC018
1A7D9919>I73 D77 D79 D<3803FFF83800701C1406140713E0A43801C00EA2
141C143838038060EBFF80EB8000A248C7FCA4120EA45AB47E181A7D991A>I<3803FFF0
3800701C140E140713E0A43801C00E141C143814E03803FF80EB80C014601470EA0700A4
000E13E0A214E114E248136238FF803C181A7D991C>82 DI<383FFFFC38381C0C002013041240133812
80A338007000A45BA4485AA4485AA41207EAFFF8161A79991B>I97
D99 DII<1307EB0980131B
EB3B00133813301370A4EA07FFEA00E0A5485AA5485AA490C7FC5AA21206126612E412CC
1270112181990C>I<13F338038B8038060700120E120C121CEA380EA4EA301CA3EA183C
5BEA07B8EA0038A25B1260EAE0E0EAC1C0007FC7FC11177E8F12>II<1203120712061200A61238124C124E128E129CA2121C1238A21270
1272A212E212E41264123808197C980C>I<121F1207A3120EA4121CA41238A41270A412
E4A412E81230081A7D990A>108 D<38307C1E38598663399E0783801403129CA239380E
0700A3140ED8701C1340A2141C158038E0380C39601807001A107C8F1F>II<
EA01F0EA0618EA0C0CEA180E12301270126012E0A2130C131C13181330EA6060EA30C0EA
1F000F107C8F14>II114 DI<1206120EA45AA2EA
FFC0EA1C005AA45AA412E1A312E212E412380A177C960D>III<
38380C10384C0E38EA4E1C008E1318129CA2381C38101238A338707020A2144012303818
B880380F0F0015107C8F19>I121
D123 D E /Fb 7 116 df82 D99 D<13FE3807FF80380F87C0381E01E0003E13F0EA7C0014F812FCA2B5FCA200FC
C7FCA3127CA2127E003E13186C1330380FC0703803FFC0C6130015167E951A>101
DI<38FF07E0EB1FF8381F307CEB403CEB803EA21300AE39FFE1FFC0A21A
167E951F>110 D114 DI E /Fc 11 116 df45 D53 D68 D<00FCEB07E0A300EE130DA3
00E71319A3EB803900E31331EBC071A200E11361A2EBE0E1A200E013C113F1EB7181A3EB
3B01A3131EA313001B1D7C9C24>77 D99 D101 D<38E3F03F39EFF8FF80D8FFFD13C039F81F81E038F00F00EAE00EAD1B127D9124>
109 D111 DI114 DI E /Fd 1 55 df<1460A214C0A2EB0180A3EB0300A21306A25BA25BA35BA25BA25B
A2485AA248C7FCA31206A25AA25AA25AA35AA25A124013287A9D00>54
D E /Fe 17 121 df48
D<12035AA25A5AB4FCA212E71207AEEAFFF8A30D197B9816>III<137C13FC13DC1201EA039CA2EA071C120F120E121E123C1238127812
F0B512E0A338001C00A53801FFC0A313197F9816>II<13F8EA03FC487EEA0F07EA1C0F1238EA78060070C7FCA2EAE3F8EAEFFCB4
7EEAF80F487EEB038012E0A21270A2130700381300EA3C1EEA1FFC6C5AEA03E011197E98
16>I<12E0B51280A338E00F00131EEA001C5B137813705BA2485AA3485AA448C7FCA711
1A7E9916>III<13E0487EA213B0A2EA03B8A31318EA071CA5EA0E0EA2EA0FFEA2487EEA1C07A3
387E0FC038FF1FE0387E0FC013197F9816>65 DI<3801F180EA07FBEA0FFFEA1F0FEA3C07EA38031270A200F0C7FC5AA77E387003
80A21238383C0700EA1F0FEA0FFE6C5AEA01F011197E9816>II<387FFFC0B5FC7EEA1C01A490C7FCA2131CA2EA1FFCA3EA1C1CA290C7FC14
E0A5EA7FFFB5FC7E13197F9816>I<387FFFE0B5FC7EEA1C00A41400A2131CA2EA1FFCA3
EA1C1CA290C7FCA6EA7F80487E6C5A13197F9816>I<387F1FC0133F131F380F1E006C5A
EA03B813F012016C5A12017FEA03B8EA073C131CEA0E0E387F1FC038FF3FE0387F1FC013
127F9116>120 D E /Ff 2 106 df<14C01303EB0700131C1378EA01E0EA0780000EC7FC
123812F0A21238120E6C7EEA01E0EA0078131C1307EB03C0130012147D901A>60
D<1206120712061200A41238124CA2128C12981218A212301232A21264A2123808147F93
0C>105 D E /Fg 7 106 df<126012F0A2126004047C830C>58 D<126012F0A212701210
A41220A212401280040C7C830C>II<3801FFC038003C001338A45BA45BA4485AA4485AA448C7FCA45A
EAFFE0121C7E9B12>73 D<39FFC00FF0391C00038015001402A25C5C121E000E5B143014
205CA25C49C7FC120FEA07025BA25BA25B5BEA03A013C05BA290C8FCA21C1D7D9B18>86
D<3A01FFC0FF803A001E003C00011C13306D13205D010F5B6D48C7FC1482EB038414CCEB
01D814F05C130080EB0170EB0278EB04381308EB103CEB201CEB401EEB800E3801000F00
027F1206001E497E39FF803FF0211C7F9B22>88 D105
D E /Fh 7 116 df99 D101
D<38E3C0F038EFF3FC38F8761C38F03C0EA2EAE038AC17117D9020>109
D111 DI114 DI E /Fi
5 89 df<126012F0A2126004047D830B>58 D<126012F0A212701210A31220A21240A204
0B7D830B>I73 D<39FF801FE0391C000700140614045C121E000E5B5CA25C14C05CD80F01
C7FC120713025BA25B5BEA039013A013C0A25BA290C8FC1B1A7E9916>86
D<3901FF01FE39003C00F01540011C1380EC0100EB0E025CEB0F086D5A14A0EB03C0A213
011303497E1304497EEB1070EB2078EB4038138048487E120248131E121EB4EB7FC01F1A
7F9920>88 D E /Fj 2 51 df<1218127812981218AC12FF08107D8F0F>49
D<121FEA6180EA40C0EA806012C01200A213C0EA0180EA030012065AEA10201220EA7FC0
12FF0B107F8F0F>I E /Fk 10 58 df<120FEA30C0EA6060A2EA4020EAC030A9EA4020EA
6060A2EA30C0EA0F000C137E9211>48 D<120C121C12EC120CAFEAFFC00A137D9211>I<
121FEA60C01360EAF07013301260EA0070A2136013C012011380EA02005AEA08101210EA
2020EA7FE012FF0C137E9211>II<136013E0A2EA0160
12021206120C120812101220126012C0EAFFFCEA0060A5EA03FC0E137F9211>III<1240EA7FFC13F8EA4010EA
80301320EA00401380EA0100A25A12021206A2120EA512040E147E9311>II<120FEA3080EA6040EA4060EAC0201330A31240EA6070EA30
B0EA0F30120013201360EAE0401380EA4100123E0C137E9211>I
E /Fl 21 118 df45 D<127812FCA4127806067D850D>I<3838
0180383FFF005B5B5B13C00030C7FCA4EA31F8EA361E38380F80EA3007000013C014E0A3
127812F8A214C012F038600F8038381F00EA1FFEEA07F0131B7E9A18>53
D<90381FE0209038FFF8E03803F80F3807C003380F800148C7FC123E1560127E127C00FC
1400A8007C1460127E123E15C07E390F8001803907C003003803F80E3800FFFCEB1FE01B
1C7D9B22>67 DI77
D99 DII<
137F3801E3803803C7C0EA0787120FEB8380EB8000A5EAFFF8A2EA0F80AEEA7FF0A2121D
809C0F>I104 D<121E123FA4121EC7FCA6127FA2121FAEEAFFC0A20A1E7F9D0E>I108 D<39FF0FC07E903831E18F3A1F40F20780D980FC13C0
A2EB00F8AB3AFFE7FF3FF8A225127F9128>I<38FF0FC0EB31E0381F40F0EB80F8A21300
AB38FFE7FFA218127F911B>II<38FF3F80EBE1
E0381F80F0EB0078147C143C143EA6143C147C1478EB80F0EBC1E0EB3F0090C7FCA6EAFF
E0A2171A7F911B>I
114 DI<1203A45AA25AA2EA3FFC12FFEA1F00A9
130CA4EA0F08EA0798EA03F00E1A7F9913>I<38FF07F8A2EA1F00AC1301120F380786FF
EA01F818127F911B>I E /Fm 26 119 df<127012F8A312700505798414>46
D<1306130EA2131CA21338A21370A213E0A2EA01C0A2EA0380A3EA0700A2120EA25AA25A
A25AA25AA25A0F1D7E9914>I64
D<3801F180EA07FFEA0E1FEA1C071238EA7003A348C7FCA738700380A338380700121CEA
0E0EEA07FCEA01F011177F9614>67 D73
D79
D83
D97 D<12FCA2121CA513F8EA1DFEEA1F07EA1E03001C1380EB01C0
A6EB0380001E1300EA1F0EEA1DFCEA0CF81217809614>II<137EA2130E
A5EA07CEEA0FFEEA1C3EEA301EEA700E12E0A61270EA301EEA383E381FEFC0EA07CF1217
7F9614>II<13FCEA01FEEA038EEA07041300A3EA7FFE12
FFEA0700ACEAFFF8A20F177F9614>I<12FCA2121CA51378EA1DFEEA1F86EA1E07121CAA
38FF8FE0A21317809614>104 D<1206120FA21206C7FCA4B4FCA21207ACEAFFF8A20D18
7C9714>I<12FCA2121CA5EBFF80A2EB1C005B5B5BEA1DC0EA1FE0A2EA1E70EA1C38133C
131C7F38FF1F80A21117809614>107 DIIIII114
DI<1206120EA4EA7FFC12FFEA0E00A8130EA3131CEA07
F8EA01F00F157F9414>II<38FE
3F80A2383C1E00EA1C1CA36C5AA3EA0630EA0770A36C5AA311107F8F14>I
E /Fn 70 127 df11 D<13FEEA038138060180EA0E03381C010090C7FCA5B51280EA
1C03AE38FF8FF0141A809915>II34 D<126012F012F812681208A31210A212201240050B7D990B>39
D<1380EA010012025A120C120812185AA35AA412E0AA1260A47EA37E1208120C12047E7E
EA008009267D9B0F>I<7E12407E7E12181208120C7EA37EA41380AA1300A41206A35A12
08121812105A5A5A09267E9B0F>I<126012F0A212701210A31220A21240A2040B7D830B>
44 DI<126012F0A2126004047D830B>I48 D<12035AB4FC1207B3A2EA7FF80D187D9713>III<1318A21338137813F813B8EA01381202A212041208121812101220
124012C0B5FCEA0038A6EA03FF10187F9713>III<1240
EA7FFF13FEA2EA4004EA80081310A2EA00201340A21380120113005AA25A1206A2120EA5
120410197E9813>III<1260
12F0A212601200A8126012F0A2126004107D8F0B>I<126012F0A212601200A8126012F0
A212701210A31220A21240A204177D8F0B>I
61 D<130CA3131EA2132F1327A2EB4380A3EB81C0A200017F1300A248B47E38020070A2
487FA3487FA2003C131EB4EBFFC01A1A7F991D>65 DI
IIIII<39FFE1FFC0390E001C00
AB380FFFFC380E001CAC39FFE1FFC01A1A7F991D>III76 DI<00FEEB7FC0000FEB0E001404EA0B80EA09C0A2EA08
E01370A21338131CA2130E1307EB0384A2EB01C4EB00E4A21474143CA2141C140C121C38
FF80041A1A7F991D>I<137F3801C1C038070070000E7F487F003C131E0038130E007813
0F00707F00F01480A80078EB0F00A20038130E003C131E001C131C6C5B6C5B3801C1C0D8
007FC7FC191A7E991E>II82 DI<
007FB5FC38701C0700401301A200C0148000801300A300001400B13803FFE0191A7F991C
>I<39FFE07FC0390E000E001404B200065B12076C5B6C6C5A3800E0C0013FC7FC1A1A7F
991D>I<39FF801FC0391C00070014066C1304A36C5BA26C6C5AA36C6C5AA26C6C5AA3EB
7080A213790139C7FCA2131EA3130CA21A1A7F991D>I<3AFF81FF07F03A3C007801C000
1CEC0080A36C90389C0100A33907010E02A33903830F04EB8207A2150C3901C40388A339
00E801D0A390387000E0A301305B01201340241A7F9927>I92 D97
D<12FC121CA913FCEA1D07381E0380381C01C0130014E0A6EB01C01480381E0300EA1906
EA10F8131A809915>II<133F1307A9EA03E7EA0C17EA180F487E127012E0A6126012706C5A
EA1C373807C7E0131A7F9915>IIII<12FC121CA9137CEA1D87381E0380A2121CAB38FF9FF0141A809915>I<1218
123CA212181200A612FC121CAE12FF081A80990A>I<12FC121CA9EB1FC0EB0F00130C5B
13205B13E0121DEA1E70EA1C7813387F131E7F148038FF9FE0131A809914>107
D<12FC121CB3A6EAFF80091A80990A>I<38FC7C1F391D8E6380391E0781C0A2001C1301
AB39FF9FE7F81D107F8F20>I
III114 DI<1208A41218A21238EAFFC0EA3800A813
20A41218EA1C40EA07800B177F960F>I<38FC1F80EA1C03AB1307120CEA0E0B3803F3F0
1410808F15>I<38FF0F80383C0700EA1C061304A26C5AA26C5AA3EA03A0A2EA01C0A36C
5A11107F8F14>I<39FE7F1F8039381C0700003C1306381C0C04130E380E16081317A238
072310149013A33803C1A014E0380180C0A319107F8F1C>I<38FF0F80383C0700EA1C06
1304A26C5AA26C5AA3EA03A0A2EA01C0A36C5AA248C7FCA212E112E212E4127811177F8F
14>121 DII126 D E /Fo 59 127 df<137E3801C180EA0301380703C0120EEB018090C7
FCA5B512C0EA0E01B0387F87F8151D809C17>12 D<1380EA0100120212065AA25AA25AA3
5AA412E0AC1260A47EA37EA27EA27E12027EEA0080092A7C9E10>40
D<7E12407E12307EA27EA27EA37EA41380AC1300A41206A35AA25AA25A12205A5A092A7E
9E10>I<1306ADB612E0A2D80006C7FCAD1B1C7E9720>43 D<126012F0A212701210A412
20A212401280040C7C830C>II<126012F0A2126004047C830C>
I48 D<5A1207123F12C71207B3A5EAFFF80D1C7C9B15
>I
II<130C
A2131C133CA2135C13DC139CEA011C120312021204120C1208121012301220124012C0B5
12C038001C00A73801FFC0121C7F9B15>II<13F0EA030CEA0404EA0C0EEA181E1230130CEA7000A21260EAE3E0EA
E430EAE818EAF00C130EEAE0061307A51260A2EA7006EA300E130CEA1818EA0C30EA03E0
101D7E9B15>I56 DI<126012F0A212601200AA126012F0A2126004127C910C>I<126012
F0A212601200AA126012F0A212701210A41220A212401280041A7C910C>I<007FB512C0
B612E0C9FCA8B612E06C14C01B0C7E8F20>61 D<1306A3130FA3EB1780A2EB37C01323A2
EB43E01341A2EB80F0A338010078A2EBFFF83802003CA3487FA2000C131F80001E5BB4EB
FFF01C1D7F9C1F>65 DI<90381F8080EBE061380180
1938070007000E13035A14015A00781300A2127000F01400A8007014801278A212386CEB
0100A26C13026C5B380180083800E030EB1FC0191E7E9C1E>III<39FFF0FFF0390F000F00AC90B5FCEB
000FAD39FFF0FFF01C1C7F9B1F>72 DI77
D80 D82
D<3807E080EA1C19EA30051303EA600112E01300A36C13007E127CEA7FC0EA3FF8EA1FFE
EA07FFC61380130FEB07C0130313011280A300C01380A238E00300EAD002EACC0CEA83F8
121E7E9C17>I<007FB512C038700F010060130000401440A200C014201280A300001400
B1497E3803FFFC1B1C7F9B1E>I<39FFF01FF0390F000380EC0100B3A26C130213800003
5BEA01C03800E018EB7060EB0F801C1D7F9B1F>I<3AFFE1FFC0FF3A1F003E003C001E01
3C13186C6D1310A32607801F1320A33A03C0278040A33A01E043C080A33A00F081E100A3
9038F900F3017913F2A2017E137E013E137CA2013C133C011C1338A20118131801081310
281D7F9B2B>87 D<12FEA212C0B3B312FEA207297C9E0C>91 D<12FEA21206B3B312FEA2
0729809E0C>93 D97 D<12FC121CAA137CEA1D87381E01
80381C00C014E014601470A6146014E014C0381E018038190700EA10FC141D7F9C17>I<
EA03F8EA0C0CEA181E1230EA700CEA600012E0A61260EA70021230EA1804EA0C18EA03E0
0F127F9112>III<13F8EA
018CEA071E1206EA0E0C1300A6EAFFE0EA0E00B0EA7FE00F1D809C0D>II<12FC121CAA137C1387EA1D03001E1380121CAD38FF9FF0141D7F9C17>I<1218123CA2
1218C7FCA712FC121CB0EAFF80091D7F9C0C>I<12FC121CAAEB0FE0EB0780EB06005B13
105B5B13E0121DEA1E70EA1C781338133C131C7F130F148038FF9FE0131D7F9C16>107
D<12FC121CB3A9EAFF80091D7F9C0C>I<39FC7E07E0391C838838391D019018001EEBE0
1C001C13C0AD3AFF8FF8FF8021127F9124>IIII114
DI<1204A4120CA2121C123CEAFFE0EA1C00A9
1310A5120CEA0E20EA03C00C1A7F9910>I<38FC1F80EA1C03AD1307120CEA0E1B3803E3
F014127F9117>I<38FF07E0383C0380381C0100A2EA0E02A2EA0F06EA0704A2EA0388A2
13C8EA01D0A2EA00E0A3134013127F9116>I<39FF3FC7E0393C0703C0001CEB01801500
130B000E1382A21311000713C4A213203803A0E8A2EBC06800011370A2EB803000001320
1B127F911E>I<38FF0FE0381E0700EA1C06EA0E046C5AEA039013B0EA01E012007F1201
1338EA021C1204EA0C0E487E003C138038FE1FF014127F9116>I<38FF07E0383C038038
1C0100A2EA0E02A2EA0F06EA0704A2EA0388A213C8EA01D0A2EA00E0A31340A25BA212F0
00F1C7FC12F312661238131A7F9116>I126
D E /Fp 17 122 df<00181306381F803EEBFFFC5C5C5C148049C7FC0018C8FCA7EB7F80
3819FFF0381B80F8381E007E00187FC7FCEC1F80A215C0A3127C12FEA315805A0078133F
006014006C133E001C5B380F01F83807FFE0C690C7FC1A277DA621>53
D<91387FE002903907FFF80690391FE01E0E90397F00039E01FCEB01FE4848EB007ED807
F0143E5B4848141E001F150E485AA21606127F90C8FC16005AA97EA26D1406123FA36C6C
140C120F6C6C14186D1438D801F814306C6C14E0017FEB03C090391FE00F00903807FFFC
9038007FE027297CA830>67 DI77 D<3803FF80000F13E0381F01F8383F80FC147EA280EA1F00C7FCA4
EB3FFF3801FE3FEA0FE0EA1F80EA3F005A12FE150CA3145F007F139F393F831FF8391FFE
0FF03903F807C01E1B7E9A21>97 D101 DI<120FEA1F8013C0
123FA2121F1380EA0F00C7FCA8EAFFC0A2120FB3A5EAFFF8A20D2B7EAA13>105
D108 D<26FFC0FEEB3F80903AC3FF80FF
E03B0FC60FC183F0903AC807E201F89039D003E40001F001FC7F01E05BA201C05BB13CFF
FC3FFF0FFFC0A2321B7E9A37>I<38FFC0FE9038C3FF80390FC60FC09038C807E0EBD003
01F013F013E0A213C0B139FFFC3FFFA2201B7E9A25>II<38FFC1FE9038C7FF8039
0FDE0FE09038F003F09038E001F801C013FC140015FEA2157FA8157E15FEA215FC140101
E013F89038F007F09038DC0FE09038C7FF809038C1FC0001C0C7FCAAEAFFFCA220277E9A
25>I<38FF83E0EB8FF8380F8C7CEB98FE13B013A0A2EBE07CEBC000B1EAFFFEA2171B7E
9A1B>114 D<3803FC60381FFFE0EA3C03EA7801EA700000F01360A300FC1300B47EEA7F
FC13FF6C13C0000F13E0000313F0EA003FEB03F8EAC00014787EA27E14706C13E0EAFE03
38E7FF803881FE00151B7E9A1A>I<1360A413E0A21201A212031207121FB512E0A23807
E000AE1430A73803F0603801F8C03800FF80EB3F0014267FA51A>I<39FFF801FFA2390F
C000707F000714606D13E0000314C07F0001EB0180A23900FC0300A26D5AEB7E06EB7F0E
EB3F0C148CEB1F98A2EB0FF0A36D5AA26D5AA26D5AA249C7FCA25BEA3006EAFC0E130C5B
1338EA7870EA3FE0EA1F8020277F9A23>121 D E end
%%EndProlog
%%BeginSetup
%%Feature: *Resolution 300dpi
TeXDict begin
%%PaperSize: a4
%%BeginPaperSize: a4
a4
%%EndPaperSize

%%EndSetup
%%Page: 1 1
1 0 bop 430 194 a Fp(Crypt)n(an)n(alys)q(i)q(s)20 b(of)i(MD5)f(Compre)r
(s)q(s)759 340 y Fo(Hans)14 b(Dobb)q(ert)o(in)589 427
y Fn(Germ)o(an)f(Inform)o(a)o(t)o(ion)i(Secur)q(it)o(y)f(Agency)615
473 y(e-m)o(ail:)g Fm(dobbertin@)o(sk)o(om.)o(rh)o(ein)o(.de)800
566 y Fn(May)f(2,)g(1996)245 665 y Fo(In)19 b(1991)f(t)n(h)o(e)i(h)o
(ash)f(fu)o(nct)o(ion)h(MD5)e(w)o(as)h(in)o(tro)q(d)o(u)o(ce)q(d)h(b)o
(y)f(Ron)g(Riv)o(e)q(st)g(as)g(stren)o(g-)183 715 y(t)n(h)o(en)o(e)q(d)
e(v)o(ers)q(ion)f(of)f(MD4.)g(Be)q(s)q(id)o(e)j(som)o(e)d(ot)n(h)o(er)i
(mo)q(di\014ca)o(t)o(ions)d(t)n(h)o(e)j(n)n(u)o(m)n(b)q(er)e(of)h(rou)o
(n)o(ds)183 765 y(i)q(s)d(ext)o(en)o(d)o(e)q(d)i(f)q(rom)d(t)n(hree)k
(t)o(o)e(four.)245 817 y(In)19 b(t)n(hi)q(s)g(sh)o(ort)g(not)o(e)g(w)o
(e)g(rep)q(ort)h(a)o(b)q(ou)o(t)f(an)g(a)o(t)n(t)o(ac)o(k)g(on)g(t)n(h)
o(e)g(compre)q(ss)h(fu)o(nct)o(ion)f(of)183 867 y(MD5,)11
b(whic)o(h)i(i)q(s)f(bas)q(e)q(d)i(on)e(s)q(imilar)e(m)o(et)n(h)o(o)q
(ds)j(as)g(previous)g(a)o(t)n(t)o(ac)o(ks)g(on)g(RIPEMD,)f(MD4)183
917 y(an)o(d)k(t)n(h)o(e)h(256-bit)e(ext)o(ens)q(ion)i(of)f(MD4)g(\(s)q
(ee)h([4)o(],)f([5)o(]\).)g(Belo)o(w)g(w)o(e)h(giv)o(e)f(a)g
Fl(co)o(lli)q(s)q(ion)1553 902 y Fk(1)1585 917 y Fl(of)183
966 y(t)n(h)o(e)e(compre)q(s)q(s)h(fu)o(nct)o(ion)e(of)i(MD5)p
Fo(.)245 1019 y(Recall)i(t)n(h)o(a)o(t)h(in)g(1993)f(Bert)i(d)o(en)g
(Bo)q(er)g(an)o(d)f(An)o(t)o(o)q(on)g(Boss)q(elaers)j([3)o(])c(sh)o(o)o
(w)o(e)q(d)i(h)o(o)o(w)183 1068 y Fl(p)q(s)q(eudo-co)o(ll)o(i)o(s)q(i)o
(ons)12 b Fo(\(in)k(our)f(t)o(erminology\))e(of)i(MD5)h(compre)q(ss)g
(can)g(b)q(e)g(fou)o(n)o(d.)f(Ma)o(t)n(t)183 1118 y(Robsh)o(aw)e
(\([8],)g(Rem)o(ar)o(k)g(1)g(in)h(Sect)o(ion)g(4.1\))f(comm)o(en)o(t)o
(e)q(d)f(t)n(hi)q(s)h(a)o(t)n(t)o(ac)o(k)i(as)e(follo)o(w:)253
1206 y Fn(\\As)f(it)h(st)o(an)o(ds,)g(t)n(h)o(e)g(ps)q(eudo-colli)q(s)q
(ion)i(ar)q(i)q(s)q(e)q(s)e(f)q(rom)e(init)o(iali)q(zi)q(n)o(g)16
b(t)n(h)o(e)c(four-w)o(ord)h(bu\013er)253 1252 y(a)o(t)d(t)n(h)o(e)h
(st)o(art)g(of)f(MD5)g(t)o(o)h(t)o(w)o(o)f(di\013eren)o(t)i(v)n(alue)q
(s.)f(Th)o(e)q(s)q(e)f(v)n(alue)q(s)i(di\013er)g(only)f(in)h(t)n(h)o(e)
e(MSB)253 1298 y(of)16 b(eac)o(h)h(of)f(t)n(h)o(e)h(four)f(w)o(ords.)g
(Th)o(e)g(sam)o(e)g(m)o(e)q(ssage)h(i)q(s)g(us)q(e)q(d)f(for)g(b)q(ot)n
(h)h(s)q(ets)f(of)g(bu\013er)253 1343 y(v)n(alue)q(s)f(an)o(d)e(t)n(h)o
(e)h(sam)o(e)f(m)o(e)q(ssage)h(dige)q(st)g(i)q(s)f(obt)o(ain)o(e)q(d.)
253 1391 y(A)c(f)q(ar)g(more)h(s)q(er)q(ious)g(\015aw)f(w)o(ould)i(b)q
(e)e(if)h(it)g(w)o(ere)f(p)q(oss)q(ible)j(t)o(o)e(c)o(h)o(o)q(os)q(e)g
(on)o(e)g(init)o(ial)i(st)o(art)o(in)o(g)253 1437 y(v)n(alue)k(for)f(t)
n(h)o(e)g(bu\013er,)h(not)f(n)o(ece)q(ssar)q(ily)j(t)n(h)o(e)d(on)o(e)h
(giv)o(en)g(in)f(t)n(h)o(e)h(algor)q(it)n(hm,)g(an)o(d)g(t)n(h)o(en)253
1482 y(c)o(h)o(o)q(os)q(e)c(t)o(w)o(o)f(di\013eren)o(t)h(m)o(e)q(ssage)
q(s,)g(p)q(erh)o(aps)h(di\013er)q(in)o(g)g(in)f(only)g(a)f(few)g(bits)g
(of)g(on)o(e)g(w)o(ord,)253 1528 y(so)i(t)n(h)o(a)o(t)h(t)n(h)o(e)f
(sam)o(e)h(m)o(e)q(ssage)g(dige)q(st)g(i)q(s)f(obt)o(ain)o(e)q(d.")183
1618 y Fo(Th)o(e)18 b(la)o(t)n(t)o(er)g(d)o(e)q(scr)q(ib)q(e)q(s)i
(preci)q(s)q(ely)e(wh)o(a)o(t)g(i)q(s)f(don)o(e)h(no)o(w.)f(W)m(e)g(t)n
(hink)h(t)n(h)o(a)o(t)g(t)n(hi)q(s)g(migh)o(t)e(b)q(e)183
1668 y(reason)f(enough)f(t)o(o)g(su)n(bst)o(it)o(u)o(t)o(e)i(MD5)d(in)g
(fu)o(t)o(ure)i(ap)o(plica)o(t)o(ions.)245 1720 y(Al)o(t)o(er)q(n)o(a)o
(t)o(iv)o(e)q(s)e(for)g(MD5)f(are)i(SHA-1)e([1])g(an)o(d)h(on)f(t)n(h)o
(e)i(ot)n(h)o(er)g(h)o(an)o(d)e(RIPEMD-160)g([6],)183
1770 y(whic)o(h)k(h)o(as)g(b)q(een)h(d)o(e)q(s)q(ign)o(e)q(d)g(as)f(a)g
(stren)o(gt)n(h)o(en)o(e)q(d)j(v)o(ers)q(ion)e(of)e(RIPEMD)h([2])f(b)o
(y)h(An)o(t)o(o)q(on)183 1820 y(Boss)q(elaers,)g(Bart)e(Pren)o(eel)h
(an)o(d)f(t)n(h)o(e)h(a)n(u)o(t)n(h)o(or)g(t)o(akin)o(g)e(accou)o(n)o
(t)i(of)e(t)n(h)o(e)h(recen)o(t)i(an)o(alys)q(i)q(s)c(of)183
1869 y(MD4-lik)o(e)g(h)o(ash)i(fu)o(nct)o(ions.)p 183
1905 237 2 v 191 1932 a Fj(1)221 1948 y Fn(Us)q(in)o(g)g(t)n(h)o(e)f(t)
o(erm)g(\\colli)q(s)q(ion)i(of)d(a)h(compre)q(ss)h(fu)o(nct)o(ion")h(w)
o(e)d(assu)o(m)o(e)i(t)n(h)o(a)o(t)f(t)n(h)o(e)h(init)o(ial)h(v)n(alue)
f(i)q(s)221 1994 y(t)n(h)o(e)g(sam)o(e)g(for)g(b)q(ot)n(h)g(inpu)o(ts,)
h(i.e.)f(an)g(init)o(ial)i(v)n(alue)f Fi(I)s(V)22 b Fn(an)o(d)15
b(t)o(w)o(o)e(di\013eren)o(t)i(inpu)o(ts)h Fi(X)g Fn(an)o(d)1600
1984 y(~)1589 1994 y Fi(X)221 2039 y Fn(are)d(giv)o(en)h(su)o(c)o(h)g
(t)n(h)o(a)o(t)613 2126 y Fh(comp)o(re)q(ss)n Fn(\()p
Fi(I)s(V)9 b Fn(;)d Fi(X)s Fn(\))k(=)h Fh(comp)o(re)q(ss)n
Fn(\()p Fi(I)s(V)e Fn(;)1183 2117 y(~)1172 2126 y Fi(X)s
Fn(\))p Fi(:)221 2213 y Fn(On)14 b(t)n(h)o(e)h(ot)n(h)o(er)g(h)o(an)o
(d)h(w)o(e)e(us)q(e)g(t)n(h)o(e)h(t)o(erm)f(\\ps)q(eudo-colli)r(s)q
(ion")j(if)e(t)o(w)o(o)f(di\013eren)o(t)i(init)o(ial)h(v)n(alue)q(s)221
2258 y Fi(I)s(V)r(;)298 2249 y Fn(~)282 2258 y Fi(I)s(V)22
b Fn(an)o(d)13 b(\(p)q(oss)q(ibly)j(id)o(en)o(t)o(ical\))f(inpu)o(ts)g
Fi(X)q(;)927 2249 y Fn(~)917 2258 y Fi(X)g Fn(are)e(giv)o(en)h(su)o(c)o
(h)g(t)n(h)o(a)o(t)613 2345 y Fh(comp)o(re)q(ss)n Fn(\()p
Fi(I)s(V)9 b Fn(;)d Fi(X)s Fn(\))k(=)h Fh(comp)o(re)q(ss)n
Fn(\()1120 2336 y(~)1104 2345 y Fi(I)s(V)e Fn(;)1183
2336 y(~)1172 2345 y Fi(X)s Fn(\))p Fi(:)221 2432 y Fn(Ps)q(eudo-colli)
q(s)q(ions)16 b(are)d(of)g(m)n(u)o(c)o(h)h(le)q(ss)g(pract)o(ical)h
(imp)q(ort)o(ance)f(t)n(h)o(an)g(colli)q(s)q(ions.)p
eop
%%Page: 2 2
2 1 bop 340 194 a Fl(Co)o(lli)q(s)q(ion)9 b(for)j(t)n(h)o(e)g(compre)q
(s)q(s)f(fu)o(nct)o(ion)f(of)i(MD5.)18 b Fo(Us)q(e)12
b(t)n(h)o(e)g(follo)o(win)o(g)c(init)o(ial)h(v)n(alue)340
244 y Fg(I)s(V)24 b Fo(an)o(d)14 b(d)o(e\014n)o(e)h(t)n(h)o(e)f
(\014rst)h(inpu)o(t)f Fg(X)i Fo(=)11 b(\()p Fg(X)1014
250 y Ff(i)1029 244 y Fo(\))1045 250 y Ff(i<)p Fk(16)1132
244 y Fo(b)o(y)i(s)q(et)n(t)o(in)o(g:)549 335 y Fg(I)s(V)22
b Fo(=)11 b Fe(0x12AC2375)h(0x3B341042)g(0x5F62B97C)g(0x4BA763ED)346
409 y Fg(X)380 415 y Fk(0)411 409 y Fo(=)g Fe(0xAA1DDA5E)37
b Fg(X)746 415 y Fk(4)776 409 y Fo(=)12 b Fe(0x1006363E)37
b Fg(X)1111 415 y Fk(8)1142 409 y Fo(=)12 b Fe(0x98A1FB19)37
b Fg(X)1477 415 y Fk(12)1524 409 y Fo(=)12 b Fe(0x1326ED65)346
459 y Fg(X)380 465 y Fk(1)411 459 y Fo(=)g Fe(0xD97ABFF5)37
b Fg(X)746 465 y Fk(5)776 459 y Fo(=)12 b Fe(0x7218209D)37
b Fg(X)1111 465 y Fk(9)1142 459 y Fo(=)12 b Fe(0x1FAE44B0)37
b Fg(X)1477 465 y Fk(13)1524 459 y Fo(=)12 b Fe(0xD93E0972)346
509 y Fg(X)380 515 y Fk(2)411 509 y Fo(=)g Fe(0x55F0E1C1)37
b Fg(X)746 515 y Fk(6)776 509 y Fo(=)12 b Fe(0xE01C135D)21
b Fg(X)1095 515 y Fk(10)1142 509 y Fo(=)12 b Fe(0x236BB992)37
b Fg(X)1477 515 y Fk(14)1524 509 y Fo(=)12 b Fe(0xD458C868)346
559 y Fg(X)380 565 y Fk(3)411 559 y Fo(=)g Fe(0x32774244)37
b Fg(X)746 565 y Fk(7)776 559 y Fo(=)12 b Fe(0x9DA64D0E)21
b Fg(X)1095 565 y Fk(11)1142 559 y Fo(=)12 b Fe(0x6B7A669B)37
b Fg(X)1477 565 y Fk(15)1524 559 y Fo(=)12 b Fe(0x6B72746A)340
658 y Fo(Th)o(e)k(s)q(econ)o(d)h(inpu)o(t)685 647 y(~)673
658 y Fg(X)h Fo(=)d(\()800 647 y(~)788 658 y Fg(X)822
664 y Ff(i)836 658 y Fo(\))852 664 y Ff(i<)p Fk(16)941
658 y Fo(i)q(s)g(d)o(e\014n)o(e)q(d)i(b)o(y)e(s)q(et)n(t)o(in)o(g)1336
647 y(~)1324 658 y Fg(X)1358 664 y Ff(i)1387 658 y Fo(=)f
Fg(X)1467 664 y Ff(i)1497 658 y Fo(\()p Fg(i)h(<)f Fo(16)p
Fg(;)7 b(i)14 b Fd(6)p Fo(=)h(14\))340 707 y(an)o(d)432
697 y(~)420 707 y Fg(X)454 713 y Fk(14)501 707 y Fo(=)d
Fg(X)579 713 y Fk(14)624 707 y Fo(+)d(2)686 692 y Fk(9)705
707 y Fo(.)k(Th)o(en)h(w)o(e)g(h)o(a)o(v)o(e)g(a)f(colli)q(s)q(ion,)e
(i.e.)625 793 y Fc(MD5-comp)o(re)q(ss)n Fo(\()p Fg(I)s(V)f
Fo(;)d Fg(X)s Fo(\))12 b(=)g Fc(MD5-comp)o(re)q(ss)n
Fo(\()p Fg(I)s(V)e Fo(;)1444 782 y(~)1432 793 y Fg(X)s
Fo(\))p Fg(;)340 878 y Fo(an)o(d)k(t)n(hi)q(s)g(common)d(compre)q(ss)k
(v)n(alue)e(i)q(s)587 963 y Fe(0xBF90E670)f(0x752AF92B)f(0x9CE4E3E1)h
(0xB12CF8DE)n Fg(:)340 1048 y Fo(Th)o(e)j(compu)o(t)o(a)o(t)o(ion)d(of)
h(su)o(c)o(h)i(a)e(colli)q(s)q(ion)e(t)o(ak)o(e)q(s)k(a)o(b)q(ou)o(t)f
(10)f(h)o(ours)h(on)g(a)g(P)o(en)o(t)o(iu)o(m)e(PC.)340
1183 y Fb(Reference)r(s)340 1278 y Fn(1.)21 b(FIPS)13
b(180-1,)d Fa(Se)n(cur)n(e)f(hash)g(standar)n(d,)e Fn(NIST,)i(US)g
(Depart)o(m)o(en)o(t)i(of)e(Comm)o(erce,)h(W)m(ashin)o(gt)o(on)391
1324 y(D.C.,)i(A)n(pr)q(il)i(1995.)340 1370 y(2.)21 b(RIPE)10
b(Consort)o(iu)o(m,)h Fa(R)o(ip)n(e)f(Inte)n(grity)e(Primitives)h({)i
(Final)e(r)n(ep)n(ort)h(of)g(RA)o(CE)h(Inte)n(grity)d(Prim-)391
1415 y(itives)k(Evaluation)f(\(R1040\))p Fn(,)f(LNCS)i(1007,)i(Spr)q
(in)o(ger-V)m(erlag,)h(1995.)340 1461 y(3.)21 b(B.)15
b(d)o(en)i(Bo)q(er,)f(A.)f(Boss)q(elaers,)j Fa(Col)r(lisions)13
b(for)j(the)f(c)n(ompr)n(ession)f(function)g(of)h(MD5)p
Fn(,)g(Ad-)391 1507 y(v)n(ance)q(s)g(in)h(Crypt)o(ology)m(,)f(Pro)q(c.)
g(Euro)q(crypt'93,)g(LNCS)e(765,)h(T.)e(Helle)q(s)q(et)n(h,)k(Ed.,)e
(Spr)q(in)o(ger-)391 1552 y(V)m(erlag,)f(1994,)h(p)o(p.)e(293{304.)340
1598 y(4.)21 b(H.)f(Dobb)q(ert)o(in,)i Fa(RIPEMD)f(with)f(two-r)n(ound)
f(c)n(ompr)n(ess)g(function)f(is)j(not)e(c)n(ol)r(lision-fr)n(e)n(e)p
Fn(,)391 1644 y(Jour)q(n)o(al)14 b(of)f(Crypt)o(ology)m(,)h(t)o(o)f(ap)
o(p)q(ear.)340 1689 y(5.)21 b(H.)d(Dobb)q(ert)o(in,)h
Fa(Cryptanalysis)d(of)i(MD4)p Fn(,)g(F)m(ast)g(Soft)o(w)o(are)g
(Encrypt)o(ion,)i(LNCS)13 b(1039,)18 b(D.)391 1735 y(Gollm)o(ann,)d
(Ed.,)d(Spr)q(in)o(ger-V)m(erlag,)k(1996,)d(p)o(p.)g(53{69.)340
1781 y(6.)21 b(H.)c(Dobb)q(ert)o(in,)h(A.)f(Boss)q(elaers,)i(an)o(d)f
(B.)f(Pren)o(eel:)h Fa(RIPEMD-160:)e(A)h(str)n(engthene)n(d)d(ver-)391
1826 y(sion)e(of)g(RIPEMD)p Fn(,)g(F)m(ast)g(Soft)o(w)o(are)g(Encrypt)o
(ion,)i(Cam)n(br)q(idge)f(W)m(orksh)o(o)o(p,)g(LNCS)f(1039,)g(D.)391
1872 y(Gollm)o(ann,)j(Ed.,)d(Spr)q(in)o(ger-V)m(erlag,)k(1996,)d(p)o
(p.)g(71-82.)1209 1856 y Fj(2)340 1918 y Fn(7.)21 b(R.)13
b(Riv)o(e)q(st,)h Fa(The)f(MD5)h(message)e(digest)g(algorithm)p
Fn(,)e(RF)o(C)j(1321,)g(A)n(pr)q(il)h(1992.)340 1963
y(8.)21 b(M.)13 b(Robsh)o(aw,)i Fa(On)f(pseudo-c)n(o)o(l)r(lis)o(ion)o
(s)d(in)j(MD5)p Fn(,)f(T)m(ec)o(hnical)h(Rep)q(ort)h(TR-102,)e(v)o(ers)
q(ion)i(1.1,)391 2009 y(RSA)e(La)o(b)q(ora)o(t)o(or)q(ie)q(s,)i(July)f
(1994.)p 340 2343 237 2 v 349 2370 a Fj(2)379 2386 y
Fn(Thi)q(s)d(\014rst)h(pu)n(blica)o(t)o(ion)i(st)o(ill)f(con)o(t)o
(ains)g(som)o(e)e(bugs.)h(Th)o(e)f(correct)o(e)q(d)g(v)o(ers)q(ion)i
(can)e(b)q(e)g(obt)o(ain)o(e)q(d)379 2432 y(u)o(n)o(d)o(er)k
Fm(ftp.esat.)o(ku)o(leu)o(ve)o(n.a)o(c.)o(be)10 b Fn(in)j(t)n(h)o(e)h
(direct)o(ory)h Fm(/pub/COSI)o(C/)o(bos)o(se)o(lae)o(/ri)o(pe)o(md/)o
Fn(.)1050 2556 y Fo(2)p eop
%%Trailer
end
userdict /end-hook known{end-hook}if
%%EOF

Xref: Re: MD5 considered insecure?  Bennet Yee
Xref subject previous
Xref subject next


For those of us who don't get MIME objects well, could someone please   
provide a net reference to where the MD5 paper can be found.

Thanks.

David Smith
Visa International  

Xref subject previous
Xref subject next


http://www.cs.ucsd.edu/users/bsy/dobbertin.ps
is a copy of the PostScript file.

--------
Bennet S. Yee		Phone: +1 619 534 4614	    Email: bsy@cs.ucsd.edu

Web:	http://www-cse.ucsd.edu/users/bsy/
USPS:	Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114

Xref subject previous
Xref subject next

Ran Atkinson says:
> In my own personal mind, it raises the question of how we should proceed
> on the AH transforms.  Possible options for the WG to consider include
> at least these:
>   - Make both HMAC MD5 and HMAC SHA-1 mandatory-to-implement
>   - Make HMAC MD5 optional-to-implement and HMAC SHA-1 mandatory-to-implement 

The second one makes much more sense. Why would we be mandating
something that we know isn't likely to stay "good" for long?

> One question I have is whether it would be sensible to substitute HMAC SHA-1
> for HMAC MD5 in the ESP "DES-CBC HMAC MD5 Replay" transform.  What do folks
> think is best ?

This substitution seems the most logical choice.
-- 
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-

Xref subject previous
Xref subject next

>Steve,
>
>  Thanks very much for sharing that paper with us.  Its quite short,
>but very interesting reading.

I must have overlooked or not received some e-mails. Would it be possible
to resend the paper (or URL)?

Thank you.

Denis
************************************************************* ************
* Denis Trcek                                       O O      * *         *
* "Jozef Stefan" Institute                        O O         * *        *
* Jamova 39, 61 111 Ljubljana, SLOVENIA           O   O        * *       *
* e-mail: denis.trcek@e5.ijs.si denis.trcek@ijs.si  O           * *      *
* Tel.:+386 61 1259 199, Fax:+386 61 1261 029, +386 61 273 677   * *     *
******************************************************************* ******

Xref subject previous

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

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

     I'm hoping to see some discussion on the list about how to proceed after
   folks have had the time to read and digest the material Steve has passed
   along.

The paper says "the computation of such a collision takes about 10
hours on a pentium PC", but it doesn't give the starting conditions of
the attack -- is it free to choose the IV and both inputs (in which
case it's not likely to turn into a practical attack), or are any of
those values fixed?

Given that HMAC uses (essentially) secret IV's, it's not clear how
much danger this attack presents to HMAC-MD5, as opposed to systems which hash 
only plaintext and then sign the hash..

Anyone have more details?

						- Bill




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

iQCVAwUBMZDzhlpj/0M1dMJ/AQF3nAP9Geq0tUv9lPkl8UvmdW1CY874CLZ4YhlR
hePDfZOv34LlZ06KFohIHfyk20ShF01Dk5kX/upuLMmb9bFJtqiIXXBYWGkEdWrh
FF5DlzsR3CTd8dyoH7xNyS+ec5nhlKs+dxkpuPDm+pzo67I0OsF2pVuS3AxQ1UDy
8IS5NpZzNT4=
=SMPS
-----END PGP SIGNATURE-----

As it has been already announced in this list, MD5 is broken for collisions
(Hans Dobbertin has extended his own techniques used against MD4 to attack
MD5 as well).
MD5 needs to be dropped (hope everyone already did) from any use that
requires resistance to collisions by plain MD5.

One application that is NOT broken with Dobbertin's attack is HMAC with MD5.
Collisions in plain MD5 do not compromise HMAC-MD5 as the latter uses
secret IVs and hides the result of the inner iterated function.
The question is whether the new attack has a significant potential
of being developed further to break also HMAC-MD5.
Beyond our own assessment we have got the opinion of a few first line
cryptographers that they see no way to make these techniques work against
the use of MD5 in HMAC.

With permission of Hans Dobbertin I reproduce this note he sent to me
over the weekend in response to my question of whether he sees any
application of his results to break HMAC-MD5:

    Date: Sat, 4 May 1996 22:48:09 +0200 (MET DST)
    From: Hans Dobbertin <>
    To: "H.Krawczyk" 

    Hi Hugo,

    I looked in your paper which you have sent me in January. To answer your
    question I can assure you that I cannot image any way to attack MD5 as it
    is used in HMAC.  To be more precise, from the recent attack on MD5
    (compress) one cannot derive any reservation against the use of MD5 in
    this context. (Perhaps one could argue that the randomness of MD5 is not
    sufficiently investigated ..., but that is another question, and I
    personally do not see a problem here.)


    Best regards, Hans



This does not mean in any way that HMAC-MD5 is going to be secure forever.
It is only to stress that the new attack is not necessarily a reason to drop
MD5 from its current use in IPSEC.

I believe that we can keep using it until new developments will bring
HMAC-MD5 closer to a break. Remember this "principle" from
/draft-ietf-ipsec-hmac-md5-txt>draft-ietf-ipsec-hmac-md5-txt.00:

     Message authentication, as opposed to encryption, has a "transient"
    effect. A published breaking of a message authentication scheme
    would lead to the replacement of that scheme, but would
    have no adversarial effect on information authenticated in the past.
    This is in sharp contrast with encryption, where information encrypted
    today may suffer from exposure in the future if, and when, the
    encryption algorithm is broken.

Following this principle I believe we can keep enjoying the better speed of
MD5 at least for some time (weeks? months? years? who knows?)

Just to stress this: there is NO known security advantage in keeping
MD5 relative to going to SHA-1. The only issue here is performance.
It is there where the trade-off seems to favor MD5 right now.

Having said all of this here is a short note on the theory behind HMAC-MD5.
In our paper we have chosen to make much stronger assumptions than needed
on the underlying hash function. This is motivated by the search of easy
to state and well-defined assumptions together with a simple and correct
analysis. One of these assumptions on the hash function which we call
"weakly collision resistance" requires resistance to collisions when the
IV is secret. In a strict sense such collisions can be found for MD5
using Dobbertin's techniques. However, this is possible through
extension attacks that are prevented in HMAC by the outer application
of MD5. Therefore, the actual function HMAC-MD5 remains secure.

In our coming Crypto'96 paper we will elaborate more on the analytical
issues and strength of assumptions. In particular, we may suggest an
additional (more conservative) variant of HMAC in which one appends a
key to the data before hashing (in the inner transformation).  However,
this has to be seen as "yet another fence" and not something for which
there is clear indication that we need to adopt immediately.

Bottom line: I suggest keeping HMAC-MD5 as defined now. (And being always
very attentive to updates from the cryptanalytic front.)

Hugo

So far, what I'm hearing is "MD5 is probably OK in HMAC". It isn't clear to
me what the recommendation is for other uses of MD5, apart from a blanket 
statement to "punt it". I tend to see such statements as knee-jerk 
reactions, which cause me to have my own knee-jerk reaction (usually
in the opposite direction ;-).

I've been trying to classify the uses of MD5, to get a better sense 
of where it's critical to replace MD5 with something else, and where
the use of MD5 isn't a risk.

My off-the-cuff list:

1) MD5 hashes to generate "bits"; something along these lines:
3DES
key1 = MD5(1|secret value)
key2 = MD5(2|secret value)
key3 = MD5(3|secret value)

2) keyed MD5, where the shared secret key is inserted into the digest
field for calculation purposes; this field is then overwritten by the 
digest. Examples: OSPF, RIP, ... 

3) keyed MD5 used like PPP CHAP [I can't remember how it's done, 
except I remember it's different than (2)]

4) HMAC-style hashes

5) MD5 in public-key signed hash functions 

6) ...

It sounds like we have more of an answer on #4 than any of the others.

MD5 is already being used by more than IPSEC. I think we should be
more formally describing the characteristics where "MD5 is safe to use"
vs. "MD5 is risky to use", so we can better advise other WGs as to
what they should do.  Maybe in some cases MD5 is OK provided that 
certain things (e.g. paramters to MD5?) are done differently. 

Right now, I wouldn't feel comfortable going to any other WG and 
telling them that they absolutely had to replace MD5 with something 
else. Maybe it isn't necessary, or maybe more is necessary than 
simply replacing the algorithm, in light of HMAC, followed by the
recent news of MD5. 

- C

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 OAKLEY Key Determination Protocol
       Author(s) : H. Orman
       Filename  : draft-ietf-ipsec-oakley-01.txt
       Pages     : 48
       Date      : 05/10/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.  The
OAKLEY 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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-oakley-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 (193.205.245.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-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: <19960513102709.I-D@CNRI.Reston.VA.US>

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

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

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

--OtherAccess--

--NextPart--

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 OAKLEY Key Determination Protocol
       Author(s) : H. Orman
       Filename  : draft-ietf-ipsec-oakley-01.txt
       Pages     : 48
       Date      : 05/10/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.  The
OAKLEY 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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-oakley-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 (193.205.245.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-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: <19960513102709.I-D@CNRI.Reston.VA.US>

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

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

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

--OtherAccess--

--NextPart--

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 OAKLEY Key Determination Protocol                   
       Author(s) : H. Orman
       Filename  : draft-ietf-ipsec-oakley-01.txt
       Pages     : 48
       Date      : 05/10/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.   
           
The OAKLEY 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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-oakley-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 (193.205.245.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-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: <19960510100020.I-D@CNRI.Reston.VA.US>

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

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

Content-Type: text/plain
Content-ID: <19960510100020.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 IP Security Protocol Working 
Group of the IETF.                                                         

       Title     : The OAKLEY Key Determination Protocol                   
       Author(s) : H. Orman
       Filename  : draft-ietf-ipsec-oakley-01.txt
       Pages     : 48
       Date      : 05/10/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.   
           
The OAKLEY 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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-oakley-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 (193.205.245.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-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: <19960510100020.I-D@CNRI.Reston.VA.US>

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

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

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

--OtherAccess--

--NextPart--

Xref: Re: SKIP Developer's Workshop Ran Atkinson
Xref subject next

We're pleased to announce the first SKIP Developers Workshop.  This will
take place at the San Francisco Airport Marriott Hotel on June 17-19.
Everyone is welcome to attend.  The workshop will feature:

	o  Direct access to SKIP developers from all over the world
	o  SKIP product demonstrations
	o  Presentations on real-world deployments of SKIP
	o  SKIP interoperability workshop and test lab
	o  Raw AH/ESP interoperability testing (S/WAN compatibility)
	o  In-depth workshops about the SKIP protocols
	o  Future directions for SKIP
	o  Cool SKIP paraphenalia!

SKIP is Simple Key management for Internet Protocols.   SKIP secures
IP network communications using IETF standard transforms and protocols.

SKIP supports high availablity, provides extremely low overhead in the 
establishment of secure IP channels, and has extensions for perfect
forward secrecy (PFS) and encrypted/authenticated multicast.

Registration is $495.00, and includes lunch on all three days and workshop
materials.  Payment will be taken on site.

To register, contact Judy Nakamura at:

	email:  X1380@applelink.apple.com
	voice:  415-812-9770
	fax:    415-812-9777

	Postal mail:
		4129 Wilkie Court
		Palo Alto, CA 94306

A block of hotel rooms has been reserved at the Marriott.  Registrants
should book their own rooms.  Mention the Sun Microsystems SKIP Developers
Workshop to obtain the group rate.

	San Francisco Airport Marriott
	1800 Old Bayshore Highway
	Burlingame, CA  94010
	415-692-9100

Xref subject previous

In article <199605162041.NAA07527@monster.incog.com> Tom Markson wrote:

[Commercial advertising deleted here]

Tom,

  Blatent commercial advertising, such as for your meeting with high
attendance fees, is NOT appropriate use of an IETF mailing list.  Please do
NOT send such material to the ipsec@tis.com list in future.

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

Xref: Re: Lame delegation for sd-bogus.tis.com  Olafur Gudmundsson
Xref subject next

I've been testing against your Secure DNS server.  This isn't a bug
report against the code, but against the domain records you are
serving from TIS.

The NS records for sd-bogus.tis.com at its parent, tis.com, say that
you have two name servers for it, relay.tis.com and uranus.tis.com.

This isn't actually true, though.  
relay.tis.com is not authoritative for sd-bogus.tis.com, and
uranus.tis.com only lists itself as a name server for sd-bogus.tis.com.

I suggest fixing the records at the tis.com servers, so that they
only list uranus.tis.com.

	John Gilmore

Xref subject next


I'm trying to figure out where folks stand on the matter of which
cryptographic hash function the IPsec WG should be using as its
default, mandatory-to-implement function.

At the LA IETF, there was a very clear consensus that the HMAC technique
described by Hugo should be the standard technique used with cryptographi
hash functions in the IPsec context.

The paper from the German Information Security Agency indicated a partial
cryptanalysis, not a full cryptanalysis, of ordinary MD5.  Reportedly,
that work does not apply to the HMAC technique of using MD5.  So there
is no known cryptanalysis of MD5 at present, though probably less confidence
in MD5 than before.

The main alternative to MD5 would be SHA-1 since MD4 is known to be less
strong than MD5.  Also, neither MD4, MD5, nor SHA-1 have patent problems.

Will active members of the WG who have a strong opinion about which
cryptographic hash function should be the default mandatory-to-implement
algorithm please send an email note to me  and to Paul Lambert
 and indicate your preference and reasoning
so we can figure out where folks stand on this question.

Thanks,

Ran
rja@cisco.com

I am in the process of adding SHA-1 support for AH in our product. I would
like to know if there are implemetations out there that I could interoperate
with.

Thanks,

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

Xref subject next


A bit of "good news, bad news", with the bad first...

A couple of people have observed in email that SHA-1 is export-controlled from
the US, which is surprising news to me (and in my personal opinion is
_incredibly_ stupid since its just a one-way hash function).  However, 
one of those folks provided me with a URL that makes this very clear.

The good news is that SHA-1 is under Commerce Department rules, which means
that US export licenses should be MUCH MUCH easier to obtain.

I'll cut/paste the relevant text from FIPS 180-1 below.  I obtained 
the quoted text from:
	http://129.6.52.11/fips/fip180-1.txt

"Export Control: Implementations of this standard are subject to Federal
Government export controls as specified in Title 15, Code of Federal
Regulations, Parts 768 through 799.  Exporters are advised to contact the
Department of Commerce, Bureau of Export Administration for more information."


If this changes the views of anyone who already responded via email,
please feel free to send a revised email along.

Ran
rja@cisco.com

-- 

Xref subject previous


John Gilmore writes:
 > I've been testing against your Secure DNS server.  This isn't a bug
 > report against the code, but against the domain records you are
 > serving from TIS.
 > 
 > The NS records for sd-bogus.tis.com at its parent, tis.com, say that
 > you have two name servers for it, relay.tis.com and uranus.tis.com.
 > 
 > This isn't actually true, though.  
 > relay.tis.com is not authoritative for sd-bogus.tis.com, and
 > uranus.tis.com only lists itself as a name server for sd-bogus.tis.com.
 > 
 > I suggest fixing the records at the tis.com servers, so that they
 > only list uranus.tis.com.
 > 
 > 	John Gilmore
 > 
Thanks pointing this out, the NS records have been fixed 

	Olafur

--Boundary-4920843-0-0

Ran, 
 
I just called the NSA on SHA export... both MD5 and SHA are both "export 
controlled", but they are both "under Department of Commerce jurisdiction". 
 
Hash algorithms can be readily exported.  SHA and MD5 are treated the same for 
US export considerations. 
 
I'd recommend a change from MD5 to SHA ... 
 
 
 
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 
-------------------------------------------------------------- 
  



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

Date: 17 May 96 09:11:59
From:"Ran Atkinson" 
To: PALAMBER@us.oracle.com
Subject: Re: moving forward ?
X-Orcl-Application: In-Reply-To:  "PALAMBER.US.ORACLE.COM" 
X-Orcl-Application: In-Reply-To:        "Re: moving forward ?" (May 17,  9:05am)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)


Umm.  There is one small problem with SHA-1.  The FIPS PUB 180-1
(http://129.6.52.11/fips/fip180-1.txt) indicates that SHA-1
is export-controlled under Commerce Department rules.  MD5
is believed not to be export controlled.  This is an issue
in many vendors' minds.

As long as we use HMAC, I'm indifferent about MD5 or SHA-1.

I'm still not seeing anything resembling consensus on key management.
We earlier put SKIP into the RFC publication queue for "Experimental"
status (it was delayed by the March issuance of "IAB Official Protocols",
which caused a backlog at the RFC Editor).  Bill Simpson plans to
put out Photuris as Experimental eventually.  I'm not sure what
the status is with ISAKMP and Oakley.  I'll ping the folks back east
and check...

Ran
rja@cisco.com


-- 


--Boundary-4920843-0-0--

Xref subject next


>A couple of people have observed in email that SHA-1 is export-controlled from
>the US.
>
>The good news is that SHA-1 is under Commerce Department rules, which means
>that US export licenses should be MUCH MUCH easier to obtain.
>

It is true that SHA-1 is export-controlled. However, according to the folks
at the Computer Security Division, NIST has sent a request to the Commerce
Department asking for a more general authorization for distributing DSS and
SHA-1. The request seemed to be approved. Unfortunately the person who was
handling the case was not available today, therefore, I would have to get
back to you next Monday regarding the specific rules for SHA distribution.

Shu-jen

Xref subject previous
Xref subject next


     Ran,
     
     The Department of State, Bureau of Politico-Military Affairs, in 22 
     CFR Part 121.1 Category 13  which addresses cryptographic systems 
     specifically excludes "data authentication which calculates a Message 
     Authentication Code (MAC) or similar result to insure no alteration of 
     text has taken place, or to authenticate users" (Section 1(vi))
     
     Only if the authentication is part of a system where encryption is 
     also being carried out would the MAC come under regulation.
     
     This would seem to conflict with the information you have. Do you have 
     a reference for that regulation?
     
     Gary L. McGreal
     


______________________________ Reply Separator _________________________________
Subject: Re: quick survey
Author:  Ran Atkinson  at INTERNET
Date:    5/17/96 1:27 PM


Received: by ccmail
Received:  from uupsi5 by ire.com (UUPC/extended 1.11) with UUCP;
           Fri, 17 May 1996 13:22:14 EDT
Received: from neptune.tis.com by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via 
S MTP;
        id AA21143 for gmcgreal; Fri, 17 May 96 13:06:43 -0400
Received: from neptune.tis.com by neptune.TIS.COM id aa03026;
          17 May 96 12:29 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa03009; 17 May 96 12:17 EDT 
Received: by relay.tis.com; id MAA13855; Fri, 17 May 1996 12:18:44 -0400 
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
    id xma013843; Fri, 17 May 96 12:18:17 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
    id AA07556; Fri, 17 May 96 12:18:26 EDT
Received: by relay.tis.com; id MAA13837; Fri, 17 May 1996 12:18:11 -0400 
Received: from unknown(171.69.1.174) by relay.tis.com via smap (V3.1)
    id xma013826; Fri, 17 May 96 12:17:55 -0400
Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA12763 for 
ipsec @tis.com; Fri, 17 May 1996 09:20:27 -0700
Message-Id: <199605171620.JAA12763@puli.cisco.com> 
From: Ran Atkinson 
X-ccAdmin: bprice@uupsi5
Date: Fri, 17 May 1996 09:20:26 PDT
X-Mailer: Mail User's Shell (7.2.5 10/14/92) 
To: ipsec@TIS.COM
Subject: Re: quick survey
Sender: ipsec-approval@neptune.tis.com 
Precedence: bulk
     
A bit of "good news, bad news", with the bad first...
     
A couple of people have observed in email that SHA-1 is export-controlled from 
the US, which is surprising news to me (and in my personal opinion is 
_incredibly_ stupid since its just a one-way hash function).  However, 
one of those folks provided me with a URL that makes this very clear.
     
The good news is that SHA-1 is under Commerce Department rules, which means 
that US export licenses should be MUCH MUCH easier to obtain.
     
I'll cut/paste the relevant text from FIPS 180-1 below.  I obtained 
the quoted text from:
 http://129.6.52.11/fips/fip180-1.txt
     
"Export Control: Implementations of this standard are subject to Federal 
Government export controls as specified in Title 15, Code of Federal 
Regulations, Parts 768 through 799.  Exporters are advised to contact the 
Department of Commerce, Bureau of Export Administration for more information."
     
     
If this changes the views of anyone who already responded via email, 
please feel free to send a revised email along.
     
Ran
rja@cisco.com
     
-- 

Xref subject previous

> From ipsec-request@neptune.tis.com Thu May 16 21:15:22 1996
> Date: Thu, 16 May 1996 19:58:52 -0700
> From: Ran Atkinson 
> To: ipsec@tis.com
> Subject: quick survey on MD5 & SHA-1
> 
> 
> I'm trying to figure out where folks stand on the matter of which
> cryptographic hash function the IPsec WG should be using as its
> default, mandatory-to-implement function.
...
> The paper from the German Information Security Agency indicated a partial
> cryptanalysis, not a full cryptanalysis, of ordinary MD5.  Reportedly,
> that work does not apply to the HMAC technique of using MD5.  So there
> is no known cryptanalysis of MD5 at present, though probably less confidence
> in MD5 than before.

If the HMAC isn't compromised by this attack, the proposed spec should
not be changed.  Strength is going to be relative anyway, and chasing
the 'strongest MAC at the time of publication' seems like a fleeting
goal.  The only gain of such a change would appear to be to delay the
demonstration implementations.

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: Re: Yes, you can export SHA and MD5 Theodore Y. Ts'o
Xref subject next


 
  
  
>The good news is that SHA-1 is under Commerce Department   
>rules, which means that US export licenses should be   
>MUCH MUCH easier to obtain.  
  
One more time .... to be sure that for this discussion we are clear:  
  
  
SHA and MD5 are both export controled, both are "easy" to export.  Export  
should not be a consideration in the comparison of SHA to MD5.  
  
  
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

   Date: 17 May 96 15:19:05 -0700
   From: "PALAMBER.US.ORACLE.COM" 

   SHA and MD5 are both export controled, both are "easy" to export.  Export  
   should not be a consideration in the comparison of SHA to MD5.  

Well, to be precise, the NSA has made the claim that SHA and MD5 are
export controlled, and the NIST's FIPS documenting SHA claims that SHA
is export controlled.  

There seems to be at least some controversy as to what their statutory
and regulatory authorities they are using to make either a statement, at
least where SHA and MD5 is being used in a system which does not use any
encryption methods or which attempts to engage in data hiding.

As far as I know, no one on the IPSEC list is a lawyer, and is actively
giving legal advise (myself included).  You should see your favorite
high-priced export control lawyer for an official legal opinion.

My own personal belief is that any algorithm suite which is using as a
weak an encryption as single DES might as well use HMAC-MD5.  If we were
going to use triple-DES for encryption it would perhaps make sense to
use HMAC-SHA, or some such.

						- Ted

Xref subject previous
Xref subject next

Gary,

  I provided a URL in my original note and don't recall that URL off the
top of my head.  The statement is embedded inside FIPS 180-1 itself.

  Btw, late breaking news is that someone at NIST is actively looking
into the current exportability state of SHA-1.  If I get more data,
I will pass it along straight away.

Ran
rja@cisco.com



-- 

Xref subject previous

the reference is:

   http://cs-www.ncsl.nist.gov/fips/fips180-1.txt

Although I should appreciate the 15 minutes of fame I have received for
supplying this URL, all I did was to bash on the search button in my web
browser.  No rocket science involved.

I too am not a lawyer, and my interpretation of the document I refer to is
"gee this looks like a sufficiently real claim that I should go ask my
lawyer about it", no more.


At 03:57 PM 5/17/96, you wrote:
>
>     Ran,
>     
>     The Department of State, Bureau of Politico-Military Affairs, in 22 
>     CFR Part 121.1 Category 13  which addresses cryptographic systems 
>     specifically excludes "data authentication which calculates a Message 
>     Authentication Code (MAC) or similar result to insure no alteration of 
>     text has taken place, or to authenticate users" (Section 1(vi))
>     
>     Only if the authentication is part of a system where encryption is 
>     also being carried out would the MAC come under regulation.
>     
>     This would seem to conflict with the information you have. Do you have 
>     a reference for that regulation?
>     
>     Gary L. McGreal
>     
>
>
>______________________________ Reply Separator
_________________________________
>Subject: Re: quick survey
>Author:  Ran Atkinson  at INTERNET
>Date:    5/17/96 1:27 PM
>
>
>Received: by ccmail
>Received:  from uupsi5 by ire.com (UUPC/extended 1.11) with UUCP;
>           Fri, 17 May 1996 13:22:14 EDT
>Received: from neptune.tis.com by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet)
via 
>S MTP;
>        id AA21143 for gmcgreal; Fri, 17 May 96 13:06:43 -0400
>Received: from neptune.tis.com by neptune.TIS.COM id aa03026;
>          17 May 96 12:29 EDT
>Received: from relay.tis.com by neptune.TIS.COM id aa03009; 17 May 96 12:17
EDT 
>Received: by relay.tis.com; id MAA13855; Fri, 17 May 1996 12:18:44 -0400 
>Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1)
>    id xma013843; Fri, 17 May 96 12:18:17 -0400
>Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
>    id AA07556; Fri, 17 May 96 12:18:26 EDT
>Received: by relay.tis.com; id MAA13837; Fri, 17 May 1996 12:18:11 -0400 
>Received: from unknown(171.69.1.174) by relay.tis.com via smap (V3.1)
>    id xma013826; Fri, 17 May 96 12:17:55 -0400
>Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id JAA12763 for 
>ipsec @tis.com; Fri, 17 May 1996 09:20:27 -0700
>Message-Id: <199605171620.JAA12763@puli.cisco.com> 
>From: Ran Atkinson 
>X-ccAdmin: bprice@uupsi5
>Date: Fri, 17 May 1996 09:20:26 PDT
>X-Mailer: Mail User's Shell (7.2.5 10/14/92) 
>To: ipsec@TIS.COM
>Subject: Re: quick survey
>Sender: ipsec-approval@neptune.tis.com 
>Precedence: bulk
>     
>A bit of "good news, bad news", with the bad first...
>     
>A couple of people have observed in email that SHA-1 is export-controlled from 
>the US, which is surprising news to me (and in my personal opinion is 
>_incredibly_ stupid since its just a one-way hash function).  However, 
>one of those folks provided me with a URL that makes this very clear.
>     
>The good news is that SHA-1 is under Commerce Department rules, which means 
>that US export licenses should be MUCH MUCH easier to obtain.
>     
>I'll cut/paste the relevant text from FIPS 180-1 below.  I obtained 
>the quoted text from:
> http://129.6.52.11/fips/fip180-1.txt
>     
>"Export Control: Implementations of this standard are subject to Federal 
>Government export controls as specified in Title 15, Code of Federal 
>Regulations, Parts 768 through 799.  Exporters are advised to contact the 
>Department of Commerce, Bureau of Export Administration for more information."
>     
>     
>If this changes the views of anyone who already responded via email, 
>please feel free to send a revised email along.
>     
>Ran
>rja@cisco.com
>     
>-- 
>
>

                  Rodney Thayer           ::         rodney@sabletech.com
                  Sable Technology Corp   ::              +1 617 332 7292
                  246 Walnut St           ::         Fax: +1 617 332 7970     
                  Newton MA 02160 USA     ::  http://www.shore.net/~sable
                           "Developers of communications software"

Xref subject next


The idea of having a transform that performs compression before
encryption has come up several times in the past, but I don't believe
it has been discussed recently.  Notably, compression has not been
added to any of the existing transform documents.  Along these lines, I
have a few questions.

1. Is compression still of interest as part of this group?  If so,
   I'll ask our local compression folks for some detailed information
   (and try to get them to write something up).  If not, I guess
   the rest of this can be ignored ;)

2. Should compression be a seperate function (i.e. ESP, AH, 
   Compression) or should it be optionally applied to the individual 
   transforms as part of ESP (and AH?)?

3. Are compression algorithm patent issues still a problem and are
   they enough of a problem to prevent IETF standardization?

Rob G.
rob.glenn@nist.gov

Dear Internet-Drafts people,

  I am trying to print this out for Prof. Ron Rivest
here at the Lab for CS at MIT.

I tried to locate
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-oakley-01.txt

and Netscape said it  ``is unable to find the file:
			internet-drafts/draft-ietf-ipsec-oakley-01.txt''
to check the file name and try again.

Can you help?

Best regards,
	Be Hubbard
	617 253-6098

	   \\ || //
	   \ .  . /
   ___.oo0_(__()__)__0oo.___
	  
Subject: Trying to print out a copy of oakley-01.txt

Dear Internet-Drafts people,

  My netscape2 was sick sick sick.  All is well and
printing now.

Best regards,
	Be Hubbard
	for RL Rivest

---------- __o       __o       __o       __o
-------- _`\<,_    _`\<,_    _`\<,_    _`\<,_
------- (*)/ (*)  (*)/ (*)  (*)/ (*)  (*)/ (*)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Xref: Re: Yes, you can export SHA and MD5 Theodore Y. Ts'o
Xref subject previous
Xref subject next


--Boundary-4941951-0-0

>You should see your favorite 
>high-priced export control lawyer for an  
>official legal opinion. 
 
No, just call the NSA ... lawyers opinions don't count. 
 
All cryptography is export controlled (from the US).  Cryptographic 
functionality used in a product that provides only integrity and 
authentication services is usually "easy" to export. 
 
 
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 
-------------------------------------------------------------- 



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

Date: 18 May 96 01:10:03
From:"Theodore Y. Ts'o" 
To: PALAMBER@us.oracle.com
Subject: Re: Yes, you can export SHA and MD5
Cc: ipsec@tis.com
X-Orcl-Application: In-Reply-To:  PALAMBER.US.ORACLE.COM's message of 17 May 96 15:19:05 -0700,
X-Orcl-Application: In-Reply-To: 	<199605180449.VAA05812@mailsun2.us.oracle.com>
X-Orcl-Application: Address:  1 Amherst St., Cambridge, MA 02139
X-Orcl-Application: Phone:  (617) 253-8091
X-Orcl-Application: Content-Length:  1150


   Date: 17 May 96 15:19:05 -0700
   From: "PALAMBER.US.ORACLE.COM" 

   SHA and MD5 are both export controled, both are "easy" to export.  Export  
   should not be a consideration in the comparison of SHA to MD5.  

Well, to be precise, the NSA has made the claim that SHA and MD5 are
export controlled, and the NIST's FIPS documenting SHA claims that SHA
is export controlled.  

There seems to be at least some controversy as to what their statutory
and regulatory authorities they are using to make either a statement, at
least where SHA and MD5 is being used in a system which does not use any
encryption methods or which attempts to engage in data hiding.

As far as I know, no one on the IPSEC list is a lawyer, and is actively
giving legal advise (myself included).  You should see your favorite
high-priced export control lawyer for an official legal opinion.

My own personal belief is that any algorithm suite which is using as a
weak an encryption as single DES might as well use HMAC-MD5.  If we were
going to use triple-DES for encryption it would perhaps make sense to
use HMAC-SHA, or some such.

						- Ted


--Boundary-4941951-0-0--

Xref subject previous
Xref subject next


--Boundary-20037326-0-0

 
>You should see your favorite 
>high-priced export control lawyer for an  
>official legal opinion. 
 
No, just call the NSA ... lawyers opinions don't count. 
 
All cryptography is export controlled (from the US).  Cryptographic 
functionality used in a product that provides only integrity and 
authentication services is usually "easy" to export. 
 
 
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 
-------------------------------------------------------------- 
  



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

Date: 18 May 96 01:10:03
From:"Theodore Y. Ts'o" 
To: PALAMBER@us.oracle.com
Subject: Re: Yes, you can export SHA and MD5
Cc: ipsec@tis.com
X-Orcl-Application: In-Reply-To: PALAMBER.US.ORACLE.COM's message of 17 May 96 15:19:05 -0700,
X-Orcl-Application: In-Reply-To:	<199605180449.VAA05812@mailsun2.us.oracle.com>
X-Orcl-Application: Address: 1 Amherst St., Cambridge, MA 02139
X-Orcl-Application: Phone: (617) 253-8091
X-Orcl-Application: Content-Length: 1150
X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com
X-Orcl-Application: Precedence: bulk


   Date: 17 May 96 15:19:05 -0700
   From: "PALAMBER.US.ORACLE.COM" 

   SHA and MD5 are both export controled, both are "easy" to export.  Export  
   should not be a consideration in the comparison of SHA to MD5.  

Well, to be precise, the NSA has made the claim that SHA and MD5 are
export controlled, and the NIST's FIPS documenting SHA claims that SHA
is export controlled.  

There seems to be at least some controversy as to what their statutory
and regulatory authorities they are using to make either a statement, at
least where SHA and MD5 is being used in a system which does not use any
encryption methods or which attempts to engage in data hiding.

As far as I know, no one on the IPSEC list is a lawyer, and is actively
giving legal advise (myself included).  You should see your favorite
high-priced export control lawyer for an official legal opinion.

My own personal belief is that any algorithm suite which is using as a
weak an encryption as single DES might as well use HMAC-MD5.  If we were
going to use triple-DES for encryption it would perhaps make sense to
use HMAC-SHA, or some such.

						- Ted


--Boundary-20037326-0-0--

Xref subject previous
Xref subject next

At 10:26 AM 5/20/96 -0400, Robert Glenn wrote:
>
>The idea of having a transform that performs compression before
>encryption has come up several times in the past, but I don't believe
>it has been discussed recently.  Notably, compression has not been
>added to any of the existing transform documents.  Along these lines, I
>have a few questions.
>
>1. Is compression still of interest as part of this group?  If so,
>   I'll ask our local compression folks for some detailed information
>   (and try to get them to write something up).  If not, I guess
>   the rest of this can be ignored ;)

Compression must be a real issue to anyone on this list that will be running
product over slow WAN links, like POTS.  I think that is most here.

My dialup experience says its a must implement, the only question is how.
See below.

>2. Should compression be a seperate function (i.e. ESP, AH, 
>   Compression) or should it be optionally applied to the individual 
>   transforms as part of ESP (and AH?)?

It seems that there were opinions that said this would be a negotiated
option.  That all of the key negotiation proposals had ways of including the
compression negotiation and that a separate transform was not needed.

>3. Are compression algorithm patent issues still a problem and are
>   they enough of a problem to prevent IETF standardization?

The PPPEXT group finally went with a variance.  Discuss this with them and
the IESG for details.  It was painful, that much I remember.


Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref subject previous
Xref subject next

   Date: 20 May 96 10:03:36 -0700
   From: "PALAMBER.US.ORACLE.COM" 

   >You should see your favorite 
   >high-priced export control lawyer for an  
   >official legal opinion. 

   No, just call the NSA ... lawyers opinions don't count. 

Paul,

I can't tell from your e-mail message whether you're joking or not.... !

							- Ted

Xref subject previous
Xref subject next

At 01:40 PM 5/20/96 -0400, Theodore Y. Ts'o wrote:
>   From: "PALAMBER.US.ORACLE.COM" 
>
>   No, just call the NSA ... lawyers opinions don't count. 
>
>I can't tell from your e-mail message whether you're joking or not.... !

Unfortunately he is not.  I have had to be in some policy meetings in DC on
ITAR stuff, and this is the theme I have heard.  Different rulings for
different companies that are not following any pattern that security savy
lawyers can use to guide companies along.

This alone is reason enough to scrap the whole system.


And a call to NSA is insufficient. You need it in writing.  Good luck on
getting that!


Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref subject previous
Xref subject next


--Boundary-4946428-0-0

>Sent: MAY       20, 1996 13:40 
>From:     Theodore Y. Ts'o  
>>   Date: 20 May 96 10:03:36 -0700 
>>   From: "PALAMBER.US.ORACLE.COM"  
>>   >You should see your favorite  
>>   >high-priced export control lawyer for an   
>>   >official legal opinion.  
>> 
>>   No, just call the NSA ... lawyers opinions don't count.  
>> 
>Paul, 
> 
>I can't tell from your e-mail message whether you're joking or not.... ! 
 
Ted, 
 
No, I am not joking.  I also spoke with the NSA on this topic ... SHA and MD5 
when used as hash algorithms have the same export considerations.  This is not 
a promise or direct ruling on SHA that our standards group can easily quote, 
but it is an indicator of the current review process.  Standards are not 
subject to export control, so we are all subject to review of the final 
embodyment of these technologies into a product. 
 
 
Paul


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

Date: 20 May 96 13:40:14
From:"Theodore Y. Ts'o" 
To: PALAMBER@us.oracle.com
Subject: Re: Yes, you can export SHA and MD5
Cc: ipsec@tis.com
X-Orcl-Application: In-Reply-To:  PALAMBER.US.ORACLE.COM's message of 20 May 96 10:03:36 -0700,
X-Orcl-Application: In-Reply-To: 	<199605201727.KAA18637@mailsun2.us.oracle.com>
X-Orcl-Application: Address:  1 Amherst St., Cambridge, MA 02139
X-Orcl-Application: Phone:  (617) 253-8091
X-Orcl-Application: Content-Length:  360


   Date: 20 May 96 10:03:36 -0700
   From: "PALAMBER.US.ORACLE.COM" 

   >You should see your favorite 
   >high-priced export control lawyer for an  
   >official legal opinion. 

   No, just call the NSA ... lawyers opinions don't count. 

Paul,

I can't tell from your e-mail message whether you're joking or not.... !

							- Ted


--Boundary-4946428-0-0--

Xref subject previous
Xref subject next


I have checked with my colleague at the Security Division and the
Bureau of Export Administration (BXA) regarding SHA code
distribution. The answer is: SHA can be exported with some
restrictions.
 
NIST can not distribute SHA implementation via WWW at this time
(see later note regarding FTP release). However, NIST has obtained
a license from the Commerce Department which permits NIST to
distribute SHA and DSS to the majority of the world with a few
exceptions. People's Republic of China and the former Soviet Block
can import SHA as long as it's intended for civil end-user
applications rather than for military purpose. The following
countries are prohibited from importing SHA: Cuba, Iran, Iraq,
Libya, North Korea, Serbia, Syria, and Sudan. Please note that this
list of embargo countries changes over time.

Companies or individuals who plan to use the SHA implementation
inside their product(s) need not obtain a separate export license
for reexporting SHA as long as the same guideline on the original
license is followed. For information or clarification on this
issue, please call BXA at (202) 482-4811.

To obtain the SHA implementation from NIST, please send email to
Eduardo Chen at eduardo.chen@nist.gov. Eduardo can also be reached
at (301) 975-3367. Other than requesting the SHA implementation,
please refrain from making other requests such as technical
consultations from Eduardo (He works for a different division).

NIST FIPS publications can be downloaded from the URL:
http://csrc.nist.gov/fips.

NIST also has a plan to make SHA and DSS implementations available
over a NIST export-controlled FTP site. The plan is being evaluated
by the upper management and legal council. I'll keep you posted as
soon as it is approved.

Shu-jen

I have checked with my colleague at the Security Division and the
Bureau of Export Administration (BXA) regarding SHA code
distribution. The answer is: SHA can be exported with some
restrictions.
 
NIST can not distribute SHA implementation via WWW at this time
(see later note regarding FTP release). However, NIST has obtained
a license from the Commerce Department which permits NIST to
distribute SHA and DSS to the majority of the world with a few
exceptions. People's Republic of China and the former Soviet Block
can import SHA as long as it's intended for civil end-user
applications rather than for military purpose. The following
countries are prohibited from importing SHA: Cuba, Iran, Iraq,
Libya, North Korea, Serbia, Syria, and Sudan. Please note that this
list of embargo countries changes over time.

Companies or individuals who plan to use the SHA implementation
inside their product(s) need not obtain a separate export license
for reexporting SHA as long as the same guideline on the original
license is followed. For information or clarification on this
issue, please call BXA at (202) 482-4811.

To obtain the SHA implementation from NIST, please send email to
Eduardo Chen at eduardo.chen@nist.gov. Eduardo can also be reached
at (301) 975-3367. Other than requesting the SHA implementation,
please refrain from making other requests such as technical
consultations from Eduardo (He works for a different division).

NIST FIPS publications can be downloaded from the URL:
http://csrc.nist.gov/fips.

NIST also has a plan to make SHA and DSS implementations available
over a NIST export-controlled FTP site. The plan is being evaluated
by the upper management and legal council. I'll keep you posted as
soon as it is approved.

Shu-jen

Xref subject previous
Xref subject next


--Boundary-4955695-0-0

 
>I thought everyone was at least *pretending* 
>that the NSA was staying within the scope of their charter. 
 
But they are ... they are not exerting any "statutory or regulatory 
authority" ... they review the technical capabilities of a product. 
 
I do not agree with the policies and find that the process hurts my business, 
but the NSA is following a fairly clear set of guidelines. 
 
>Different rulings for different companies that  
>are not following any pattern that security savy 
>lawyers can use to guide companies along. 
 
I have not seen that much variation ... perhaps a gradual loosening, but no 
wild variations.  The variations most likely come from the range in ablility 
of vendors to document the products that they build. 
 
 
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 
-------------------------------------------------------------- 
  



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

Date: 20 May 96 15:59:41
From:"Theodore Y. Ts'o" 
To: Robert,Moskowitz,rgm3@chrysler.com
Subject: Re: Yes, you can export SHA and MD5
Cc: LAMBER@us.oracle.com
X-Orcl-Application: In-Reply-To:  Robert Moskowitz's message of Mon, 20 May 1996 15:25:57 -0400,
X-Orcl-Application: In-Reply-To: 	<2.2.32.19960520192557.00c5f3ec@pop3hub.is.chrysler.com>
X-Orcl-Application: Address:  1 Amherst St., Cambridge, MA 02139
X-Orcl-Application: Phone:  (617) 253-8091
X-Orcl-Application: Content-Length:  1445


   Date: Mon, 20 May 1996 15:25:57 -0400
   From: Robert Moskowitz 

(Note: ipsec has been removed from the cc list.)

   At 01:40 PM 5/20/96 -0400, Theodore Y. Ts'o wrote:
   >   From: "PALAMBER.US.ORACLE.COM" 
   >
   >   No, just call the NSA ... lawyers opinions don't count. 
   >
   >I can't tell from your e-mail message whether you're joking or not.... !

   Unfortunately he is not.  I have had to be in some policy meetings in DC on
   ITAR stuff, and this is the theme I have heard.  Different rulings for
   different companies that are not following any pattern that security savy
   lawyers can use to guide companies along.

I didn't think the NSA as an agency had the statutory or regulatory
authority to make decisions regarding export control.  It's one thing if
the State Department and the Commerce Department were under the thrall
of the NSA and always blindly followed the NSA's lead --- but that's
still a far cry from saying that companies should call the NSA because
its the agency running the whole show.  (This was why I wasn't sure
whether Paul was joking!)  I thought everyone was at least *pretending*
that the NSA was staying within the scope of their charter.  :-)

   This alone is reason enough to scrap the whole system.

What you've described is called "secret law" (if you can prove it) and
last I checked, it wasn't legal within the United States....

						- Ted


--Boundary-4955695-0-0--

Xref subject previous

At 07:58 PM 5/20/96 -0700, PALAMBER.US.ORACLE.COM wrote:
> 
>>Different rulings for different companies that  
>>are not following any pattern that security savy 
>>lawyers can use to guide companies along. 
> 
>I have not seen that much variation ... perhaps a gradual loosening, but no 
>wild variations.  The variations most likely come from the range in ablility 
>of vendors to document the products that they build. 

The last sentence tells it all.

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref subject previous

>
>   Companies or individuals who plan to use the SHA implementation
>   inside their product(s) need not obtain a separate export license
>   for reexporting SHA as long as the same guideline on the original
>   license is followed. For information or clarification on this
>   issue, please call BXA at (202) 482-4811.
>
>Shu-jen,
>	If the text of the original export license which NIST has
>obtained for the export of SHA could be obtained in electronic form,
>could you please post a pointer to it?  I suspect it would be of great
>interest to many implementors on this list.
>

Unfortunately the export license NIST obtained from the Commerse Department
is not available in electronic form nor self-explanatory. The license contains:

1. Export Control Classification Number: 5D13A (this is the reference number
for making inquiries). In fact,

    5 - indicates the "Telecommunications and Cryptography" category. 
    D - software
    01 - 19: Coordinating Committee Controls
         (others are:
            20-39: Missile Technology Controls
            40-59: Nuclear Non-Proliferation Controls
            60-79: Chemical and Biological Weapons Controls
            80-99: Other Controls)
    A - a data processing code to indicate the country group for which a
Validated License is required

2. General license eligibility: GTDR, GLX

        GTDR(General License Technical Data Restricted) is the code for the
free world countries.

        GLX is the code for countries where SHA can only be imported for
non-military usage.

3. Validated License Required for Country Groups: All

The license also contains the following footnotes:

Commodities eligible for export under General License and used in the
design, development, production or use of Nuclear, Chemical or Biological
weapons or ballistic missiles require a Validated export license.

The countries included in each Country Group are listed on the reverse side
of this form (Not copied for this email message). For shipments of the above
commodities to any of the destinations indicated in the validated license
required column (meaning the item 3 above), the exporter must apply for and
obtain a validated license document from the Office of Exporter Services, P.O.
Box 273, Washington, D.C. 20044.

When an export is made, it is necessary for the exporter to show on the
Shipper's Export Declaration (Form 7525-V), either the validated license
number or the applicable general license symbol (e.g., GLV, G-DEST, etc.).
Form 7525-V is available from the Superintendent of Documents, U.S.
Government Printing Office, Washinton, D. C. 20402, and from Export
Administration District Offices (U.S. Dept of Commerce). They may also be
obtained from certain commercial stationers.

For Information concerning this classification (i.e. 5D13A) contact 
        Gustaf A. Sundquist 
        Phone: 202 482-1265

Above is the information contained in NIST's export license, granted on
8/17/1995.

>	I don't quite understand what you mean by "the same guidelines
>on the original license".  In the context of your message, that could be
>interepreted as "anywhere except the embargoed countries, plus civilian
>use only for China and former Soviet Bloc countries", or it could imply
>there were other restrictions on the original license.
>

Your first interpretation was exactly what I meant to convey. I have called
BXA to confirm this interpretation. For example, if country A exports SHA to
country B under the general license GTDR, and country B later on wants to
export SHA to country C, country B does not need a separate license as long
as country A can export to country C under the original license.

When Eduardo Chen sends out the SHA code upon request, he will attach a memo
basically saying something similar to what I summarized in yesterday's message. 

I hope this long message is useful to most of you.

>
>P.S.  I do think NIST should be commended in its proactive role in
>obtaining an export license for SHA which could be used by other
>companies or individuals who are contemplating using SHA in their
>products. 
>

Thank you, service is our name:-).

Shu-jen

Xref subject next


This is the formal IPsec WG Last Call for the drafts below.  Comments on this
action should be sent by midnight (US Pacific Time) 27 May to the co-chairs,
Paul Lambert  and Randall Atkinson .
Minor editorial comments should be sent directly to the document editors,
with a copy to each of the co-chairs.

draft-ietf-ipsec-ah-hmac-sha-00.txt to "Proposed Standard" as
	mandatory to implement for all IPv6 systems and
	mandatory to implement for IPv4 systems that implement AH.

draft-ietf-ipsec-ah-hmac-md5-00.txt to "Proposed Standard" with
	elective status.

draft-ietf-ipsec-hmac-md5-00.txt to "Proposed Standard" with
	elective status. 

Ran
rja@cisco.com

-- 

Xref: Re: Whatever happend to compression?  Bill Sommerfeld
Xref subject previous
Xref subject next

am I to take this as an indication that at least some people would do a
compression transform "beside" an encryption transform?  In other words, the
"don't worry PPP will make you happy" answer is not considered sufficient?

>X-Sender: t3125rm@pop3hub.is.chrysler.com
>Date: Mon, 20 May 1996 12:35:08 -0400
>To: Robert Glenn , ipsec@TIS.COM
>From: Robert Moskowitz 
>Subject: Re: Whatever happend to compression?
>Cc: rob.glenn@nist.gov
>Sender: ipsec-approval@neptune.tis.com
>
>At 10:26 AM 5/20/96 -0400, Robert Glenn wrote:
>>
>>The idea of having a transform that performs compression before
>>encryption has come up several times in the past, but I don't believe
>>it has been discussed recently.  Notably, compression has not been
>>added to any of the existing transform documents.  Along these lines, I
>>have a few questions.
>>
>>1. Is compression still of interest as part of this group?  If so,
>>   I'll ask our local compression folks for some detailed information
>>   (and try to get them to write something up).  If not, I guess
>>   the rest of this can be ignored ;)
>
>Compression must be a real issue to anyone on this list that will be running
>product over slow WAN links, like POTS.  I think that is most here.
>
>My dialup experience says its a must implement, the only question is how.
>See below.
>
>>2. Should compression be a seperate function (i.e. ESP, AH, 
>>   Compression) or should it be optionally applied to the individual 
>>   transforms as part of ESP (and AH?)?
>
>It seems that there were opinions that said this would be a negotiated
>option.  That all of the key negotiation proposals had ways of including the
>compression negotiation and that a separate transform was not needed.
>
>>3. Are compression algorithm patent issues still a problem and are
>>   they enough of a problem to prevent IETF standardization?
>
>The PPPEXT group finally went with a variance.  Discuss this with them and
>the IESG for details.  It was painful, that much I remember.
>
>
>Robert Moskowitz
>Chrysler Corporation
>(810) 758-8212
>
>
>

                  Rodney Thayer           ::         rodney@sabletech.com
                  Sable Technology Corp   ::              +1 617 332 7292
                  246 Walnut St           ::         Fax: +1 617 332 7970     
                  Newton MA 02160 USA     ::  http://www.shore.net/~sable
                           "Developers of communications software"

Xref subject next

Hi,

The quick survey indicated very clear consensus that HMAC SHA-1 should be the
mandatory-to-implement approach for AH and that HMAC MD5 should be
optional-to-implement for AH.  I'll post the WG Last Call for the 2 HMAC AH
transforms in a few minutes.

It isn't clear to me whether this also means that folks prefer to have
"DES-CBC + HMAC SHA-1 + Replay protection" instead of "DES-CBC + HMAC SHA-1 +
Replay protection" in the mandatory-to-implement ESP transform.  

Could the active members of the WG with a strong view either way on the
integrity part of the ESP transform please send a quick note _now_ to Paul
Lambert  and to me  indicating your
preference with regard to ESP ?  

If this new survey results in MD5 as OK for ESP, then we'll hold WG Last Call
for the combined ESP transform edited by Jim Hughes right away.  Otherwise,
Jim will need to re-edit his draft according to the consensus and WG Last Call
will necessarily be delayed on that edit cycle.

Thanks,

Ran
rja@cisco.com

-- 

Xref subject previous
Xref subject next

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

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

   In other words, the "don't worry PPP will make you happy" answer is
   not considered sufficient?

Well, it won't make you happy (unless all you want is a
feature-checkoff box..)

Any encryption algorithm which generates output which is compressible
should be considered highly suspect.

You need to compress before you encrypt (and decompress after you
decrypt).

					- Bill




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

iQCVAwUBMaIjkFpj/0M1dMJ/AQGn2wP+JhUxC3VU/cuflIWNH1eFtdX9+QaYD6pO
ZLjirmc7fbR3snvPzKqG3rZfWB+80vtTmIkTNm7HJdNbr5sUXGolAoNcvf4qLooR
MyqsIbJ95cZnlUa+v1ueVfQA6al04ZGvqyhzOmXUre70+qRWmGPSXNTL7D1gIUbo
ESwfBDkj+G4=
=70/K
-----END PGP SIGNATURE-----

Xref subject previous
Xref subject next

At 02:55 PM 5/21/96 -0400, Rodney Thayer wrote:
>am I to take this as an indication that at least some people would do a
>compression transform "beside" an encryption transform?  In other words, the
>"don't worry PPP will make you happy" answer is not considered sufficient?

How can PPP 'make you happy' when the data is already encrypted?

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref: Re: Whatever happend to compression? Phil Karn Jr
Xref subject previous
Xref subject next

sorry -- that's what I meant.  I guess I was asking this...

is this combination:

   original IP packet -> AH + ESP(Compression(original))

something that other people are thinking about.  ESP being one payload
scheme and Compression being another payload scheme.  I believe the RFC's
support the concept of multiple payload schemes, right?

>To: Rodney Thayer 
>Cc: ipsec@TIS.COM
>Subject: Re: Whatever happend to compression? 
>Date: Tue, 21 May 1996 16:12:07 -0400
>From: Bill Sommerfeld 
>Sender: ipsec-approval@neptune.tis.com
>
>-----BEGIN PGP SIGNED MESSAGE-----
>
>content-type: text/plain; charset=us-ascii
>
>   In other words, the "don't worry PPP will make you happy" answer is
>   not considered sufficient?
>
>Well, it won't make you happy (unless all you want is a
>feature-checkoff box..)
>
>Any encryption algorithm which generates output which is compressible
>should be considered highly suspect.
>
>You need to compress before you encrypt (and decompress after you
>decrypt).
>
>					- Bill
>
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQCVAwUBMaIjkFpj/0M1dMJ/AQGn2wP+JhUxC3VU/cuflIWNH1eFtdX9+QaYD6pO
>ZLjirmc7fbR3snvPzKqG3rZfWB+80vtTmIkTNm7HJdNbr5sUXGolAoNcvf4qLooR
>MyqsIbJ95cZnlUa+v1ueVfQA6al04ZGvqyhzOmXUre70+qRWmGPSXNTL7D1gIUbo
>ESwfBDkj+G4=
>=70/K
>-----END PGP SIGNATURE-----
>
>

                  Rodney Thayer           ::         rodney@sabletech.com
                  Sable Technology Corp   ::              +1 617 332 7292
                  246 Walnut St           ::         Fax: +1 617 332 7970     
                  Newton MA 02160 USA     ::  http://www.shore.net/~sable
                           "Developers of communications software"

Xref subject previous
Xref subject next

At 05:47 PM 5/21/96 -0400, Rodney Thayer wrote:
>sorry -- that's what I meant.  I guess I was asking this...
>
>is this combination:
>
>   original IP packet -> AH + ESP(Compression(original))
>
>something that other people are thinking about.  ESP being one payload
>scheme and Compression being another payload scheme.  I believe the RFC's
>support the concept of multiple payload schemes, right?

That is the best way IMHO.  Compression is something that should be
negotiated, just like ESP and AH.

Afterall, there are many compression schemes, some preferable over others
(read better patent terms), just like cryphers.

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref: Re: Results of quick survey Phil Karn
Xref subject previous
Xref subject next

Regarding the issue of HMAC SHA-1 versus HMAC MD5 and the mandatory
transform for ESP ....

During the discussion of the combined ESP DES-CBC, HMAC + Replay
Prevention transform at the LA IPSEC, there was a question on whether
the ICV (HMAC Residual) should be encrypted or unencrypted by ESP.

The desire for the ICV to be unencrypted is credited to Phil Karn in
his desire to lessen the impact of flooding (aka "clogging") attacks
where the receiver would be required to spend lots of time decrypting
bogus packets that could be dealt with more efficiently, and discarded
if bogus, by a less intensive MAC check.  If I recall correctly, Phil
announced at LA that as far as he was now concerned, this no longer
was an issue becasue he could run DES as fast as MD5 and therefore
unencrypting a packet was no big deal.  An issue: is this also the
case for DES vs SHA-1 and therefore we still don't care?

What I don't remember was the group coming to any consensus regarding
which way to go.  The current version of the transform
(draft-ietf-ipsec-esp-des-md5-01.txt) still has the ICV unencrypted.
Given the recent turmoil over the cryptographic weakness of MD5,
doesn't it make sense to limit the exposure of whichever MAC algorithm
used to any future cryptographic attacks by encrypting the ICV?


Regards,

Howie 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: Re: Whatever happend to compression?  Bill Sommerfeld
Xref subject previous
Xref subject next

Well, we could certainly add compression as an optional ESP transform,
but it does seem to me that the widespread use of compression at the
application layer may render this moot in the majority of cases. It's
already standard practice to compress large files before ftping them
over the net, and of course virtually every network image format has
compression built-in. Compressing at the application layer does have
the significant advantage of saving bandwidth all along the network path,
not just in the part that's encrypted with ESP (assuming tunnel mode
operation, which I expect to be IPSP's primary use in the near term).

Phil

Xref: Re: Results of quick survey Uri Blumenthal
Xref subject previous
Xref subject next

One point about the relative ordering of authentication and encryption.
Even though I can now do DES pretty fast, it's still true that if you
wrap encryption outside authentication then you still have to perform
both algorithms to determine that the packet is bogus. If you
authenticate outside of encryption, then you only need execute the
authentication algorithm before you toss the bogus packet. So unless
your encryption algorithm is *free* (not just as cheap as the authentication)
there is still a good reason to put authentication outside encryption.

Phil

Xref subject previous
Xref subject next

Phil Karn says:
> One point about the relative ordering of authentication and encryption.
> Even though I can now do DES pretty fast, it's still true that if you
> wrap encryption outside authentication then you still have to perform
> both algorithms to determine that the packet is bogus. 

On the other hand, it is considered best to authenticate the
"final result" date, which is the plaintext. For "proving"
that this encrypted data was "kosher" strictly speaking,
is NOT equivalent to "proving" that the decrypted data
is what was sent (i.e. it may decrypt to different
things under different keys and so on)...

Do we care? [I understand your concern about performance.]
-- 
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-

Xref subject previous
Xref subject next

	 Phil Karn says:
	 > One point about the relative ordering of authentication and encrypti
	on.
	 > Even though I can now do DES pretty fast, it's still true that if yo
	u
	 > wrap encryption outside authentication then you still have to perfor
	m
	 > both algorithms to determine that the packet is bogus. 
	 
	 On the other hand, it is considered best to authenticate the
	 "final result" date, which is the plaintext. For "proving"
	 that this encrypted data was "kosher" strictly speaking,
	 is NOT equivalent to "proving" that the decrypted data
	 is what was sent (i.e. it may decrypt to different
	 things under different keys and so on)...
	 
	 Do we care? [I understand your concern about performance.]

The problem with putting the authentication check on the inside is that
the short-block guessing attack can be used.

I'm not at all convinced, though, that denial-of-service is worth
worrying about here.  Or rather, it is a problem, and a serious one,
but it would happen either way; it's very cheap for the attacker to
generate the packets and expensive for you to detect them, whichever
tack you take.

[speaking as an individual, not as co-chair]

  My personal preference would be to retain HMAC MD5 for use with the Combined
ESP transform.  There are no known problems with HMAC MD5 and there is ample
freely distributable source code, some of which has pretty good performance.
SHA-1 is generally believed to be slower than MD5 and performance ought not be
completely ignored.

  I also prefer to put the HMAC MD5 residual underneath the encryption.  While
I understand Phil Karn's point, I prefer to have the additional protection on
the authentication that is provided by having it beneath the encryption.  I
also thought Uri's point about the semantic of the authentication was a good
one.  What do other folks think about making this change ?

[as co-chair]
  We need to reach closure on the Combined ESP transform very very soon.
Folks with open issues or comments should PLEASE raise them NOW to the list
(or if you prefer, directly with the Jim Hughes).

Thanks,

Ran
rja@cisco.com

Xref subject previous
Xref subject next

Phil Karn writes:
> So unless your encryption algorithm is *free* (not just as cheap
> as the authentication) there is still a good reason to put
> authentication outside encryption.

Uri Blumenthal writes:
# On the other hand, it is considered best to authenticate the
# "final result" date, which is the plaintext.

Does anyone think it might be worthwhile to authenticate _both_ inside and
outside the encryption ?  I.e. HMAC(DES-CBC(HMAC(data)))

This might improve protection against clogging attacks as per Phil, while
authenticating an unambiguous plaintext as suggested by Uri. Howie Weiss
expressed concern earlier about exposing the HMAC result in case the
underlying hash is (partially) cryptanalyzed. The outer HMAC, upon which
the quick anti-clogging protection relies, would be equally vulnerable in
this scheme. But the inner HMAC should be shielded in part against hash
collision attacks, by the covering encryption.

Two immediate problems with this approach are performance degradation for
the sender, and (the big one) complication of the protocol and its analysis.
The receiver could be allowed to choose to ignore the outer HMAC value, thus
avoiding a performance hit by passing up the chance to detect bad packets
early in the processing. Of course this adds complexity to receivers' 
policies.

-Lewis McCarthy
lew@cs.cornell.edu (until June 1)

Xref subject previous
Xref subject next

At 7:58 PM 5/22/96, Lewis McCarthy wrote:
>Does anyone think it might be worthwhile to authenticate _both_ inside and
>outside the encryption ?  I.e. HMAC(DES-CBC(HMAC(data)))

Yes, I wondering the same thing.  And if one is going to authenticate both
inside and outside, is there an opportunity to share some of the work.
E.g.other than violating layering rather grossly, what else is wrong with
computing the hash of the plain text, the hash of the ciphertext and then
just one signature covering both hashes?  Two hash computations are still
required, and the receiver could still elect elect to ignore the outer
hash, but the cost would be lower and the tendency to ignore this outer
check would be lessened.

Steve


--------------------
Steve Crocker                                     Main: +1 703 620 4200
CyberCash, Inc.                                   Desk: +1 703 716 5214
2100 Reston Parkway                               Fax:  +1 703 620 4215
Reston, VA 22091                                  crocker@cybercash.com

Xref: Re: Whatever happend to compression?  Perry E. Metzger
Xref subject previous
Xref subject next

A few thoughts.

In general, compression is nice in that it randomizes the data first, 
then encryption further scrambles the bits making it harder for 
anyone to make sense of it. It's another roadblock to the bad guy.

Compression should happen before encryption since compression
works better on raw data than on encrypted data.
  
Compression (as per the CCP draft RFC) can compress the PPP 
header information as well as the data which helps overall 
performance on WAN links.

How about this? Once RFC's are set for IPSEC and CCP, another WG
could be put together to define encryption and compression 
interaction in the PPP world. Eh? Or will a WG even be needed?

Xref subject previous
Xref subject next

Steve Crocker says:
> >Does anyone think it might be worthwhile to authenticate _both_ inside and
> >outside the encryption ?  I.e. HMAC(DES-CBC(HMAC(data)))
> 
> Yes, I wondering the same thing.  And if one is going to authenticate both
> inside and outside, is there an opportunity to share some of the work.

Probably it's a good idea, *if* the "outside" authentication is
cheap "enough" [you tell me what "enough" means here :-]. I'd
see it mostly as anti-clogging measure.

> E.g.other than violating layering rather grossly, what else is wrong with
> computing the hash of the plain text, the hash of the ciphertext and then
> just one signature covering both hashes?  Two hash computations are still
> required, and the receiver could still elect elect to ignore the outer
> hash, but the cost would be lower and the tendency to ignore this outer
> check would be lessened.

Yeah, but where would you put that "double hash"? 

Analysis [in my understanding] would be a true hellish nightmare.

I don't really believe any work can be shared between the "outer" 
and "inner" auth...
-- 
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-

Xref: Re: Whatever happend to compression? J. Alves Foss 2nd account
Xref: Re: Whatever happend to compression? Joe Konczal
Xref subject previous
Xref subject next


Matt Holdrege/Ascend/US writes:
> A few thoughts.
> 
> In general, compression is nice in that it randomizes the data first, 
> then encryption further scrambles the bits making it harder for 
> anyone to make sense of it. It's another roadblock to the bad guy.

Any compression scheme you can reverse doesn't randomize the data in
any meaningful sense. The reason to want compression is to reduce
bandwidth, not for security.

> Compression should happen before encryption since compression
> works better on raw data than on encrypted data.

Compression should not work at all on encrypted data since encrypted
data should be essentially random to anyone without the key. That
implies incompressable.

Perry

	For info, here is the reference for the compression control protocol
which has been mentioned recently.

	Our experience with IPSEC protocols over classic 28.8k dialup PPP
links suggests that payload compression is a must.

Martin


>----------------Begin Forwarded Message----------------<

Date: Thu, 23 May 96 09:26:37 -0400
From: Internet-Drafts@CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pppext-stacker-07.txt
To: IETF-Announce@
Cc: ietf-ppp@MERIT.EDU

A Revised Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Point-to-Point Protocol 
Extensions Working Group of the IETF.                                      

Note: This revision reflects comments received during the last call period.

       Title     : PPP Stac LZS Compression Protocol                       
       Author(s) : R. Friend, W. Simpson
       Filename  : draft-ietf-pppext-stacker-07.txt
       Pages     : 14
       Date      : 05/22/1996

The Point-to-Point Protocol (PPP) [1] provides a standard method for 
transporting multi-protocol datagrams over point-to-point links.  
         
The PPP Compression Control Protocol [2] provides a method to negotiate and
utilize compression protocols over PPP encapsulated links.           

This document describes the use of the Stac LZS data compression algorithm, 
with single or multiple compression histories, for compressing 
PPP encapsulated packets.                                                                   

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-pppext-stacker-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-stacker-07.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 (193.205.245.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-pppext-stacker-07.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.
>----------------End Forwarded Message----------------<


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

Xref: Re: Whatever happend to compression? Phil Karn
Xref subject previous
Xref subject next

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

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

   Well, we could certainly add compression as an optional ESP transform,
   but it does seem to me that the widespread use of compression at the
   application layer may render this moot in the majority of cases. 

There's no application-layer compression to speak of in:

	http
	pop
	smtp
	telnet

All of these mostly transport text, which is eminently compressible.

   Compressing at the application layer does have the significant
   advantage of saving bandwidth all along the network path, not just
   in the part that's encrypted with ESP (assuming tunnel mode
   operation, which I expect to be IPSP's primary use in the near
   term).

If the primary use of tunnel mode is for "road warriors" stringing up
a tunnel to the home office, the "last hop" from the other tunnel
endpoint to the application server will probably be over a LAN, which
has effectively infinite bandwidth compared with 28.8k or even ISDN..

						- Bill




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

iQCVAwUBMaSPpVpj/0M1dMJ/AQE3vgP9HVrw0q77Gziay2liMvXQa376Q4lnAtvd
2ua1t791PFcEdmUcpeMe8aE/Uv8aYOxYU/iJi9NLlxMupl81XQJiZkOswfz31zQy
J/493J6pdWUbgr4rFzKfcQtfbVf/oUMFPZ1dZOHc9xAaaikdEQp0gju0+HnYs9ld
5UGg+r+mR6g=
=ezXw
-----END PGP SIGNATURE-----

Xref subject previous
Xref subject next

> 
> 
> Matt Holdrege/Ascend/US writes:
> > A few thoughts.
> > 
> > In general, compression is nice in that it randomizes the data first, 
> > then encryption further scrambles the bits making it harder for 
> > anyone to make sense of it. It's another roadblock to the bad guy.
> 
> Any compression scheme you can reverse doesn't randomize the data in
> any meaningful sense. The reason to want compression is to reduce
> bandwidth, not for security.
> 
> > Compression should happen before encryption since compression
> > works better on raw data than on encrypted data.
> 
> Compression should not work at all on encrypted data since encrypted
> data should be essentially random to anyone without the key. That
> implies incompressable.
> 
> Perry
> 

Xref: Re: Whatever happend to compression? Tatu Ylonen
Xref subject previous
Xref subject next

>There's no application-layer compression to speak of in:

	http
True, though most HTML documents transferred with HTTP aren't particularly
large. GIF and JPEGs transferred with HTTP are already compressed.

	pop
	smtp

I've been saying for some time that these ought to be replaced with a
"mailbag" protocol which would make life for road warriors much more
pleasant.

	telnet

This is hard to compress since the packets are already so small to
begin with, and the traffic is fairly low speed anyway.

I'm not disputing the usefulness of compression below the application
layer, but I do think that the payback may not be as great as you
might think.

Phil

Xref subject previous
Xref subject next


>>    If the primary use of tunnel mode is for "road warriors" stringing up
>>    a tunnel to the home office, the "last hop" from the other tunnel
>>    endpoint to the application server will probably be over a LAN, which
>>    has effectively infinite bandwidth compared with 28.8k or even ISDN..

Agreed.  Furthermore, the use of tunneled-mode encryption eliminates 
any benefit from network or link level compression (e.g. modem-based) 
since encrypted bytes aren't readily compressible.  It takes payload 
compression prior to encryption to draw back even with non-encrypted 
performance over slow lines. 

Ted Wobber
DEC Systems Research Center

Xref: Re: Whatever happend to compression? Phil Karn Jr
Xref subject previous
Xref subject next

> 	telnet
> 
> This is hard to compress since the packets are already so small to
> begin with, and the traffic is fairly low speed anyway.

My experience from SSH is that for terminal sessions, compression
reduces the amount of data transmitted in the server->client direction
to about a third.  That is the direction in which most of the data
flows.  You update the entire screen very often.  

    Tatu

Xref: Re: Whatever happend to compression?  Perry E. Metzger
Xref subject previous
Xref subject next


> From: "Perry E. Metzger" 
> Sender: ipsec-approval@neptune.tis.com
> Content-Length: 711
> 
> 
> Matt Holdrege/Ascend/US writes:
> > A few thoughts.
> > 
> > In general, compression is nice in that it randomizes the data first, 
> > then encryption further scrambles the bits making it harder for 
> > anyone to make sense of it. It's another roadblock to the bad guy.
> 
>Any compression scheme you can reverse doesn't randomize the data in
>any meaningful sense. The reason to want compression is to reduce
>bandwidth, not for security.

Actually, I have a paper here in front of me, "Contemporary
Cryptology:  An Introduction" by James Massey that talks about
compression and security.  The section that talks about this explains
how redundancy in the data can be used to help break "an imperfect
cipher".  Since compression removes redundance the article suggests
"...that data compression is a useful cryptographic tool."  It goes on
to imply that the practice of removing redundancy from data before
encrypting has been going on for quite some time.

I don't know if this has any relevance to current crypto algorithms
such as DES.  I just thought it was interesting that in some instances
compression is/was used to improve security.


Rob G.
rob.glenn@nist.gov

Xref subject previous
Xref subject next

>>>>> "Perry" == Perry E Metzger  writes:

    Perry> Matt Holdrege/Ascend/US writes:
    >> A few thoughts.
    >> 
    >> In general, compression is nice in that it randomizes the data
    >> first, then encryption further scrambles the bits making it
    >> harder for anyone to make sense of it. It's another roadblock
    >> to the bad guy.

    Perry> Any compression scheme you can reverse doesn't randomize
    Perry> the data in any meaningful sense. The reason to want
    Perry> compression is to reduce bandwidth, not for security.

Compression reduces the redundancy of the plaintext and increases the
unicity distance of the cypher [1, p. 12].  This makes the cryptogram
both smaller and stronger.

[1] "Contemporary Cryptography: An Introduction" by James L. Massey
(reprinted from "Contemporary Cryptography: the Science of Information
Integrity" G.J. Simmons, editor. IEEE Press, 1991), in "Cryptography
and Data Protection" J.H. van Lint and R. Tijdeman, editors,
Konninklijke Nederlandse Akademie van Wetenshappen Verhandelingen,
1992.

-- 
Joe Konczal	  		
National Institute of Standards and Technology		
Building 820, Room 410				Phone: (301) 975-3285
Gaithersburg, MD  20899  USA			  Fax: (301) 948-0279

Xref subject previous
Xref subject next


Robert Glenn writes:
> Actually, I have a paper here in front of me, "Contemporary
> Cryptology:  An Introduction" by James Massey that talks about
> compression and security.  The section that talks about this explains
> how redundancy in the data can be used to help break "an imperfect
> cipher".  Since compression removes redundance the article suggests
> "...that data compression is a useful cryptographic tool."  It goes on
> to imply that the practice of removing redundancy from data before
> encrypting has been going on for quite some time.

The problem is the way that many modern compression algorithms work,
they leave lots of nearly known plaintext in the data stream. I don't
know that this can be well exploited, but I suspect it can.

Perry

Xref subject previous

Ref:  Your note of Tue, 21 May 1996 12:13:04 PDT

I missed the "quick survey" (I was away from my email),
anyway I want to repeat my opinion on this issue.

Based on the message I sent to this list on May 8
I support using HMAC-MD5 for AH and ESP+AH.

(I do this with my hat of "implementer" and the recognition of the
need for best possible performance rather than with my more conservative hat
of "pure cryptographer").

I recommend adding the following paragraph (or any correct English-variant
of it) to the documents defining HMAC-MD5 as the default transform:

   The currently known cryptanalytic results on MD5 do not indicate
   a practical weakness of MD5 for its use with the HMAC construction.
   Due to this fact and the performance advantages of MD5 over other
   alternatives (e.g., SHA-1) this document defines MD5 as the basic hash
   function to be used with HMAC. However, implementers need to be aware
   that future cryptographic developments may call for the replacement of
   MD5 with other hash functions. In particular, implementers are strongly
   encouraged to provide support for SHA-1 with HMAC in addition to the
   required support for MD5. This will facilitate a future migration to SHA-1
   without jeopardizing interoperability.

Hugo

Xref: Re: MD5 vs. SHA-1, Selection Criteria  Craig Metz
Xref: Re: MD5 vs. SHA-1, Selection Criteria Phil Karn Jr
Xref subject next

HUGO@watson.ibm.com wrote:
{stuff deleted}
>    Due to this fact and the performance advantages of MD5 over other
>    alternatives (e.g., SHA-1)... 


I'm still not convinced that throughput performance should be a criteria for choosing a default hash function.  Just for 
reference, could someone repost their best performance times for both algorithms?  Are we talking about a factor of 2, 10, 
100?  My guess is that the difference in performance is not significant when compared with the security requirements for the 
algorithm.  And one of those requirements most certainly is "user confidence".  I think confidence in MD5 is falling rapidly 
in the cryptographic community.

The fact that HMAC-MD5 is a mode for MD5 usage that doesn't *currently* seem susceptible to the recent attack described by 
Hans Dobbertin says more for the HMAC technique than the long-term viability of MD5.

By not abandoning MD5 outright in favor of SHA-1, I think we are sending the wrong message to the not-so-crypto-saavy 
community.  What about the people that missed this discussion and use MD5 in its native mode because they don't know any 
better?

From a commercial standpoint, I believe system designers are ill-advised to specify MD5 for new systems and should embrace 
SHA-1.  Security is an endeavor that it best served by a conservative attitude.  You certainly don't see anyone trying to 
keep MD2 and MD4 around as an option.  And for good reason!  It is interesting that that conservative (sometimes radically) 
posture usually exhibited by the IPSEC group is not showing up in this case.

My position is that MD5 should be immediately abandoned for use in ANY mode.  MD5 is a cryptographic algorithm the strength 
of which is serious dispute.  It should be removed from consideration by IETF and other standards committee for use in any 
form.  I also think that implementors should re-examine the cost to move to SHA-1 versus the cost of retaining a hash 
function that probably has a limited lifetime.  And in case this applies to anyone, let me note that just because a company 
is using MD5 in a current system does not mean it is a good reason to lobby for it as an option in IETF IPSEC.  Keeping it 
around in an existing system is a business decision; it should not be a consideration for a security standard with the 
longevity this one is expected to have.

BTW, if/when SHA-1 begins to shows its age, I will be quite happy to see it retired in a timely manner.


-John Kennedy
jkennedy@cylink.com

Xref: Re: AH HMAC * Last Call  Craig Metz
Xref subject next

Steve Bellovin has asked that both AH HMAC MD5 and AH HMAC SHA be
made mandatory to implement.  If others agree/disagree, that should
be included in your WG Last Call response so Paul and I know what
the consensus is.

Thanks,

Ran
rja@cisco.com


-- 

Xref: Re: MD5 vs. SHA-1, Selection Criteria Uri Blumenthal
Xref subject previous
Xref subject next

> Date: Thu, 23 May 1996 18:00:48 -0400
> From: John Kennedy 
> Subject: MD5 vs. SHA-1, Selection Criteria
> 
> HUGO@watson.ibm.com wrote:
> {stuff deleted}
> >    Due to this fact and the performance advantages of MD5 over other
> >    alternatives (e.g., SHA-1)... 

> I'm still not convinced that throughput performance should be a
> criteria for choosing a default hash function.  Just for reference,
> could someone repost their best performance times for both algorithms?
> Are we talking about a factor of 2, 10, 100?

2. On A Sun SPARC 20/71 in SunOS 4.1.3, I have measured:

	stand-alone MD5		60 Mbps +/- 3 Mbps
	stand-alone SHA		30 Mbps +/- 2 Mbps

Note that these are not the performance expected from IP.
Our current measurements of MD5 in IPv4 depend on the
MTU:
	
	34 Mbps for 8 KB packets (upper bound on our system)
	16 Mbps for 4 KB packets
	0.6 Mbps for 1.5 KB (ethernet MTU) packets
	0.5 Mbps for Internet MTU (512 B) packets
				
> The fact that HMAC-MD5 is a mode for MD5 usage that doesn't 
> *currently* seem susceptible to the recent attack described by Hans
> Dobbertin says more for the HMAC technique than the long-term
> viability of MD5.

How is HMAC affected by the properties of the hash function used?
I have another hash which is admittedly weaker than MD5, but
which runs twice as fast as MD5, each in IPv4, for large MTUs.

For small MTUs (1KB or less), this is really moot. Three different
hashes we tested all run down around 0.3-0.5 Mbps.

Joe

PS - this is in preparation for Infocomm.

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

Hi John,

I pulled down a copy of your "draft-ietf-ipsec-esp-des-md5-01.txt".  
I wanted to pass on a comment concerning the way which in you use the IV.


It seems to be almost a tradition, but it is NOT correct in DES CBC encryption 
to use an adversarially-predictable IV (when the IV is used in the usual way).
Nor is it correct if any two IVs differ by an adversarially-predictable amount.
As a simple illustration, suppose the IV is a counter, initially 0.  Then the 
length-2 sequence of encrypted messages whose plaintext blocks are
  0, 0  
is easy to differentiate from the length-2 sequence of encrypted messages 
whose plaintext blocks are 
  0, 1
(here 0 and 1 representing integers 0 and 1 encoded into 64 bits).
Assume the adversary has a. priori. knowledge that the sequence of plaintexts
will be one of the above.  Then no "good" encryption scheme should be leaking 
which one;  a "good" encryption scheme leaks only the length of each plaintext,
even when the adversary has partial information about some of the plaintexts.


A clean way to get around this is to define DES-CBC_{k,IV}(x_1 ... x_n) by
  y_i = DES_k(y_{i-1} xor x_i)
where
  y_0 = DES_k(IV)    // instead of y_0 = IV
This would make a counter (or any other nonce) fine for an IV, releasing the
burden on the user to construct a good-enough IV.  It would also make 32 bits 
adequate for the IV.  Under this change I don't know of a cryptographic justification 
in support of having both the long and short IVs of esp-DES-IV32 and esp-DES-IV64.  
Also, you could simply consider the replay prevention field as the IV in esp-DES-HMAC-RP.
As it currently stands, you'd need to demand that the IV in esp-DES-IV32 and esp-DES-IV64 
meet a property which is extremely hard to explain to the user of this document; and in 
esp-DES-HMAC-RP it looks like the IP isn't going to be right no matter what.



Kind regards,
Phil Rogaway

Xref subject previous
Xref subject next

In message <31A4E010.3BA9@cylink.com>, you write:
>My position is that MD5 should be immediately abandoned for use in ANY mode.  
>MD5 is a cryptographic algorithm the strength 
>of which is serious dispute.  It should be removed from consideration by IETF 
>and other standards committee for use in any 
>form.

	Then I trust you'd be happy to do a quick demonstration and hijack
an AH HMAC-MD5 protected TCP connection?

	Until you can show me that, I believe that MD5 has value. The value is
that random people cannot defeat it. Maybe major governments can. When it comes
to MY traffic, *I* want to be able to make the trade-off between security and
performance.

	I strongly oppose any efforts to completely scrap HMAC-MD5 because
it's taking away a legitimate and reasonable choice for the end user.

>I also think that implementors should re-examine the cost to move to SH
>A-1 versus the cost of retaining a hash 
>function that probably has a limited lifetime.

	The flaw in this line of thinking should be obvious.

								-Craig

Xref subject previous
Xref subject next

In message <199605240147.SAA05793@puli.cisco.com>, you write:
>Steve Bellovin has asked that both AH HMAC MD5 and AH HMAC SHA be
>made mandatory to implement.  If others agree/disagree, that should
>be included in your WG Last Call response so Paul and I know what
>the consensus is.

	I fully agree.

							-Craig

Xref subject previous
Xref subject next


>Steve Bellovin has asked that both AH HMAC MD5 and AH HMAC SHA be
>made mandatory to implement.  If others agree/disagree, that should
>be included in your WG Last Call response so Paul and I know what
>the consensus is.

I believe that HMAC SHA should be mandatory and HMAC MD5 should be optional.
There may be performance reasons for preferring MD5 (although Joe
Touch's recent data imply that both hashes are poor for ethernet MTUs
due to long setup times), so MD5 certainly should not be removed as
an option.

But making it mandatory sends the wrong message in a protocol designed
to be at the heart of Internet security.  Conservative design would
dictate that only the "most secure" option be mandatory, while still
allowing implementors to make performance tradeoffs if they feel it's
in their best interests.

It appears *at this time* that the HMAC construct is powerful enough
to resist Dobbertin's attacks against MD5.  But there must be a limit
to the ability of HMAC to hide weaknesses in the hash function - I
wouldn't expect AH-HMAC-CRC16, for example, to be a useful mode :-).
Based on current knowledge, it is reasonable to predict that MD5 will
fall to a level where HMAC can't protect it before that happens to SHA.

It is true that making MD5 mandatory to implement does not take away
anyone's option to not use it.  But a standards-track protocol will be
at least referenced, if not read, by people with a wide range of
expertise.  The mandatory status of an algorithm will be easily understood
by those not necessarily familiar with the qualifications attached to
its use. For this reason MD5 should be optional.

Xref subject previous
Xref subject next

Ref:  Your note of Thu, 23 May 1996 18:00:48 -0400 (attached)


jkennedy@cylink.com wrote:
 >
 > HUGO@watson.ibm.com wrote:
 {stuff deleted}
 > And in case this applies to anyone, let me note that just because a company
 > is using MD5 in a current system does not mean it is a good reason to lobby for it as an option in IETF IPSEC.

I'd like to believe this is not directed to me and IBM; I would have found
such a suggestion personally insulting.

Hugo

PS: Well, the truth is that IBM was trying hard to buy MD5 for some time;
since the coup didn't succeed we went and bought Lotus...

Xref subject previous
Xref subject next

HUGO@watson.ibm.com wrote:
> 
> Ref:  Your note of Thu, 23 May 1996 18:00:48 -0400 (attached)
> 
> jkennedy@cylink.com wrote:
>  >
>  > HUGO@watson.ibm.com wrote:
>  {stuff deleted}
>  > And in case this applies to anyone, let me note that just because a company
>  > is using MD5 in a current system does not mean it is a good reason to lobby for it as an option in IETF IPSEC.
> 
> I'd like to believe this is not directed to me and IBM; I would have found
> such a suggestion personally insulting.
> 
> Hugo
> 
> PS: Well, the truth is that IBM was trying hard to buy MD5 for some time;
> since the coup didn't succeed we went and bought Lotus...

Hugo, 

This comment was honestly not directed to you, IBM, or anyone else in particular.  It was directed 
to the broad mailing list audience.  It is merely my own opinion on the standards development 
process and something I wanted to open up dialog on.  Personal attacks have no place in this 
process.  The fact that I happened to respond to *your* message in that thread was just a matter 
of chance.

Regards,

-John Kennedy
jkennedy@cylink.com

Xref subject previous


I'm not sure of the benefit of having multiple AH transforms mandatory
to implement.  I thought the purpose of having *one* was to insure
interoperability and to perhaps provide some kind of baseline.  Having
two will just muddy the waters, so to speak.

On that note, I think selecting HMAC SHA as mandatory and HMAC MD5
as optional is best.  

Rob G.
rob.glenn@nist.gov

Xref: Re: sha vs. md5  C. Harald Koch
Xref subject next

After reading John Kennedy's comments on SHA-1 I decided I should share a
couple of my thoughts.  I don't mean to start a fight, just to offer some
opinions...

- I think it's architecturally unsound to mandate a protocol that can't be 
exported from the U.S.  besides, I believe it violates 1825, which makes a
comment on AH always being exportable.

- I agree that I expect we should be conservative on crypto issues and an
"it seems to be still ok" attitude sounds inappropriate.

- as I recall the last time I got to fill out export paperwork there was no
check-box marked "somebody on an IETF mailing list said the NSA said in a
telephone call it was ok to export this" so I do think you need to get
paperwork for this stuff, which makes it hard to move across country
boundries, which impacts deployment, which impacts architecture, which makes
exportability a technical issue  -- sorry.

                  Rodney Thayer           ::         rodney@sabletech.com
                  Sable Technology Corp   ::              +1 617 332 7292
                  246 Walnut St           ::         Fax: +1 617 332 7970     
                  Newton MA 02160 USA     ::  http://www.shore.net/~sable
                           "Developers of communications software"

Xref: Re: MD5 vs. SHA-1, Selection Criteria Phil Karn Jr
Xref subject previous
Xref subject next


Phil Karn Jr writes:
> I'm all in favor of being conservative when it comes to choosing ciphers.
> My only concern is whether SHA-1 has had the level of intensive study as
> MD5. Would we be merely jumping from the frying pan into the fire? I really
> don't know the answer.

SHA-1 is a product of our friends at the NSA. Although I'm not always
a fan of their export policies, they do appear to usually release
algorithms of the highest possible quality.

Perry

Xref: Re: MD5 vs. SHA-1, Selection Criteria  Craig Metz
Xref subject previous
Xref subject next

Craig Metz wrote:
> ----------
> In message <31A4E010.3BA9@cylink.com>, you write:
> >My position is that MD5 should be immediately abandoned for use in ANY mode.
> >MD5 is a cryptographic algorithm the strength
> >of which is serious dispute.  It should be removed from consideration by IETF
> >and other standards committee for use in any
> >form.
> 
>         Then I trust you'd be happy to do a quick demonstration and hijack
> an AH HMAC-MD5 protected TCP connection?
>
> 
>         Until you can show me that, I believe that MD5 has value. The value is
> that random people cannot defeat it. Maybe major governments can. When it comes
> to MY traffic, *I* want to be able to make the trade-off between security and
> performance.
> ----------

I agree that MD5 still has some value, but not as much long-term value as SHA-1.  DES still has 
plenty of value, too, but new standards are moving away from DES to Triple-DES and other 
stronger algorithms.  Not because DES is broken now, but because the safety margin seems to 
be shrinking.

> ----------
> >I also think that implementors should re-examine the cost to move to SH
> >A-1 versus the cost of retaining a hash
> >function that probably has a limited lifetime.
> 
>         The flaw in this line of thinking should be obvious.
> 
>                                                                 -Craig
>-----------

I guess it wasn't obvious to me. :) If I gave you a free implementation of SHA-1 that ran as fast or faster than MD5, 
would that change your mind?

My goal was to solicit debate on Performance vs. Perceived Strength vs. Utility.  We all place different weight
on these criteria depending on the task at hand.  Finding a compromise is one of our unenviable tasks as a working 
group.

Perhaps Steve Bellovin's suggestion of making both HMAC-MD5 and HMAC-SHA1 mandatory to implement is a suitable 
compromise.  However, I think that by keeping HMAC-MD5 as an *optional* transform that we encourage the use of stronger 
cryptography over higher performance where it can be accomodated.


-John Kennedy
jkennedy@cylink.com

Xref subject previous
Xref subject next


Phil Karn Jr writes:
> Also, I'd expect that compression in ssh, which is
> the application layer, works much better than compression at a lower
> packet level since it can work on a very long stream.

I would tend to believe that as well.

Perry

Xref subject previous
Xref subject next

Phil Karn Jr wrote:
> 
> John,
> 
> I'm all in favor of being conservative when it comes to choosing ciphers.
> My only concern is whether SHA-1 has had the level of intensive study as
> MD5. Would we be merely jumping from the frying pan into the fire? I really
> don't know the answer.
> 
> Phil

I have heard things regarding the MD5-to-SHA-to-SHA1 evolution in 
conversations with cryptographers at NIST and NSA that lead me to believe 
that SHA-1 has been very thoroughly reviewed and is much more robust than 
MD5.  It is unfortunate that this review isn't as complete in the public 
arena.

-John

Xref: Re: MD5 vs. SHA-1, Selection Criteria  Perry E. Metzger
Xref subject previous
Xref subject next

John,

I'm all in favor of being conservative when it comes to choosing ciphers.
My only concern is whether SHA-1 has had the level of intensive study as
MD5. Would we be merely jumping from the frying pan into the fire? I really
don't know the answer.

Phil

Xref: Re: Whatever happend to compression?  Perry E. Metzger
Xref subject previous

>My experience from SSH is that for terminal sessions, compression
>reduces the amount of data transmitted in the server->client direction
>to about a third.  That is the direction in which most of the data
>flows.  You update the entire screen very often.  

I can buy that. Of course, you probably aren't saturating your link
(unless it's very slow) since at some point you have to read the stuff
you're receiving. Also, I'd expect that compression in ssh, which is
the application layer, works much better than compression at a lower
packet level since it can work on a very long stream. Anybody have
more precise figures on this point?

Phil

Xref subject previous
Xref subject next

In message <31A5D755.796C@cylink.com>, you write:
>If I gave you a free implementation of SHA
>-1 that ran as fast or faster than MD5, 
>would that change your mind?

	I'd be very interested in seeing this. All of the SHA code I've seen
thus far is slower than MD5. (Most of it's pretty poorly written, too.)

>Perhaps Steve Bellovin's suggestion of making both HMAC-MD5 and HMAC-SHA1 mand
>atory to implement is a suitable 
>compromise.  However, I think that by keeping HMAC-MD5 as an *optional* transf
>orm that we encourage the use of stronger 
>cryptography over higher performance where it can be accomodated.

	I think a strong argument in favor of making both mandatory is simply
the desire to have at least two options available to the end user.

	If someone posted a short program to sci.crypt tomorrow that could
recover a key from an AH HMAC-SHA stream (extremely unlikely, but just
suppose), would you want to have to wait for a vendor to get you an update (and
how long have certain vendors sat on security fixes in the past?) or would you
like to twiddle a configuration knob to change your local default? I don't know
about you, but I want to have a backup available in all cases that I can choose
to use. Just in case.

	(We should do the same for encryption...)

									-Craig

Xref subject previous
Xref subject next

In message <199605241757.NAA00859@park.interport.net>, Rodney Thayer writes:
>
> - I think it's architecturally unsound to mandate a protocol that can't be 
> exported from the U.S.  besides, I believe it violates 1825, which makes a
> comment on AH always being exportable.

Several people on the list have pointed out that MD5 and SHA-1 are covered by
the *same* U.S. export restrictions. So by your arguent, we should not
mandate either algorithm.

In message <199605241754.NAA15403@sloth.ncsl.nist.gov>, Robert Glenn writes:
>
> I'm not sure of the benefit of having multiple AH transforms mandatory
> to implement.  I thought the purpose of having *one* was to insure
> interoperability and to perhaps provide some kind of baseline.  Having
> two will just muddy the waters, so to speak.

We are creating standards here. It is not our job to dictate security v.s.
performance tradeoffs to end users; it is our job to make it possible for
end users to make these decisions for themselves. As such, mandating *both*
algorithms is the only option that will support the choice, while still
allowing full interoperability.

[ Yes, I'm for making both algorithms mandatory. ]

-- 
C. Harald Koch          | Border Network Technologies Inc.
chk@border.com          | Senior System Developer
+1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8
+1 416 368 7789 (fax)   | Madness takes its toll. Please have exact change.

  I am looking for implementations of the Photuris Session Key Management
  Protocol. Could you point me in the right direction ?

  Thanks,
  Gabi Istrail

Xref subject previous
Xref subject next

> Date: Fri, 24 May 1996 16:26:53 -0400
> From: Craig Metz 
> 
> In message <31A5D755.796C@cylink.com>, you write:
> >If I gave you a free implementation of SHA
> >-1 that ran as fast or faster than MD5, 
> >would that change your mind?

It may be surprising. Given that, according to "Applied Crypto",
2nd Ed., p445, (including recent Addenda), 
	SHA is MD4 with 
		an expanded transform, 
		an extra round, and 
		better avalanche effect
	MD5 is MD4 with 
		improved bit-hashing,
		an extra round, and
		better avalanche effect

The fact that SHA appears to be half as fast as MD5
hints that SHA's transform costs more than MD5's bit-hash
improvements, but that they are algorithmically very similar,
and that in fact SHA is slightly more work (expanded transform 
vs. different bit-hash function) than MD5. 


> 	I'd be very interested in seeing this. All of the SHA code I've seen
> thus far is slower than MD5. (Most of it's pretty poorly written, too.)

Even the MD5 code, however you consider it written, is within about
20% of it's analytical maximum, this seems moot. The overall
performance isn't going to change by 1-2 orders of magnitude.

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


--Boundary-5037284-0-0

  
  
I'll vote for SHA for all uses (AH, ESP) and hashing inside the encryption  
(ESP conf & integrity) ...  
  
  
Paul  
  
 



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

Date: 22 May 96 17:40:32
From:"Uri Blumenthal " 
To: Phil,Karn,karn@qualcomm.com
Subject: Re: Results of quick survey
Cc: ipsec@tis.com
Reply-to: uri@watson.ibm.com
X-Orcl-Application: In-Reply-To:  <199605222002.NAA29982@servo.qualcomm.com> from "Phil Karn" at May 22, 96 01:02:06 pm
X-Mailer: ELM [version 2.4 PL25]
X-Orcl-Application: Content-Type:  text
X-Orcl-Application: Sender:  ipsec-approval@neptune.tis.com
X-Orcl-Application: Precedence:  bulk


Phil Karn says:
> One point about the relative ordering of authentication and encryption.
> Even though I can now do DES pretty fast, it's still true that if you
> wrap encryption outside authentication then you still have to perform
> both algorithms to determine that the packet is bogus. 

On the other hand, it is considered best to authenticate the
"final result" date, which is the plaintext. For "proving"
that this encrypted data was "kosher" strictly speaking,
is NOT equivalent to "proving" that the decrypted data
is what was sent (i.e. it may decrypt to different
things under different keys and so on)...

Do we care? [I understand your concern about performance.]
-- 
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-



--Boundary-5037284-0-0--

--Boundary-20289777-0-0

 
>I strongly oppose any efforts to completely scrap HMAC-MD5 because .... 
 
It would seem easier to use SHA for all baseline specification under 
consideration, not because HMAC-MD5 has a specific vulnerability, but because 
we want to limit the number of choices.  So, to clarify my earlier comments to 
this poll ... HMAC-SHA should be mandatory for AH and anything else should be 
elective.  
 
Protocol      Mandatory Transform 
---------------------------------- 
AH            HMAC-SHA 
ESP           SHA-DES  (tbd - SHA inside or outside ...  DES-SHA) 
 
 
 
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 
-------------------------------------------------------------- 
  



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

Date: 24 May 96 07:27:18
From:"Craig Metz " 
To: John,Kennedy,jkennedy@cylink.com
Subject: Re: MD5 vs. SHA-1, Selection Criteria 
Cc: ipsec@tis.com
X-Orcl-Application: In-Reply-To: Your message of "Thu, 23 May 1996 18:00:48 EDT."
X-Orcl-Application: In-Reply-To:             <31A4E010.3BA9@cylink.com> 
X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved.
X-Reposting-Policy: With explicit permission only
X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com
X-Orcl-Application: Precedence: bulk


In message <31A4E010.3BA9@cylink.com>, you write:
>My position is that MD5 should be immediately abandoned for use in ANY mode.  
>MD5 is a cryptographic algorithm the strength 
>of which is serious dispute.  It should be removed from consideration by IETF 
>and other standards committee for use in any 
>form.

	Then I trust you'd be happy to do a quick demonstration and hijack
an AH HMAC-MD5 protected TCP connection?

	Until you can show me that, I believe that MD5 has value. The value is
that random people cannot defeat it. Maybe major governments can. When it comes
to MY traffic, *I* want to be able to make the trade-off between security and
performance.

	I strongly oppose any efforts to completely scrap HMAC-MD5 because
it's taking away a legitimate and reasonable choice for the end user.

>I also think that implementors should re-examine the cost to move to SH
>A-1 versus the cost of retaining a hash 
>function that probably has a limited lifetime.

	The flaw in this line of thinking should be obvious.

								-Craig


--Boundary-20289777-0-0--

Xref subject previous


--Boundary-5037796-0-0

Rodney, 
 
Your comments are not useful in the determination of the IPsec use of MD5 
versus SHA: 
 
>- as I recall the last time I got to fill out export paperwork there was no 
>check-box marked "somebody on an IETF mailing list said the NSA said in a 
>telephone call it was ok to export this" so I do think you need to get 
>paperwork for this stuff, which makes it hard to move across country 
>boundries, which impacts deployment, which impacts architecture, which makes 
>exportability a technical issue  -- sorry. 
 
My comments that you refer have never stated the above ... my point has always 
been that: 
 
 - SHA and MD5 are both export controlled 
 - SHA and MD5 when used only for integrity checks are "easy"  
   to export (as compared to encryption). 
 - export considerations are not consideration when comparing 
   the use of SHA to MD5 
 
So, please ... my e-mail box is filling with irrelevant SHA versus MD5 
comments, please be concise in this polling of comments.  Additional noise 
only obscures the legitimate points that people are trying to make. 
 
Paul 



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

Date: 24 May 96 13:57:46
From:"Rodney Thayer " 
To: ipsec@tis.com
Subject: sha vs. md5
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 2.1.2
X-Orcl-Application: Mime-Version:  1.0
X-Orcl-Application: Content-Type:  text/plain; charset="us-ascii"
X-Orcl-Application: Sender:  ipsec-approval@neptune.tis.com
X-Orcl-Application: Precedence:  bulk


After reading John Kennedy's comments on SHA-1 I decided I should share a
couple of my thoughts.  I don't mean to start a fight, just to offer some
opinions...

- I think it's architecturally unsound to mandate a protocol that can't be 
exported from the U.S.  besides, I believe it violates 1825, which makes a
comment on AH always being exportable.

- I agree that I expect we should be conservative on crypto issues and an
"it seems to be still ok" attitude sounds inappropriate.

- as I recall the last time I got to fill out export paperwork there was no
check-box marked "somebody on an IETF mailing list said the NSA said in a
telephone call it was ok to export this" so I do think you need to get
paperwork for this stuff, which makes it hard to move across country
boundries, which impacts deployment, which impacts architecture, which makes
exportability a technical issue  -- sorry.

                  Rodney Thayer           ::         rodney@sabletech.com
                  Sable Technology Corp   ::              +1 617 332 7292
                  246 Walnut St           ::         Fax: +1 617 332 7970     
                  Newton MA 02160 USA     ::  http://www.shore.net/~sable
                           "Developers of communications software"



--Boundary-5037796-0-0--

Xref subject previous
Xref subject next

>SHA-1 is a product of our friends at the NSA. Although I'm not always
>a fan of their export policies, they do appear to usually release
>algorithms of the highest possible quality.

Assuming, of course, that they are properly motivated to do so. They
certainly know as well as we do that a well designed hash function can
serve as the primitive of a strong cipher. I suspect they knew this
well before they read it in Applied Cryptography and in Dan
Bernstein's famous "snuffle" papers.

So given NSA's well-documented reluctance to distribute strong ciphers
without a back door, I am highly skeptical that they really made SHA-1
as strong as it could be.

Or maybe I'm just paranoid. But it's a point worth considering.

Phil

Xref subject previous

touch@isi.edu says:
> 2. On A Sun SPARC 20/71 in SunOS 4.1.3, I have measured:
> 
> 	stand-alone MD5		60 Mbps +/- 3 Mbps
> 	stand-alone SHA		30 Mbps +/- 2 Mbps

I have similar data (factor of 2) on Pentium under Linux-1.2.13.
-- 
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-