draft-ietf-beep-framework-02.txt   draft-ietf-beep-framework-03.txt 
Network Working Group M.T. Rose Network Working Group M.T. Rose
Internet-Draft Invisible Worlds, Inc. Internet-Draft Invisible Worlds, Inc.
Expires: March 26, 2001 September 25, 2000 Expires: April 9, 2001 October 9, 2000
The Blocks Extensible Exchange Protocol Framework The Blocks Extensible Exchange Protocol Framework
draft-ietf-beep-framework-02 draft-ietf-beep-framework-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 26, 2001. This Internet-Draft will expire on April 9, 2001.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
This memo describes a generic application protocol framework for This memo describes a generic application protocol framework for
connection-oriented, asynchronous interactions. The framework connection-oriented, asynchronous interactions. The framework
permits simultaneous and independent exchanges within the context of permits simultaneous and independent exchanges within the context of
skipping to change at page 3, line 11 skipping to change at page 3, line 11
6. Initial Registrations . . . . . . . . . . . . . . . . . . 45 6. Initial Registrations . . . . . . . . . . . . . . . . . . 45
6.1 Registration: BEEP Channel Management . . . . . . . . . . 45 6.1 Registration: BEEP Channel Management . . . . . . . . . . 45
6.2 Registration: TLS Transport Security Profile . . . . . . . 45 6.2 Registration: TLS Transport Security Profile . . . . . . . 45
6.3 Registration: SASL Family of Profiles . . . . . . . . . . 46 6.3 Registration: SASL Family of Profiles . . . . . . . . . . 46
7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 47 7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 47
7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 49 7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 49
7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 50 7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 50
8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 51 8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 51
9. Security Considerations . . . . . . . . . . . . . . . . . 52 9. Security Considerations . . . . . . . . . . . . . . . . . 52
10. IANA Considerations . . . . . . . . . . . . . . . . . . . 53 References . . . . . . . . . . . . . . . . . . . . . . . . 53
References . . . . . . . . . . . . . . . . . . . . . . . . 54 Author's Address . . . . . . . . . . . . . . . . . . . . . 54
Author's Address . . . . . . . . . . . . . . . . . . . . . 55 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 55
A. Changes from draft-ietf-beep-framework-01 . . . . . . . . 56 B. IANA Considerations . . . . . . . . . . . . . . . . . . . 56
B. Changes from draft-ietf-beep-framework-00 . . . . . . . . 57 Full Copyright Statement . . . . . . . . . . . . . . . . . 57
C. Changes from draft-mrose-bxxp-framework-01 . . . . . . . . 58
D. Changes from draft-mrose-bxxp-framework-00 . . . . . . . . 59
E. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 60
Full Copyright Statement . . . . . . . . . . . . . . . . . 61
1. Introduction 1. Introduction
This memo describes a generic application protocol framework for This memo describes a generic application protocol framework for
connection-oriented, asynchronous interactions. Consult [1] for a connection-oriented, asynchronous interactions.
description of the framework's design principles.
At the core of the BEEP framework is a framing mechanism that At the core of the BEEP framework is a framing mechanism that
permits simultaneous and independent exchanges of messages between permits simultaneous and independent exchanges of messages between
peers. Messages are arbitrary MIME[2] content, but are usually peers. Messages are arbitrary MIME[1] content, but are usually
textual (structured using XML[3]). textual (structured using XML[2]).
All exchanges occur in the context of a channel -- a binding to a All exchanges occur in the context of a channel -- a binding to a
well-defined aspect of the application, such as transport security, well-defined aspect of the application, such as transport security,
user authentication, or data exchange. user authentication, or data exchange.
Each channel has an associated "profile" that defines the syntax and Each channel has an associated "profile" that defines the syntax and
semantics of the messages exchanged. Implicit in the operation of semantics of the messages exchanged. Implicit in the operation of
BEEP is the notion of channel management. In addition to defining BEEP is the notion of channel management. In addition to defining
BEEP's channel management profile, this document defines: BEEP's channel management profile, this document defines:
o the TLS[4] transport security profile; and, o the TLS[3] transport security profile; and,
o the SASL[5] family of profiles. o the SASL[4] family of profiles.
Other profiles, such as those used for data exchange, are defined by Other profiles, such as those used for data exchange, are defined by
an application protocol designer. an application protocol designer.
2. The BEEP Framework 2. The BEEP Framework
A BEEP session is mapped onto an underlying transport service. A A BEEP session is mapped onto an underlying transport service. A
separate series of documents describe how a particular transport separate series of documents describe how a particular transport
service realizes a BEEP session. For example, [6] describes how a service realizes a BEEP session. For example, [5] describes how a
BEEP session is mapped onto a single TCP[7] connection. BEEP session is mapped onto a single TCP[6] connection.
When a session is established, each BEEP peer advertises the profile When a session is established, each BEEP peer advertises the profile
it supports. Later on, during the creation of a channel, the client it supports. Later on, during the creation of a channel, the client
supplies one or more proposed profiles for that channel. If the supplies one or more proposed profiles for that channel. If the
server creates the channel, it selects one of the profiles and sends server creates the channel, it selects one of the profiles and sends
it in a reply; otherwise, it may indicate that none of the profiles it in a reply; otherwise, it may indicate that none of the profiles
are acceptable, and decline creation of the channel. are acceptable, and decline creation of the channel.
Channel usage falls into one of two categories: Channel usage falls into one of two categories:
skipping to change at page 7, line 8 skipping to change at page 7, line 8
course of performing some task, replies with zero or more "ANS" course of performing some task, replies with zero or more "ANS"
messages, and, upon completion of the task, sends a "NUL" messages, and, upon completion of the task, sends a "NUL"
message, which signifies the end of the reply. message, which signifies the end of the reply.
The first two styles are termed one-to-one exchanges, whilst the The first two styles are termed one-to-one exchanges, whilst the
third style is termed a one-to-many exchange. third style is termed a one-to-many exchange.
2.2 Messages and Frames 2.2 Messages and Frames
A message is structured according to the rules of MIME. Accordingly, A message is structured according to the rules of MIME. Accordingly,
each message may begin with "entity-headers" (c.f., MIME[2]'s each message may begin with "entity-headers" (c.f., MIME[1]'s
Section 3). If none, or only some, of the "entity-headers" are Section 3). If none, or only some, of the "entity-headers" are
present: present:
o the default "Content-Type" is "application/octet-stream"; and, o the default "Content-Type" is "application/octet-stream"; and,
o the default "Content-Transfer-Encoding" is "binary". o the default "Content-Transfer-Encoding" is "binary".
Normally, a message is sent in a single frame. However, it may be Normally, a message is sent in a single frame. However, it may be
convenient or necesary to segment a message into multiple frames convenient or necesary to segment a message into multiple frames
(e.g., if only part of a message is ready to be sent). (e.g., if only part of a message is ready to be sent).
skipping to change at page 8, line 7 skipping to change at page 8, line 7
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' /> C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
C: </start> C: </start>
C: END C: END
C: C:
In this example, note that the entire message is represented in a In this example, note that the entire message is represented in a
single frame. single frame.
2.2.1 Frame Syntax 2.2.1 Frame Syntax
The ABNF[8] for a frame is: The ABNF[7] for a frame is:
frame = data / mapping frame = data / mapping
data = header payload trailer data = header payload trailer
header = msg / rpy / err / ans / nul header = msg / rpy / err / ans / nul
msg = "MSG" SP common CR LF msg = "MSG" SP common CR LF
rpy = "RPY" SP common CR LF rpy = "RPY" SP common CR LF
ans = "ANS" SP common SP ansno CR LF ans = "ANS" SP common SP ansno CR LF
skipping to change at page 10, line 7 skipping to change at page 10, line 7
S: RPY 0 1 . 307 0 S: RPY 0 1 . 307 0
S: END S: END
S: S:
The answer number ("ansno") must be a non-negative integer (in the The answer number ("ansno") must be a non-negative integer (in the
range 0..4294967295) and must have a different value than all other range 0..4294967295) and must have a different value than all other
answers in progress for the message being replied to. answers in progress for the message being replied to.
There are two kinds of frames: data and mapping. each transport There are two kinds of frames: data and mapping. each transport
mapping (c.f., Section 2.5) may define its own frames. For example, mapping (c.f., Section 2.5) may define its own frames. For example,
[6] defines the SEQ frame. The remainder of this section discusses [5] defines the SEQ frame. The remainder of this section discusses
data frames. data frames.
When a message is segmented and sent as several frames, those frames When a message is segmented and sent as several frames, those frames
must be sent sequentally, without any intervening frames from other must be sent sequentally, without any intervening frames from other
messages on the same channel. However, there are two exceptions: messages on the same channel. However, there are two exceptions:
first, no restriction is made with respect to the interleaving of first, no restriction is made with respect to the interleaving of
frames for other channels; and, second, in a one-to-many exchange, frames for other channels; and, second, in a one-to-many exchange,
multiple answers may be simultaneously in progress. Accordingly, multiple answers may be simultaneously in progress. Accordingly,
frames for "ANS" messages may be interleaved on the same channel -- frames for "ANS" messages may be interleaved on the same channel --
the answer number is used for collation, e.g., the answer number is used for collation, e.g.,
skipping to change at page 15, line 7 skipping to change at page 15, line 7
If a poorly-formed reply is received on channel zero, the session is If a poorly-formed reply is received on channel zero, the session is
terminated without generating a response, and it is recommended that terminated without generating a response, and it is recommended that
a diagnostic entry be logged. a diagnostic entry be logged.
If a poorly-formed reply is received on another channel, then the If a poorly-formed reply is received on another channel, then the
channel must be closed using the procedure in Section 2.3.1.3. channel must be closed using the procedure in Section 2.3.1.3.
2.2.2.2 XML-based Profiles 2.2.2.2 XML-based Profiles
If a profile uses XML[3] to structure its messages, then only XML's If a profile uses XML[2] to structure its messages, then only XML's
baseline facilities (as described in the XML 1.0 specification[3]) baseline facilities (as described in the XML 1.0 specification[2])
are allowed. Additional XML facilities (e.g., namespaces) are made are allowed. Additional XML facilities (e.g., namespaces) are made
available only by being explicitly permitted in a given profile's available only by being explicitly permitted in a given profile's
specification. specification.
In particular this limitation allows use of only the five predefined In particular this limitation allows use of only the five predefined
general entities references ("&amp;", "&lt;", "&gt;", "&apos;", and general entities references ("&amp;", "&lt;", "&gt;", "&apos;", and
"&quot;") and numeric entity references in the messages exchanged. "&quot;") and numeric entity references in the messages exchanged.
Further, because the profile registration template defines the Further, because the profile registration template defines the
messages exchanged over a channel, the XML documents exchanged in messages exchanged over a channel, the XML documents exchanged in
skipping to change at page 18, line 14 skipping to change at page 18, line 14
The "greeting" element has two optional attributes ("features" and The "greeting" element has two optional attributes ("features" and
"localize") and zero or more "profile" elements, one for each "localize") and zero or more "profile" elements, one for each
profile supported by the BEEP peer acting in a server role: profile supported by the BEEP peer acting in a server role:
o the "features" attribute, if present, contains one or more o the "features" attribute, if present, contains one or more
feature tokens, each indicating an optional feature of the feature tokens, each indicating an optional feature of the
channel management profile supported by the BEEP peer; channel management profile supported by the BEEP peer;
o the "localize" attribute, if present, contains one or more o the "localize" attribute, if present, contains one or more
language tokens (defined in [9]), each identifying a desirable language tokens (defined in [8]), each identifying a desirable
language tag to be used by the remote BEEP peer when generating language tag to be used by the remote BEEP peer when generating
textual diagnostics for the "close" and "error" elements (the textual diagnostics for the "close" and "error" elements (the
tokens are ordered from most to least desirable); and, tokens are ordered from most to least desirable); and,
o each "profile" element contained within the "greeting" element o each "profile" element contained within the "greeting" element
identifies a profile, and unlike the "profile" elements that identifies a profile, and unlike the "profile" elements that
occur within the "start" element, the content of each "profile" occur within the "start" element, the content of each "profile"
element may not contain an optional initialization message. element may not contain an optional initialization message.
At present, there are no optional features defined for the channel At present, there are no optional features defined for the channel
skipping to change at page 31, line 13 skipping to change at page 31, line 13
refer to different messages sent on channel zero. refer to different messages sent on channel zero.
3. Transport Security 3. Transport Security
When a BEEP session is established, plaintext transfer, without When a BEEP session is established, plaintext transfer, without
privacy, is provided. Accordingly, transport security in BEEP is privacy, is provided. Accordingly, transport security in BEEP is
achieved using an initial tuning profile. achieved using an initial tuning profile.
This document defines one profile: This document defines one profile:
o the TLS transport security profile, based on TLS version one[4]. o the TLS transport security profile, based on TLS version one[3].
Other profiles may be defined and deployed on a bilateral basis. Other profiles may be defined and deployed on a bilateral basis.
Note that because of their intimate relationship with the tranpsort Note that because of their intimate relationship with the tranpsort
service, a given transport security profile tends to be relevant to service, a given transport security profile tends to be relevant to
a single transort mapping (c.f., Section 2.5). a single transort mapping (c.f., Section 2.5).
When a channel associated with transport security begins the When a channel associated with transport security begins the
underlying negotiation process, all channels (including channel underlying negotiation process, all channels (including channel
zero) are closed on the BEEP session. Accordingly, upon completion zero) are closed on the BEEP session. Accordingly, upon completion
of the negotiation process, regardless of its outcome, a new of the negotiation process, regardless of its outcome, a new
skipping to change at page 37, line 13 skipping to change at page 37, line 13
transport security. transport security.
4. User Authentication 4. User Authentication
When a BEEP session is established, anonymous access, without trace When a BEEP session is established, anonymous access, without trace
information, is provided. Accordingly, user authentication in BEEP information, is provided. Accordingly, user authentication in BEEP
is achieved using an initial tuning profile. is achieved using an initial tuning profile.
This document defines a family of profiles based on SASL mechanisms: This document defines a family of profiles based on SASL mechanisms:
o each mechanism in the IANA SASL registry[14] has an associated o each mechanism in the IANA SASL registry[13] has an associated
profile. profile.
Other profiles may be defined and deployed on a bilateral basis. Other profiles may be defined and deployed on a bilateral basis.
Whenever a successful authentication occurs, on any channel, the Whenever a successful authentication occurs, on any channel, the
authenticated identity is updated for all existing and future authenticated identity is updated for all existing and future
channels on the BEEP session; further, no additional attempts at channels on the BEEP session; further, no additional attempts at
authentication are allowed. authentication are allowed.
Note that regardless of transport security and user authentication, Note that regardless of transport security and user authentication,
skipping to change at page 38, line 15 skipping to change at page 38, line 15
4.1 The SASL Family of Profiles 4.1 The SASL Family of Profiles
Section 6.3 contains the registration for this profile. Section 6.3 contains the registration for this profile.
Note that SASL may provide both user authentication and transport Note that SASL may provide both user authentication and transport
security. Once transport security is successfully negotiated for a security. Once transport security is successfully negotiated for a
BEEP session, then a SASL security layer must not be negotiated; BEEP session, then a SASL security layer must not be negotiated;
similarly, once any SASL negotiation is successful, a transport similarly, once any SASL negotiation is successful, a transport
security profile must not begin its underlying negotiation process. security profile must not begin its underlying negotiation process.
Section 4 of the SASL specification[5] requires the following Section 4 of the SASL specification[4] requires the following
information be supplied by a protocol definition: information be supplied by a protocol definition:
service name: "beep" service name: "beep"
initiation sequence: Creating a channel using a BEEP profile initiation sequence: Creating a channel using a BEEP profile
corresponding to a SASL mechanism starts the exchange. An corresponding to a SASL mechanism starts the exchange. An
optional parameter corresponding to the "initial response" sent optional parameter corresponding to the "initial response" sent
by the client is carried within a "blob" element during channel by the client is carried within a "blob" element during channel
creation. creation.
skipping to change at page 43, line 27 skipping to change at page 43, line 27
continue: used by either a client or server, otherwise. continue: used by either a client or server, otherwise.
Finally, note that SASL's EXTERNAL mechanism works with an "external Finally, note that SASL's EXTERNAL mechanism works with an "external
authentication" service, which is provided by one of: authentication" service, which is provided by one of:
o a transport security profile, capable of providing authentication o a transport security profile, capable of providing authentication
information (e.g., Section 3.1), being active on the connection; information (e.g., Section 3.1), being active on the connection;
o a network service, capable of providing strong authentication o a network service, capable of providing strong authentication
(e.g., IPSec[12]), underlying the connection; or, (e.g., IPSec[11]), underlying the connection; or,
o a locally-defined security service. o a locally-defined security service.
For authentication to succeed, two conditions must hold: For authentication to succeed, two conditions must hold:
o an external authentication service must be active; and, o an external authentication service must be active; and,
o if present, the authentication identity must be consistent with o if present, the authentication identity must be consistent with
the credentials provided by the external authentication service the credentials provided by the external authentication service
(if the authentication identity is empty, then an authorization (if the authentication identity is empty, then an authorization
identity is automatically derived from the credentials provided identity is automatically derived from the credentials provided
by the external authentication service). by the external authentication service).
5. Registration Templates 5. Registration Templates
5.1 Profile Registration Template 5.1 Profile Registration Template
When a profile is registered, the following information is supplied: When a profile is registered, the following information is supplied:
Profile Identification: specify a URI[10] that authoritatively Profile Identification: specify a URI[9] that authoritatively
identifies this profile. identifies this profile.
Message Exchanged during Channel Creation: specify the datatypes Message Exchanged during Channel Creation: specify the datatypes
that may be exchanged during channel creation. that may be exchanged during channel creation.
Messages starting one-to-one exchanges: specify the datatypes that Messages starting one-to-one exchanges: specify the datatypes that
may be present when an exchange starts. may be present when an exchange starts.
Messages in positive replies: specify the datatypes that may be Messages in positive replies: specify the datatypes that may be
present in a positive reply. present in a positive reply.
skipping to change at page 46, line 9 skipping to change at page 46, line 9
Message Semantics: c.f., Section 3.1.3 Message Semantics: c.f., Section 3.1.3
Contact Information: c.f., the "Author's Address" section of this Contact Information: c.f., the "Author's Address" section of this
memo memo
6.3 Registration: SASL Family of Profiles 6.3 Registration: SASL Family of Profiles
Profile Identification: Profile Identification:
http://xml.resource.org/profiles/sasl/MECHANISM, where http://xml.resource.org/profiles/sasl/MECHANISM, where
"MECHANISM" is a token registered with the IANA[15] "MECHANISM" is a token registered with the IANA[14]
Messages exchanged during Channel Creation: "blob" Messages exchanged during Channel Creation: "blob"
Messages starting one-to-one exchanges: "blob" Messages starting one-to-one exchanges: "blob"
Messages in positive replies: "blob" Messages in positive replies: "blob"
Messages in negative replies: "error" Messages in negative replies: "error"
Messages in one-to-many exchanges: none Messages in one-to-many exchanges: none
skipping to change at page 48, line 27 skipping to change at page 48, line 27
<!ATTLIST greeting <!ATTLIST greeting
features %FTRS; #IMPLIED features %FTRS; #IMPLIED
localize %LOCS; "i-default"> localize %LOCS; "i-default">
<!ELEMENT start (profile)+> <!ELEMENT start (profile)+>
<!ATTLIST start <!ATTLIST start
number %CHAN; #REQUIRED number %CHAN; #REQUIRED
serverName CDATA #IMPLIED> serverName CDATA #IMPLIED>
<!-- profile element is empty if contained in a greeting --> <!-- profile element is empty if contained in a greeting -->
<!ELEMENT profile (#PCDATA)*> <!ELEMENT profile (#PCDATA)>
<!ATTLIST profile <!ATTLIST profile
uri %URI; #REQUIRED uri %URI; #REQUIRED
encoding (none|base64) "none"> encoding (none|base64) "none">
<!ELEMENT close (#PCDATA)*> <!ELEMENT close (#PCDATA)>
<!ATTLIST close <!ATTLIST close
number %CHAN; "0" number %CHAN; "0"
code %XYZ; #REQUIRED code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED> xml:lang %LANG; #IMPLIED>
<!ELEMENT ok EMPTY> <!ELEMENT ok EMPTY>
<!ELEMENT error (#PCDATA)*> <!ELEMENT error (#PCDATA)>
<!ATTLIST error <!ATTLIST error
code %XYZ; #REQUIRED code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED> xml:lang %LANG; #IMPLIED>
7.2 TLS Transport Security Profile DTD 7.2 TLS Transport Security Profile DTD
<!-- <!--
DTD for the TLS Transport Security Profile, as of 2000-09-04 DTD for the TLS Transport Security Profile, as of 2000-09-04
Refer to this DTD as: Refer to this DTD as:
skipping to change at page 50, line 25 skipping to change at page 50, line 25
--> -->
<!-- <!--
SASL messages SASL messages
role MSG RSP ERR role MSG RSP ERR
====== === === === ====== === === ===
I or L blob blob error I or L blob blob error
--> -->
<!ELEMENT blob (#PCDATA)*> <!ELEMENT blob (#PCDATA)>
<!ATTLIST blob <!ATTLIST blob
xml:space (default|preserve) xml:space (default|preserve)
"preserve" "preserve"
status (abort|complete|continue) status (abort|complete|continue)
"continue"> "continue">
8. Reply Codes 8. Reply Codes
code meaning code meaning
==== ======= ==== =======
skipping to change at page 52, line 12 skipping to change at page 52, line 12
554 transaction failed 554 transaction failed
(e.g., policy violation) (e.g., policy violation)
9. Security Considerations 9. Security Considerations
The BEEP framing mechanism, per se, provides no protection against The BEEP framing mechanism, per se, provides no protection against
attack; however, judicious use of initial tuning profiles provides attack; however, judicious use of initial tuning profiles provides
varying degrees of assurance: varying degrees of assurance:
1. If one of the profiles from the SASL family is used, refer to 1. If one of the profiles from the SASL family is used, refer to
[5]'s Section 9 for a discussion of security considerations. [4]'s Section 9 for a discussion of security considerations.
2. If the TLS transport security profile is used (or if a SASL 2. If the TLS transport security profile is used (or if a SASL
security layer is negotiated), then: security layer is negotiated), then:
1. A man-in-the-middle may remove the security-related profiles 1. A man-in-the-middle may remove the security-related profiles
from the BEEP greeting or generate a negative reply to the from the BEEP greeting or generate a negative reply to the
"ready" element of the TLS transport security profile. A "ready" element of the TLS transport security profile. A
BEEP peer may be configurable to refuse to proceed without BEEP peer may be configurable to refuse to proceed without
an acceptable level of privacy. an acceptable level of privacy.
skipping to change at page 53, line 5 skipping to change at page 53, line 5
As different TLS ciphersuites provide varying levels of As different TLS ciphersuites provide varying levels of
security, administrators should carefully choose which security, administrators should carefully choose which
ciphersuites are provisioned. ciphersuites are provisioned.
As BEEP is peer-to-peer in nature, before performing any task As BEEP is peer-to-peer in nature, before performing any task
associated with a message, each channel should apply the appropriate associated with a message, each channel should apply the appropriate
access control based on the authenticated identity and privacy level access control based on the authenticated identity and privacy level
associated with the BEEP session. associated with the BEEP session.
10. IANA Considerations
The IANA registers "beep" as a GSSAPI[13] service name, as specified
in Section 4.1.
The IANA maintains a list of:
o BEEP profiles, c.f., Section 5.1; and,
o features for the channel management profile, c.f., Section 5.2.
The IANA makes the registrations specified in Section 6.2 and
Section 6.3. It is recommended that the IANA register these profiles
using the IANA as a URI-prefix, and populate those URIs with the
respective profile registrations.
References References
[1] Rose, M.T., "On the Design of Application Protocols", [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
draft-mrose-beep-design-00 (work in progress), July 2000.
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[3] World Wide Web Consortium, "Extensible Markup Language (XML) [2] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998, 1.0", W3C XML, February 1998,
<URL:http://www.w3.org/TR/1998/REC-xml-19980210>. <URL:http://www.w3.org/TR/1998/REC-xml-19980210>.
[4] Dierks, T., Allen, C., Treese, W., Karlton, P. L., Freier, A. [3] Dierks, T., Allen, C., Treese, W., Karlton, P. L., Freier, A.
O. and P. C. Kocher, "The TLS Protocol Version 1.0", RFC 2246, O. and P. C. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999. January 1999.
[5] Myers, J.G., "Simple Authentication and Security Layer [4] Myers, J.G., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997. (SASL)", RFC 2222, October 1997.
[6] Rose, M.T., "Mapping the BEEP Framework onto TCP", [5] Rose, M.T., "Mapping the BEEP Framework onto TCP",
draft-ietf-beep-tcpmapping-02 (work in progress), September draft-ietf-beep-tcpmapping-03 (work in progress), October 2000.
2000.
[7] Postel, J., "Transmission Control Protocol", RFC 793, STD 7, [6] Postel, J., "Transmission Control Protocol", RFC 793, STD 7,
Sep 1981. Sep 1981.
[8] Crocker, D. H. and P. Overell, "Augmented BNF for Syntax [7] Crocker, D. H. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[9] Alvestrand, H., "Tags for the Identification of Languages", [8] Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995. RFC 1766, March 1995.
[10] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform [9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998. 1998.
[11] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, [10] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
October 1998. October 1998.
[12] Kent, S. and R. Atkinson, "Security Architecture for the [11] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[13] Linn, J., "Generic Security Service Application Program [12] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997. Interface, Version 2", RFC 2078, January 1997.
[14] <URL:http://www.isi.edu/in-notes/iana/assignments/sasl-mechanis [13] <URL:http://www.isi.edu/in-notes/iana/assignments/sasl-mechanis
ms> ms>
[15] <URL:http://www.iana.org/>
[14] <URL:http://www.iana.org/>
Author's Address Author's Address
Marshall T. Rose Marshall T. Rose
Invisible Worlds, Inc. Invisible Worlds, Inc.
1179 North McDowell Boulevard 1179 North McDowell Boulevard
Petaluma, CA 94954-6559 Petaluma, CA 94954-6559
US US
Phone: +1 707 789 3700 Phone: +1 707 789 3700
EMail: mrose@invisible.net EMail: mrose@invisible.net
URI: http://invisible.net/ URI: http://invisible.net/
Appendix A. Changes from draft-ietf-beep-framework-01 Appendix A. Acknowledgements
o s/BXXP/BEEP/g
o The default "Content-Type:" is now "application/octet-stream".
o Initialization messages are now character data, not XML elements.
o A template is provided for channel management feature
registration (c.f., Section 5.2).
Appendix B. Changes from draft-ietf-beep-framework-00
o The names of messages are renamed:
* "REQ" messages are now "MSG" messages; and,
* "RSP" messages are now "RPY" (positive), "ANS"/"NULL"
(one-to-many), and "ERR" (negative).
o One-to-many exchanges are supported using the "ANS" message.
o Commonly-used paraemters are re-ordered in the header:
* channel numbers appear in each frame (and are 31-bits wide);
and,
* serial numbers are now message numbers, and are per-channel.
o MIME "entity-headers" are now part of the payload (and there is
no longer any header-related processing associated with them).
o An IANA registration for BEEP error codes is no longer required
(the error codes are used only within this specification).
o The close message (Section 2.3.1.3) is also used to release the
BEEP session.
Appendix C. Changes from draft-mrose-bxxp-framework-01
o Channel numbers are now 31-bits wide (instead of 8-bits).
o Peers should support at least 257 concurrent channels.
o The consistency rules in Section 2.2.1.1 now mandate that any
MIME entity-headers occur only in the first frame of a message.
o Discussion of the role of the entity-headers is moved to Section
2.2.1.1.
o Section 2.2.2 requires that a BEEP peer close a channel when a
poorly-formed reply is received (unless it's channel zero, in
which case the BEEP session is terminated).
o Section 2.2.2 explains that in an XML-based profile, if something
other than UTF-8 is sent, then a "Content-Type:" entity-header
must be present to specify the character set.
o The close (Section 2.3.1.3) and ok (Section 2.3.1.4) messages
were added.
o Both Section 2.3.1.3 and Section 2.3.1.5 clarify that diagnostic
text is not to be interpreted by programs.
o Section 5.1 limits the the size of an initialization element to
4K octets.
Appendix D. Changes from draft-mrose-bxxp-framework-00
o The IPR notice is changed to be in full conformance with all
provisions of Section 10 of RFC2026.
o At the beginning of Section 2.2 (and in the ABNF in Section The author gratefully acknowledges the contributions of: David
2.2.1) the relationship between messages and frames is clarified. Clark, Dave Crocker, Steve Deering, Wesley Michael Eddy, Marco
Gazzetta, Danny Goodman, Steve Harris, Robert Herriot, Ken Hirsch,
Greg Hudson, Ben Laurie, Carl Malamud, Michael Mealling, Keith
McCloghrie, Paul Mockapetris, RL 'Bob' Morgan, Frank Morton, Darren
New, Chris Newman, Joe Touch, Paul Vixie, Gabe Wachob, Daniel Woods,
and, James Woodyatt. In particular, Dave Crocker provided helpful
suggestions on the nature of segmentation in the framing mechanism.
o A typo involving the final CR LF in the ABNF in Section 2.2.1 is Appendix B. IANA Considerations
corrected.
o In Section 2.2.1.1, the "contiguous message" rule replaces the The IANA registers "beep" as a GSSAPI[12] service name, as specified
"transport-specific" assertion (the sixth rule for identifying in Section 4.1.
poorly-formed frames).
o At the beginning of Section 2.3, an explanation of the The IANA maintains a list of:
relstionship between profiles and channels (and the greeting and
start messages) is added.
o In Section 2.3.1, the order of the sections for the greeting and o BEEP profiles, c.f., Section 5.1; and,
start messages is reversed for readability.
Appendix E. Acknowledgements o features for the channel management profile, c.f., Section 5.2.
The author gratefully acknowledges the contributions of: David The IANA makes the registrations specified in Section 6.2 and
Clark, Dave Crocker, Steve Deering, Marco Gazzetta, Danny Goodman, Section 6.3. It is recommended that the IANA register these profiles
Steve Harris, Robert Herriot, Ken Hirsch, Greg Hudson, Ben Laurie, using the IANA as a URI-prefix, and populate those URIs with the
Carl Malamud, Michael Mealling, Keith McCloghrie, Paul Mockapetris, respective profile registrations.
RL 'Bob' Morgan, Frank Morton, Darren New, Chris Newman, Joe Touch,
Paul Vixie, Gabe Wachob, Daniel Woods, and, James Woodyatt. In
particular, Dave Crocker provided helpful suggestions on the nature
of segmentation in the framing mechanism.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
 End of changes. 48 change blocks. 
164 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/