later carry out a dictionary attack.
- The use of DIGEST-MD5 and/or TLS counters this
vulnerability.
V2. An attacker can attempt to masquerade as a credential server
in an attempt to get a client to reveal information online
that allows for a later dictionary attack.
- The use of server or mutual authentication counters this
vulnerability.
V3. An attacker can attempt to get a client to decrypt a chosen
"ciphertext" and get the client to make use of the resulting
plaintext - the attacker may then be able to carry out a
dictionary attack (e.g. if the plaintext resulting from
"decryption" of a random string is used as a DSA private
key).
- The use of server or mutual authentication counters this
vulnerability.
V4. An attacker could overwrite a repository entry so that when
a user subsequently uses what they think is a good
credential, they expose information about their password
(and hence the "real" credential).
- Server implementations SHOULD take measures to protect the
database. Clients MAY use the ClientInfo field to store
e.g. a signature over the Credential, which they then verify
before using the private component.
V5. An attacker can copy a credential server’s repository and
carry out a dictionary attack.
- Server implementations SHOULD take measures to protect the
database.
V6. An attacker can attempt to masquerade as a client in an
attempt to get a server to reveal information that allows
for a later dictionary attack.
- The mutual authentication requirements of this protocol
counter this to a great extent. Additionally, credential
servers MAY choose to provide mechanisms that protect
against online dictionary attacks against user account
passwords, either by repeated access attempts to a single
user account (varying the password) or by attempting to
access many user accounts using the same password.
V7. An attacker can persuade a server that a successful login
has occurred, even if it hasn’t.
- Client authentication prevents this.
V8. (Upload) An attacker can overwrite someone else’s
credentials on the server.
- Only if they know the account password already (thanks to
mutual authentication).
V9. (When using password-based authentication) An attacker can
force a password change to a known (or "weak") password.
- Client authentication counters this.
V10. An attacker can attempt a man-in-the-middle attack for lots
of reasons...
- Mutual authentication and the encryption of subsequent
messages prevents this.
V11. User enters password instead of name.
- Since the DIGEST-MD5 mechanism is only used after TLS
tuning, the user’s name is also protected.
V12. An attacker could attempt various denial-of-service attacks.
- No specific countermeasures against DoS are proposed.
If the CreateAccountRequest message were sent over a cleartext
channel (or otherwise exposed), then an attacker could mount a
dictionary attack and recover the account password. This is why the
server authenticated TLS transport is REQUIRED for this operation.
If someone steals the server database they can launch a dictionary
attack. If the dictionary attack is successful, the attacker can
decrypt the user’s credentials. An attacker that has learned the
user’s account password can also upload new credentials, assuming the
user is authorized to modify the credentials, because someone who
knows the user’s account password is assumed to be the user.
However, if someone steals the server database and is unsuccessful at
obtaining the user’s account password through a dictionary attack,
they will be unable to upload new credentials.
Credential servers SHOULD incorporate measures that act to counter
denial of service attacks. In particular, they SHOULD drop inactive
connections and minimize the use of resources by un-authenticated
connections. A number of recommendations are listed at [DDOS].
Various operations in the SACRED protocol depend upon server
authentication being provided by server authenticated TLS. SACRED
clients SHOULD take care that the correct server is at the far end of
the TLS "pipe" by performing the checks which are listed in section
3.1 of RFC 2818 [RFC2818]. Clients SHOULD also include the optional
BEEP serverName field in their "start" message and SHOULD then ensure
that the BEEP serverName is consistent with the checks on the TLS
server described in RFC 2818. Failure to carry out these checks
could allow a spoof server access to a user’s credential.
If the SACRED account password were to be used in some other, less
secure protocol, using DIGEST-MD5, then it might appear to be the
case that a man-in-the-middle (MITM) attack could be mounted.
However, this is not the case since the DIGEST-MD5 client hash
includes a client-selected "digest-uri-value", which in SACRED’s case
will be "sacred/<serverName>". In a MITM attack, those values will
be something else. A MITM attack as described is therefore thwarted,
because digest-uri-value wouldn’t match what the SACRED server is
expecting.
6. References
6.1. Normative References
[BEEP] Rose, M., "The Blocks Extensible Exchange Protocol
Core", RFC 3080, March 2001.
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as
a SASL Mechanism", RFC 2831, May 2000.
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax
Standard," RSA Laboratories, June 2000.
[REQS] Arsenault, A. and S. Farrell, "Securely Available
Credentials - Requirements", RFC 3157, August 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol - Version
1.0", RFC 2246, January 1999.
[TLSAES] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", RFC
3268, June 2002.
[XMLDSIG] Eastlake, 3rd, D., Reagle, J. and D. Solo, "(Extensible
Mark-Up Language) XML-Signature Syntax and Processing",
RFC 3275, March 2002.
[XMLSCHEMA] "XML Schema Part 1: Structures", D. Beech, M. Maloney,
N. Mendelsohn, and H. Thompson. W3C Recommendation, May
2001. Available at http://www.w3.org/TR/2001/REC-
xmlschema-2-20010502/
6.2. Informative References
[DDOS] "Recommendations for the Protection against Distributed
Denial-of-Service Attacks in the Internet",
http://www.iwar.org.uk/comsec/resources/dos/ddos_en.htm
[RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
[RFC3760] Gustafson, D., Just, M. and M. Nystrom, "Securely
Available Credentials - Credential Server Framework,"
RFC 3760, April 2004.
[XKMS] Hallam-Baker, P. (ed), "XML Key Management
Specification", http://www.w3.org/TR/xkms2/
[XBULK] Hughes, M (ed), "XML Key Management Specification - Bulk
Operation", http://www.w3.org/TR/xkms2-xbulk/
Acknowledgements
Radia Perlman (radia.perlman@sun.com) and Charlie Kaufman
(charliek@microsoft.com) co-authored earlier versions of this
document. Michael Zolotarev (mzolotar@tpg.com.au) did much of the
initial work, adapting an earlier version to the use of SRP (though
SRP was subsequently dropped, much of the framework survives).
Marshall Rose (mrose@dbc.mtview.ca.us) helped out a lot, in
particular, with the BEEP profile. And the following people were
actively involved in the mailing list discussions leading to this
document:
David Chizmadia,
Dave Crocker (dcrocker@brandenburg.com),
Lawrence Greenfield (leg+@andrew.cmu.edu),
Dale Gustafson (degustafson@comcast.net),
Mike Just (just.mike@tbs-sct.gc.ca),
John Linn (jlinn@rsasecurity.com),
Neal McBurnett (neal@bcn.boulder.co.us),
Keith Moore (moore@cs.utk.edu),
RL "Bob" Morgan (rlmorgan@washington.edu),
Magnus Nystrom (magnus@rsasecurity.com),
Eamon O’Tuathail (eamon.otuathail@clipcode.com),
Gareth Richards (grichards@rsasecurity.com)
Of course, any and all errors remain the editor’s responsibility.
Appendix A: XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<schema
targetNamespace="urn:sacred-2002-12-19"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:sacred="urn:sacred-2002-12-19"
xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=
"http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
<!-- extensibility holes -->
<complexType name="ProcessInfoType">
<sequence maxOccurs="unbounded">
<any namespace="##other"/>
</sequence>
</complexType>
<element name="ProcessInfo" type="sacred:ProcessInfoType"/>
<complexType name="ClientInfoType">
<sequence maxOccurs="unbounded">
<any namespace="##other"/>
</sequence>
</complexType>
<element name="ClientInfo" type="sacred:ClientInfoType"/>
<!-- Where to put authenentication information -->
<complexType name="AuthInfoType">
<choice maxOccurs="unbounded">
<element name="DigestMD5AuthInfo">
<complexType>
<sequence>
<element name="PasswordVerifier" type="base64Binary"/>
<element name="Realm" type="string" />
</sequence>
</complexType>
</element>
<any namespace="##other"/>
</choice>
</complexType>
<element name="AuthInfo" type="sacred:AuthInfoType"/>
<!-- authentication mechanism parameters -->
<complexType name="AuthParamsType">
<choice maxOccurs="unbounded">
<element name=" DigestMD5AuthParams">
<complexType>
<sequence>
<element name="Realm" type="string"
minOccurs="1" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<any namespace="##other"/>
</choice>
</complexType>
<element name="AuthParams" type="sacred:AuthParamsType"/>
<!-- Protocol messsages -->
<!-- "account handling" operations -->
<!-- Information request -->
<element name="InfoRequest"/>
<element name="InfoResponse">
<complexType>
<sequence>
<element name="Status" type="string" minOccurs="0"/>
<element name="ServerId" type="string"/>
<element ref="sacred:AuthParams"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- Create Account Request -->
<element name="CreateAccountRequest">
<complexType>
<sequence>
<element name="UserId" type="string"/>
<element ref="sacred:AuthInfo"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- remove account request -->
<element name="RemoveAccountRequest">
<complexType>
<sequence>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- password change request -->
<element name="ModifyAccountRequest">
<complexType>
<sequence>
<element ref="sacred:AuthInfo"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- "run-time" operations -->
<!-- DownLoad Request -->
<element name="DownloadRequest">
<complexType>
<sequence>
<element name="CredentialSelector" type="string"
minOccurs="0"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- Download Response -->
<element name="DownloadResponse">
<complexType>
<sequence>
<element name="Status" type="string" minOccurs="0"/>
<element name="Credential" type="sacred:CredentialType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<!-- Upload request -->
<element name="UploadRequest">
<complexType>
<sequence>
<element name="Credential" type="sacred:CredentialType"/>
</sequence>
</complexType>
</element>
<element name="DeleteRequest">
<complexType>
<sequence>
<choice>
<sequence>
<element name="CredentialSelector" type="string"/>
<element name="LastModified" type="dateTime"
minOccurs="0"/>
</sequence>
<element name="All"/>
</choice>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- Credential related structures -->
<!-- A new ds:KeyInfo thing -->
<element name="SacredPKCS15" type="base64Binary"/>
<!-- credential -->
<complexType name="CredentialType">
<sequence>
<element name="CredentialSelector" type="string"/>
<element name="LastModified" type="dateTime"/>
<element name="Payload" type="ds:KeyInfoType" minOccurs="0"/>
<element name="TimeToLive" type="string" minOccurs="0"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
<element ref="sacred:ClientInfo" minOccurs="0"/>
</sequence>
</complexType>
</schema>
Appendix B: An Example of Tuning with BEEP
Here is what tuning BEEP for authentication and confidentiality
looks like using TLS and SASL’s DIGEST-MD5:
L: <wait for incoming connection>
I: <open connection>
... each peer sends a greeting indicating the services that
it offers ...
L: RPY 0 0 . 0 233
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri=’http://iana.org/beep/SASL/DIGEST-MD5’ />
L: <profile uri=’http://iana.org/beep/TLS’ />
L: <profile uri=’http://iana.org/beep/sacred’ />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
... the initiator starts a channel for TLS and piggybacks a request
to start the TLS negotiation ...
I: MSG 0 1 . 52 149
I: Content-Type: application/beep+xml
I:
I: <start number=’1’ serverName="sacred.example.org">
I: <profile uri=’http://iana.org/beep/TLS’>
I: <ready />
I: </profile>
I: </start>
I: END
... the listener creates the channel and piggybacks its readiness to
start TLS ...
L: RPY 0 1 . 233 112
L: Content-Type: application/beep+xml
L:
L: <profile uri=’http://iana.org/beep/TLS’>
L: <proceed />
L: </profile>
L: END
... upon receiving the reply, the initiator starts up TLS ...
... successful transport security negotiation ...
... a new greeting is sent (cf., Section 9 of RFC 3080), note that
the listener no longer advertises TLS (we’re already running
it)
L: RPY 0 0 . 0 186
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri=’http://iana.org/beep/SASL/DIGEST-MD5’ />
L: <profile uri=’http://iana.org/beep/sacred’ />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
... the initiator starts a channel for DIGEST-MD5 and piggybacks
initialization information for the mechanism ...
I: MSG 0 1 . 52 178
I: Content-Type: application/beep+xml
I:
I: <start number=’1’>
I: <profile uri=’http://iana.org/beep/SASL/DIGEST-MD5’>
I: <blob> ... </blob>
I: </profile>
I: </start>
I: END
... the listener creates the channel and piggybacks a challenge ...
L: RPY 0 1 . 186 137
L: Content-Type: application/beep+xml
L:
L: <profile uri=’http://iana.org/beep/SASL/DIGEST-MD5’>
L: <blob> ... </blob>
L: </profile>
L: END
... the initiator sends a response to the challenge ...
I: MSG 1 0 . 0 58
I: Content-Type: application/beep+xml
I:
I: <blob> ... </blob>
I: END
... the listener accepts the challenge and tells the initiator
that it is now authenticated ...
L: RPY 1 0 . 0 66
L: Content-Type: application/beep+xml
L:
L: <blob status=’complete’ />
L: END
... the initiator starts a channel for SACRED and piggybacks its
initial SACRED request ...
I: MSG 0 2 . 230 520
I: Content-Type: application/beep+xml
I:
I: <start number=’3’>
I: <profile uri=’http://iana.org/beep/sacred’ />
I: <?xml version="1.0" encoding="UTF-8"?>
I: <sacred:DownloadRequest
I: xmlns:sacred="urn:sacred-2002-12-19"
I: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
I: xsi:schemaLocation="urn:sacred-2002-12-19 sacred.xsd">
I: <CredentialSelector>
I: magnus-credentials</CredentialSelector>
I: </sacred:DownloadRequest>
I: </start>
I: END
... the listener creates the channel and piggybacks the response to
the initial SACRED request
L: RPY 0 2 . 323 805
L: Content-Type: application/beep+xml
L:
L: <profile uri=’http://iana.org/beep/sacred’ />
L: <?xml version="1.0" encoding="UTF-8"?>
L: <sacred:DownloadResponse
L: xmlns:sacred="urn:sacred-2002-12-19"
L: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
L: xsi:schemaLocation="urn:sacred-2002-12-19 sacred.xsd">
L: <Status>Success</Status>
L: <Credential>
L: <CredentialSelector>
L: magnus-credential</CredentialSelector>
L: <LastModified>2002-11-22T00:00:08Z</LastModified>
L: <Payload>
L: <sacred:SacredPKCS15
L: xmlns:sacred="urn:sacred-2002-12-19">GpM7
L: </sacred:SacredPKCS15>
L: </Payload>
L: </Credential>
L: </sacred:DownloadResponse>
L: </profile>
L: END
Appendix C: Provision SACRED using other Protocols
SACRED may be implemented in a non-BEEP environment, provided that
before any SACRED PDUs are sent, the application protocol must be
protected according to the security mandates provided in Section 2.3.
For example, if SACRED is provisioned as the payload of an
application protocol that supports SASL and TLS, then the appropriate
SASL and/or TLS negotiation must successfully occur before exchanging
Sacred PDUs.
Alternatively, if the application protocol doesn’t support SASL, then
one or more PDUs are defined to facilitate a SASL negotiation, and
the appropriate negotiation must occur before exchanging Sacred PDUs.
Editor’s Address
Stephen Farrell,
Distributed Systems Group,
Computer Science Department,
Trinity College Dublin,
IRELAND
Phone: +353-1-608-3070
EMail: stephen.farrell@cs.tcd.ie
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to