Network Working Group P Karn (Qualcomm)
Internet Draft W A Simpson (DayDreamer)
expires in six months May 1997
Photuris: Extended Schemes and Privacy Protection
draft-simpson-photuris-schemes-01.txt
Status of this Memo
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)
Distribution of this memo is unlimited.
Abstract
Photuris is a session-key management protocol. 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 May 1997
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 tunnel IP Source has been dynamically allocated, it provides
no useful information to an eavesdropper.
This leaves the identifying information that the parties send during
the Photuris [RFC-zzzz] 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 names in certificates or by checking sig-
natures 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 with the Clogging Defense, the
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 function is used to
Karn & Simpson expires in six months [Page 1]
DRAFT Photuris Schemes May 1997
create a special privacy session-key. This function is calculated
over the following concatenated values:
+ the computed shared-secret,
+ the Initiator Cookie,
+ the Responder Cookie,
+ the SPI Owner Exchange-Value,
+ the SPI User 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 function, these keying-bits are generated by
duplicating the trailing shared-secret, and recalculating the func-
tion. That is, the first iteration will have one trailing copy of
the shared-secret, the second iteration will have two trailing copies
of the shared-secret, and so forth.
If decryption failure is detected, the users are notified, and a Ver-
ification_Failure message is sent, without adding any Security Asso-
ciations. Otherwise, the usual verification procedures occur.
Implementation Notes:
This is distinct 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 Exchange-Value data 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.
Karn & Simpson expires in six months [Page 2]
DRAFT Photuris Schemes May 1997
2. Additional Exchange Schemes
The packet format and basic facilities are already defined for Pho-
turis [RFC-zzzz].
These optional exchange schemes are specified separately, and no sin-
gle implementation is expected to support all of them.
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 Privacy-Method is "not protected".
The "SPI Messages" Validity-Method is "MD5-KDpKp".
(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 Privacy-Method is "DES-CBC with secret IV".
The "SPI Messages" Validity-Method is "MD5-KDpKp".
(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 Privacy-Method is "not protected".
The "SPI Messages" Validity-Method is "MD5-KDpKp".
(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 Privacy-Method is "DES-CBC with secret IV".
The "SPI Messages" Validity-Method is "MD5-KDpKp".
(7) Implementation Optional. Any modulus (p) with a variable gen-
erator (g). Each is encoded in a separate Variable Precision
Number. The generator VPN is followed by (concatenated to) the
modulus VPN, and the pair are contained in the Exchange Scheme
Value field in the list of Offered-Schemes.
Karn & Simpson expires in six months [Page 3]
DRAFT Photuris Schemes May 1997
The Privacy-Method is "not protected".
The "SPI Messages" Validity-Method is "MD5-KDpKp".
(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 Privacy-Method is "DES-EDE3-CBC with secret IV".
The "SPI Messages" Validity-Method is "SHA1-KDpKp".
(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 Privacy-Method is "DES-CBC with secret IV".
The "SPI Messages" Validity-Method is "MD5-KDpKp".
(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 Privacy-Method is "DES-EDE3-CBC with secret IV".
The "SPI Messages" Validity-Method is "SHA1-KDpKp".
(14) Implementation Optional. Any modulus (p) with a variable gen-
erator (g). Each is encoded in a separate Variable Precision
Number. The generator VPN is followed by (concatenated to) the
modulus VPN, and the pair are contained in the Exchange Scheme
Value field in the list of Offered-Schemes.
The Privacy-Method is "DES-CBC with secret IV".
The "SPI Messages" Validity-Method is "MD5-KDpKp".
(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 Privacy-Method is "DES-EDE3-CBC with secret IV".
The "SPI Messages" Validity-Method is "SHA1-KDpKp".
(28) Implementation Optional. Any modulus (p) with a variable gen-
erator (g). Each is encoded in a separate Variable Precision
Karn & Simpson expires in six months [Page 4]
DRAFT Photuris Schemes May 1997
Number. The generator VPN is followed by (concatenated to) the
modulus VPN, and the pair are contained in the Exchange Scheme
Value field in the list of Offered-Schemes.
The Privacy-Method is "DES-EDE3-CBC with secret IV".
The "SPI Messages" Validity-Method is "SHA1-KDpKp".
3. Privacy Methods
3.1. DES-CBC with secret IV
MD5 [RFC-1321] is used as the key generation function 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).
Although extremely rare, weak, semi-weak, and possibly weak keys are
discarded. Another iteration of the key generation function is used.
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. DES-EDE3-CBC with secret IV
This "Triple DES" method indicates outer-CBC EDE encryption (and DED
decryption) with three 56-bit keys [KR96].
MD5 [RFC-1321] is used as the key generation function for generating
the three privacy session-keys, as described in "Party Privacy Pro-
tection". The most significant 64-bits of the first generated hash
are used for the first session-key. The least significant 64-bits of
the first generated hash are used for the second session-key. The
most significant 64-bits of the second generated hash are used for
the third session-key. In all three keys, the least significant bit
of each key octet is ignored (or set to parity when the implementa-
tion requires).
Weak, semi-weak, and possibly weak keys are not discarded. They are
extremely rare, and masked by the other keys.
Karn & Simpson expires in six months [Page 5]
DRAFT Photuris Schemes May 1997
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-KDpKp
As described in [RFC-zzzz] "Validity Verification", the SHA1
[FIPS-180-1] hash is calculated over the concatenation of
SHA1( key, data, datafill, key, sha1fill )
where the key is the computed shared-secret.
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).
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.
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
Karn & Simpson expires in six months [Page 6]
DRAFT Photuris Schemes May 1997
initial encrypted block for every SPI creation message.
This obscurement is not effective when the SPI is invariant or is 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.
William Simpson designed the packet formats, and additional exchange
schemes, editing and formatting. All such mistakes are his responsi-
bity.
Use of privacy protection is also found in the Station-To-Station
authentication protocol [DOW92].
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, and 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).
[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, "On the security of
two MAC algorithms", Advances in Cryptology -- Eurocrypt
'96, Lecture Notes in Computer Science 1070 (May 1996),
Springer-Verlag, pages 19-32.
[RFC-1321]
Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321,
Karn & Simpson expires in six months [Page 7]
DRAFT Photuris Schemes May 1997
MIT Laboratory for Computer Science, April 1992.
[RFC-zzzz]
Karn, P., Simpson, W., "Photuris: Session Key Management
Protocol", work in progress.
Contacts
Comments about this document should be discussed on the
photuris@majordomo.soscorp.com mailing list.
Questions about this document 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 (preferred)
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 8]