Network Working Group P Karn
Internet Draft Qualcomm
W A Simpson
DayDreamer
expires in six months April 1996
Photuris Schemes and Privacy Protection
draft-simpson-photuris-schemes-00.txt
Status of this Memo
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute work-
ing 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 refer-
ence 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
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.
Karn & Simpson expires in six months [Page i]
DRAFT Photuris Schemes April 1996
1. Party Privacy Protection
Although each IP datagram carries a cleartext IP Destination, the
ultimate destination can be hidden by "laundering" it through an
encrypted tunnel. The IP Source could be hidden in the same manner.
If the IP Source has been dynamically allocated, it provides no use-
ful information to an eavesdropper.
This leaves the identifying information that the parties send during
the Photuris [Firefly] Identification Exchange. One would often like
to deny this information to an eavesdropper, especially when this
would reveal the location of a mobile user.
The identification can be easily protected by encrypting the Identi-
fication Exchange with the shared-secret just established. This
keeps a passive eavesdropper from learning the identities of the par-
ties, either directly from the certificates or by checking signatures
against a known database of public keys.
The scheme is not foolproof. By posing as the Responder, an active
attacker could trick the Initiator into revealing its identity.
However, this active attack is considerably more difficult than pas-
sive vacuum-cleaner monitoring. As in the Clogging Defense, this
attack requires appropriating a physical link, or subverting Internet
routing.
Unless the attacker can steal the private/secret key belonging to the
Responder, the Initiator will discover the deception when verifying
the Identification Exchange.
Nota Bene:
It is not possible for an Initiator to similarly trick the Respon-
der. The Responder will verify the Initiator Identification
before returning its own identity.
This facility is distinct from party anonymity, where one of the
parties refuses to identify itself to the other. Mutual party
identification is fundamental to the security of this protocol.
1.1. Identification Exchange
Identification Exchange messages are encrypted and decrypted using
the Privacy-Method indicated by the current Scheme-Choice (see "Addi-
tional Exchange Schemes").
The Privacy-Method specified key generation cryptographic hash is
Karn & Simpson expires in six months [Page 1]
DRAFT Photuris Schemes April 1996
used to create a special privacy session-key. This hash is calcu-
lated over the following concatenated values:
+ the computed shared-secret,
+ the Initiator Cookie,
+ the Responder Cookie,
+ the SPI Owner (receiver) Exchange-Value,
+ the SPI User (sender) Exchange-Value,
+ the computed shared-secret again.
Since the order of the Exchange-Value fields is different in each
direction, the resulting privacy session-key will usually be differ-
ent in each direction.
When a larger number of keying-bits are needed than are available
from the specified cryptographic hash, these keying-bits are gener-
ated by duplicating the trailing shared-secret, and recalculating the
hash. That is, the first hash will have one trailing copy of the
shared-secret, the second hash will have two trailing copies of the
shared-secret, and so forth.
Implementation Notes:
This is separate from any encryption method specified for Security
Associations.
The fields protected, the length of the Padding (if any), and
other details are dependent on the Privacy-Method. See the "Pri-
vacy Methods".
The hash of the Exchange-Value includes both the Size and Value
fields.
1.2. SPI Messages
SPI Messages are encrypted and decrypted in the same fashion speci-
fied for Identification Exchange messages.
2. Additional Exchange Schemes
The packet format and basic facilities are already defined for Pho-
turis [Firefly].
These optional exchange schemes are specified separately, and no sin-
gle implementation is expected to support all of them.
Karn & Simpson expires in six months [Page 2]
DRAFT Photuris Schemes April 1996
Up-to-date values for the Exchange Schemes will be specified in the
most recent "Assigned Numbers" [RFC-1700]. This document defines the
following values:
(3) Implementation Optional. Any modulus (p) with a recommended
generator (g) of 3. The modulus is contained in the Exchange
Scheme Value field in the list of Offered-Schemes.
The "Identification Exchange" and "SPI Messages" Privacy-Method
is "not protected".
The "SPI Messages" Validity-Method is "MD5-DP".
(4) Implementation Optional. Any modulus (p) with a recommended
generator (g) of 2. The modulus is contained in the Exchange
Scheme Value field in the list of Offered-Schemes.
The "Identification Exchange" and "SPI Messages" Privacy-Method
is "DES-CBC with secret IV".
The "SPI Messages" Validity-Method is "MD5-DP".
(5) Implementation Optional. Any modulus (p) with a recommended
generator (g) of 5. The modulus is contained in the Exchange
Scheme Value field in the list of Offered-Schemes.
The "Identification Exchange" and "SPI Messages" Privacy-Method
is "not protected".
The "SPI Messages" Validity-Method is "MD5-DP".
(6) Implementation Optional. Any modulus (p) with a recommended
generator (g) of 3. The modulus is contained in the Exchange
Scheme Value field in the list of Offered-Schemes.
The "Identification Exchange" and "SPI Messages" Privacy-Method
is "DES-CBC with secret IV".
The "SPI Messages" Validity-Method is "MD5-DP".
(7) Implementation Optional. Any modulus (p) with a variable gen-
erator (g). The generator has the same number of significant
bits as the modulus. The modulus is followed by (concatenated
to) the generator, and the variable number of significant bits
are contained in the Exchange Scheme Value field in the list of
Offered-Schemes.
The "Identification Exchange" and "SPI Messages" Privacy-Method
Karn & Simpson expires in six months [Page 3]
DRAFT Photuris Schemes April 1996
is "not protected".
The "SPI Messages" Validity-Method is "MD5-DP".
(8) Implementation Optional. Any modulus (p) with a recommended
generator (g) of 2. The modulus is contained in the Exchange
Scheme Value field in the list of Offered-Schemes.
The "Identification Exchange" and "SPI Messages" Privacy-Method
is "Triple DES-CBC with secret IV".
The "SPI Messages" Validity-Method is "SHA1-DP".
(10) Implementation Optional. Any modulus (p) with a recommended
generator (g) of 5. The modulus is contained in the Exchange
Scheme Value field in the list of Offered-Schemes.
The "Identification Exchange" and "SPI Messages" Privacy-Method
is "DES-CBC with secret IV".
The "SPI Messages" Validity-Method is "MD5-DP".
(12) Implementation Optional. Any modulus (p) with a recommended
generator (g) of 3. The modulus is contained in the Exchange
Scheme Value field in the list of Offered-Schemes.
The "Identification Exchange" and "SPI Messages" Privacy-Method
is "Triple DES-CBC with secret IV".
The "SPI Messages" Validity-Method is "SHA1-DP".
(14) Implementation Optional. Any modulus (p) with a variable gen-
erator (g). The generator has the same number of significant
bits as the modulus. The modulus is followed by (concatenated
to) the generator, and the variable number of significant bits
are contained in the Exchange Scheme Value field in the list of
Offered-Schemes.
The "Identification Exchange" and "SPI Messages" Privacy-Method
is "DES-CBC with secret IV".
The "SPI Messages" Validity-Method is "MD5-DP".
(20) Implementation Optional. Any modulus (p) with a recommended
generator (g) of 5. The modulus is contained in the Exchange
Scheme Value field in the list of Offered-Schemes.
The "Identification Exchange" and "SPI Messages" Privacy-Method
Karn & Simpson expires in six months [Page 4]
DRAFT Photuris Schemes April 1996
is "Triple DES-CBC with secret IV".
The "SPI Messages" Validity-Method is "SHA1-DP".
(28) Implementation Optional. Any modulus (p) with a variable gen-
erator (g). The generator has the same number of significant
bits as the modulus. The modulus is followed by (concatenated
to) the generator, and the variable number of significant bits
are contained in the Exchange Scheme Value field in the list of
Offered-Schemes.
The "Identification Exchange" and "SPI Messages" Privacy-Method
is "Triple DES-CBC with secret IV".
The "SPI Messages" Validity-Method is "SHA1-DP".
3. Privacy Methods
3.1. DES-CBC with secret IV
MD5 [RFC-1321] is used as the key generation cryptographic hash for
generating the privacy session-key, as described in "Party Privacy
Protection". The most significant 64-bits of the generated hash are
used for the key. The least significant bit of each key octet is
ignored (or set to parity when the implementation requires).
The least significant 64-bits of the generated hash are used for the
Initialization Vector (IV). For each message, this is logically
XOR'd with the concatenated message Type, LifeTime, and SPI fields,
and then used for the message IV.
Message encryption begins with the next field after the SPI, and con-
tinues to the end of the data indicated by the UDP Length.
3.2. Triple DES-CBC with secret IV
This method indicates outer-CBC EDE encryption (and DED decryption)
with three 56-bit keys [KR96].
MD5 [RFC-1321] is used as the key generation cryptographic hash for
generating the three privacy session-keys, as described in "Party
Privacy Protection". The most significant 64-bits of the first gen-
erated hash are used for the first session-key. The least signifi-
cant 64-bits of the first generated hash are used for the second ses-
sion-key. The most significant 64-bits of the second generated hash
are used for the third session-key. In all three keys, the least
Karn & Simpson expires in six months [Page 5]
DRAFT Photuris Schemes April 1996
significant bit of each key octet is ignored (or set to parity when
the implementation requires).
The least significant 64-bits of the generated hash are used for the
Initialization Vector (IV). For each message, this is logically
XOR'd with the concatenated message Type, LifeTime, and SPI fields,
and then used for the message IV.
Message encryption begins with the next field after the SPI, and con-
tinues to the end of the data indicated by the UDP Length.
4. Validity Methods
4.1. SHA1-DP
As described in [Firefly] "Validity Verification", the SHA1
[FIPS-180-1] hash is calculated over the concatenation of
SHA1( key, data, datafill, key, sha1fill )
The leading key is not padded to any particular alignment.
The datafill uses the same pad-with-length technique defined for
sha1fill. The length includes the leading key and data.
The resulting Verification field is a 160-bit variable precision num-
ber (22 octets including Size).
Karn & Simpson expires in six months [Page 6]
DRAFT Photuris Schemes April 1996
A. Example Bootstrap Moduli
During the initial bootstrap of the implementation, there may not be
sufficient time to generate a new modulus before a security associa-
tion is needed. These moduli are verified examples that may be used
during this bootstrap period.
(1024-5)
A 1024-bit strong prime (p), expressed in hex:
a478 8e21 84b8 d68b fe02 690e 4dbe 485b
17a8 0bc5 f21d 680f 1a84 1313 9734 f7f2
b0db 4e25 3750 018a ad9e 86d4 9b60 04bb
bcf0 51f5 2fcb 66d0 c5fc a63f bfe6 3417
3485 bbbf 7642 e9df 9c74 b85b 6855 e942
13b8 c2d8 9162 abef f434 2435 0e96 be41
edd4 2de9 9a69 6163 8c1d ac59 8bc9 0da0
69b5 0c41 4d8e b865 2adc ff4a 270d 567f
The recommended generator (g) for this prime is 5.
This prime modulus was randomly generated by a freely available
program written by Phil Karn, verified using the
mpz_probab_prime() function Miller-Rabin test in the Gnu Math
Package (GMP) version 1.3.2; and also verified with GMP on
another platform by Frank A Stevenson.
Currently estimated to provide 80 (pessimistic) through 98
(optimistic) bit-equivalents of cryptographic strength. Expo-
nent lengths of 160 to 256 bits (or more) are recommended.
Security Considerations
In addition to the obvious usage, party privacy protection provides a
significant improvement in cryptographic strength for the Photuris
message exchanges.
Hiding the Identification and Verification fields prevents an
attacker from direct verification of forgery attacks on the authenti-
cation function.
Also, hiding the Verification fields inhibits cryptanalysis of ses-
sion-key generation by reducing the number of known fields used in
the generation.
Karn & Simpson expires in six months [Page 7]
DRAFT Photuris Schemes April 1996
Hiding attribute choices inhibits traffic cryptanalysis when multiple
transform algorithms are implemented.
The "whitening" of the DES IV is intended to obscure the relation of
the number of parties and SPIs active between two IP nodes. The com-
bination of a randomized secret IV with the SPI generates a different
initial encrypted block for every SPI creation message.
This obscurement is not effective when the SPI is invariant or not
created for a particular exchange direction. The number of parties
will be revealed by the number of exchanges with differences in the
initial encrypted blocks.
Acknowledgements
Phil Karn was principally responsible for the design of party privacy
protection, and provided much of the design rationale text. Use of
privacy protection is also found in the Station-To-Station authenti-
cation protocol [DOW92].
William Simpson designed the packet formats, and additional exchange
schemes, editing and formatting. All such mistakes are his responsi-
bity.
Bart Preneel and Paul C van Oorschot in [PO96] suggested adding
padding between the data and trailing key when hashing for authenti-
cation.
References
[DOW92] Whitfield Diffie, Paul C van Oorshot, Michael J Wiener,
"Authentication and Authenticated Key Exchanges", Designs,
Codes and Cryptography, v 2 pp 107-125, Kluwer Academic Pub-
lishers, 1992.
[FIPS-180-1]
"Secure Hash Standard", National Institute of Standards and
Technology, U.S. Department Of Commerce, April 1995.
Also known as: 59 Fed Reg 35317 (1994).
[Firefly]
Karn, P., Simpson, W., "The Photuris Session Key Management
Protocol", work in progress.
Karn & Simpson expires in six months [Page 8]
DRAFT Photuris Schemes April 1996
[KR96] Kaliski, B., and Robshaw, M., "Multiple Encryption: Weighing
Security and Performance", Dr. Dobbs Journal, January 1996.
[PO96] Bart Preneel, and Paul C van Oorshot, "...Two MACs", work in
progress.
[RFC-1321]
Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321,
MIT Laboratory for Computer Science, April 1992.
[RFC-1700]
Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
USC/Information Sciences Institute, October 1994.
Contacts
Comments should be submitted to the photuris@majordomo.soscorp.com
mailing list.
Questions about this memo can also be directed to:
Phil Karn
Qualcomm, Inc.
6455 Lusk Blvd.
San Diego, California 92121-2779
karn@qualcomm.com
karn@unix.ka9q.ampr.org (prefered)
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
bsimpson@MorningStar.com
Karn & Simpson expires in six months [Page 9]