OAuth 2.0 Threat Model and Security Considerations
draft-ietf-oauth-v2-threatmodel-07
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6819.
|
|
|---|---|---|---|
| Authors | Torsten Lodderstedt , Mark McGloin , Phil Hunt | ||
| Last updated | 2012-10-02 (Latest revision 2012-08-16) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Telechat review
by Miguel García
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | Barry Leiba | ||
| IESG | IESG state | Became RFC 6819 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date |
(None)
Needs a YES. |
||
| Responsible AD | Stephen Farrell | ||
| IESG note | ** No value found for 'doc.notedoc.note' ** | ||
| Send notices to | oauth-chairs@tools.ietf.org, draft-ietf-oauth-v2-threatmodel@tools.ietf.org |
draft-ietf-oauth-v2-threatmodel-07
RFC:767
A STRUCTURED FORMAT FOR TRANSMISSION OF MULTI-MEDIA DOCUMENTS
Jonathan B. Postel
August 1980
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
(213) 822-1511
< INC-PROJECT, MMMSFS.NLS.21, >, 5-Sep-80 20:19 JBP ;;;;
Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
TABLE OF CONTENTS
PREFACE ........................................................ iii
1. INTRODUCTION ..................................................... 1
1.1. Motivation ................................................... 1
1.2. Scope ........................................................ 1
1.3. Terminology .................................................. 1
1.4. Document Description ......................................... 2
1.5. Other Work ................................................... 2
2. SPECIFICATION .................................................... 3
2.1. Document ..................................................... 3
2.2. Message Objects ............................................. 5
2.3. Body Structures ............................................. 13
2.3.1. Simple Elements ........................................... 13
2.3.2. Structured Text ........................................... 13
2.3.3. NLS File Example .......................................... 13
2.3.4. Multimedia Structures ..................................... 15
2.3.5. The Media ................................................. 21
2.3.6. TEXT ...................................................... 22
2.3.7. VOICE ..................................................... 22
2.3.8. FACSIMILE ................................................. 23
2.3.9. GRAPHICS .................................................. 24
3. EXAMPLES & SCENARIOS ............................................ 25
Example 1: Text Example .......................................... 25
Example 2: Multimedia Example .................................... 28
REFERENCES .......................................................... 31
Postel [Page i]
August 1980
A Structured Format for Transmission of Multi-Media Documents
[Page ii] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
PREFACE
This is the first edition of this format specification and should be
treated as a request for comments, advice, and suggestions. A great
deal of prior work has been done on computer aided message systems and
some of this is listed in the reference section. This specification was
shaped by many discussions with members of the ARPA research community,
and others interested in the development of computer aided message
systems. This document was prepared as part of the ARPA sponsored
Internetwork Concepts Research Project at ISI.
Jon Postel
Postel [Page iii]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Postel [Page iv]
RFC: 767 J. Postel
USC-ISI
August 1980
A STRUCTURED FORMAT FOR TRANSMISSION OF MULTI-MEDIA DOCUMENTS
1. INTRODUCTION
This document describes a format for transmitting structured data
representations of multimedia documents. This format is intended to be
used with the Internet Message Protocol in an internetwork message
delivery system. That system is designed to transmit messages between
processes in host computers called Message Processing Modules (MPMs).
MPMs are located in several networks and together constitute an
internetwork message delivery system. The Internet Message Protocol
defines a message as being composed of an Identification, a Command, and
a Document. This report is intended to define the format of such
Documents. The reader is assumed to be familiar with the Internet
Message Protocol [1].
1.1. Motivation
Computer applications are being implemented which interact with users
in a variety of media (text, graphics, facsimile, speech). As
computer devices become available to process multimedia information it
becomes desirable to use computers to exchange multimedia information
between programs and users via various mechanisms including computer
mail.
1.2. Scope
This format is intended to be used for the transmission of multimedia
documents in the internetwork message delivery system, but it is
thought that it has a wider applicability.
1.3. Terminology
The messages are routed by a process called the Message Processing
Module or MPM. Messages are created and consumed by User Interface
Programs (UIPs) in conjunction with users.
The basic unit transferred between MPMs is called a message. A
message is made up of a transaction identifier (which uniquely
identifies the message), a command (which contains the necessary
information for delivery), and document. The document is a data
structure.
For a personal letter the document body corresponds to the contents of
Postel [Page 1]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Introduction
the letter; the document header corresponds to the date line,
greeting, and signature.
For an inter-office memo the document body corresponds to the text;
the document header corresponds to the header of the memo.
The commands correspond to the information used by the Post Office or
the mail room to route the letter or memo. Some of the information in
the command is supplied by the UIP.
1.4. Document Description
The document is composed of fields. Each field will carry an
identifying name. Typical fields are DATE, TO, SUBJECT, and BODY.
Most of the fields will be very simple, some will be complex. The
body field may be quite complex. For example, the DATE is a very
constrained character string specifying the date and time in ISO
format. A more complex example is the TO field which is a list of
mailboxes, where a mailbox is itself a property list of address
information items. The BODY may be simply a character string, or a
very structured collection of data representing information in
different media.
The BODY may be structured to indicate a controlled presentation of
multimedia information. There is provision for the inclusion of text,
graphics, facsimile, and voice information in the body of documents.
The presentation of information units may sequential, independent, or
simultaneous.
1.5. Other Work
This protocol the benefited from the earlier work on message protocols
in the ARPA Network [2,3,4,5,6], and the ideas of others about the
design of computer message systems [7,8,9,10,11,12,13,14,15,16,17,18].
[Page 2] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
2. SPECIFICATION
The structured format of a document is built on the basic data elements
used in the Internet Message Protocol [1].
2.1. Document
The document is a property list of <name,value> pairs called fields.
A few fields are specifically required and many are optional. Some of
the field values are simple and a few are quite complicated. In
particular the body value may be highly structured.
Older message systems have considered the document to be divided into
a header and a body, and have used keywords to indicate specific
header fields (e.g., date, to, subject). Roughly speaking, this
functionality is provided in this new structured format by considering
the name part of the <name,value"
allows iFrames for a list of trusted origins.
This is a countermeasure against the following threats:
o Clickjacking attacks
5.2.3. Client authentication and authorization
As described in Section 3 (Security Features), clients are
identified, authenticated and authorized for several purposes, such
as a
o Collate requests to the same client,
o Indicate to the user the client is recognized by the authorization
server,
o Authorize access of clients to certain features on the
authorization or resource server, and
o Log a client identifier to log files for analysis or statistics.
Due to the different capabilities and characteristics of the
different client types, there are different ways to support these
objectives, which will be described in this section. Authorization
server providers should be aware of the security policy and
deployment of a particular clients and adapt its treatment
accordingly. For example, one approach could be to treat all clients
as less trustworthy and unsecure. On the other extreme, a service
provider could activate every client installation individually by an
administrator and that way gain confidence in the identity of the
software package and the security of the environment the client is
installed in. And there are several approaches in between.
5.2.3.1. Don't issue secrets to client with inappropriate security
policy
Authorization servers should not issue secrets to clients that cannot
protect secrets ("public" clients). This reduces probability of the
server treating the client as strongly authenticated.
Lodderstedt, et al. Expires February 15, 2013 [Page 57]
Internet-Draft OAuth 2.0 Security August 2012
For example, it is of limited benefit to create a single client id
and secret which is shared by all installations of a native
application. Such a scenario requires that this secret must be
transmitted from the developer via the respective distribution
channel, e.g. an application market, to all installations of the
application on end-user devices. A secret, burned into the source
code of the application or a associated resource bundle, is not
protected from reverse engineering. Secondly, such secrets cannot be
revoked since this would immediately put all installations out of
work. Moreover, since the authorization server cannot really trust
the client's identifier, it would be dangerous to indicate to end-
users the trustworthiness of the client.
There are other ways to achieve a reasonable security level, as
described in the following sections.
5.2.3.2. Public clients without secret require user consent
Authorization servers should not allow automatic authorization for
public clients. The authorization may issue an individual client id,
but should require that all authorizations are approved by the end-
user. This is a countermeasure for clients without secret against
the following threats:
o Impersonation of public client applications
5.2.3.3. Client_id only in combination with redirect_uri
The authorization may issue a client_id and bind the client_id to a
certain pre-configured redirect_uri. Any authorization request with
another redirection URI is refused automatically. Alternatively, the
authorization server should not accept any dynamic redirection URI
for such a client_id and instead always redirect to the well-known
pre-configured redirection URI. This is a countermeasure for clients
without secrets against the following threats:
o Cross-site scripting attacks
o Impersonation of public client applications
5.2.3.4. Installation-specific client secrets
An authorization server may issue separate client identifiers and
corresponding secrets to the different installations of a particular
client (i.e. software package). The effect of such an approach would
be to turn otherwise "public" clients back into "confidential"
clients.
Lodderstedt, et al. Expires February 15, 2013 [Page 58]
Internet-Draft OAuth 2.0 Security August 2012
For web applications, this could mean to create one client_id and
client_secret per web site a software package is installed on. So
the provider of that particular site could request client id and
secret from the authorization server during setup of the web site.
This would also allow to validate some of the properties of that web
site, such as redirection URI, website URL, and whatever proofs
useful. The web site provider has to ensure the security of the
client secret on the site.
For native applications, things are more complicated because every
copy of a particular application on any device is a different
installation. Installation-specific secrets in this scenario will
require
1. Either to obtain a client_id and client_secret during download
process from the application market, or
2. During installation on the device.
Either approach will require an automated mechanism for issuing
client ids and secrets, which is currently not defined by OAuth.
The first approach would allow to achieve a certain level of trust in
the authenticity of the application, whereas the second option only
allows to authenticate the installation but not to validate
properties of the client. But this would at least help to prevent
several replay attacks. Moreover, installation-specific client_id
and secret allow to selectively revoke all refresh tokens of a
specific installation at once.
5.2.3.5. Validation of pre-registered redirect_uri
An authorization server should require all clients to register their
redirect_uri and the redirect_uri should be the full URI as defined
in [I-D.ietf-oauth-v2]. The way this registration is performed is
out of scope of this document. As per the core spec, every actual
redirection URI sent with the respective client_id to the end-user
authorization endpoint must match the registered redirection URI.
Where it does not match, the authorization server should assume the
inbound GET request has been sent by an attacker and refuse it.
Note: the authorization server should not redirect the user agent
back to the redirection URI of such an authorization request.
Validating the pre-registered redirect_uri is a countermeasure
against the following threats:
o Authorization code leakage through counterfeit web site: allows to
detect attack attempts already after first redirect to end-user
authorization endpoint (Section 4.4.1.7).
Lodderstedt, et al. Expires February 15, 2013 [Page 59]
Internet-Draft OAuth 2.0 Security August 2012
o Open Redirector attack via client redirection endpoint. (
Section 4.1.5. )
o Open Redirector phishing attack via authorization server
redirection endpoint ( Section 4.2.4 )
The underlying assumption of this measure is that an attacker will
need to use another redirection URI in order to get access to the
authorization code. Deployments might consider the possibility of an
attacker using spoofing attacks to a victims device to circumvent
this security measure.
Note: Pre-registering clients might not scale in some deployments
(manual process) or require dynamic client registration (not
specified yet). With the lack of dynamic client registration, pre-
registered "redirect_uri" only works for clients bound to certain
deployments at development/configuration time. As soon as dynamic
resource server discovery is required, the pre-registered
redirect_uri may be no longer feasible.
5.2.3.6. Client secret revocation
An authorization server may revoke a client's secret in order to
prevent abuse of a revealed secret.
Note: This measure will immediately invalidate any authorization code
or refresh token issued to the respective client. This might be
unintentionally impact client identifiers and secrets used across
multiple deployments of a particular native or web application.
This a countermeasure against:
o Abuse of revealed client secrets for private clients
5.2.3.7. Use strong client authentication (e.g. client_assertion /
client_token)
By using an alternative form of authentication such as client
assertion [I-D.ietf-oauth-assertions], the need to distribute a
client_secret is eliminated. This may require the use of a secure
private key store or other supplemental authentication system as
specified by the client assertion issuer in its authentication
process.
5.2.4. End-user authorization
This secion involves considerations for authorization flows involving
the end-user.
Lodderstedt, et al. Expires February 15, 2013 [Page 60]
Internet-Draft OAuth 2.0 Security August 2012
5.2.4.1. Automatic processing of repeated authorizations requires
client validation
Authorization servers should NOT automatically process repeat
authorizations where the client is not authenticated through a client
secret or some other authentication mechanism such as a signed
authentication assertion certificate (Section 5.2.3.7 Use strong
client authentication (e.g. client_assertion / client_token)) or
validation of a pre-registered redirect URI (Section 5.2.3.5
Validation of pre-registered redirection URI ).
5.2.4.2. Informed decisions based on transparency
The authorization server should clearly explain to the end-user what
happens in the authorization process and what the consequences are.
For example, the user should understand what access he is about to
grant to which client for what duration. It should also be obvious
to the user, whether the server is able to reliably certify certain
client properties (web site URL, security policy).
5.2.4.3. Validation of client properties by end-user
In the authorization process, the user is typically asked to approve
a client's request for authorization. This is an important security
mechanism by itself because the end-user can be involved in the
validation of client properties, such as whether the client name
known to the authorization server fits the name of the web site or
the application the end-user is using. This measure is especially
helpful in situations where the authorization server is unable to
authenticate the client. It is a countermeasure against:
o Malicious application
o A client application masquerading as another client
5.2.4.4. Binding of authorization code to client_id
The authorization server should bind every authorization code to the
id of the respective client which initiated the end-user
authorization process. This measure is a countermeasure against:
o replay of authorization codes with different client credentials
since an attacker cannot use another client_id to exchange an
authorization code into a token
o Online guessing of authorization codes
Note: This binding should be protected from unauthorized
Lodderstedt, et al. Expires February 15, 2013 [Page 61]
Internet-Draft OAuth 2.0 Security August 2012
modifications (e.g. using protected memory and/or a secure database).
5.2.4.5. Binding of authorization code to redirect_uri
The authorization server should be able to bind every authorization
code to the actual redirection URI used as redirect target of the
client in the end-user authorization process. This binding should be
validated when the client attempts to exchange the respective
authorization code for an access token. This measure is a
countermeasure against authorization code leakage through counterfeit
web sites since an attacker cannot use another redirection URI to
exchange an authorization code into a token.
5.3. Client App Security
This section deals with considerations for client applications.
5.3.1. Don't store credentials in code or resources bundled with
software packages
Because of the numbers of copies of client software, there is limited
benefit to create a single client id and secret which is shared by
all installations of an application. Such an application by itself
would be considered a "public" client as it cannot be presumed to be
able to keep client secrets. A secret, burned into the source code
of the application or an associated resource bundle, cannot be
protected from reverse engineering. Secondly, such secrets cannot be
revoked since this would immediately put all installations out of
work. Moreover, since the authorization server cannot really trust
the client's identifier, it would be dangerous to indicate to end-
users the trustworthiness of the client.
5.3.2. Standard web server protection measures (for config files and
databases)
Use standard web server protection measures - Section 5.3.2
5.3.3. Store secrets in a secure storage
The are different way to store secrets of all kinds (tokens, client
secrets) securely on a device or server.
Most multi-user operating systems segregate the personal storage of
the different system users. Moreover, most modern smartphone
operating systems even support to store app-specific data in separate
areas of the file systems and protect it from access by other
applications. Additionally, applications can implements confidential
data itself using a user-supplied secret, such as PIN or password.
Lodderstedt, et al. Expires February 15, 2013 [Page 62]
Internet-Draft OAuth 2.0 Security August 2012
Another option is to swap refresh token storage to a trusted backend
server. This mean in turn requires a resilient authentication
mechanisms between client and backend server. Note: Applications
should ensure that confidential data is kept confidential even after
reading from secure storage, which typically means to keep this data
in the local memory of the application.
5.3.4. Utilize device lock to prevent unauthorized device access
On a typical modern phone, there are many "device lock" options which
can be utilized to provide additional protection where a device is
stolen or misplaced. These include PINs, passwords and other
biomtric featres such as "face recognition". These are not equal in
the level of security they provide.
5.3.5. Link state parameter to user agent session
The state parameter is used to link client requests and prevent CSRF
attacks, for example against the redirection URI. An attacker could
inject their own authorization code or access token, which can result
in the client using an access token associated with the attacker's
protected resources rather than the victim's (e.g. save the victim's
bank account information to a protected resource controlled by the
attacker).
The client should utilize the "state" request parameter to send the
authorization server a value that binds the request to the user-
agent's authenticated state (e.g. a hash of the session cookie used
to authenticate the user-agent) when making an authorization request.
Once authorization has been obtained from the end-user, the
authorization server redirects the end-user's user-agent back to the
client with the required binding value contained in the "state"
parameter.
The binding value enables the client to verify the validity of the
request by matching the binding value to the user- agent's
authenticated state.
5.4. Resource Servers
The following section details security considerations for resource
servers.
5.4.1. Authorization headers
Authorization headers are recognized and specially treated by HTTP
proxies and servers. Thus the usage of such headers for sending
access tokens to resource servers reduces the likelihood of leakage
Lodderstedt, et al. Expires February 15, 2013 [Page 63]
Internet-Draft OAuth 2.0 Security August 2012
or unintended storage of authenticated requests in general and
especially Authorization headers.
5.4.2. Authenticated requests
An authorization server may bind tokens to a certain client
identifier and enable resource servers to be able to validate that
association on resource access. This will require the resource
server to authenticate the originator of a request as the legitimate
owner of a particular token. There are a couple of options to
implement this countermeasure:
o The authorization server may associate the client identifier with
the token (either internally or in the payload of an self-
contained token). The client then uses client certificate-based
HTTP authentication on the resource server's endpoint to
authenticate its identity and the resource server validates the
name with the name referenced by the token.
o same as before, but the client uses his private key to sign the
request to the resource server (public key is either contained in
the token or sent along with the request)
o Alternatively, the authorization server may issue a token-bound
secret, which the client uses to MAC (message authentication code)
the request (see [I-D.ietf-oauth-v2-http-mac]). The resource
server obtains the secret either directly from the authorization
server or it is contained in an encrypted section of the token.
That way the resource server does not "know" the client but is
able to validate whether the authorization server issued the token
to that client
Authenticated requests are a countermeasure against abuse of tokens
by counterfeit resource servers.
5.4.3. Signed requests
A resource server may decide to accept signed requests only, either
to replace transport level security measures or to complement such
measures. Every signed request should be uniquely identifiable and
should not be processed twice by the resource server. This
countermeasure helps to mitigate:
o modifications of the message and
o replay attempts
Lodderstedt, et al. Expires February 15, 2013 [Page 64]
Internet-Draft OAuth 2.0 Security August 2012
5.5. A Word on User Interaction and User-Installed Apps
OAuth, as a security protocol, is distinctive in that its flow
usually involves significant user interaction, making the end user a
part of the security model. This creates some important difficulties
in defending against some of the threats discussed above. Some of
these points have already been made, but it's worth repeating and
highlighting them here.
o End users must understand what they are being asked to approve
(see Section Section 5.2.4.1). Users often do not have the
expertise to understand the ramifications of saying "yes" to an
authorization request. and are likely not to be able to see subtle
differences in wording of requests. Malicious software can
confuse the user, tricking the user into approving almost
anything.
o End-user devices are prone to software compromise. This has been
a long-standing problem, with frequent attacks on web browsers and
other parts of the user's system. But with increasing popularity
of user-installed "apps", the threat posed by compromised or
malicious end-user software is very strong, and is one that is
very difficult to mitigate.
o Be aware that users will demand to install and run such apps, and
that compromised or malicious ones can steal credentials at many
points in the data flow. They can intercept the very user login
credentials that OAuth is designed to protect. They can request
authorization far beyond what they have led the user to understand
and approve. They can automate a response on behalf of the user,
hiding the whole process. No solution is offered here, because
none is known; this remains in the space between better security
and better usability.
o Addressing these issues by restricting the use of user-installed
software may be practical in some limited environments, and can be
used as a countermeasure in those cases. Such restrictions are
not practical in the general case, and mechanisms for after-the-
fact recovery should be in place.
o While end users are mostly incapable of properly vetting
applications they load onto their devices, those who deploy
Authorization Servers might have tools at their disposal to
mitigate malicious Clients. For example, a well run Authorization
Server must only assert client properties to the end-user it is
effectively capable of validating, explicitely point out which
properties it cannot validate, and indicate to the end-user the
risk associated with granting access to the particular client.
Lodderstedt, et al. Expires February 15, 2013 [Page 65]
Internet-Draft OAuth 2.0 Security August 2012
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Acknowledgements
We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu,
Francisco Corella, Peifung E Lam, Shane B Weeden, Skylar Woodward,
Niv Steingarten, Tim Bray, and James H. Manger for their comments and
contributions.
8. References
8.1. Informative References
[I-D.ietf-oauth-v2]
Hardt, D., "The OAuth 2.0 Authorization Framework",
draft-ietf-oauth-v2-31 (work in progress), August 2012.
[I-D.ietf-oauth-v2-bearer]
Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage",
draft-ietf-oauth-v2-bearer-23 (work in progress),
August 2012.
8.2. Informative References
[I-D.gondrom-x-frame-options]
Ross, D. and T. Gondrom, > pair to be a keyword. In addition,
this new structured format eliminates the separate treatment of the
body.
It is impossible to foresee the many forms documents will take so the
standard for a document header must be flexible. The approach here is
to define a set of basic fields and allow addition of whatever fields
are necessary. Features added in this fashion may not be understood
by others.
The minimum document is a property list of the following fields:
Name Value
---- -----
DATE date string (name)
SENDER a mailbox
SUBJECT subject string (text)
BODY a data structure
A typical document is a property list containing the following fields:
Name Value
---- -----
DATE date string (name)
SENDER a mailbox
FROM list of mailboxes
TO list of mailboxes
CC list of mailboxes
SUBJECT subject string (text)
BODY a data structure
Postel [Page 3]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
An elaborate document might contain the following fields:
Name Value
---- -----
DATE date string (name)
SENDER a mailbox
FROM list of mailboxes
TO list of mailboxes
CC list of mailboxes
BCC list of mailboxes
REPLY-TO list of mailboxes
SUBJECT subject string (text)
COMMENTS comment string (text)
MESSAGE-ID message identifier of this message (text)
IN-REPLY-TO message identifier of previous message (text)
REFERENCES message identifiers of other messages (text)
KEYWORDS key terms used in this message (text)
BODY a data structure
One of the key objects is the mailbox. It appears in the sender,
from, to, cc, bcc, and reply-to fields. The mailbox is a property
list of objects that combine to specify a destination recipient for a
message. Most of the <name,value> pairs that make up a mailbox are
identical to those used in the deliver command in the Internet Message
Protocol [1]. A few additional <name,value> pairs are defined for use
in a mailbox in the document context. In particular, there is a field
for the real name of a person in contrast to the "user name" which
identifies a computer account.
In addition there is a field to specify a distribution group name.
Such group names are used to indicate that a document is being sent to
a group of recipients. This essentially presents an alternate form
for a mailbox which consists of the single <name,value> pair for the
group name. There is no required relationship between a group name
mailbox and other mailboxes in the same list.
For example, all of the following situations are allowed:
. a mailbox list consisting of a single mailbox specifying a
particular user,
. a mailbox list consisting of a single mailbox with a group name,
. a mailbox list consisting of a mailbox with a group name and a
mailbox specifying a particular user, with either the user in or
not in the group,
. a mailbox list consisting of a mailbox with a group name and a
[Page 4] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
several mailboxes specifying a particular users, with some users
in the group and some not,
. a mailbox list consisting of several mailboxes specifying group
names and a several mailboxes specifying a particular users, with
some users in the groups and some not.
2.2. Message Objects
In the documents of messages, we use a set of objects such as mailbox
or date. These objects are encoded in basic data elements. Some
objects are simple things like integers or character strings, other
objects are more complex things like lists or property lists. The
following is a list of the objects used in messages. The object
descriptions are in alphabetical order.
Account
The account information. Represented by a name element.
Address
Address is intended to contain the minimum information necessary to
identify a user, and no more (compare with mailbox).
An address is a property list which contains the following
<name,value> pairs:
name description
---- -----------
NET network name
HOST host name
USER user name
or:
name description
---- -----------
MPM mpm-identifier
USER user name
Answer
A yes (true) or no (false) answer to a question. Represented by a
boolean element.
Postel [Page 5]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
BCC
A list of mailboxes. The addresses of those who receive "blind
carbon copies" of the message.
Body
A data structure. This may be as simple as a character string
(represented by a name or text element), or complex structure of
lists. It may be encrypted in part or in whole. Section 3.3
describes some possible structured bodies.
C
A character. Represented by a name element.
CC
A list of mailboxes. When copies of a message are sent to others in
addition to the addresses in the To object, those to whom the copies
are sent will have their addresses recorded here.
City
A city. Represented by a name element.
Comments
A comment string. Represented by a text element.
Count
A count of items of some sort. Represented by a integer element.
Country
A country. Represented by a name element.
[Page 6] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
Date
The date and time are represented according to the International
Standards Organization (ISO) recommendations [19,20,21]. Taken
together the ISO recommendations 2014, 3307, and 4031 result in the
following representation of the date and time:
yyyy-mm-dd-hh:mm:ss,fff+hh:mm
Where yyyy is the four-digit year, mm is the two-digit month, dd is
the two-digit day, hh is the two-digit hour in 24 hour time, mm is
the two-digit minute, ss is the two-digit second, and fff is the
decimal fraction of the second. To this basic date and time is
appended the offset from Greenwich as plus or minus hh hours and mm
minutes.
The time is local time and the offset is the difference between
local time and Coordinated Universal Time (UTC). To convert from
local time to UTC algebraically subtract the offset from the local
time.
For example, when the time in
Los Angeles is 14:25:00-08:00
the UTC is 22:25:00
or when the time in
Paris is 11:43:00+01:00
the UTC is 10:43:00
Device
A device name. Represented by a name element.
Document
A property list of fields.
Distribution Group
An distribution group is a property list which contains the
following <name,value> pair:
name description
---- -----------
GROUP document distribution group name
This construct is used so that a distribution group will be a
special case of a mailbox.
Postel [Page 7]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
Facsimile Structure
A facsimile data structure. Represented by a property list.
File
A file name. Represented by a name element.
Format
A format indicator. Represented by a name element.
From
A list of mailboxes. The From is the name of the author of a
document.
Graphics Structure
A graphics data structure. Represented by a property list.
Group
A document distribution group name. Represented by a name element.
Host
A host name. Represented by a name element.
Ident
The identifier of a person, usually their initials. Represented by
a name element.
In-Reply-To
The message identifier of previous message. Represented by a text
element.
Internet Address
This identifies a host in the ARPA internetwork environment. The
internet address is a 32 bit number, the higher order 8 bits
identify the network, and the lower order 24 bits identify the host
on that network [22]. For use in this format the internet address
is divided into eight bit fields and the value of each field is
represented in decimal digits. For example, the ARPANET address of
ISIE is 167837748 and is represented as 10,1,0,52. Further, this
[Page 8] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
representation may be extended to include an address within a host,
such as the TCP port of an MPM, for example, 10,1,0,52,0,45.
Keywords
The key terms used in this message. Represented by a text element.
Mailbox
This is the destination address of a user of the internetwork mail
system. Mailbox contains information such as network, host,
location, and local user identifier of the recipient of the message.
The mailbox may contain information in addition to the minimum
required for delivery.
As an example, when one sends a message to someone for the first
time, he may include many items to aid in identifying the correct
recipient. However, once he gets a reply to this message, the reply
will contain an Address (as opposed to Mailbox) which may be used
from then on.
A mailbox is a property list. A mailbox might contain the
following <name,value> pairs:
name description
---- -----------
MPM mpm-identifier
NET network name
HOST host name
PORT address of MPM within the host
USER user name (computer account name)
PERSON the real name of a person
GROUP document distribution group
ORG organization name
CITY city
STATE state
COUNTRY country
ZIP zip code
PHONE phone number
The minimum mail box is an Address or a Distribution Group.
Message-ID
The message identifier of this message. This is not related to the
MPM message identification, but is a UIP long term document
identifier. Represented by a text element.
Postel [Page 9]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
MPM-Identifier
The internetwork address of an MPM. This may be the ARPA Internet
Address or an X.121 Public Data Network Address [23]. The
mpm-identifier is a property list which has one <name,value> pair.
This unusual structure is used so that it will be easy to determine
the type of address used.
Net
A network name. Represented by a name element.
NLS Block
The information in an NLS node. Represented by a property list.
NLS Node
An NLS block and substructure. Represented by a property list.
NLS Substructure
A list of NLS nodes. Represented by a list.
Org
An organization name. Represented by a name element.
Paragraph
A paragraph of text. Represented by a text element.
Parcel
The basic unit of voice data. Represented by a bitstr element.
Person
The real name of a person. Represented by a name element.
Password
A password. Represented by a name element.
Phone
A phone number. Represented by a name element.
[Page 10] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
Pointer
A pointer to information stored outside this data structure. A
property list containing the information necessary to locate the
external data, the information necessary to gain access to the
external data, and the information necessary to apply the correct
interpretation to the external data. For example, this might
include:
name description
---- -----------
NET network name
HOST host name
FILE file name
USER user name (computer account name)
PASSWORD password
ACCOUNT account
FORMAT format
Port
The address of MPM within the host. Represented by a name element.
Presentation Descriptor
A property list of <name,value> pairs, where the name is an order
indicator, and the value is a presentation element. The order
indicators are SEQUENTIAL, SIMULTANEOUS, and INDEPENDENT.
Presentation Element
A property list of media structures.
Protocol
The name of the coding scheme used for a medium. Represented by a
name element.
References
The message identifiers of other messages. Represented by a list of
text elements.
Reply-To
A list of mailboxes. Sometimes it will be desired to direct the
replies of a message to some address other than the from or the
sender. In such a case the reply-to object can be used.
Postel [Page 11]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
R 450 Block
The unit of Rapicom 450 data (585 bits). Represented by a bitstr
element.
Sender
A mailbox. The sender will contain the address of the individual
who sent the message. In some cases this is NOT the same as the
author of the message. Under such a condition, the author should be
specified in the from object.
SID
An NLS statement indetifier. Represented by a integer element.
State
A state name. Represented by a name element.
Subject
The subject of the message. Represented by a text element.
Text Structure
A text data structure. Represented by a property list.
To
A list of mailboxes. To identifies the addressees of the message.
User
A user name (computer account name). Represented by a name element.
Version
A version number. Represented by a index element.
Vocoder
A vocoder name. Represented by a name element.
Voice Structure
A voice data structure. Represented by a property list.
[Page 12] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
X121 Address
This identifies a host in the Public Data Network environment. When
used as a part of identifier, it identifies the originating host of
a message. The X121 address is a sequence of up to 14 digits [23].
For use in this format the X121 address is represented in decimal
digits.
ZIP
A zip code. Represented by a name element.
2.3. Body Structures
2.3.1. Simple Elements
The body could simply be a single data element. For example a
single text element can represent a lengthy character string.
<body> := TEXT
or
text:"this is the actual text of the body"
2.3.2. Structured Text
The body could be thought of as paragraphs, where each paragraph is
represented by a text element. The paragraphs are then the elements
of a list.
<body> := LIST (<paragraph>, <paragraph>, ...)
<paragraph> := TEXT
or
list:(text:"paragraph one", text:"paragraph two", ...)
2.3.3. NLS File Example
It is possible to represent the data from NLS files in this format.
NLS is a large multipurpose system which operates on structured data
files. The files are tree structured, and there is data associated
with each node of the tree. There are several fields associated
with each node as well.
Postel [Page 13]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
An NLS file is:
proplist( file
name:"FILENAME", name:<file> name of file
name:"CREATION-DATE", name:<date> creation date and time
name:"VERSION", index:<version> file version number
name:"SID-COUNT", integer<count> current SID count
name:"LAST-WRITER", name:<ident> last writer of file
name:"OWNER", name:<ident> owner of file
name:"LAST-WRITE-TIME", name:<date> last write date and time
name:"LEFT-NAME-DELIM-DEFAULT", name:<c> default name
name:"RIGHT-NAME-DELIM-DEFAULT", name:<c> delimiters
name:"SUBSTRUCTURE", <nls-substructure> substructure
)endlist
An NLS substructure is:
list:( substructure
<nls-node> node is defined below
.
.
.
)endlist
An NLS node is:
proplist:( node
name:"BLOCK", <nls-block> block defined below
name:"SUBSTRUCTURE", <nls-substructure> substructure
)endlist
An NLS block is:
proplist:( block
name:"LEFT-NAME-DELIM", name:<c> left name delimiter
name:"RIGHT-NAME-DELIM", name:<c> right name delimiter
name:"SID", integer:<sid> SID number
name:"CREATOR", name:<ident> statement creator
name:"CREATION-TIME", name:<date> creation date and time
name:"DATA", <data> data defined below
)endlist
[Page 14] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
NLS data is:
proplist:( data
name:"<a data name>", <type depends on data name>
. .
. .
. .
)endlist
For text, data is:
proplist:( data
name:"TEXT", text:"text of statement" text
)endlist
2.3.4. Multimedia Structures
One can conceive of graphical information being displayed along with
a running commentary, much as seminars use slides. A slide and its
description are tied together. The coordination of such a
presentation is central to its understanding. This synchronization
should be captured within the document structure.
There are three fundamentally different types of time ordered
control which are needed within the document structure. These are:
Simultaneous
Sequential
Independent
Simultaneous data is intended for synchronous presentation. The
implication is that this data is presented in parallel.
Sequential data items will be presented one at a time, in the order
listed. The ordering is strictly left to right.
Independent data can be presented in any time order. It is not
ordered in any manner.
The data is broken into small information units called presentation
elements or PEs. The PEs can be combined in structures to control
the presentation order. A PE is a property list of elements
representing information of various media. For example:
<pe> := proplist(
name:"VOICE", <voice-structure>,
name:"GRAPHICS", <graphics-structure>
)endlist
Postel [Page 15]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
PEs are combined into larger controled presentations by
presentation-descriptors or PDs. A PD is a property list which
specifies the type of time ordering of the PEs in its list.
<pd> := <<seq>> | <<sim>> | <<ind>>
<<seq>> := name:"SEQUENTIAL", <pe>
<<sim>> := name:"SIMULTANEOUS", <pe>
<<ind>> := name:"INDEPENDENT", <pe>
A PE is a property list of the media <name,value> pairs, or PDs.
<pe> := <<text>> | <<voice>> | <<facsimile>>
| <<graphics>> | <pd>
<<text>> := name:"TEXT", <text structure>
<<voice>> := name:"VOICE", <voice structure>
<<facsimile>> := name:"FACSIMILE", <facsimile structure>
<<graphics>> := name:"GRAPHICS", <graphics structure>
If more than one <name,value> pair is present within a PE the media
are presented on different output devices in the order specified by
the PE's parent PD. The order of appearance within the proplist is
important only in the event that the parent PD specified sequential
ordering.
The structure of multimedia messages which use this scheme will be
demonstrated by a few simple examples chosen to illustrate a basic
text document and the different ordering options. The last example
will suggest some more exotic uses.
[Page 16] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
Plain Text Message
A simple text body could be represented in a single text data
structure. To give the simplest example of a structured body we
show a simple text body represented in the multimedia structure.
<body> := <pd>
<pd> := <<seq>>
<<seq>> := name:"SEQUENTIAL", <pe>
<pe> := name:"TEXT", <text structure>
or
proplist: (name:"SEQUENTIAL",
proplist:(
name:"TEXT", <text structure"HTTP Header X-Frame-Options",
draft-gondrom-x-frame-options-00 (work in progress),
March 2012.
[I-D.ietf-oauth-assertions]
Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0",
draft-ietf-oauth-assertions-04 (work in progress),
July 2012.
[I-D.ietf-oauth-json-web-token]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token-03 (work in
progress), July 2012.
Lodderstedt, et al. Expires February 15, 2013 [Page 66]
Internet-Draft OAuth 2.0 Security August 2012
[I-D.ietf-oauth-revocation]
Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token
Revocation", draft-ietf-oauth-revocation-00 (work in
progress), May 2012.
[I-D.ietf-oauth-v2-http-mac]
Hammer-Lahav, E., "HTTP Authentication: MAC Access
Authentication", draft-ietf-oauth-v2-http-mac-01 (work in
progress), February 2012.
[IMEI] 3GPP, "International Mobile station Equipment Identities
(IMEI)", 3GPP TS 22.016 3.3.0, July 2002.
[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005.
[OASIS.sstc-gross-sec-analysis-response-01]
Linn, J., Ed. and P. Mishra, Ed., "SSTC Response to
"Security Analysis of the SAML Single Sign-on Browser/
Artifact Profile"", January 2005.
[OASIS.sstc-saml-bindings-1.1]
Maler, E., Ed., Mishra, P., Ed., and R. Philpott, Ed.,
"Bindings and Profiles for the OASIS Security Assertion
Markup Language (SAML) V1.1", September 2003.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Lodderstedt, et al. Expires February 15, 2013 [Page 67]
Internet-Draft OAuth 2.0 Security August 2012
[framebusting]
Rydstedt, G., Bursztein, Boneh, D., and C. Jackson,
"Busting Frame Busting: a Study of Clickjacking
Vulnerabilities on Popular Sites", IEEE 3rd Web 2.0
Security and Privacy Workshop, 2010.
[gross-sec-analysis]
Gross, T., "Security Analysis of the SAML Single Sign-on
Browser/Artifact Profile, 19th Annual Computer Security
Applications Conference, Las Vegas", December 2003.
[iFrame] World Wide Web Consortium, "Frames in HTML documents",
W3C HTML 4.01, Dec 1999.
[openid] "OpenID Foundation Home Page", <http://openid.net/>.
[owasp] "Open Web Application Security Project Home Page",
<https://www.owasp.org/>.
[portable-contacts]
Smarr, J., "Portable Contacts 1.0 Draft C", August 2008,
<http://portablecontacts.net/>.
[ssl-latency]
Sissel, J., Ed., "SSL handshake latency and HTTPS
optimizations", June 2010.
Appendix A. Document History
[[ to be removed by RFC editor before publication as an RFC ]]
draft-lodderstedt-oauth-security-01
o section 4.4.1.2 - changed "resource server" to "client" in
countermeasures description.
o section 4.4.1.6 - changed "client shall authenticate the server"
to "The browser shall be utilized to authenticate the redirection
URI of the client"
o section 5 - general review and alignment with public/confidential
client terms
o all sections - general clean-up and typo corrections
draft-ietf-oauth-v2-threatmodel-00
Lodderstedt, et al. Expires February 15, 2013 [Page 68]
Internet-Draft OAuth 2.0 Security August 2012
o section 3.4 - added the purposes for using authorization codes.
o extended section 4.4.1.1
o merged 4.4.1.5 into 4.4.1.2
o corrected some typos
o reformulated "session fixation", renamed respective sections into
"authorization code disclosure through counterfeit client"
o added new section "User session impersonation"
o worked out or reworked sections 2.3.3, 4.4.2.4, 4.4.4, 5.1.4.1.2,
5.1.4.1.4, 5.2.3.5
o added new threat "DoS using manufactured authorization codes" as
proposed by Peifung E Lam
o added XSRF and clickjacking (incl. state parameter explanation)
o changed sub-section order in section 4.4.1
o incorporated feedback from Skylar Woodward (client secrets) and
Shane B Weeden (refresh tokens as client instance secret)
o aligned client section with core draft's client type definition
o converted I-D into WG document
draft-ietf-oauth-v2-threatmodel-01
o Alignment of terminology with core draft 22 (private/public
client, redirect URI validation policy, replaced definition of the
client categories by reference to respective core section)
o Synchronisation with the core's security consideration section
(UPDATE 10.12 CSRF, NEW 10.14/15)
o Added Resource Owner Impersonation
o Improved section 5
o Renamed Refresh Token Replacement to Refresh Token Rotation
draft-ietf-oauth-v2-threatmodel-02
Lodderstedt, et al. Expires February 15, 2013 [Page 69]
Internet-Draft OAuth 2.0 Security August 2012
o Incoporated Tim Bray's review comments (e.g. removed all normative
language)
draft-ietf-oauth-v2-threatmodel-03
o removed 2119 boilerplate and normative reference
o incorporated shepherd review feedback
draft-ietf-oauth-v2-threatmodel-06
o incorporated AD review feedback
draft-ietf-oauth-v2-threatmodel-07
o added new section on token substituation
o made references to core and bearer normative
Authors' Addresses
Torsten Lodderstedt (editor)
Deutsche Telekom AG
Email: torsten@lodderstedt.net
Mark McGloin
IBM
Email: mark.mcgloin@ie.ibm.com
Phil Hunt
Oracle Corporation
Email: phil.hunt@yahoo.com
Lodderstedt, et al. Expires February 15, 2013 [Page 70]