[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SKIP Design & Applicability Statement
[ I'm having problems receiving ipsec at incog.com, so I'm posting
this from another account -- rjs ]
Paul,
I'm sorry you haven't found value in my recent contributions to
the discussion on IPsec. I've done my best to keep my replies
focused on technical issues, and to avoid as much as possible
getting sucked into personal exchanges or unnecessarily replying
to messages. Indeed, the quote of mine you selected was taken from
a post which included a response from me to John Gilmore's issue
about CDP endpoints. This sort of discussion seems entirely
appropriate to this forum.
I was quite frankly amazed when you characterized Ashar's technical
and rather dry applicability statement as "marketing material".
I'm certain that if I actually posted anything with the slightest
whiff of real marketing hype to this list, my mailbox would quickly
be consumed with flames. But indeed, in the week since I sent that
message, I haven't received a single personal reply (other than
yours), and the only list reply was a response from Phil Karn
regarding a technical point about PFS.
> Perhaps, but so many postings on the "benefits" of a proposal could appear
> self serving.
Why is "benefits" in quotes?
I am rather upset at being censured in this way by one of the co-chairs.
I feel I have acted in good faith to respond to technical discussions on
this list. It does not seem fair that others may point out negatives in
SKIP, but we are admonished when we respond to these points. This only
adds to our concerns about the openness and impartiality of this process.
> Your many postings to this list may not be helping to advocate SKIP.
For the record, over the past 14 days I have been responsible for
9 of the 116 messages to ipsec. This includes my posting of Ashar's
applicability statement. This puts me in third place; Bob Moskowitz
and Perry Metzger tied for first, with 10 posts each.
Fri, 13 Sep 1996 14:40:39 -0700
Message-Id: <199609132140.OAA05500@cornpuffs.cisco.com>
From: Ran Atkinson <rja@cisco.com>
Date: Fri, 13 Sep 1996 14:40:39 PDT
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: ipsec@TIS.COM
Subject: Mobile IP background data
Sender: ipsec-approval@neptune.tis.com
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
rja@cisco.com
--
From: Ashar Aziz <ashar@osmosys.incog.com>
Message-Id: <199609132352.QAA19686@miraj.incog.com>
Subject: Re: IPsec Minutes from Montreal
To: ipsec@TIS.COM
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: ipsec-approval@neptune.tis.com
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: palamber@us.oracle.com, rja@cisco.com, jis@mit.edu
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 ipsec-request@neptune.tis.com 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: <323B06F1.3617@network.com>
Date: Sat, 14 Sep 1996 03:59:56 -0400
From: Jim Hughes <hughes@nsco.network.com>
Reply-To: hughes@nsco.network.com
Organization: Network Systems Corporation
X-Mailer: Mozilla 3.0b8Gold (Macintosh; I; PPC)
Mime-Version: 1.0
To: ipsec@TIS.COM, internet-drafts@cnri.reston.va.us
Cc: hughes@nsco.network.com, Steven Bellovin <smb@research.att.com>,
Bill Simpson <bsimpson@morningstar.com>,
"D. A. Wagner" <daw@cs.berkeley.edu>, Steven Keny <kent@bbn.com>,
Harry Varnis <hgv@nsco.network.com>,
James Hughes <hughes@nsco.network.com>,
Ken Hardwick <ken@morkeleb.dragonsden.sherwood.or.us>,
Paul Lambert <palamber@us.oracle.com>, Perry Metzger <perry@piermont.com>,
Ran Atkinson <rja@cisco.com>, Robert Baldwin <baldwin@rsa.com>
Subject: ietf-ipsec-esp-des-md5-03.txt
Content-Type: multipart/mixed; boundary="------------7E8465AB58A2"
Sender: ipsec-approval@neptune.tis.com
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 (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, 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
<baldwin@rsa.com>
RSA Labs.
Kevin Kingdon
<kevin@rsa.com>
RSA Labs
Hugo Krawczyk
<hugo@watson.ibm.com>
IBM Corporation
Perry Metzger
<perry@piermont.com>
Piermont Information Services
Phil Rogaway
<rogaway@cs.ucdavis.edu>
University of California at Davis
Bill Simpson
<bill.simpson@um.cc.umich.edu>
Computer Systems Consulting Services
David A Wagner
<daw@cs.berkeley.edu>
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
<ant@ankey.ru>
Ankey Engineering
Hughes September 14, 1996 [Page 11]
RFC DRAFT September 1996
The IPsec working group can be contacted through the chairs:
Ran Atkinson
<rja@cisco.com>
Cisco Systems
Paul Lambert
<PALAMBER@us.oracle.com>
Oracle Corporation
9. Editor's Address
James P. Hughes
<hughes@network.com>
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", ¤t);
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--
References: