Network Working Group W A Simpson
Internet Draft [DayDreamer]
expires in six months March 1999
Photuris: Secret Exchange
draft-simpson-photuris-secret-01.txt (B)
Status of this Memo
This document is an Internet Draft, and is in full conformance with
all provisions of Section 10 of RFC2026, except that the right to
produce derivative works is not granted.
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups. Note that
other groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is not appropriate to use Internet Drafts as
reference material, or to cite them other than as "Work In Progress."
The list of current Internet Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
To view the list of Internet Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Note that the first paragraph of this section is a meaningless
bureaucratic requirement of the IESG. It is provided so as to
satisfy those bureaucratic requirements, and serves no other purpose
whatever. No assumption should be made that the author(s) have
assented to any of it.
Information as to any intellectual property rights, beyond the right
to redistribute this document and make use of it for the purposes of
an Internet Draft, should be sought in other parts of this document.
Distribution of this memo is unlimited.
Simpson expires in six months [Page i]
DRAFT Secret Exchange March 1999
Copyright Notice
Copyright (C) William Allen Simpson (1995,1998-1999). All Rights
Reserved.
Abstract
Photuris is a session-key management protocol. Extensible Messages
are provided to enable future implementation changes without
affecting the basic protocol.
The Secret Exchange messages provide the capability to create
ephemeral symmetric secrets between parties.
Simpson expires in six months [Page ii]
DRAFT Secret Exchange March 1999
1. Introduction
The packet format and basic facilities are already defined for
Photuris [RFC-2522].
In addition to establishing session-keys, Photuris is easily capable
of generating high quality unpredictable secrets. This facility can
be useful to augment or expand lower quality user passwords, and to
substitute for computationally expensive public-key operations.
Existing identities are exchanged between the parties, and new
identities with symmetric secrets are created. Upon successful
completion of the Photuris exchange, the existing access permissions
and other delegated authorizations are associated with the
corresponding substitute identities.
1.1. Terminology
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "required", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [RFC-2119].
nonce A value that is not used more than once for the same
purpose. The value is recommended to be generated
by a cryptographically random method, which may be
concatenated with a timestamp or sequence number.
Party Secret Index (PSI)
A number that indicates a particular symmetric
secret. The value is recommended to be generated by
a cryptographically random method.
The use of this value is orthogonal to usage of
similar values by other related security protocols,
such as the Security-Parameters-Index (SPI). That
is, the same value MAY be used by multiple protocols
to concurrently indicate different Security
Association parameters.
1.2. LifeTimes
Each PSI identity and secret has an associated LifeTime, specified by
the PSI Owner (sender). This PSI LifeTime (PSILT) is usually long-
lived (typically 4 to 8 weeks), but it MUST NOT be greater than the
lifetime of original identity used in its creation.
Simpson expires in six months [Page 1]
DRAFT Secret Exchange March 1999
There is no requirement that a long LifeTime be accepted by the PSI
User. A PSI identity may be used only for the current Photuris
exchange, or be purged at any time.
Whenever a new PSI identity is established, a common implementation
technique is to immediately expire all previous identities associated
with the same pair of original identities. However, selecting
randomly among several PSIs to expire might provide some defense
against traffic analysis.
When a PSI identity expires (or is replaced by a newer value),
existing Photuris exchanges and any unexpired derived SPIs are not
affected.
Although PSI identities and secrets can be stored in an external
database in the same manner as other long-lived identities and
secrets, care MUST be taken that PSI identities and secrets are
purged as they expire, and are not retained in backup storage. The
paranoid operator might store the data in a memory-only cryptographic
file system.
1.3. Value Exchange Parameter Selection
Photuris exchanges employing the Secret Exchange MUST select Value
Exchange parameters with at least the equivalent cryptographic
strength of the identities that will be utilized. Later exchanges
MAY use less strength to reduce computational cost, relying on the
quality of the PSI secrets for protection.
Implementations enjoying party privacy protection SHOULD select the
greatest cryptographic strength available. This inhibits discovery
and linking of the original identities of the parties with the
substitute PSI identities in later exchanges.
Simpson expires in six months [Page 2]
DRAFT Secret Exchange March 1999
2. Secret Exchange
The Secret Exchange will occur following the usual Value Exchange:
Initiator Responder
========= =========
Cookie_Request ->
<- Cookie_Response
Value_Request ->
<- Value_Response
[generate shared-secret from exchanged values]
Frequently, the Secret Exchange will occur before the Identification
Exchange:
Initiator Responder
========= =========
Secret_Request ->
make PSI
identify self
authenticate
make privacy key(s)
mask/encrypt message
<- Secret_Response
make PSI
identify self
generate nonce
authenticate
make privacy key(s)
mask/encrypt message
Identity_Request ->
make SPI
pick SPI attribute(s)
generate nonce
authenticate
make privacy key(s)
mask/encrypt message
[make PSI secret-keys in each direction]
<- Identity_Response
[make SPI session-keys in each direction]
Alternatively, the Secret Exchange can occur in the middle of the
Identification Exchange:
Simpson expires in six months [Page 3]
DRAFT Secret Exchange March 1999
Initiator Responder
========= =========
Identity_Request ->
<- Secret_Request
Secret_Response ->
[make PSI secret-keys in each direction]
<- Identity_Response
[make SPI session-keys in each direction]
The exchange of messages is ordered, although the formats and
meanings of the messages are similar in each direction. The messages
are easily distinguished by the parties themselves, by examining the
Message and Identification fields.
Nota Bene: A Secret_Request may be sent by either the Initiator or
Responder. The terms Primary and Secondary are used for the Secret
Exchange parties.
2.0.1. Send Secret_Request
The Primary chooses an appropriate Identification, the PSI and
PSILT, calculates the Verification, and masks the message using the
Privacy-Method indicated by the current Scheme-Choice.
The Primary also starts a retransmission timer. If no valid
Secret_Response arrives within the time limit, its previous
Secret_Request is retransmitted for the remaining number of
Retransmissions.
When Retransmissions have been exceeded, if a Bad_Cookie message has
been received during the exchange, the Primary SHOULD begin the
Photuris exchange again by sending a new Cookie_Request.
2.0.2. Receive Secret_Request
The Secondary validates the pair of Cookies, the Padding, the
Verification, and the Identification.
- When an invalid/expired cookie is detected, a Bad_Cookie message
is sent.
- After unmasking, when invalid Padding is detected, or the
Verification format is invalid, the message is silently discarded.
Simpson expires in six months [Page 4]
DRAFT Secret Exchange March 1999
- When the message verification fails, or an invalid Identification
format is detected, or external signature validation fails, or
other authorization policy failures are indicated, a
Verification_Failure message is sent.
- Whenever such a problem is detected, the Security Association is
not established; the implementation SHOULD log the occurance, and
notify an operator as appropriate.
When the message is valid, the Secondary returns a Secret_Response.
The Secondary keeps a copy of the incoming Secret_Request values, and
its Secret_Response. If a duplicate Secret_Request is received, it
merely resends its previous Secret_Response, and takes no further
action.
Implementation Notes:
Validation of message formats MUST take place before determination
of signatures and authorization. Such determination may take a
substantial amount of time.
To improve performance, an implementation can cache the public
keys for the issuers that frequently sign end-user certificates.
These cached public keys can be used to verify the final
certificate, and avoid the cost of verifying each certificate in
the chain.
2.0.3. Send Secret_Response
The Secondary chooses an appropriate (optional) Identification, the
PSI and PSILT, generates an appropriate Secret-Value for the
Secret_Request Identity-Choice, calculates the Verification, and
masks the message using the Privacy-Method indicated by the current
Scheme-Choice.
2.0.4. Receive Secret_Response
The Primary validates the pair of Cookies, the Padding, the
Verification, the Secret-Value, and the (optional) Identification.
- When an invalid/expired cookie is detected, the message is
silently discarded.
- After unmasking, when invalid Padding is detected, or the
Verification format is invalid, or the Secret-Value format is
Simpson expires in six months [Page 5]
DRAFT Secret Exchange March 1999
invalid, the message is silently discarded.
- When the message verification fails, or an invalid Identification
format is detected, or external signature validation fails, or
other authorization policy failures are indicated, a
Verification_Failure message is sent.
- Whenever such a problem is detected, the Security Association is
not established; the implementation SHOULD log the occurance, and
notify an operator as appropriate.
- Once a valid message has been received, later Secret_Responses
with both matching cookies are also silently discarded, until a
new Cookie_Request is sent.
When the message is valid, the Primary sends an appropriate
Identification Message.
Implementation Notes:
Validation of message formats MUST take place before determination
of signatures and authorization. Such determination may take a
substantial amount of time.
To improve performance, an implementation can cache the public
keys for the issuers that frequently sign end-user certificates.
These cached public keys can be used to verify the final
certificate, and avoid the cost of verifying each certificate in
the chain.
Simpson expires in six months [Page 6]
DRAFT Secret Exchange March 1999
2.1. Secret_Request
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | LifeTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Party-Secret-Index |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
~ Verification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identity-Choice | |
+ + + + + + + + + + + + + + + + + +
| |
~ Identification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Value_Request.
Responder-Cookie 16 bytes. Copied from the Value_Request.
Message 6
LifeTime 3 bytes. The number of seconds remaining before
the indicated PSI expires. The value zero
indicates that the PSI is used for only this
Identification Exchange.
Party-Secret-Index (PSI)
4 bytes. The PSI to be used for this party in
the Identification Exchange. The value MUST NOT
be zero.
Verification Variable Precision Integer, or other format
indicated by the current Scheme-Choice. The
calculation of the value is described in
Simpson expires in six months [Page 7]
DRAFT Secret Exchange March 1999
"Integrity Verification".
The field may be any integral number of bytes in
length. It does not require any particular
alignment. The 32-bit alignment shown is for
convenience in the illustration.
Identity-Choice 2 or more bytes. An identity attribute is
selected from the list of Offered-Attributes sent
by the peer.
The field may be any integral number of bytes in
length, as indicated by its Length field. It
does not require any particular alignment. The
16-bit alignment shown is for convenience in the
illustration.
Identification Variable Precision Integer, or alternative format
indicated by the Identity-Choice. See the
"Additional Attributes" for details.
The field may be any integral number of bytes in
length. It does not require any particular
alignment. The 32-bit alignment shown is for
convenience in the illustration.
Padding 8 to 255 bytes. This field is filled up to at
least a 128 byte boundary, measured from the
beginning of the message. The number of pad
bytes are chosen randomly.
In addition, when a Privacy-Method indicated by
the current Scheme-Choice requires the plaintext
to be a multiple of some number of bytes (the
block size of a block cipher), this field is
adjusted as necessary to the size required by the
algorithm.
Self-Describing-Padding begins with the value 1.
Each byte contains the index of that byte. Thus,
the final pad byte indicates the number of pad
bytes to remove. For example, when the unpadded
message length is 120 bytes, the padding values
might be 1, 2, 3, 4, 5, 6, 7, and 8.
The portion of the message after the PSI field is masked using the
Privacy-Method indicated by the current Scheme-Choice.
Simpson expires in six months [Page 8]
DRAFT Secret Exchange March 1999
The fields following the PSI are opaque. That is, the values are
set prior to masking (and optional encryption), and examined only
after unmasking (and optional decryption).
2.1.1. Integrity Verification
The Secret_Request is authenticated using the Validity-Method
indicated by the current Scheme-Choice. The Verification value is
calculated prior to masking (and optional encryption), and
verified after unmasking (and optional decryption).
The Validity-Method authentication function is supplied with two
input values:
- the integrity-key,
- the data to be verified (as a concatenated sequence of bytes).
The resulting output value is stored in the Verification field.
The Scheme-Choice specified Key-Generation-Function is used to
create a special integrity-key. This function is calculated over
the computed shared-secret.
The verification data consists of the following concatenated
values:
+ the Initiator Cookie,
+ the Responder Cookie,
+ the Message, LifeTime and PSI fields,
+ the Identity-Choice and Identification,
+ the Padding.
Implementation Notes:
The exact details of the Identification included in the
Verification calculation are dependent on the corresponding
Identity-Choice.
Failure to find an Identification in either an internal or
external database results in the same Verification_Failure
message as failure of the verification computation.
Simpson expires in six months [Page 9]
DRAFT Secret Exchange March 1999
2.2. Secret_Response
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message | LifeTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Party-Secret-Index |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
~ Verification ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Secret-Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Identity-Choice) | |
+ + + + + + + + + + + + + + + + + +
| |
~ (Identification) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Secret_Request.
Responder-Cookie 16 bytes. Copied from the Secret_Request.
Message 5
LifeTime 3 bytes. The number of seconds remaining before
the indicated PSI expires. The value zero
indicates that the PSI is used for only this
Identification Exchange.
Party-Secret-Index (PSI)
4 bytes. The PSI to be used for this party in
the Identification Exchange. The value MUST NOT
be zero. Also, the value SHOULD NOT equal the
Simpson expires in six months [Page 10]
DRAFT Secret Exchange March 1999
PSI from the Secret_Request.
Verification Variable Precision Integer, or other format
indicated by the current Scheme-Choice. The
calculation of the value is described in
"Integrity Verification".
The field may be any integral number of bytes in
length. It does not require any particular
alignment. The 32-bit alignment shown is for
convenience in the illustration.
Secret-Value Variable Precision Integer, or alternative format
indicated by the Secret_Request Identity-Choice.
Used for calculating a pair of symmetric secret-
keys between the parties.
The field may be any integral number of bytes in
length, as indicated by its Size field. It does
not require any particular alignment. The 32-bit
alignment shown is for convenience in the
illustration.
(Identity-Choice)
2 or more bytes. An identity attribute is
selected from the list of Offered-Attributes sent
by the peer.
This field may be omitted. See "During
Identification Exchange".
The field may be any integral number of bytes in
length, as indicated by its Length field. It
does not require any particular alignment. The
16-bit alignment shown is for convenience in the
illustration.
(Identification) Variable Precision Integer, or alternative format
indicated by the Identity-Choice. See the
"Additional Attributes" for details.
This field may be omitted. See "During
Identification Exchange".
The field may be any integral number of bytes in
length. It does not require any particular
alignment. The 32-bit alignment shown is for
convenience in the illustration.
Simpson expires in six months [Page 11]
DRAFT Secret Exchange March 1999
Padding 8 to 255 bytes. This field is filled up to at
least a 128 byte boundary, measured from the
beginning of the message. The number of pad
bytes are chosen randomly.
In addition, when a Privacy-Method indicated by
the current Scheme-Choice requires the plaintext
to be a multiple of some number of bytes (the
block size of a block cipher), this field is
adjusted as necessary to the size required by the
algorithm.
Self-Describing-Padding begins with the value 1.
Each byte contains the index of that byte. Thus,
the final pad byte indicates the number of pad
bytes to remove. For example, when the unpadded
message length is 120 bytes, the padding values
might be 1, 2, 3, 4, 5, 6, 7, and 8.
The portion of the message after the PSI field is masked using the
Privacy-Method indicated by the current Scheme-Choice.
The fields following the PSI are opaque. That is, the values are
set prior to masking (and optional encryption), and examined only
after unmasking (and optional decryption).
2.2.1. Before Identification Exchange
When the Secret Exchange occurs before the Identification
Exchange, the optional Identity-Choice and Identification fields
are included in the Secret_Response.
The subsequent Identification_Request is modified. The
Identification field is replaced by a Secret-Value field. (The
Identity-Choice field remains in place.)
The derived Primary Secret Identity is used internally instead of
the usurped Identification field, with the associated Primary
secret-key.
The derived Secondary Secret Identity MUST be used in the
Identification_Response, with the associated Secondary secret-key.
Simpson expires in six months [Page 12]
DRAFT Secret Exchange March 1999
2.2.2. During Identification Exchange
When the Secret Exchange occurs during the Identification
Exchange, the optional Identity-Choice and Identification fields
are excluded from the Secret_Response.
Instead, the values are taken from the Identification_Request, and
the secret-nonce is the associated generation-key.
The derived Primary Secret Identity MUST be used in the
Identification_Response, with the associated Primary secret-key.
The derived Secondary Secret Identity is unused in this exchange,
but MAY be used in a later exchange.
2.2.3. Integrity Verification
The Secret_Response is authenticated using the Validity-Method
indicated by the current Scheme-Choice. The Verification value is
calculated prior to masking (and optional encryption), and
verified after unmasking (and optional decryption).
The Validity-Method authentication function is supplied with two
input values:
- the integrity-key,
- the data to be verified (as a concatenated sequence of bytes).
The resulting output value is stored in the Verification field.
The Scheme-Choice specified Key-Generation-Function is used to
create a special integrity-key. This function is calculated over
the following concatenated values:
+ the Secret_Request Verification field,
+ the computed shared-secret.
The verification data consists of the following concatenated
values:
+ the Initiator Cookie,
+ the Responder Cookie,
+ the Message, LifeTime and PSI fields,
+ the Secret-Value,
+ the Identity-Choice and Identification (optional),
+ the Padding.
Simpson expires in six months [Page 13]
DRAFT Secret Exchange March 1999
If the verification fails, the users are notified, and a
Verification_Failure message is sent, without adding any PSI
identities. On success, normal operation begins with the
remainder of the Identification Exchange.
The Secret Exchange depends upon the Identification Exchange for
ultimate verification. When later verification fails, the PSI
secret-keys MUST be discarded.
Implementation Notes:
The exact details of the Identification and Secret-Value
included in the Verification calculation are dependent on the
corresponding Identity-Choices.
Failure to find an Identification in either an internal or
external database results in the same Verification_Failure
message as failure of the verification computation.
2.3. Secret-Nonce
A secret-nonce is formed as indicated by the Identity-Choice and
Identification specified in the Secret_Request (and optionally in
the Secret_Response).
Asymmetric Identity Attribute
The Secret-Value contains the nonce encoded by the specified
public-key.
Symmetric Identity Attribute
The Value part of the Secret-Value is concatenated to (followed
by) the existing symmetric secret-key.
Regardless of the internal representation of the secret-nonce,
when used in calculations it is in the same form as the Value part
of a Variable Precision Integer:
- most significant byte first.
- bits used are right justified within byte boundaries.
- any unused bits are in the most significant byte.
- unused bits are zero filled.
The secret-nonce does not include a Size field.
Simpson expires in six months [Page 14]
DRAFT Secret Exchange March 1999
2.4. Secret-Key Computation
Each pair of PSI values is used to generate a corresponding pair
of symmetric secret-keys (one for each party).
The Scheme-Choice specified Key-Generation-Function is used to
create the secret-key for each party. This function is calculated
over the following concatenated values:
+ the Initiator Cookie,
+ the Responder Cookie,
+ the Owner Message, LifeTime and PSI,
+ the Peer Message, LifeTime and PSI,
+ the Owner secret-nonce,
+ the Peer secret-nonce,
+ the computed shared-secret.
Since the order of the Owner and Peer fields is different in each
direction, the resulting secret-key will usually be different in
each direction.
2.5. Secret Identities
The pair of PSI values also identifies the secret-keys. These
identities can be used with a symmetric identity attribute in any
subsequent Identification message.
The Primary identity is the Secret_Request PSI value, concatenated
to (followed by) the Secret_Response Verification value. The
Secret_Request LifeTime is used as the LifeTime.
The Secondary identity is the Secret_Response PSI value,
concatenated to (followed by) the Secret_Response Verification
value, concatenated to (followed by) the Secret_Request PSI value.
The Secret_Response LifeTime is used as the LifeTime.
Simpson expires in six months [Page 15]
DRAFT Secret Exchange March 1999
3. Additional Attributes
The attribute format and basic facilities are already defined for
Photuris [RFC-2522].
These optional attributes are specified separately, and no single
implementation is expected to support all of them.
Nota Bene: Support is always required for the [RFC-2522]
"MD5-IPMAC" (#5) attribute for the Secret_Request Identity-Choice.
This document defines the following values:
Use Type
I 27 DNS Key RR
I 28 OpenPGP
I 29 X.509
I Identity-Choice
3.0.1. Authentication
These attributes are never used as an AH or ESP Attribute-Choice.
3.0.2. Verification
These attributes are never used for [RFC-2522] "Identity
Verification" or "Validity Verification". Instead, the Secret
Exchange occurs to associate a pair of symmetric secrets with the
Identification.
Simpson expires in six months [Page 16]
DRAFT Secret Exchange March 1999
3.1. DNS Key Resource Record
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length | Power | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 27
Length 2
Power 1 byte. The public/private-key bits supported,
expressed as a power of two.
When listed as an Offered-Attribute, the Power is
set to the maximum supported. As a minimum, all
implementations MUST support value 10 (1024-bit
keys).
When selected as an Attribute-Choice, the Power
is set to the actual value to be used.
Algorithm 1 byte. An algorithm supported. See [RFC-2535]
for details.
Examples include:
1 [RFC-2537] RSA with MD5.
3 [RFC-2536] DSA with SHA1.
When more than one Algorithm is supported,
multiple attributes are listed in the Offered-
Attributes.
When this attribute is implemented, [RFC-2535] requires support
for Algorithm #3 [RFC-2536], which SHOULD be present in every
Offered-Attributes list.
3.1.1. Asymmetric Identification
When selected as an Identity-Choice, the immediately following
Identification field contains the binary form of the DNS Key
Resource Record. The domain name is fully expanded (no name
compression via pointers).
Any Key RR that is available for authentication (the
Authentication flag bit is clear) MAY be used. Currently, no
Simpson expires in six months [Page 17]
DRAFT Secret Exchange March 1999
specific Key Protocol value has been defined for Photuris. It is
recommended that DNSSEC (#3), email (#2), and TLS (#1) keys be
used in preference to Oakley/IPSEC (#4) keys that are specific to
another session-key management protocol.
No DNS Signature Resource Records are included with the
Identification. Valid Identifications and corresponding signature
certificates are preconfigured by the parties, or maintained in
external databases.
The Identification value is not contained within a Variable
Precision Integer (VPI). The Key RR elements are parsed by the
implementation to determine the end of the Identification field.
The returned Secret-Value consists of a nonce encoded by the
specified public-key, of the form determined by the DNS Key
algorithm. The result is contained within a Variable Precision
Integer (VPI).
3.2. OpenPGP Identification
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length | Power | Version ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |
+-+-+-+-+-+-+-+-+
Attribute 28
Length 3
Power 1 byte. The public/private-key bits supported,
expressed as a power of two.
When listed as an Offered-Attribute, the Power is
set to the maximum supported. As a minimum, all
implementations MUST support value 10 (1024-bit
keys).
When selected as an Attribute-Choice, the Power
is set to the actual value to be used.
Version 2 bytes. A Public Key Packet version supported.
See [RFC-2440] for details.
Versioning is complicated by the number of
Simpson expires in six months [Page 18]
DRAFT Secret Exchange March 1999
algorithms supported. For negotiation, the
version and algorithm combinations are treated as
a single quantity.
Examples include:
0x0301 RSA in PGP 2.6.x.
0x0401 RSA in PGP 5.x.
0x0403 RSA in PGP 5.x, signature only.
0x0411 DSA in PGP 5.x.
0x0414 ElGamal in PGP 5.x, encrypt or sign.
When more than one Version is supported, multiple
attributes are listed in the Offered-Attributes.
When this attribute is implemented, [RFC-2440] requires support
for Version #0411, which SHOULD be present in every Offered-
Attributes list.
Due to the widespread use of PGP 2.6.x, this specification also
recommends support for Version #0301.
3.2.1. Asymmetric Identification
When selected as an Identity-Choice, the immediately following
Identification field contains a PGP "Public Key Packet".
PGP "User ID Packet", "Signature Packet", or sub-packet elements
MUST NOT be included in the Identification. Valid Identifications
and corresponding signature certificates are preconfigured by the
parties, or maintained in external databases.
The Identification value is not contained within a Variable
Precision Integer (VPI). The PGP elements are parsed by the
implementation to determine the end of the Identification field.
The returned Secret-Value consists of a nonce encoded by the
specified public-key, of the form determined by the OpenPGP
algorithm. The result is contained within a Variable Precision
Integer (VPI).
Nota Bene:
The PGP Multi-Precision Integer (MPI) is very similar to the
Variable Precision Integer (VPI). However, the Size field is
not extensible, and PGP library functions truncate leading
significant zeroes.
Simpson expires in six months [Page 19]
DRAFT Secret Exchange March 1999
3.3. X.509 Identification
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 29
Length 0
Future extensions to this attribute may add
parameter values. This will be indicated by a
non-zero value.
3.3.1. Asymmetric Identification
When selected as a Identity-Choice, the immediately following
Identification field contains an X.509 "TBSCertificate",
conforming to the profile specified in [RFC-2459].
Full X.509 certificates with signatures MUST NOT be included in
the Identification. Valid Identifications and corresponding
signature certificates are preconfigured by the parties, or
maintained in external databases accessed by [RFC-2510 and
RFC-2511].
The Identification value is not contained within a Variable
Precision Integer (VPI). The X.509 elements are parsed by the
implementation to determine the end of the Identification field.
The returned Secret-Value consists of a nonce encoded by the
specified public-key, of the form determined by the
subjectPublicKey algorithm. The result is contained within a
Variable Precision Integer (VPI).
Simpson expires in six months [Page 20]
DRAFT Secret Exchange March 1999
A. DSA Secret-Value
When using asymmetric public/private-key identities, this protocol
requires the passing of a nonce encoded by the specified public-
key. While this has a natural fit with RSA, DSA was not intended
for public-key encryption of random values.
However, it is possible to use the DSA parameters, bypassing the
signature function, given a sufficiently generic programming
interface. A brief description can be found in [Schneier95].
Using the OpenSSL library,
Operational Considerations
Each party configures a list of known identities and validation
certificates.
In addition, each party configures local policy that determines
what access (if any) is granted to the holder of a particular
identity. For example, the party might allow anonymous FTP, but
prohibit Telnet. Such considerations are outside the scope of
this document.
Security Considerations
Keys retrieved from external sources should not be trusted without
independent verification by the party.
When using asymmetric public/private-key identities, it is
possible that an active interception and modification attack
(sometimes called "Monkey in the Middle" or MITM) will use
entirely valid certificates. Operators should be suspicious when
the peer identities are all certified by a single entity, such as
the regional security agency equivalent. This attack can only be
prevented through rigorous authorization policy enforcement.
Simpson expires in six months [Page 21]
DRAFT Secret Exchange March 1999
Acknowledgements
William Simpson was responsible for the packet formats, additional
message types, editing and formatting.
Robert W Baldwin provided text for X.509 Certificates and other
implementation details.
Steven Bellovin suggested enhancing existing symmetric secret-keys
with greater entropy.
Hilarie Orman suggested adding secret "nonces" to session-key
generation for asymmetric public/private-key identity methods.
References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, Harvard University, March
1997.
[RFC-2440]
[RFC-2459]
[RFC-2510]
[RFC-2511]
[RFC-2522] Karn, P., and Simpson, W., "Photuris: Session-Key
Management Protocol", March 1999.
[RFC-2535]
[RFC-2536]
[RFC-2537]
[Schneier95]
Schneier, B., "Applied Cryptography Second Edition",
John Wiley & Sons, New York, NY, 1995. ISBN
0-471-12845-7.
Simpson expires in six months [Page 22]
DRAFT Secret Exchange March 1999
Contacts
Comments about this document should be discussed on the
photuris@adk.gr mailing list.
Questions about this document can also be directed to:
William Allen Simpson
DayDreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
Full Copyright Statement
Copyright (C) William Allen Simpson (1995,1998-1999). All Rights
Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, except as required to translate it into languages other than
English.
This document and the information contained herein is provided on
an "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
A PARTICULAR PURPOSE.
Simpson expires in six months [Page 23]