Re: IPsec Minutes from Montreal

[Ashar Aziz <[e-mail]>]

About two weeks ago I sent the following protest regarding the
Montreal meeting minutes to the IPsec chairs.  I haven't seen
a correction posted or received any response to my message.
Since the minutes went out on the ipsec mailing list, I would
like to make my objections known here also.


-----------(Begin Forwarded Message)--------------------------
From:                  <ashar>
To:                     [e-mail], [e-mail], [e-mail]
Subject:           Re: IPsec Minutes from Montreal
Date sent:            Tue, 3 Sep 1996 17:07:12

Folks,

I would like to protest at the way the meeting minutes were
reported for the ipsec Montreal meeting. Although these
were published a few weeks ago, I have only recently had
a chance to catch up to the postings on the ipsec list.

IMHO the meeting minutes should reflect what transpired, and
not be editorialized with the minute writer's personal views
of the various proposals. 

Also, when there are competing proposals, I believe some 
consideration should be given to fairness in the way the various 
proposals are described. I refer specifically to the use of 
adjectives such as "significant overhead", "hard to implement 
and scale" and "claimed" support of multicast when describing 
SKIP. By contrast, adjectives used for ISAKMP/Oakley are 
"very general", "very flexible", etc.

In addition, I have the following very specific objections to 
the minutes, which I am submitting for the record.

> From [e-mail] Mon Aug  5 16:56 PDT 1996
> The minutes of the last IPsec Working Group were posted to the IETF weeks ago 
> and have yet to appear in the official archive.  For those of you that missed 
> attending the meeting in Montreal the minutes are attached below. 
>  
>  
> Regards, 
>  
> Paul 
> -------------------------------------------------------------- 

> 	Ashar Aziz presented SKIP.  Note the use of the SKIP header 
> between IP header and AH or ESP.  Two modes of use: the first mode has no 
> setup messages once the master keys are in place, no Perfect Forward Secrecy, 
> and has significant per-message overhead.  This mode relies on pre-positioned 
> D-H master keys from which unicast keys are derived.  The second mode uses 
> ephemeral Diffie-Hellman, with certificates, in a 4-6 message exchange, with 
> approximate PFS, anonymity, etc.  Claimed multicast mode support is based on a 
> group co-ordinator creating a group key (distribution of the private key to 
> group members is not described here and is potentially hard to implement or 
> scale) which the sender uses as the target for Diffie-Hellman computation. 
> Checkpoint, Toshiba, ETH, Sun have interoperable implementations of SKIP, 
> based on recent testing.  Some gaps in the SKIP-06 spec were uncovered, and 
> are being fixed in the next draft.  Ashar pushed for adoption of the 
> certificate discovery protocol (CDP) independent of SKIP.  Also can move CRLs 
> as well as certificates, not just X.509 certificates, but PGP too. 
>  

First, the SKIP PFS exchange requires 2 messages, not 4-6. 
This is what I presented at the talk, and is present in
the SKIP PFS I-D. 

Second, I don't understand what "approximate PFS" means. Is
this a new term? If so, I would like to be enlightened,
with perhaps some reference to the relevant literature.
In any case, this is not a term that I used, and not
something that come up during the discussion.

Third, wrt "claimed" multicast support, distribution
of group private key WAS described at the meeting. In fact more
than one way of distributing the group private key was
described. One of these used an exanding ring multicast
search, which gets around the single node responsible
for distributing the group private key. In any case, there
were no comments about "difficult to implement" or
"scaling" at the meeting, and therefore it would have
been more pleasant to not find these in the meeting minutes
(which I assume are the minute writer's personal views).

Same comment wrt "significant per message overhead" description.
This was not something that came up at the meeting, and
is a subjective evaluation. Again, I assume this is a personal
opinion of the minute writer and not something that should
be part of the meeting minutes.

Also, the group private key is not used as the target
for any Diffie-Hellman computation. This is simply a
misunderstanding of the protocol on the part of the minute
writer.

> 	Doug Maughan reported on ISAKMP.  Free software is available via MIT 
> server at http://web.mit.edu/network/isakmp.  

And finally, we also have free software which we mentioned at
the meeting, and gave the URL to. In fairness, perhaps it too 
should have been in the meeting minutes for the benefit of those 
who couldn't attend?

I can understand that the minute writers (I assume that this
included the chairs) have personal opinions about the competing 
proposals. May I request, however, that the meeting minutes not 
be used as the forum to promulgate these opinions, when they 
don't correspond to events that transpired at the meeting?

Ashar.

From: Ashar Aziz <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: IPsec Minutes from Montreal
To: [e-mail]
Date: Fri, 13 Sep 1996 16:52:16 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL24 PGP5]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

About two weeks ago I sent the following protest regarding the
Montreal meeting minutes to the IPsec chairs.  I haven't seen
a correction posted or received any response to my message.
Since the minutes went out on the ipsec mailing list, I would
like to make my objections known here also.


-----------(Begin Forwarded Message)--------------------------
From:                  <ashar>
To:                     [e-mail], [e-mail], [e-mail]
Subject:           Re: IPsec Minutes from Montreal
Date sent:            Tue, 3 Sep 1996 17:07:12

Folks,

I would like to protest at the way the meeting minutes were
reported for the ipsec Montreal meeting. Although these
were published a few weeks ago, I have only recently had
a chance to catch up to the postings on the ipsec list.

IMHO the meeting minutes should reflect what transpired, and
not be editorialized with the minute writer's personal views
of the various proposals. 

Also, when there are competing proposals, I believe some 
consideration should be given to fairness in the way the various 
proposals are described. I refer specifically to the use of 
adjectives such as "significant overhead", "hard to implement 
and scale" and "claimed" support of multicast when describing 
SKIP. By contrast, adjectives used for ISAKMP/Oakley are 
"very general", "very flexible", etc.

In addition, I have the following very specific objections to 
the minutes, which I am submitting for the record.

> From [e-mail] Mon Aug  5 16:56 PDT 1996
> The minutes of the last IPsec Working Group were posted to the IETF weeks ago 
> and have yet to appear in the official archive.  For those of you that missed 
> attending the meeting in Montreal the minutes are attached below. 
>  
>  
> Regards, 
>  
> Paul 
> -------------------------------------------------------------- 

> 	Ashar Aziz presented SKIP.  Note the use of the SKIP header 
> between IP header and AH or ESP.  Two modes of use: the first mode has no 
> setup messages once the master keys are in place, no Perfect Forward Secrecy, 
> and has significant per-message overhead.  This mode relies on pre-positioned 
> D-H master keys from which unicast keys are derived.  The second mode uses 
> ephemeral Diffie-Hellman, with certificates, in a 4-6 message exchange, with 
> approximate PFS, anonymity, etc.  Claimed multicast mode support is based
on a 
> group co-ordinator creating a group key (distribution of the private key to 
> group members is not described here and is potentially hard to implement or 
> scale) which the sender uses as the target for Diffie-Hellman computation. 
> Checkpoint, Toshiba, ETH, Sun have interoperable implementations of SKIP, 
> based on recent testing.  Some gaps in the SKIP-06 spec were uncovered, and 
> are being fixed in the next draft.  Ashar pushed for adoption of the 
> certificate discovery protocol (CDP) independent of SKIP.  Also can move CRLs 
> as well as certificates, not just X.509 certificates, but PGP too. 
>  

First, the SKIP PFS exchange requires 2 messages, not 4-6. 
This is what I presented at the talk, and is present in
the SKIP PFS I-D. 

Second, I don't understand what "approximate PFS" means. Is
this a new term? If so, I would like to be enlightened,
with perhaps some reference to the relevant literature.
In any case, this is not a term that I used, and not
something that come up during the discussion.

Third, wrt "claimed" multicast support, distribution
of group private key WAS described at the meeting. In fact more
than one way of distributing the group private key was
described. One of these used an exanding ring multicast
search, which gets around the single node responsible
for distributing the group private key. In any case, there
were no comments about "difficult to implement" or
"scaling" at the meeting, and therefore it would have
been more pleasant to not find these in the meeting minutes
(which I assume are the minute writer's personal views).

Same comment wrt "significant per message overhead" description.
This was not something that came up at the meeting, and
is a subjective evaluation. Again, I assume this is a personal
opinion of the minute writer and not something that should
be part of the meeting minutes.

Also, the group private key is not used as the target
for any Diffie-Hellman computation. This is simply a
misunderstanding of the protocol on the part of the minute
writer.

> 	Doug Maughan reported on ISAKMP.  Free software is available via MIT 
> server at http://web.mit.edu/network/isakmp.  

And finally, we also have free software which we mentioned at
the meeting, and gave the URL to. In fairness, perhaps it too 
should have been in the meeting minutes for the benefit of those 
who couldn't attend?

I can understand that the minute writers (I assume that this
included the chairs) have personal opinions about the competing 
proposals. May I request, however, that the meeting minutes not 
be used as the forum to promulgate these opinions, when they 
don't correspond to events that transpired at the meeting?

Ashar.



Message-Id: <[e-mail]>
From: Ran Atkinson <[e-mail]>
Date: Fri, 13 Sep 1996 14:40:39 PDT
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: [e-mail]
Subject: Mobile IP background data
Sender: [e-mail]
Precedence: bulk


	I was one of several people directly involved with the addition
of cryptographic authentication to the Mobile IP specification.  So
perhaps I can provide some additional background context and perspective.
 
Historical Background:
        The reason that Mobile IP talks concretely about the Mobile Node
(MN) to Home Agent (HA) control messages being authenticated is that it
is _entirely_ practical to preconfigure the Mobile-IP SA before the MN
goes mobile.

        The reason that the other Mobile IP control messages are indicated
as items that might be authenticated is that it was much less clear that
preconfiguring a Mobile-IP SA with the Foreign Agent (FA) would be
practical for either the MN or the HA.

        During the time period when this authentication mechanism was
added to Mobile IP, there was active discussion of future use of
an application-layer authenticated D-H exchange protocol to establish
the Mobile-IP SAs to/from the FA.  At that time, this technical approach
was generally believed to be reasonable and feasible to deploy and use.

Commentary:
	I believe that most folks still believe that it is reasonable and
feasible to deploy and use such a technology approach for establishing and
maintaining Mobile-IP SAs, in part because most folks seem to believe that
Mobile-IP sessions in the near term are not likely to have extremely short
IP-layer location lifetimes.

        In many cases that I'm familiar with, mobility support can be provided
at the link-layer or through a combination of link-layer and Mobile-IP
mechanisms.  The use of link-layer mechanisms (e.g.  cellular telephones,
CDPD, PCS, Iridium, INMARSAT) can significantly increase the lifetime of a
location as perceived by the IP-layer.

Ran
[e-mail]


-- 



Message-Id: <[e-mail]>
Date: Sat, 14 Sep 1996 03:59:56 -0400
From: Jim Hughes <[e-mail]>
Reply-To: [e-mail]
Organization: Network Systems Corporation
X-Mailer: Mozilla 3.0b8Gold (Macintosh; I; PPC)
Mime-Version: 1.0
To: [e-mail], [e-mail]
Subject: ietf-ipsec-esp-des-md5-03.txt
Content-Type: multipart/mixed; boundary="------------7E8465AB58A2"
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

--------------7E8465AB58A2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Here is draft -03 for the combined DES/HMAC. (When I sent the previous
draft to the working group I called it 03, but I was mistaken, it was
02. This draft is indeed number 03. Sorry for the confusion.)

These changes are relatively minor, mostly optional modes and some key
schedule changes.

Editorially, there are changes to the words MUST, SHOULD and MAY to make
the document in line with other IPSEC documents. Section numbers have
been added. References to SwIPe have also been added. Clarification that
IV_key_ does not change during the life of the key has been added. 

At the request of Steven Kent and approved by the working group:

	An optional explicit IV has been added so that hardware that can 
	not support a constant IV_key_ can be used. Use of this feature 
	will be negotiated by the key exchange. (This is over the objection
	of Steven Bellovan.)

At the request of the working group:

	The replay window size now is negotiated.

At the suggestion of Steven Bellovan:

	The keys are now fully differentiated for direction. DES, HMAC, 
	IV, and replay start values are all different for each direction.

	The pad now SHOULD be random.

At the suggestion of Anton Elin:

	The code (1<<diff) does not work on machines with 16 bit integer 
	constants (Intel) when the diff is larger than 15. Changing it to
	(1l<<diff) fixes the problem.

Thanks to all. Please CC me on any comments you want me to see :^)

jim

--------------7E8465AB58A2
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854";
x-mac-creator="522A6368"; name="esp-des-md5-03.txt"
Content-Transfer-Encoding: 7bit
Content-Description: BBEdit 3.5 Document
Content-Disposition: inline; filename="esp-des-md5-03.txt"







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


    Combined DES-CBC, HMAC and Replay Prevention Security Transform
                 <draft-ietf-ipsec-esp-des-md5-03.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 ([e-mail]) 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, authentication,
   integrity and replay prevention into a single packet format.

   This document is the result of significant work by several major con-
   tributors 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. [IB93] [IBK93]







Hughes                     September 14, 1996                   [Page 1]





RFC DRAFT                                                 September 1996



Requirements Terminology

   In this document, the words that are used to define the  significance
   of  each particular requirement are usually capitalised.  These words
   are:

   - MUST

      This word or the adjective "REQUIRED" means that the  item  is  an
      absolute requirement of the specification.

   - SHOULD

      This word or the adjective "RECOMMENDED" means  that  there  might
      exist  valid  reasons  in  particular circumstances to ignore this
      item, but the full implications should be understood and the  case
      carefully weighed before taking a different course.

   - MAY

      This word or the adjective "OPTIONAL" means that this item is tru-
      ly  optional.  One vendor might choose to include the item because
      a particular marketplace requires it or because  it  enhances  the
      product, for example; another vendor may omit the same item.

   For the purpose of this RFC, the terms conformance and compliance are
   synonymous.

1.  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 claims of privacy, integrity, authentication, and replay preven-
   tion are made in this draft. A good general text describing the
   methods and algorithm are in [Schneier95].

   Privacy is provided by DES-CBC [FIPS-46] [FIPS-46-1] [FIPS-74]
   [FIPS-81].

   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.




Hughes                     September 14, 1996                   [Page 2]





RFC DRAFT                                                 September 1996


   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.

2.  Packet Format


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




2.1.  Security Parameters Index

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

2.2.  Initialization Vector

   The use of an explicit Initialization Vector MAY be negotiated. The
   purpose of this mode is to support devices that automatically gen-
   erate IVs and can not operate using a constant IV_key_.

   This field is optional and is only used when an explicit IV is nego-
   tiated during key exchange.  This field is contains random data or
   contains the last cyphertext block of a previous packet sent or
   received.

   For the packet which the explicit IV is received, the explicit IV is



Hughes                     September 14, 1996                   [Page 3]





RFC DRAFT                                                 September 1996


   used in place of the constant IV_key_ described later in this docu-
   ment.

2.3.  Replay Prevention

   Replay Prevention is an unsigned 32 bit incrementing counter starting
   at a mutual agreed upon value (see Key Material) and is enforced to
   be within a mutually negotiated window size.

   The key (K, as described in a later section) MUST be changed fre-
   quently enough so that the counter is not allowed to return to the
   initial value; in other words, the key MUST be changed before 2^32
   packets are transmitted using this key. For a given SPI, counter
   wrapping MUST be considered to be a replay attack. (While a wrap is a
   replay attack, there is always the possibility that a packet can get
   duplicated, so the presence of a single or small number of duplicate
   packets is not an absolute indication of a replay attack.)

   The receiver MUST verify that for a given SPI the packets received
   have non-repeating (non-duplicate) counter values. This can be imple-
   mented as a simple increasing count test or the receiver MAY choose
   to accept out-of-order packets as long as it is guaranteed that pack-
   ets can be received only once. For example, an implementation can use
   a sliding receive window. If such a receive window is supported, the
   receiver MUST ensure that it will accept packets within the current
   window only once, and reject any packets it receives with a value
   that is less than the lower bound of the window.

   Negotiated window sizes of 1 and 32 are suggested and larger multi-
   ples of 32 are allowed. 1 indicates that only constantly increasing
   replay numbers are allowed and packets which have replay values less
   than the highest received are always rejected. 32 indicates that are
   within 32 of the highest received, and are guaranteed not to have
   been received before, are allowed.

   A window size of 1 MUST be supported. A value of 32 SHOULD be sup-
   ported.

   If a value of 32 is negotiated, then the most recent 32 packets are
   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. Appendix A has actual code that
   implement a 32 packet replay window and a test routine. The purpose
   of this routine is to show how it could be implemented.

2.4.  Payload

   The payload contains data that is described by the payload type



Hughes                     September 14, 1996                   [Page 4]





RFC DRAFT                                                 September 1996


   field. This field is an integral number of bytes in length; the fol-
   lowing padding and pad length fields will help provide alignment to a
   double word boundary.

2.5.  Padding

   The padding (pad bytes and pad length field) is used to align the
   following "payload type" field to end on a double word boundary (when
   counting from the start of the replay field).

   Padding bytes SHOULD be initialized with random data.

   At a minimum, the number of pad bytes added MUST be enough to align
   the payload type field on the next appropriate boundary. However, the
   sender MAY choose to include additional padding, provided that the
   alignment is maintained. In total, the sender can add 0-255 bytes of
   padding.

2.6.  Pad Length

   The pad length field indicates the number of pad bytes immediately
   preceding it. The range of valid values is 0-255, where a value of
   zero indicates that the byte immediately preceding the pad length
   field is the last byte of the payload.

2.7.  Payload Type

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

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


2.8.  HMAC Digest

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

   HMAC is a keyed algorithm, where both directions are keyed
   separately.  The implementation MUST use the HMAC_key_ as described
   in the section on keys.

3.  Encryption Transform Procedure

   CBC chaining with an constant IV_key_ is used (IV_key_I for the ini-
   tiator -> responder direction and IV_key_R for the responder -> ini-
   tiator direction). The IV_key_ remains constant for all packets send
   in this direction.




Hughes                     September 14, 1996                   [Page 5]





RFC DRAFT                                                 September 1996


   If an explicit IV is negotiated, 64 bits of random or the last
   cyphertext block of a previous packet send or receive can be used.

        IV or
       IV_key_  count|x1          x2             x3
          |        |              |              |
          |-------(+)    --------(+)    --------(+)
                   |     |        |     |        |
                -------  |     -------  |     --------
             k--| DES |  |  k--| DES |  |  k--| DES  |
                -------  |     -------  |     --------
                   |     |        |     |        |
                   |-----|        |-----|        |----...
                   |              |              |
                   y1             y2             y3



   Where count is the Replay counter. x1, x2, x3 are the plaintext (x1
   is 32 bits, all others are 64 bits). y1, y2, y3 are the ciphertext.

   This transformation is comprised of the following 3 steps.

      1. Taking the data and encapsulating it with the SPI, IV (if
      present), count, pad, pad length, and payload type.

      2. Calculating the HMAC using the HMAC_key_ and creating the dig-
      est from the SPI, IV (if present), count, data, pad, pad length,
      and payload type and placing the result into the HMAC digest
      field.

      3. Encrypting the count, data, pad, pad length, payload type, and
      HMAC digest using DES and the appropriate DES_key_ and IV_key_.
      (Note that the first DES block is a combination of the count and
      the first word of plaintext.)


4.  Decryption Transform Procedure

   CBC chaining with an constant IV_key_ is used. if an IV is present in
   the packet, then the IV_key_ is not used and is replaced by the IV.










Hughes                     September 14, 1996                   [Page 6]





RFC DRAFT                                                 September 1996



         IV or
        IV_key_    y1             y2             y3
          |        |              |              |
          |        |------        |------        |----...
          |        |     |        |     |        |
          |     -------  |     -------  |     --------
          |  k--| DES |  |  k--| DES |  |  k--| DES  |
          |     -------  |     -------  |     --------
          |        |     |        |     |        |
          |-------(+)    |-------(+)    |-------(+)
                   |              |              |
              (count|x1)          x2             x3



   Decryption is comprised of the following 4 steps.

      1. (Optional step) Decrypt the first bock of data using the
      appropriate DES_key_ and IV_key_ (or IV) and then do a quick "san-
      ity check" of the count. If the count has decreased below the win-
      dow or has increased by more than 65k, then it is safe to discard
      this packet as either a replay, non-authentic or too old. If the
      count is within 65K, then the probability that the packet is
      authentic is 65535/65536. (The following replay check and HMAC
      check are both still required).

      2. Decrypt the count (if not already done), data, pad, pad length,
      and payload type using DES and the appropriate DES_key_ and
      IV_key_ (or IV).

      3. Calculate the HMAC using the HMAC_key_ and create the digest
      from the SPI, IV (if present) count, data, pad, pad length, and
      payload type and checking the result at digest at the end of the
      packet. If the digest is incorrect, discard the packet.

      4. Check the count using the window algorithm discussed above. If
      the packet is duplicate or too old, discard the packet.


5.  Key Material

   The key K is provided by the key management layer. This key is used
   to derive the symmetric keys, they are:

      DES_Key_I is the DES key for traffic from the initiator ->
      responder.




Hughes                     September 14, 1996                   [Page 7]





RFC DRAFT                                                 September 1996


      DES_Key_R is the DES key for traffic from the responder -> initia-
      tor.

      HMAC_Key_I is the key for the HMAC Algorithm for traffic from the
      initiator -> responder.

      HMAC_Key_R is the key for the HMAC Algorithm for traffic from the
      responder -> initiator.

      IV_key_I is used to stop code book attacks on the first block for
      traffic from the initiator -> responder.

      IV_key_R is used to stop code book attacks on the first block for
      traffic from the responder -> initiator.

      RP_key_I is the initial value and wrap point for the replay
      prevention field for traffic from the initiator -> responder.

      RP_key_R is the initial value and wrap point for the replay
      prevention field for traffic from the responder -> initiator.

   The vertical bar symbol "|" is used to denote concatenation of bit
   strings.

   MD5(x|y) denotes the result of applying the MD5 function to the con-
   catenated bit strings x and y.

   Truncate(x,n) denotes the result of truncating x to its first n bits.























Hughes                     September 14, 1996                   [Page 8]





RFC DRAFT                                                 September 1996


       DES_Key_I  = Truncate(MD5( D_Pad_I | K ),64)
       DES_Key_R  = Truncate(MD5( D_Pad_R | K ),64)
        IV_Key_I  = Truncate(MD5( I_Pad_I | K ),64)
        IV_Key_R  = Truncate(MD5( I_Pad_R | K ),64)
      HMAC_Key_I  =          MD5( H_Pad_I | K )
      HMAC_Key_R  =          MD5( H_Pad_R | K )
        RP_Key_I  = Truncate(MD5( R_Pad_I | K ),32)
        RP_Key_R  = Truncate(MD5( R_Pad_R | K ),32)


   where each _Pad_is 512 bit string.

      D_Pad_I = 0x5C repeated 64 times.
      D_Pad_R = 0x3A repeated 64 times.
      I_Pad_I = 0xAC repeated 64 times.
      I_Pad_R = 0x55 repeated 64 times.
      H_Pad_I = 0x53 repeated 64 times.
      H_Pad_R = 0x3C repeated 64 times.
      R_Pad_I = 0x35 repeated 64 times.
      R_Pad_R = 0xCC repeated 64 times.


   (Implementation note, The 16 byte intermediate residuals can be  pre-
   calculated from these constants and stored to reduce processing over-
   head).

6.  Security Considerations

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

   The implications of the size of K can be found in [Blaze96].

7.  References

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

   [FIPS-46] US National Bureau of Standards, "Data Encryption Stan-
   dard", Federal Information Processing Standard (FIPS) Publication 46,
   January 1977.








Hughes                     September 14, 1996                   [Page 9]





RFC DRAFT                                                 September 1996


   [FIPS-46-1] US National Bureau of Standards, "Data Encryption Stan-
   dard", Federal Information Processing Standard (FIPS) Publication
   46-1, January 1988.

   [FIPS-74] US National Bureau of Standards, "Guidelines for Implement-
   ing and Using the Data Encryption Standard", Federal Information Pro-
   cessing Standard (FIPS) Publication 74, April 1981.

   [FIPS-81] US National Bureau of Standards, "DES Modes of Operation"
   Federal Information Processing Standard (FIPS) Publication 81,
   December 1980.

   [Krawczyk96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC-MD5:
   Keyed-MD5 for Message Authentication", work-in-progress,
   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), work-in-progress,
   http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec-
   isakmp-04.txt, February, 1996

   [Orman96] Orman, H., "The Oakley Key Determination Protocol", work-
   in-progress, 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 Pro-
   tocol", 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

   [Blaze96] Blaze M., Diffie, W., Rivest, R., Schneier, B., Shimomura,
   T., Thompson, E., Wiener, M., "Minimal Key Lengths for Symmetric
   Ciphers to Provide Adequate Commercial Security",
   http://theory.lcs.mit.edu/~rivest/bsa-final-report.ascii, January,
   1996

   [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementa-
   tion of Network-layer Security Under Unix", Proceedings of USENIX
   Security Symposium, Santa Clara, CA, October 1993.







Hughes                     September 14, 1996                  [Page 10]





RFC DRAFT                                                 September 1996


   [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-
   Layer Security for IP", presentation at the Spring 1993 IETF Meeting,
   Columbus, Ohio.

8.  Acknowledgements

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

        Robert W. Baldwin
        <[e-mail]>
        RSA Labs.

        Kevin Kingdon
        <[e-mail]>
        RSA Labs

        Hugo Krawczyk
        <[e-mail]>
        IBM Corporation

        Perry Metzger
        <[e-mail]>
        Piermont Information Services

        Phil Rogaway
        <[e-mail]>
        University of California at Davis

        Bill Simpson
        <[e-mail]>
        Computer Systems Consulting Services

        David A Wagner
        <[e-mail]>
        University of California at Berkeley


   In addition, the contributions of the entire IPSEC Working Group  are
   acknowledged.  Additional  thanks for finding the missing "l"s in the
   window code to:


        Anton Elin
        <[e-mail]>
        Ankey Engineering





Hughes                     September 14, 1996                  [Page 11]





RFC DRAFT                                                 September 1996



   The IPsec working group can be contacted through the chairs:

        Ran Atkinson
        <[e-mail]>
        Cisco Systems

        Paul Lambert
        <[e-mail]>
        Oracle Corporation


9.  Editor's Address

        James P. Hughes
        <[e-mail]>
        Network Systems Corporation


































Hughes                     September 14, 1996                  [Page 12]





RFC DRAFT                                                 September 1996


Appendix A

   This is a routine that implements a 32 packet window. This is intend-
   ed on being an implementation sample.

   #include <stdio.h>
   #include <stdlib.h>
   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 = (bitmap << diff) | 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 & (1l << diff)) return 0; /* this packet already seen */
       bitmap |= (1l << diff);  /* mark as seen */
       return 1;               /* out of order but good */
   }














Hughes                     September 14, 1996                  [Page 13]





RFC DRAFT                                                 September 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):\n");
    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:%lu\n", bitmap, lastSeq);
    printf("Input value to test (current):\n");

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

























Hughes                     September 14, 1996                  [Page 14]



--------------7E8465AB58A2--




Date: Sun, 15 Sep 1996 15:02:10 -0500 (CDT)
From: BEZALEL GAVISH <[e-mail]>
Subject: CFP - 5th Inter Conf on Telecommunication Systems
To: list2: ;, [e-mail]
Message-Id: <[e-mail]>
X-Vms-To: IN%"list2"
X-Vms-Cc: GAVISHB
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Sender: [e-mail]
Precedence: bulk

								    TSM97CFP
		       C A L L	 for  P A P E R S
       5th International Conference on Telecommunication Systems
			Modelling and Analysis
			  March 20-23, 1997
			    Nashville, TN

Sponsored by:	  American Telecommunications Systems Management Association
		  BellSouth Telecommunications, Inc.
		  IFIP Working Group 7.3 "Computer system modelling and
					  performance evaluation"
		  INFORMS Technical Section on Telecommunications
		  INFORMS College of Information Systems


The 5th International Conference on Telecommunication Systems - Modelling and
Analysis will be held in Nashville on March 20-23, 1997.  The conference will
build on the tradition of the earlier conferences with a few changes in format
due to the new conference location.  The general idea is to limit the number of
participants, concentrate on a few topics, present new problems and problem
areas, encouraging informal interaction and exchanges of ideas.  The objective
is to advance the state of the modelling and analysis in telecommunications by
stimulating research activity on new and important problems.

The conference will be divided into segments with each segment devoted to a
specific topic.  This will allow for little conflict between segments.	All
papers will be screened by the Program Committee to ensure the quality of
presentations.	A decentralized paper handling process will be used.  The
Program Committee has been divided along geographical regions with a separate
Program Subcommittee assigned to each region.  Abstracts and papers should be
submitted directly to the Program Committee Chair of the appropriate area.  It
is expected that this will expedite the paper review process.  In response to
suggestions made by last year's participants, social and cultural activities
will be included in the 1997 agenda.  The conference will be held at two sites,
Thursday and Friday meetings will take place at the Tenessee Economic
Development Center at the BellSouth Tower in downtown Nashville.  The Saturday
and Sunday meeting will be held at the Union Station hotel (see description at
the end of the message).

Lead Speakers and Keynote speakers include:

Erol Gelenbe, Andrew Viterbi, Paul Kuehn.


The Chairmen of the geographic Program Committees are:


---Australia, New Zealand and South East Asia:
		Prof. Richard Harris
Department of Communication and Electronic Engineering
Royal Melbourne Institute of Technology
723 Swanston Street
Carlton, Victoria
Australia, 3001
Phone  :  [phone] (CATT), 61 3 9660 2457 (RMIT)
Fax    :  [phone] (CATT), 61 3 9660 1060 (RMIT)
E-Mail :  [e-mail]


---Europe:  (except Scandinavia and Baltic states)
		Prof. Guy Pujolle
Laboratoire PRiSM
Universite de Versailles - Saint Quentin
45 avenue des Etats-Unis
78 035 Versailles Cedex
FRANCE
Phone  :  [phone]
Fax    :  [phone]
E-Mail :  [e-mail]


---Europe:  (Scandinavia and Baltic states)
		Dr. Johan M. Karlsson
Department of Communication Systems
Lund Institute of Technology
P.O. Box 118
S-221 00 Lund
Sweden
E-Mail :  [e-mail]


---North America:
		Prof. June S. Park
Department of Management Sciences
The University of Iowa
108 Pappajohn Business Administration Bldg.
Iowa City, IA  52242-1000
USA
Phone  :  [phone]
Fax    :  [phone]
E-Mail :  [e-mail]


---North East Asia:
		Prof. Yutaka Takahashi
Graduate School of Information Science
Nara Institute of Science and Technology
Nara 630-01, Japan
Phone  :  [phone]
Fax    :  [phone]
E-Mail :  [e-mail]


---South and Central America:
		Dr. Ernesto Santibanez-Gonzalez
Escuela de Ingenieria Industrial
Universidad Catolica, Valparaiso
Av. Brasil 2147
Valparaiso
Chile
Phone  :  [phone]
Fax    :  [phone]
E-Mail :  [e-mail]


---Chairman of the Economics track:
		Prof. William W. Sharkey
Federal Communications Commission
1919 M Street
Washington, DC	20554
USA
Phone  :  [phone]
Fax    :  [phone]
E-Mail :  [e-mail]


---All other geographic areas:
		Prof. Bezalel Gavish
Owen Graduate School of Management
Vanderbilt University			Tel: [phone]
401 21st Avenue South			FAX: [phone]
Nashville, TN  37203			Email:	[e-mail]


Listed below are some of the potential segments:

-- Configuration of ATM networks
-- Internet and its Impact on Commerce
-- Internet and Intranet
-- Standards
-- Topological Design and Network Configuration Problems
-- Design and Analysis of Local Access Networks and Outside Plant Problems
-- Low Earth Orbit Satellite Communication Systems
-- Cellular Systems and PCS Modelling and Configuration
-- Time Dependent Expansion of Telecommunication Systems
-- Designing Networks for Reliability and Availability
-- Network Design Problems in Gigabit and Terabit Networks
-- LAN, WAN Global Network Interconnection
-- ATM, ISDN, BISDN Modeling and Analysis Issues
-- Artificial Intelligence/Heuristics in  Telecommunication Systems
-- Group Decision Support Systems
-- Quantitative Methods in Network Management
-- Pricing and Economic Analysis of Telecommunications
-- Impact of Telecommunications on Industrial Organization
-- Performance Evaluation of Telecommunication Systems
-- Distributed Computing and Distributed Data Bases
-- Security and Privacy Issues in Telecommunications
-- Virtual Reality, Multimedia and their Impact

The Program Committee is open to any ideas you might have regarding additional
topics or format of the conference.  The intention is whenever possible, to
limit the number of parallel sessions to two.  The conference is scheduled over
a weekend so as to reduce teaching conflicts for academic participants,
enabling participants to take advantage of weekend hotel and airfare rates and
of the many events that take place in the downtown area.

Due to the limit on the number of participants early conference and hotel
registration is recommended.  The Union Station Hotel is the official hotel of
the conference.  To ensure your participation, please use the following steps:

1.  Send to the appropriate Program Committee Chair by October 1, 1996, a paper
(preferable), or titles and extended abstracts for potential presentations to
be considered for the conference.  Sending more than one extended abstract is
encouraged, enabling the Program Committee to have a wider choice in terms of
assigning talks to segments.  Use E-mail to expedite the submission of titles
and abstracts.

2.  Use the forms at the end of this message to preregister for the conference
and the hotal.	Let us also know if you would like to have a formal duty during
the conference as:  Session Chair, or Discussant.

3.  You will be notified by December 1, 1996, which abstract/s have been
selected for the conference.  Detailed instructions on how to prepare camera
ready copies will be sent to authors of accepted presentations.  January 30,
1997, is the deadline for sending a final version of the paper.  Participants
will receive copies of the collection of papers to be presented.  All papers
submitted to the conference will be considered for publication in the
"Telecommunication Systems" Journal.

The Program Committee looks forward to receiving your feedback/ideas.  Feel
free to volunteer any help you can offer.  If you have suggestions for Segment
Leaders (i.e., individuals who will have a longer time to give an
overview/state of the art talk on their segment subject) please E-mail them to
Prof Gavish.  Also, if there are individuals whose participation you view as
important, please send their names and E-mail addresses to the Program
Committee Chairman, or forward to them a copy of this message.

I look forward to a very successful conference.

Sincerely yours,
Bezalel Gavish
-------------------------------------------------------------------------------
				 Cut Here
-------------------------------------------------------------------------------
	Fifth International Conference on Telecommunication Systems
			 Modelling and Analysis
			   REGISTRATION FORM	       Date: __________________
   Dates: March 20, 1997 (afternoon) to March 23, 1997

       Name: ________________________________________ Title: __________________

Affiliation: __________________________________________________________________

    Address: __________________________________________________________________

	     __________________________________________________________________

      Phone: ____________________________  FAX: _______________________________

     E-mail: __________________________________________________________________

Potential Title of Paper(s): __________________________________________________

	   ____________________________________________________________________


I would like to Volunteer as			  Comments
A Session Chair   :  Yes  No   ________________________________________________
A Discussant	  :  Yes  No   ________________________________________________
Organize a Session:  Yes  No   ________________________________________________
			       ________________________________________________



REGISTRATION RATES and DEADLINES

				 Last Applica-	 Academic  Industry  Corporate
				 ble  Date	 Rate	   Rate      Rate
				---------------  --------  --------  --------
1. Preregistration	  Until   Dec. 9, 1996	  $ 400     $ 500    $1,300
2. Registration 	  Until   Jan. 15, 1997   $ 500     $ 600    $1,300
3. On Site Registration   After   Jan. 15, 1997   $ 600     $ 750    $1,500

As part of the conference registration dues you can become a member of the
"American Telecommunication Systems Management Association" . Please mark an X
in the following entry if you wish to become an ATSMA member.

____ Yes, I wish to become an ATSMA member.
____ No, I don't wish to become an ATSMA member.

Mail your registration form and check to:

	       Mrs. Dru Lundeng
	       Owen Graduate School of Management
	       Vanderbilt University
	       401 21st Avenue, South
	       Nashville, TN 37203, USA

The check should be endorsed to:
	       ATSMA, Inc.


Refund Policy: Half refund, for requests received by February 1, 1997.
	       No refund after February 1, 1997.
-----------------------------------------------------------------------------


If you have any questions regarding the conference, please contact Dru Lundeng
at 615-322-3694 or through E-mail at [e-mail].



			   Hotel Reservation


A block of rooms has been reserved at Union Station Hotel for the Conference
participants.  Please make your hotel arrangements early, to insure getting a
room at the special conference rate.  You will need to mention that you are a
participant of the Telecommunication Systems Conference to receive the best
price.	Our advice is to make your reservations as soon as possible.  Hotel
rooms will be released from the Telecommunication Systems Conference blocks on
February 15, 1997, so please be sure and reserve your rooms before February
15th.

Union Station Hotel
1001 Broadway
Nashville, TN  37203
Phone:	[phone] or 1-800-331-2123
Fax:  [phone]
$99.00	 Single or Double Occupancy Room
$109.00  Triple or Quad Occupancy Room

- Rates are subject to state and local tax, which is now 12.25 percent.

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

			    Union Station Hotel
			  Reservation Request Form

Name of Conference: Telecommunication Systems Conference
     Arrival Date _________________	   Departure Date __________________

Guest Name:__________________________________________________

Address   :__________________________________________________

	  :__________________________________________________

Phone No. :__________________________________________________


A one night deposit should be enclosed to guarantee the reservation

Payment Method:  Check	   Check No.______________    Amount____________

		 Credit Card Type______________   No.____________________
		 Expiration Date____________

Type of Room:  King	  or	 2 Double Beds
	       Smoking	  or	 Nonsmoking


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



		      Union Station Hotel Description
			  A Grand Heritage Hotel
			  Features and Amenities

In the heart of "Music City" stands a hotel with the personality of an intimate
friend...Union Station Hotel.

The heartbeat of Nashville has always been strongest at the Union Station.
>From the grand opening in 1890 until the decline of rail travel in the 50s no
other building in the city has been the site of more commercial activity and
human drama.  Nearly a century later, the Union Station Hotel, a National
Historic Landmark, is again an integral part of life in Music City


124 guest rooms including 13 suites on seven levels are architecturally
distinctive and capture the historic elegance of a bygone era.	Stained glass,
glittering gold leaf and newly silvered mirrors scatter reflections of an era
which has endured for nearly a century.  4 conference rooms with over 10,000
square feet of flexible meeting and banquet space to accommodate groups of 5 to
200.

* Arthur's Restaurant - gourmet dining, the recipient of the Mobil Travel
Guide's Four Stars, Wine Spectator's Award of Excellence, and the Travel
Holiday Award.

* Broadway Bistro - casual dining open for lunch and dinner.

Selected in the 1996 Zagat Survey as the city's best overall and best dining
hotel.

Heritage Executive Level with enhanced amenities ideal for the business and
leisure traveler including concierge service, continental breakfast and evening
cocktails Monday through Friday.

   *  Valet parking.
   *  Complimentary limo service in downtown Nashville.
   *  Complimentary newspaper.
   *  Blocks from downtown area, famed Music Row, Vanderbilt
      University and Convention Center.

Recommended Airport:  Nashville Metro Airport, 7 miles to the East.
Transportation:  Grayline Shuttle to the hotel.  $8.00 one way, $14.00 round
trip.

Complimentary shuttle service within three mile radius of hotel for conference
guests.




-------------------------------------------------------------------------------
Bezalel Gavish
Owen Graduate School of Management
Vanderbilt University
Nashville, TN, 37203
Bitnet: GAVISHB@VUCTRVAX
Internet: [e-mail]
Tel: [phone]                Home: [phone]
FAX: [phone]
-------------------------------------------------------------------------------