2006-10-02 18:22:13 -04:00
<?xml version='1.0' encoding='UTF-8'?>
2006-10-03 18:46:54 -04:00
< !DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
2006-10-02 18:22:13 -04:00
%ents;
]>
2006-10-03 18:46:54 -04:00
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
2006-10-02 18:22:13 -04:00
2006-10-03 18:46:54 -04:00
<xep >
2006-10-02 18:22:13 -04:00
<header >
2009-10-09 16:09:37 -04:00
<title > A Framework For Securing Jabber Conversations</title>
2006-10-02 18:22:13 -04:00
<abstract >
Although the value and utility of contemporary instant messaging
systems, like Jabber, are now indisputable, current security
features to protect message data are generally inadequate for
many deployments; this is particularly true in security conscious
environments like large, commercial enterprises and government
agencies. These current features suffer from issues of
scalability, usability, and supported features. Furthermore, there is a
lack of standardization.
We present a protocol to allow communities of Jabber users to
apply cryptographic protection to selected conversation data.
</abstract>
2016-12-26 10:02:53 -05:00
&LEGALNOTICE;
2009-10-09 13:17:13 -04:00
<number > 0031</number>
2009-10-09 15:51:02 -04:00
<status > Deferred</status>
<type > Standards Track</type>
2009-10-09 16:09:37 -04:00
<sig > Standards</sig>
2016-12-26 10:02:53 -05:00
<dependencies />
<supersedes />
<supersededby />
<shortname > N/A</shortname>
2006-10-02 18:22:13 -04:00
<author >
2016-12-26 10:02:53 -05:00
<firstname > Paul</firstname>
<surname > Lloyd</surname>
<email > paul_lloyd@hp.com</email>
<jid > paul_lloyd@jabber.hp.com (private)</jid>
2006-10-02 18:22:13 -04:00
</author>
<revision >
2009-10-09 16:09:37 -04:00
<version > 0.2</version>
<date > 2002-07-09</date>
2016-12-26 10:02:53 -05:00
<initials > PCL</initials>
2006-10-02 18:22:13 -04:00
<remark >
updated to reflect group consensus to incorporate XML Encryption, as well
as other group comments from Draft 0.9.
</remark>
</revision>
<revision >
2009-10-09 16:09:37 -04:00
<version > 0.1</version>
<date > 2002-05-07</date>
2006-10-02 18:22:13 -04:00
<initials >
PCL
</initials>
<remark >
initial version
</remark>
</revision>
</header>
<section1 topic= "Introduction" >
<p >
Instant messaging has clearly crossed the chasm from experimental
to mainstream in a short amount of time. It is particularly
interesting to note the extent to which the employees and
affiliates of large enterprises have adopted instant messaging as
part of their daily professional lives. IM is no longer simply
used on Friday evening to select which movie to watch; it's now
used on Monday morning to select which company to acquire.
</p>
<p >
While the benefits of IM are clear and compelling, the risks
associated with sharing sensitive information in an IM
environment are often overlooked. We need a mechanism that
permits communities of users to protect their IM conversations.
This document presents an extension protocol that can be
incorporated into the existing Jabber protocol to provide such a
mechanism. We hope that this protocol spurs both interest
and further investigation into mechanisms to protect Jabber
conversations. We also hope that the Jabber community can
accelerate the adoption of standardized security mechanisms.
</p>
<p >
In addition to its ability to protect traditional messaging data,
the proposed protocol may also serve as a foundation for securing
other data transported via other Jabber extensions.
</p>
<p >
We use the following terms throughout this document to describe
the most relevant aspects of the IM environment that we wish to
address:
</p>
<ul >
<li >
<p >
user. A user is simply any Jabber user. Users are uniquely
identified by a JID; they connect to Jabber hosts using a
Jabber node.
</p>
<p >
Users produce and consume information, and we wish to
provide them with mechanisms that can be used to protect
this information.
</p>
</li>
<li >
<p >
community. A community is a collection of users who wish to
communicate via Jabber. No restrictions or assumptions are
made about the size of communities or the geographical,
organizational, or national attributes of the members.
Communities are assumed to be dynamic and ad-hoc. Users
typically join communities by the simple act of invitation.
All members of a community are assumed to be peers.
</p>
<p >
The members of communities share information among
themselves, and we wish to provide them with mechanisms
that can permit information to only be shared by community
members.
</p>
</li>
<li >
<p >
conversation. A conversation is the set of messages
that flows among the members of a community via some
network. Conversations consist of both the actual
conversation data produced and consumed by the various
users as well as the Jabber protocol elements that
transport it. Members participate in a conversation when
they are the source or destination of this traffic.
</p>
<p >
In hostile network environments, like the Internet,
conversation data is vulnerable to a variety of well-known
attacks.
</p>
</li>
</ul>
<p >
Other Jabber and IM terms are used in a traditional, intuitive
fashion.
</p>
</section1>
<section1 topic= "Requirements And Considerations" >
<p >
The proposed protocol is designed to address the specific
requirements and considerations presented in this section.
</p>
<section2 topic= "Security Requirements" >
<section3 topic= "Data Protection Requirements" >
<p >
A secure IM system must permit conversation participants to
preserve the following properties of their conversation data:
</p>
<ul >
<li >
<p >
confidentiality. Conversation data must only be disclosed
to authorized recipients
</p>
</li>
<li >
<p >
integrity. Conversation data must not be altered
</p>
</li>
<li >
<p >
data origin authentication. Recipients must be able to
determine the identity of the sender and trust that the
message did, in fact, come from the sender. It is important
to note that this requirement does not include the
requirement of a durable digital signature on conversation
data.
</p>
</li>
<li >
<p >
replay protection. Recipients must be able to detect and
ignore duplicate conversation data.
</p>
</li>
</ul>
<p >
These are established, traditional goals of information security
applied to the conversation data. In the IM environment, these
goals protect against these attacks:
</p>
<ul >
<li >
<p >
eavesdropping, snooping, etc.
</p>
</li>
<li >
<p >
masquerading as a conversation participant
</p>
</li>
<li >
<p >
forging messages
</p>
</li>
</ul>
<p >
Preserving the availability of conversation data is not addressed
by this protocol.
</p>
<p >
Preserving the anonymity of conversation participants is an
interesting topic which we defer for future exploration.
</p>
<p >
Finally, note that this protocol does not concern any authentication
between a Jabber node and a Jabber host.
</p>
</section3>
<section3 topic= "Data Classification Requirements" >
<p >
A secure IM system must support a data classification feature through the use
of security labeling. Conversation participants must be
able to associate a security label with each piece of
conversation data. This label may be used to specify a data
classification level for the conversation data.
</p>
</section3>
<section3 topic= "The End To End Requirement" >
<p >
It is easy to imagine Jabber systems in which the servers play
active, fundamental roles in the protection of conversation
data. Such systems could offer many advantages, like:
</p>
<ul >
<li >
<p >
allowing the servers to function as credential issuing
authorities,
</p>
</li>
<li >
<p >
allowing the servers to function as policy enforcement
points.
</p>
</li>
</ul>
<p >
Unfortunately, such systems have significant disadvantages when
one considers the nature of instant messaging:
</p>
<ul >
<li >
<p >
Many servers may be untrusted, public servers.
</p>
</li>
<li >
<p >
In many conversation communities, decisions of trust and
membership can only be adequately defined by the members
themselves.
</p>
</li>
<li >
<p >
In many conversation communities, membership in the
community changes in real time based upon the dynamics of
the conversation.
</p>
</li>
<li >
<p >
In many conversation communities, the data classifaction of
the conversation changes in real time based upon the
dynamics of the conversation.
</p>
</li>
</ul>
<p >
Furthermore, the widespread use of gateways to external IM
systems is a further complication.
</p>
<p >
Based on this analysis, we propose that security be entirely
controlled in an end to end fashion by the conversation
participants themselves via their user agent software.
</p>
</section3>
<section3 topic= "Trust Issues" >
<p >
We believe that, ultimately, trust decisions are in the hands of
the conversation participants. A security protocol and
appropriate conforming user agents must provide a mechanism for them to make
informed decisions.
</p>
</section3>
<section3 topic= "Cryptosystem Design Considerations" >
<p >
One of the accepted axioms of security is that people must avoid
the temptation to start from scratch and produce new, untested
algorithms and protocols. History has demonstrated that such
approaches are likely to contain flaws and that considerable time
and effort are required to identify and address all of these
flaws. Any new security protocol should be based on existing,
established algorithms and protocols.
</p>
</section3>
</section2>
<section2 topic= "Environmental Considerations" >
<p >
Any new IM security protocol must integrate smoothly into the
existing IM environment, and it must also recognize the nature of
the transactions performed by conversation participants. These
considerations are especially important:
</p>
<ul >
<li >
<p >
dynamic communities. The members of a community are defined
in near real time by the existing members.
</p>
</li>
<li >
<p >
dynamic conversations. Conversations may involve any
possible subset of the entire set of community members.
</p>
</li>
</ul>
<p >
Addressing these considerations becomes especially crucial when
selecting a conference keying mechanism.
</p>
</section2>
<section2 topic= "Usability Requirements" >
<p >
Given the requirement to place the responsibility for the
protection of conversation data in the hands of the participants,
it is imperative to address some fundamental usability issues:
</p>
<ul >
<li >
<p >
First, overall ease of use is a requirement. For protocol
purposes, one implication is that some form of
authentication via passphrases is necessary. While we
recognize that this can have appalling consequences,
especially when we realize that a passphrase may be shared
by all of the community members, we also recognize the
utility.
</p>
</li>
<li >
<p >
PKIs are well established in many large organizations, and
some communities will prefer to rely on credentials issued
from these authorities. To ensure ease of use, we must
strive to allow the use of existing PKI credentials and
trust models rather than impose closed, Jabber-specific
credentials.
</p>
</li>
<li >
<p >
Finally, performance must not be negatively impacted; this
is particularly true if we accept that most communities are
composed of human users conversing in real time. For
protocol purposes, one obvious implication is the desire to
minimize computationally expensive public key operations.
</p>
</li>
</ul>
<p >
We note that, in practice, the design and construction of user
agents will also have a major impact on ease of use.
</p>
</section2>
<section2 topic= "Development And Deployment Requirements" >
<p >
To successfully integrate into the existing Jabber environment,
an extension protocol for security must satisfy the following:
</p>
<ul >
<li >
<p >
It must be an optional extension of the existing Jabber protocol.
</p>
</li>
<li >
<p >
It must be transparent to existing Jabber servers.
</p>
</li>
<li >
<p >
It must function gracefully in cases where some community
members are not running a user agent that supports the
protocol.
</p>
</li>
<li >
<p >
It must make good use of XML.
</p>
</li>
<li >
<p >
It must avoid encumbered algorithms.
</p>
</li>
<li >
<p >
It must be straightforward to implement using widely
available cryptographic toolkits.
</p>
</li>
<li >
<p >
It must not require a PKI.
</p>
</li>
</ul>
<p >
Failure to accommodate these will impede or prohibit adoption of
any security protocol.
</p>
</section2>
</section1>
<section1 topic= "Protocol Specification" >
<section2 topic= "Protocol Overview" >
<p >
Ultimately, conversation data is protected by the application of
keyed cryptographic operations. One operation is used to provide
confidentiality, and a separate operation is used to provide
integrity and data origin authentication. The keys used to
parameterize these operations are called conversation keys. Each
conversation should have its own unique set of conversation keys
shared among the conversation participants.
</p>
<p >
Conversation keys are transported among the conversation
participants within a negotiated security session. A security session allows
pairs of conversation participants to securely share conversation keys
throught all participants in the conversation as required.
</p>
</section2>
<section2 topic= "Definitions And Notation" >
<p >
The following terms are used throughout this specification:
</p>
<ul >
<li >
<p >
initiator. The initiator is the user who requested a security session
negotiation. Initiator's are identified by their JID.
</p>
</li>
<li >
<p >
responder. The responder is the user who responded to a security session
negotiation request. Responder's are identified by their JID.
</p>
</li>
<li >
<p >
hmac. This indicates the HMAC algorithm. The notation hmac (key, value)
indicates the HMAC computation of value using key.
</p>
</li>
<li >
<p >
concatentation operator. The '|' character is used in character or octet
string expressions to indicate concatenation.
</p>
</li>
<li >
<p >
security session ID. A character string that uniquely identifies a
security session between two users. Security session IDs MUST only
consist of Letters, Digits, and these characters: '.', '+', '-',
'_', '@'. Security session IDs are case sensitive.
</p>
</li>
<li >
<p >
SS. This term indicates the security session secret that is agreed to
during a security session negotiation.
</p>
</li>
<li >
<p >
SKc. This term indicates the keying material used within a security session
to protect confidentiality. The SKc is derived from the security session secret, SS.
</p>
</li>
<li >
<p >
SKi. This term indicates the keying material used within a security session
to protect integrity and to provide authnetication. The SKi is derived from the
security session secret, SS.
</p>
</li>
<li >
<p >
conversation key ID. A character string that uniquely identifies a
conversation key shared by a community of users. Conversation key IDs MUST only
consist of Letters, Digits, and these characters: '.', '+', '-',
'_', '@'. Conversation key IDs are case sensitive. Conversation key IDs SHOULD
be generated from at least 128 random bits.
</p>
</li>
<li >
<p >
passphrase ID. A character string that uniquely identifies a
passphrase shared by a community of users. Passphrase IDs MUST only
consist of Letters, Digits, and these characters: '.', '+', '-',
'_', '@'. Passphrase IDs are case sensitive.
</p>
</li>
</ul>
</section2>
<section2 topic= "XML Processing" >
<p >
Since cryptographic operations are applied to data that is
transported within an XML stream, the protocol defines a set of
rules to ensure a consistent interpretation by all conversation
participants.
</p>
<section3 topic= "Transporting Binary Content" >
<p >
Binary data, such as the result of an HMAC, is always transported
in an encoded form; the two supported encoding schemes are base64
and hex.
</p>
<p >
Senders MAY include arbitrary white space within the character
stream. Senders SHOULD NOT include any other characters outside
of the encoding set.
</p>
<p >
Receivers MUST ignore all characters not in the encoding set.
</p>
</section3>
<section3 topic= "Transporting Encrypted Content" >
<p >
Encrypted data, including wrapped cryptographic keys, are always
wrapped per XML Encryption.
</p>
</section3>
<section3 topic= "HMAC Computation" >
<p >
HMACs are computed over a specific collection of attribute values
and character data; when computing an HMAC the following rules
apply:
</p>
<ul >
<li >
<p >
All characters MUST be encoded in UTF-8.
</p>
</li>
<li >
<p >
The octets in each character MUST be processed in network
byte order.
</p>
</li>
<li >
<p >
For a given element, the attribute values that are HMACed
MUST be processed in the specified order regardless of the
order in which they appear in the element tag.
</p>
</li>
<li >
<p >
For each attribute value, the computation MUST only include
characters from the anticipated set defined in this
specification; in particular, white space MUST always be
ignored.
</p>
</li>
<li >
<p >
For character data that is represented in an encoded form,
such as base64 or hex, the computation MUST only include
valid characters from the encoding set.
</p>
</li>
</ul>
</section3>
<section3 topic= "Performing Cryptographic Operations" >
<p >
The following algorithm is used to encrypt a character string, such as
an XML element:
</p>
<ul >
<li >
<p >
The character string MUST be encoded in UTF-8.
</p>
</li>
<li >
<p >
The octets in each character MUST be processed in network byte order.
</p>
</li>
<li >
<p >
Appropriate cryptographic algorithm parameters, such as an
IV for a block cipher, are generated.
</p>
</li>
</ul>
</section3>
</section2>
<section2 topic= "XML Namespaces" >
<p >
In order to integrate smoothly with the existing Jabber protocol,
this protocol utilizes a new XML namespace, jabber:security.
</p>
</section2>
<section2 topic= "Security Sessions" >
<section3 topic= "Overview" >
<p >
A security session is a pair-wise relationship between two users
in which the users have achieved the following:
</p>
<ul >
<li >
<p >
They have mutually authenticated each other using credentials acceptable to both.
</p>
</li>
<li >
<p >
They have agreed on a set of key material known only to both.
</p>
</li>
</ul>
<p >
Security sessions are identified by a 3-tuple consisting of the following items:
</p>
<ul >
<li >
<p >
initiator. This is the JID of the user who initiated the session.
</p>
</li>
<li >
<p >
responder. This is the JID of the user who responded to the initiator's request.
</p>
</li>
<li >
<p >
sessionId. A label generated by the initiator.
</p>
</li>
</ul>
<p >
Security sessions are used to transport conversation keys between the conversation participants.
</p>
<p >
Scalabilty is an immediate, obvious concern with such an approach. We expect this
approach to be viable in practice because:
</p>
<ul >
<li >
<p >
The number of participants in typical, interactive conversations is generally on the order of 10^1.
</p>
</li>
<li >
<p >
New participants are usually invited to dynamically join a
conversation by being invited by an existing participant;
this existing participant is the only one who needs to
establish a security session with the new participant,
because this single security session can be used to
transport all of the required conversation keys.
</p>
</li>
<li >
<p >
User agents can permit the lifetime of security sessions to
last long enough to allow transport of conversation keys
for a variety of converstions.
</p>
</li>
<li >
<p >
Conversation keys can be established with a suitable lifetime.
</p>
</li>
</ul>
<p >
Other approaches, including the incorporation of more
sophisticated conference keying algorithms, are a topic for
future exploration.
</p>
</section3>
<section3 topic= "Security Session Negotiation" >
<p >
Security sessions are negotiated using an authenticated Diffie-Hellman key agreement
exchange. The two goals of the exchange are to perform the mutual authentication
and to agree to a secret that is know only to each.
</p>
<p >
The exchange also allows the parties to negotiate the various algorithms
and authentication mechanisms that will be used.
</p>
<p >
Once the pair agree on a shared secret, they each derive key material from the
secret; this key material is used to securely transport the conversation keys,
which are used to actually protect conversation data.
</p>
<p >
The protocol data units (PDUs) that comprise the exchange are transported
within existing Jabber protocol elements.
</p>
</section3>
<section3 topic= "DTDs" >
<example >
< !ELEMENT session1
(nonce, keyAgreement, algorithms, authnMethods) >
< !ATTLIST session1
version CDATA #REQUIRED
initiator CDATA #REQUIRED
responder CDATA #REQUIRED
sessionId CDATA #REQUIRED
hmac (hmac-sha1) #REQUIRED >
< !ELEMENT nonce
(#PCDATA)* >
< !ATTLIST nonce
encoding (base64 | hex) #REQUIRED >
< !ELEMENT keyAgreement
(dh) >
< !ELEMENT dh
(publicKey) >
< !ATTLIST dh
group (modp1024 | modp2048 | modp4096 | modp8192) #REQUIRED >
< !ELEMENT publicKey
(#PCDATA)* >
< !ATTLIST publicKey
encoding (base64 | hex) #REQUIRED >
< !ELEMENT algorithms
(algorithm)+ >
< !ELEMENT algorithm
(confAlg, hmacAlg) >
< !ELEMENT confAlg EMPTY >
< !ATTLIST confAlg
cipher (3des-cbc | aes-128-cbc | aes-256-cbc) #REQUIRED >
< !ELEMENT hmacAlg EMPTY >
< !ATTLIST hmacAlg
alg (hmac-sha1 | hmac-md5) #REQUIRED>
< !ELEMENT authnMethods
(authnMethod)+ >
< !ELEMENT authnMethod
(digSig | passphrase) >
< !ELEMENT digSig
(certificate+, caCertificate*) >
< !ATTLIST digSig
alg (rsa) #REQUIRED>
< !ELEMENT certificate
(#PCDATA)* >
< !ATTLIST certificate
type (x509 | pkcs7) #REQUIRED
encoding (base64 | hex) #REQUIRED >
< !ELEMENT caCertificate
(#PCDATA)* >
< !ATTLIST caCertificate
type (x509 | pkcs7) #REQUIRED
encoding (base64 | hex) #REQUIRED >
< !ELEMENT passphrase EMPTY >
< !ATTLIST passphrase
passphraseId CDATA #REQUIRED >
< !ELEMENT session2
(nonce, keyAgreement, algorithm, authnMethod, authenticator) >
< !ATTLIST session2
version CDATA #REQUIRED
initiator CDATA #REQUIRED
responder CDATA #REQUIRED
sessionId CDATA #REQUIRED
hmac (hmac-sha1) #REQUIRED >
< !ELEMENT authenticator
(#PCDATA)* >
< !ATTLIST authenticator
encoding (base64 | hex) #REQUIRED>
< !ELEMENT session3
(authenticator, keyTransport*) >
< !ATTLIST session3
version CDATA #REQUIRED
initiator CDATA #REQUIRED
responder CDATA #REQUIRED
sessionId CDATA #REQUIRED
hmac (hmac-sha1) #REQUIRED >
</example>
</section3>
<section3 topic= "Generating And Sending the session1 PDU" >
<p >
The initiator's user agent employs the following algorithm to generate the session1 PDU:
</p>
<ul >
<li >
<p >
Appropriate values for the version, initiator, responder,
sessionId, and hmac attributes are assembled. The version of
this specification is '1.0'. The values of initiator and
responder MUST be the JIDs of the two participants,
respectively.
</p>
</li>
<li >
<p >
The nonce is prepared by first generating a string of 20
random octets (160 random bits). The octets are then
encoded into a string of 40 hex characters representing the
random string.
</p>
</li>
<li >
<p >
A Diffie-Hellman group is selected. The appropriate values
for g and p will be used to generate the initiator's public
key.
</p>
</li>
<li >
<p >
An ephemeral private key, x, is generated using g and p
for the selected group. This key MUST be generated using an
appropriate random number source. The corresponding public
key, g^x, is generated and encoded.
</p>
</li>
<li >
<p >
The desired set of confidentiality and HMAC cryptographic
algorithms is selected. The manner in which these
algorithms are selected and all related policy issues are
outside the scope of this specification.
</p>
</li>
<li >
<p >
The desired set of authentication algorithms is selected.
The manner in which these algorithms are selected and all
related policy issues are outside the scope of this
specification. When the digital signature form of
authentication is selected, the relevant end-entity
certificate and, optionally, a chain of CA certificates
representing a validation path, is assembled and encoded. A
set of trusted CA certificates MAY optionally be included
via caCertificate elements; if so, the set MUST include the
issuer of the initiator's end-entity certificate.
</p>
</li>
</ul>
<p >
These values are then used to prepare the XML session1 element;
this element is transmitted via the existing Jabber iq mechanism:
</p>
<example >
< iq from="initiator's JID" to="responder's JID" type="get" id="whatever">
< query xmlns="jabber:security:session">
< session1> ...< /session1>
< /query>
< /iq>
</example>
</section3>
<section3 topic= "Receiving And Processing the session1 PDU" >
<p >
The responder's user agent employs the following algorithm to process each session1 PDU:
</p>
<ul >
<li >
<p >
The version and hmac attributes are checked against the
values supported by the user agent. An unsupported version
results in an error code of 10000, and an unsupported hmac
results in an error code of 10001. The responder attribute MUST
match the JID of the receiver; a mismatch results in an error code of 10009
</p>
</li>
<li >
<p >
The nonce is decoded, and its length is checked. The nonce
may also be checked to detect replays. An invalid nonce
results in an error code of 10002.
</p>
</li>
<li >
<p >
The Diffie-Hellman group is checked against the values
supported by the user agent. An unsupported group results
in an error code of 10003
</p>
</li>
<li >
<p >
The desired confidentiality and HMAC cryptographic
algorithms are selected from the proposed set. The manner
in which these algorithms are selected and all related
policy issues are outside the scope of this specification.
If none of the proposed algorithms are supported, an error
code of 10004 occurs.
</p>
</li>
<li >
<p >
The desired authentication algorithm is selected from the
proposed set. The manner in which this algorithm is
selected and all related policy issues are outside the
scope of this specification. In the digital signature case,
the responder's end-entity
certificate MUST be issued by one of the trusted CAs listed
in the session1 PDU or by the same issuer as the
initiator's end-entity certificate. If none of the proposed
algorithms are supported, an error code of 10005 results.
If the responder does not have acceptable credentials, an
error code of 10006 occurs.
</p>
</li>
</ul>
<p >
If any errors occur during processing, the session negotiation
fails, and the error is communicated via the existing Jabber iq
mechanism:
</p>
<example >
< iq from="responder's JID" to="initiator's JID" type="error" id="whatever">
< error code="???"> ...< /error>
< /iq>
</example>
<p >
If no errors occur, then the responder's user agent proceeds with
the session2 PDU.
</p>
</section3>
<section3 topic= "Generating And Sending the session2 PDU" >
<p >
The responder's user agent employs the following algorithm to generate the session2 PDU:
</p>
<ul >
<li >
<p >
Appropriate values for the version, initiator, responder,
sessionId, and hmac attributes are assembled. The version of
this specification is '1.0'. The values of initiator and
responder MUST be the JIDs of the two participants,
respectively. The sessionId and hmac values MUST match the
sessionId and hmac values contained in the session1 PDU.
</p>
</li>
<li >
<p >
The nonce is prepared by first generating a string of 20
random octets (160 random bits). The octets are then
encoded into a string of 40 hex characters representing the
random string.
</p>
</li>
<li >
<p >
An ephemeral private key, y, is generated using g and p
for the group indicated by the session1 PDU. This key MUST
be generated using an appropriate random number source. The
corresponding public key, g^y, is generated and encoded.
</p>
</li>
<li >
<p >
The desired pair of confidentiality and HMAC cryptographic
algorithms is selected. The manner in which this pair is
selected and all related policy issues are outside the
scope of this specification.
</p>
</li>
<li >
<p >
The desired authentication algorithm is selected. The
manner in which this algorithm is selected and all related
policy issues are outside the scope of this specification.
When the digital signature form of authentication is
selected, the relevant end-entity certificate and,
optionally, a chain of CA certificates representing a
validation path, is assembled and encoded.
</p>
</li>
<li >
<p >
Based on the selected authentication algorithm, the
responder's authenticator is constructed. A digital signature algorithm
requires calculating:
</p>
<ul >
<li >
<p >
HK = hmac (initiator's nonce | responder's nonce, g^xy)
</p>
</li>
<li >
<p >
HASH_R = hmac (HK, version | sessionId | g^y | g^x | responder's JID)
</p>
</li>
</ul>
<p >
HASH_R is signed using the responder's private key and encoded in PKCS#1 format.
The PKCS#1 octets are then further encoded in base64 or hex.
</p>
<p >
The passphrase algorithm requires calculating:
</p>
<ul >
<li >
<p >
HK = hmac (hash (passphrase), initiator's nonce | responder's nonce)
</p>
</li>
<li >
<p >
HASH_R = hmac (HK, version | sessionId | g^y | g^x | responder's JID)
</p>
</li>
</ul>
<p >
The octets of HASH_R are simply encoded in base64 or hex.
</p>
<p >
The manner in which the responder's user agent gains access
to the responder's credentials is outside the scope of this
specification.
</p>
</li>
</ul>
<p >
These values are then used to prepare the XML session2 element;
this element is transmitted via the existing Jabber iq mechanism:
</p>
<example >
< iq from="responder's JID" to="initiator's JID" type="result" id="whatever">
< query xmlns="jabber:security:session">
< session2> ...< /session2>
< /query>
< /iq>
</example>
</section3>
<section3 topic= "Receiving And Processing the session2 PDU" >
<p >
The initiator's user agent employs the following algorithm to process each session2 PDU:
</p>
<ul >
<li >
<p >
The attribute values are checked against the values sent in
the session1 PDU. A mismatch results in an error code of
10008.
</p>
</li>
<li >
<p >
The nonce is decoded, and its length is checked. The nonce
may also be checked to detect replays. An invalid nonce
results in an error code of 10002.
</p>
</li>
<li >
<p >
The Diffie-Hellman group is checked against the value sent
in the session1 PDU. A mismatch results in an error code of 10003
</p>
</li>
<li >
<p >
The confidentiality and HMAC cryptographic algorithms are
validated against the set proposed in the session1 PDU. A
mismatch results in an error code of 10004.
</p>
</li>
<li >
<p >
The authentication algorithm is validated against the set
proposed in the session1 PDU. A mismatch results in an
error code of 10005.
</p>
</li>
<li >
<p >
The authenticator is verified. A failure results in an error code of 10007.
</p>
</li>
</ul>
<p >
If any errors occur during processing, the session negotiation
fails, and the error is communicated via the existing Jabber iq
mechanism:
</p>
<example >
< iq from="initiator's JID" to="responder's JID" type="error" id="whatever">
< error code="???"> ...< /error>
< /iq>
</example>
<p >
If no errors occur, then the initiator's user agent proceeds with the session3 PDU.
</p>
</section3>
<section3 topic= "Generating And Sending the session3 PDU" >
<p >
The initiator's user agent employs the following algorithm to generate the session3 PDU:
</p>
<ul >
<li >
<p >
Appropriate values for the version, initiator, responder,
sessionId, and hmac attributes are assembled. The version of
this specification is '1.0'. The values of initiator and
responder MUST be the JIDs of the two participants,
respectively. The sessionId and hmac values MUST match the
sessionId and hmac values contained in both the session1 and
session2 PDUs.
</p>
</li>
<li >
<p >
Based on the selected authentication algorithm, the
initiator's authenticator is constructed. A digital signature algorithm
requires calculating:
</p>
<ul >
<li >
<p >
HK = hmac (initiator's nonce | responder's nonce, g^xy)
</p>
</li>
<li >
<p >
HASH_I = hmac (HK, version | sessionId | g^x | g^y | initiator's JID)
</p>
</li>
</ul>
<p >
HASH_I is signed using the responder's private key and encoded in PKCS#1 format.
The PKCS#1 octets are then further encoded in base64 or hex.
</p>
<p >
The passphrase algorithm requires calculating:
</p>
<ul >
<li >
<p >
HK = hmac (hash (passphrase), initiator's nonce | responder's nonce)
</p>
</li>
<li >
<p >
HASH_I = hmac (HK, version | sessionId | g^x | g^y | initiator's JID)
</p>
</li>
</ul>
<p >
The octets of HASH_I are simply encoded in base64 or hex.
</p>
<p >
The manner in which the initiator's user agent gains access
to the initiator's credentials is outside the scope of this
specification.
</p>
</li>
<li >
<p >
A set of conversation keys may optionally be included in
the response. This should typically be the case since
security sessions are negotiated for the sole purpose of
key transport.
</p>
</li>
</ul>
<p >
These values are then used to prepare the XML session3 element;
this element is transmitted via the existing Jabber iq mechanism:
</p>
<example >
< iq from="initiator's JID" to="responder's JID" type="result" id="whatever">
< query xmlns="jabber:security:session">
< session3> ...< /session3>
< /query>
< /iq>
</example>
</section3>
<section3 topic= "Receiving And Processing the session3 PDU" >
<p >
The responder's user agent employs the following algorithm to process each session3 PDU:
</p>
<ul >
<li >
<p >
The attribute values are checked against the values sent in
the session2 PDU. A mismatch results in an error code of
10008.
</p>
</li>
<li >
<p >
The authenticator is verified. A failure results in an error code of 10007.
</p>
</li>
<li >
<p >
Any keys included in the PDU are processed and added to the user agent's key store.
</p>
</li>
</ul>
<p >
If any errors occur during processing, the session negotiation
fails, and the error is communicated via the existing Jabber iq
mechanism:
</p>
<example >
< iq from="responder's JID" to="initiator's JID" type="error" id="whatever">
< error code="???"> ...< /error>
< /iq>
</example>
</section3>
<section3 topic= "Session Key Material Derivation" >
<p >
TBA
</p>
</section3>
</section2>
<section2 topic= "Key Transport" >
<section3 topic= "Overview" >
<p >
Conversation keys are used to protect conversation data.
</p>
</section3>
<section3 topic= "The Key Transport Mechanism" >
<p >
Conversation keys are transported using the symmetric key wrap feature of
XML Encryption embedded in the keyTransport PDU.
</p>
</section3>
<section3 topic= "DTDs" >
<example >
< !ELEMENT keyTransport
(convId, payload, hmac) >
< !ATTLIST keyTransport
version CDATA #REQUIRED
initiator CDATA #REQUIRED
responder CDATA #REQUIRED
sessionId CDATA #REQUIRED >
< !ELEMENT convId
(#PCDATA)* >
< !-- These are actually instances of xenc:EncryptedKey -->
< !ELEMENT payload
(confKey, hmacKey) >
< !ELEMENT hmac
(#PCDATA)* >
< !ATTLIST hmac
encoding (base64 | hex) #REQUIRED >
</example>
</section3>
<section3 topic= "Generating And Sending the keyTransport PDU" >
<p >
The sender's user agent employs the following algorithm to generate the keyTransport PDU:
</p>
<ul >
<li >
<p >
Appropriate values for the version, initiator, responder, and
sessionId attributes are assembled. The version of
this specification is '1.0'. The values of initiator and
responder MUST be the JIDs of the two participants who negotiated the
security session, respectively, and they
MUST correspond to an existing security session.
</p>
</li>
<li >
<p >
The key's identifier, convId, is assembled.
</p>
</li>
<li >
<p >
The payload, which consists of the confidentiality key and the integrity key, is wrapped
in instances of xenc:EncryptedKey as follows:
</p>
<ul >
<li >
<p >
The Type attribute of the xenc:EncryptedKey element MUST indicate 'content'.
</p>
</li>
<li >
<p >
The Id, MimeType and Encoding attributes of the xenc:EncryptedKey element MUST NOT
be present.
</p>
</li>
<li >
<p >
The xenc:EncryptionMethod element MUST be present, and the Algorithm attribute
MUST indicate a valid symmetric key wrap algorithm. Furthermore, the
algorithm MUST be the same as was negotiated for the security session.
</p>
</li>
<li >
<p >
The ds:KeyInfo element MUST NOT be present. The key to use is SKc of the
security session.
</p>
</li>
<li >
<p >
The xenc:CipherData element MUST be present, and it MUST use the CipherValue choice.
</p>
</li>
</ul>
2007-02-16 00:20:39 -05:00
</li>
2006-10-02 18:22:13 -04:00
<li >
<p >
The HMAC is computed using SKi of the security session over the following values:
</p>
<ul >
<li >
<p >
the version attribute of the keyTransport element
</p>
</li>
<li >
<p >
the initiator attribute of the keyTransport element
</p>
</li>
<li >
<p >
the responder attribute of the keyTransport element
</p>
</li>
<li >
<p >
the sessionId attribute of the keyTransport element
</p>
</li>
<li >
<p >
the character string used to construct the body of the convId element
</p>
</li>
</ul>
</li>
</ul>
<p >
These values are then used to prepare the XML keyTransport element;
this element is transmitted via the existing Jabber iq mechanism:
</p>
<example >
< iq from="sender's JID" to="receiver's JID" type="set" id="whatever">
< query xmlns="jabber:security:keyTransport">
< keyTransport> ...< /keyTransport>
< /query>
< /iq>
</example>
</section3>
<section3 topic= "Receiving and Processing the keyTransport PDU" >
<p >
The receiver's user agent employs the following algorithm to process each keyTransport PDU:
</p>
<ul >
<li >
<p >
The values of the version, initiator, responder, and sessionId are validated; initiator,
responder, and sessionId MUST indicate an existing security session.
A version mismatch results in an error code of 10000; an invalid security session
results in an error of 10010.
</p>
</li>
<li >
<p >
The payload, which consists of the confidentiality key and the intergrity key, is unwrapped.
Any failures result in an error code of 10012.
</p>
</li>
<li >
<p >
The body of the HMAC element is decoded into the actual HMAC octet string.
</p>
</li>
<li >
<p >
The HMAC is validated. An invalid HMAC results in an error code of 10011.
</p>
</li>
<li >
<p >
The keys are added to the user agent's key store.
</p>
</li>
</ul>
<p >
If any errors occur during processing, the error is communicated via the existing Jabber iq
mechanism:
</p>
<example >
< iq from="receiver's JID" to="sender's JID" type="error" id="whatever">
< error code="???"> ...< /error>
< /iq>
</example>
</section3>
</section2>
<section2 topic= "Message Protection" >
<section3 topic= "Overview" >
<p >
The ultimate goal is, of course, the protection of conversation data. The protocol exchanges
described above allow the conversation participants to cryptographically protect their conversation data using the conversation keys that they share.
</p>
</section3>
<section3 topic= "The Message Protection Mechanism" >
<p >
A protected message is defined as a traditional Jabber message whose body content
is extended to include the transport of a cryptographically protected message body.
The two key features are
</p>
<ul >
<li >
<p >
First, the usual body element contains some arbitrary text. Those familiar with the
evolution of email protocols will recognize this trick as the same one used
when MIME was introduced.
</p>
</li>
<li >
<p >
Second, the message contains a Jabber x element defining the Jabber:security:message
namespace; this element transports the protected message.
</p>
</li>
</ul>
<p >
This mechanism has the advantages of allowing transparent integration with existing
Jabber servers and existing Jabber clients.
</p>
</section3>
<section3 topic= "DTD" >
<example >
< !ELEMENT protectedMessage
(securityLabel?, payload, hmac) >
< !ATTLIST protectedMessage
version CDATA #REQUIRED
from CDATA #REQUIRED
to CDATA #REQUIRED
convId #REQUIRED
seqNum #REQUIRED >
< !ELEMENT securityLabel
(#PCDATA)* >
< !-- this is actually an instance of xenc:EncryptedData -->
< !ELEMENT payload
(#PCDATA)* >
< !ELEMENT hmac
(#PCDATA)* >
< !ATTLIST hmac
encoding (base64 | hex) #REQUIRED >
</example>
</section3>
<section3 topic= "Generating And Sending the protectedMessage PDU" >
<p >
The sender's user agent employs the following algorithm to generate the protectedMessage PDU:
</p>
<ul >
<li >
<p >
Appropriate values for the version, from, to, convId, and
seqNum attributes are assembled. The version of
this specification is '1.0'. The value of convId MUST correspond to an existing, valid key.
</p>
</li>
<li >
<p >
The actual message body is encoded into a character string corresponding to a Jabber message body element. This character string is then wrapped in an instance of xenc:EncryptedData as follows:
</p>
<ul >
<li >
<p >
The Type attribute of the xenc:EncryptedData element MUST indicate 'element'.
</p>
</li>
<li >
<p >
The Id, MimeType and Encoding attributes of the xenc:EncryptedData element MUST NOT
be present.
</p>
</li>
<li >
<p >
The xenc:EncryptionMethod element MUST be present, and the Algorithm attribute
MUST indicate a valid block encryption algorithm.
</p>
</li>
<li >
<p >
The ds:KeyInfo element MUST NOT be present. The key to be used is the confidentiality
key indicated by the convId attribute.
</p>
</li>
<li >
<p >
The xenc:CipherData element MUST be present, and it MUST use the CipherValue choice.
</p>
</li>
</ul>
2007-02-16 00:20:39 -05:00
</li>
2006-10-02 18:22:13 -04:00
<li >
<p >
Using the HMAC key indicated by the convId attribute, the HMAC is computed
over the following values:
</p>
<ul >
<li >
<p >
the version attribute of the protectedMessage element
</p>
</li>
<li >
<p >
the from attribute of the protectedMessage element
</p>
</li>
<li >
<p >
the to attribute of the protectedMessage element
</p>
</li>
<li >
<p >
the convId attribute of the protectedMessage element
</p>
</li>
<li >
<p >
the seqNum attribute of the protectedMessage element
</p>
</li>
<li >
<p >
any securityLabel element
</p>
</li>
<li >
<p >
the character string used to construct the body of the payload element
</p>
</li>
</ul>
</li>
</ul>
<p >
These values are then used to prepare the XML protectedMessage element;
this element is transmitted via the existing Jabber message mechanism:
</p>
<example >
< message from="sender's JID" to="reveiver's JID" id="whatever">
< body> The real body is protected.< /body>
< x xmlns="jabber:security:message">
< protectedMessage> ...< /protectedMessage>
< /x>
< /iq>
</example>
</section3>
<section3 topic= "Receiving and Processing the protectedMessage PDU" >
<p >
The receiver's user agent employs the following algorithm to process each protectedMessage PDU:
</p>
<ul >
<li >
<p >
The values of the version, from, to, convId, and seqNum are validated.
A version mismatch results in an error code of 10000. An unknown convId
results in an error code of 10015. If replay protection is utilized, a
duplicate seqNum results in an error code of 10016.
</p>
</li>
<li >
<p >
The body of the HMAC element is decoded into the actual HMAC octet string.
</p>
</li>
<li >
<p >
The payload, which consists of the actual message body, is unwrapped.
Any failures result in an error code of 10012.
</p>
</li>
<li >
<p >
The HMAC is validated. An invalid HMAC results in an error code of 10011.
</p>
</li>
</ul>
<p >
If any errors occur during processing, the error is communicated via the existing Jabber iq
mechanism:
</p>
<example >
< iq from="receiver's JID" to="sender's JID" type="error" id="whatever">
< error code="???"> ...< /error>
< /iq>
</example>
</section3>
</section2>
<section2 topic= "Requesting Keys" >
2016-12-26 10:02:53 -05:00
<p > TBA</p>
2006-10-02 18:22:13 -04:00
</section2>
<section2 topic= "Conformance Profile" >
<p >
The following block encryption algorithms are required, as
specified by XML Encryption:
</p>
<ul >
<li >
<p >
http://www.w3.org/2001/04/xmlenc#tripledes-cbc
</p>
</li>
<li >
<p >
http://www.w3.org/2001/04/xmlenc#aes128-cbc
</p>
</li>
<li >
<p >
http://www.w3.org/2001/04/xmlenc#aes256-cbc
</p>
</li>
</ul>
<p >
The following symmetric key wrap algorithms are required, as
specified by XML Encryption:
</p>
<ul >
<li >
<p >
http://www.w3.org/2001/04/xmlenc#kw-tripledes
</p>
</li>
<li >
<p >
http://www.w3.org/2001/04/xmlenc#kw-aes128
</p>
</li>
<li >
<p >
http://www.w3.org/2001/04/xmlenc#kw-aes256
</p>
</li>
</ul>
</section2>
</section1>
<section1 topic= "Diffie-Hellman Groups" >
<p >
This protocol makes use of the following Diffie-Hellman groups adopted from IKE.
</p>
<section2 topic= "1024 bit Group, modp1024" >
<p >
The hexidecimal value of the prime, p, is
</p>
<example >
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
</example>
<p >
The decimal value of the generator, g, is 2.
</p>
</section2>
<section2 topic= "2048 bit Group, modp2048" >
<p >
The hexidecimal value of the prime, p, is
</p>
<example >
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
</example>
<p >
The decimal value of the generator, g, is 2.
</p>
</section2>
<section2 topic= "4096 bit Group, modp4096" >
<p >
The hexidecimal value of the prime, p, is
</p>
<example >
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
FFFFFFFF FFFFFFFF
</example>
<p >
The decimal value of the generator, g, is 2.
</p>
</section2>
<section2 topic= "8192 bit Group, modp8192" >
<p >
The hexidecimal value of the prime, p, is
</p>
<example >
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD
F8FF9406 AD9E530E E5DB382F 413001AE B06A53ED 9027D831
179727B0 865A8918 DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B
DB7F1447 E6CC254B 33205151 2BD7AF42 6FB8F401 378CD2BF
5983CA01 C64B92EC F032EA15 D1721D03 F482D7CE 6E74FEF6
D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F BEC7E8F3
23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328
06A1D58B B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C
DA56C9EC 2EF29632 387FE8D7 6E3C0468 043E8F66 3F4860EE
12BF2D5B 0B7474D6 E694F91E 6DBE1159 74A3926F 12FEE5E4
38777CB6 A932DF8C D8BEC4D0 73B931BA 3BC832B6 8D9DD300
741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C 5AE4F568
3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B
4BCBC886 2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A
062B3CF5 B3A278A6 6D2A13F8 3F44F82D DF310EE0 74AB6A36
4597E899 A0255DC1 64F31CC5 0846851D F9AB4819 5DED7EA1
B1D510BD 7EE74D73 FAF36BC3 1ECFA268 359046F4 EB879F92
4009438B 481C6CD7 889A002E D5EE382B C9190DA6 FC026E47
9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
</example>
<p >
The decimal value of the generator, g, is 2.
</p>
</section2>
</section1>
<section1 topic= "Security Considerations" >
<p >
This entire document is about security.
</p>
<p >
This version of the protocol deliberately incorporates only a minimal amount
of cryptographic choice. Examples of possible choices that can readily
added in future drafts include:
</p>
<ul >
<li >
<p >
Support for the Digital Signature Standard
</p>
</li>
<li >
<p >
Support for Elliptic Curve Cryptography
</p>
</li>
<li >
<p >
Additional symmetric algorithms
</p>
2007-02-16 00:20:39 -05:00
</li>
2006-10-02 18:22:13 -04:00
<li >
<p >
Additional hash algorithms
</p>
</li>
</ul>
<p >
Furthermore, additional credential formats, such as OpenPGP, may be addressed
in future drafts.
</p>
<p >
This version of the protocol includes a mechanism that derives a cryptographic key from a
passphrase shared by a community of users. It is impossible to overstate the security
issues that such a mechanism raises.
</p>
<p >
This version of the protocol does not include a specific rekeying capability. Data volumes
in IM environments are expected to be small, and the protocol prefers to simply instantiate
new conversation keys. It is straightforward to extend the security session protocol to
enable negotiation of a new key.
</p>
</section1>
<section1 topic= "Examples" >
<section2 topic= "Security Session" >
<example >
< iq from='initiator@some.tld'
to='responder@other.tld'
type='get'
id='whatever' >
< x xmlns='jabber:security:session>
< session1 version='1.0'
initiator='initiator@some.tld'
responder='responder@other.tld'
sessionId='session11223344556677@some.tld'
hmac='hmac-sha1'>
< nonce encoding='hex'>
...
< /nonce>
< keyAgreement>
< dh group='modp4096'>
< publicKey encoding='base64'>
...
< /publicKey>
< /dh>
< /keyAgreement>
< algorithms>
< algorithm>
< confAlg cipher='3des-cbc'/>
< hmacAlg alg='hmac-sha1'/>
< /algorithm>
< /algorithms>
< authnMethods>
< authnMethod>
< digSig alg='rsa'>
< certificate type='x509' encoding='base64'>
...
< /certificate>
< /digSig>
< /authnMethod>
< /authnMethods>
< /session1>
< /x>
< /iq>
< iq from='responder@other.tld'
to='initiator@some.tld'
type='result'
id='whatever' >
< x xmlns='jabber:security:session>
< session2 version='1.0'
initiator='initiator@some.tld'
responder='responder@other.tld'
sessionId='session11223344556677@some.tld'
hmac='hmac-sha1'>
< nonce encoding='hex'>
...
< /nonce>
< keyAgreement>
< dh group='modp4096'>
< publicKey encoding='base64'>
...
< /publicKey>
< /dh>
< /keyAgreement>
< algorithm>
< confAlg cipher='3des-cbc'/>
< hmacAlg alg='hmac-sha1'/>
< /algorithm>
< authnMethod>
< digSig alg='rsa'>
< certificate type='x509' encoding='base64'>
...
< /certificate>
< /digSig>
< /authnMethod>
< authenticator encoding='base64'>
...
< /authenticator>
< /session2>
< /x>
< /iq>
< iq from='initiator@some.tld'
to='responder@other.tld'
type='result'
id='whatever' >
< x xmlns='jabber:security:session>
< session3 version='1.0'
initiator='initiator@some.tld'
responder='responder@other.tld'
sessionId='session11223344556677@some.tld'
hmac='hmac-sha1'>
< authenticator encoding='base64'>
...
< /authenticator>
< /session3>
< /x>
< /iq>
</example>
</section2>
<section2 topic= "Key Transport" >
<example >
< iq type='set' >
< x xmlns='jabber:security:key>
< keyTransport version='1.0'
initiator='initiator@some.tld'
responder='responder@other.tld'
sessionId='session11223344556677@some.tld'>
< convId>
44d2d2d2d2@some.tld
< /convId>
< EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
< EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#kw-tripledes>
< /EncryptionMethod>
< CipherData>
< CipherValue>
...
< /CipherValue>
< /CipherData>
< /EncryptedKey>
< EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
< EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#kw-tripledes>
< /EncryptionMethod>
< CipherData>
< CipherValue>
...
< /CipherValue>
< /CipherData>
< /EncryptedKey>
< hmac encoding='hex'>
...
< /hmac>
< /keyTransport>
< /x>
< /iq>
</example>
</section2>
<section2 topic= "Message Protection" >
<example >
< message from='initiator@some.tld'
to='responder@other.tld'>
< body>
The real body is protected.
< /body>
< x xmlns='jabber:security:message'>
< protectedMessage version='1.0'
from='initiator@some.tld'
to='responder@other.tld'
convId='44d2d2d2d2@some.tld'
seqNum='1'>
< securityLabel>
Confidential
< /securityLabel>
< EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Element'>
< EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc>
< /EncryptionMethod>
< CipherData>
< CipherValue>
...
< /CipherValue>
< /CipherData>
< /EncryptedData>
< hmac encoding='hex'>
...
< /hmac>
< /protectedMessage>
< /x>
< /message>
</example>
</section2>
</section1>
<section1 topic= "References" >
<p >
"XML Encryption Syntax and Processing"; http://www.w3.org/TR/xmlenc-core
</p>
<p >
more to be added
</p>
</section1>
2006-10-03 18:46:54 -04:00
</xep>
