RFC3080 - The Blocks Extensible Exchange Protocol Core(2)

BEEP session, then a SASL security layer must not be negotiated;
similarly, once any SASL negotiation is successful, a transport
security profile must not begin its underlying negotiation process.

Section 4 of the SASL specification [4] requires the following
information be supplied by a protocol definition:

service name: "beep"

initiation sequence: Creating a channel using a BEEP profile
corresponding to a SASL mechanism starts the exchange. An
optional parameter corresponding to the "initial response" sent by
the client is carried within a "blob" element during channel
creation.

exchange sequence: "Challenges" and "responses" are carried in
exchanges of the "blob" element. The "status" attribute of the
"blob" element is used both by a server indicating a successful
completion of the exchange, and a client aborting the exchange,
The server indicates failure of the exchange by sending an "error"
element.

security layer negotiation: When a security layer starts negotiation,
all channels (including channel zero) are closed on the BEEP
session. Accordingly, upon completion of the negotiation process,
regardless of its outcome, a new greeting is issued by both BEEP
peers.

If a security layer is successfully negotiated, it takes effect
immediately following the message that concludes the server's
successful completion reply.

use of the authorization identity: This is made available to all
channels for the duration of the BEEP session.

4.1.1 Profile Identification and Initialization

Each SASL mechanism registered with the IANA is identified as:

http://iana.org/beep/SASL/mechanism

where "MECHANISM" is the token assigned to that mechanism by the
IANA.

Note that during channel creation, a BEEP peer may provide multiple
profiles to the remote peer, e.g.,

C: MSG 0 1 . 52 178
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS' />
C: <profile uri='http://iana.org/beep/SASL/OTP' />
C: </start>
C: END
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP' />
S: END

During channel creation, the corresponding "profile" element in the
BEEP "start" element may contain a "blob" element. Note that it is
possible for the channel to be created, but for the encapsulated
operation to fail, e.g.,

C: MSG 0 1 . 52 183
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP'>
C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 221 178
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP'>
S: <![CDATA[<error code='534'>authentication mechanism is
S: too weak</error>]]>
S: </profile>
S: END

In this case, a positive reply is sent (as channel creation
succeeded), but the encapsulated response contains an indication as
to why the operation failed.

Otherwise, the server sends a challenge (or signifies success), e.g.,

C: MSG 0 1 . 52 183
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/OTP'>
C: <![CDATA[<blob>AGJsb2NrbWFzdGVy</blob>]]>
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 221 171
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/OTP'>
S: <![CDATA[<blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=
</blob>]]>
S: </profile>
S: END

Note that this example implies that the "blob" element in the
server's reply appears on two lines -- this is an artifact of the
presentation; in fact, only one line is used.

If a challenge is received, then the client responds and awaits
another reply, e.g.,

C: MSG 1 0 . 0 97
C: Content-Type: application/beep+xml
C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END
S: RPY 1 0 . 0 66
S: Content-Type: application/beep+xml
S:
S: <blob status='complete' />
S: END

Of course, the client could abort the authentication process by
sending "<blob status='abort' />" instead.

Alternatively, the server might reject the response with an error:
e.g.,

C: MSG 1 0 . 0 97
C: Content-Type: application/beep+xml
C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END
S: ERR 1 0 . 0 60
S: Content-Type: application/beep+xml
S:
S: <error code='535' />
S: END

Finally, depending on the SASL mechanism, an initialization element
may be exchanged unidirectionally during channel creation, e.g.,

C: MSG 0 1 . 52 125
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/CRAM-MD5' />
C: </start>
C: END
S: RPY 0 1 . 221 185
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/CRAM-MD5'>
S: <![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1
jaS5uZXQ+</blob>]]>
S: </profile>
S: END

Note that this example implies that the "blob" element in the
server's reply appears on two lines -- this is an artifact of the
presentation; in fact, only one line is used.

4.1.2 Message Syntax

Section 7.3 defines the messages that are used for each profile in
the SASL family.

Note that because many SASL mechanisms exchange binary data, the
content of the "blob" element is always a base64-encoded string.

4.1.3 Message Semantics

The "blob" element has an optional "status" attribute, and arbitrary
octets as its content:

o the "status" attribute, if present, takes one of three values:

abort: used by a client to indicate that it is aborting the
authentication process;

complete: used by a server to indicate that the exchange is
complete and successful; or,

continue: used by either a client or server, otherwise.

Finally, note that SASL's EXTERNAL mechanism works with an "external
authentication" service, which is provided by one of:

o a transport security profile, capable of providing authentication
information (e.g., Section 3.1), being active on the connection;

o a network service, capable of providing strong authentication
(e.g., IPSec [12]), underlying the connection; or,

o a locally-defined security service.

For authentication to succeed, two conditions must hold:

o an external authentication service must be active; and,

o if present, the authentication identity must be consistent with
the credentials provided by the external authentication service
(if the authentication identity is empty, then an authorization
identity is automatically derived from the credentials provided by
the external authentication service).

5. Registration Templates

5.1 Profile Registration Template

When a profile is registered, the following information is supplied:

Profile Identification: specify a URI [10] that authoritatively
identifies this profile.

Message Exchanged during Channel Creation: specify the datatypes that
may be exchanged during channel creation.

Messages starting one-to-one exchanges: specify the datatypes that
may be present when an exchange starts.

Messages in positive replies: specify the datatypes that may be
present in a positive reply.

Messages in negative replies: specify the datatypes that may be
present in a negative reply.

Messages in one-to-many exchanges: specify the datatypes that may be
present in a one-to-many exchange.

Message Syntax: specify the syntax of the datatypes exchanged by the
profile.

Message Semantics: specify the semantics of the datatypes exchanged
by the profile.

Contact Information: specify the postal and electronic contact
information for the author of the profile.

5.2 Feature Registration Template

When a feature for the channel management profile is registered, the
following information is supplied:

Feature Identification: specify a string that identifies this
feature. Unless the feature is registered with the IANA, the
feature's identification must start with "x-".

Feature Semantics: specify the semantics of the feature.

Contact Information: specify the postal and electronic contact
information for the author of the feature.

6. Initial Registrations

6.1 Registration: BEEP Channel Management

Profile Identification: not applicable

Messages exchanged during Channel Creation: not applicable

Messages starting one-to-one exchanges: "start" or "close"

Messages in positive replies: "greeting", "profile", or "ok"

Messages in negative replies: "error"

Messages in one-to-many exchanges: none

Message Syntax: c.f., Section 7.1

Message Semantics: c.f., Section 2.3.1

Contact Information: c.f., the "Author's Address" section of this
memo

6.2 Registration: TLS Transport Security Profile

Profile Identification: http://iana.org/beep/TLS

Messages exchanged during Channel Creation: "ready"

Messages starting one-to-one exchanges: "ready"

Messages in positive replies: "proceed"

Messages in negative replies: "error"

Messages in one-to-many exchanges: none

Message Syntax: c.f., Section 7.2

Message Semantics: c.f., Section 3.1.3

Contact Information: c.f., the "Author's Address" section of this
memo

6.3 Registration: SASL Family of Profiles

Profile Identification: http://iana.org/beep/SASL/mechanism, where
"mechanism" is a token registered with the IANA

Messages exchanged during Channel Creation: "blob"

Messages starting one-to-one exchanges: "blob"

Messages in positive replies: "blob"

Messages in negative replies: "error"

Messages in one-to-many exchanges: none

Message Syntax: c.f., Section 7.3

Message Semantics: c.f., Section 4.1.3

Contact Information: c.f., the "Author's Address" section of this
memo

6.4 Registration: application/beep+xml

MIME media type name: application

MIME subtype name: beep+xml

Required parameters: none

Optional parameters: charset (defaults to "UTF-8" [13])

Encoding considerations: This media type may contain binary content;
accordingly, when used over a transport that does not permit
binary transfer, an appropriate encoding must be applied

Security considerations: none, per se; however, any BEEP profile
which uses this media type must describe its relevant security
considerations

Interoperability considerations: n/a

Published specification: This media type is a proper subset of the
the XML 1.0 specification [2]. Two restrictions are made.

First, no entity references other than the five predefined general
entities references ("&", "<", ">", "'", and
""") and numeric entity references may be present.

Second, neither the "XML" declaration (e.g., <?xml version="1.0"
?>) nor the "DOCTYPE" declaration (e.g., <!DOCTYPE ...>) may be
present. (Accordingly, if another character set other than UTF-8
is desired, then the "charset" parameter must be present.)

All other XML 1.0 instructions (e.g., CDATA blocks, processing
instructions, and so on) are allowed.

Applications which use this media type: any BEEP profile wishing to
make use of this XML 1.0 subset

Additional Information: none

Contact for further information: c.f., the "Author's Address" section
of this memo

Intended usage: limited use

Author/Change controller: the IESG

7. DTDs

7.1 BEEP Channel Management DTD





<!ENTITY % CHAN "CDATA">
<!ENTITY % URI "CDATA">
<!ENTITY % FTRS "NMTOKENS">
<!ENTITY % LANG "NMTOKEN">
<!ENTITY % LOCS "NMTOKEN">
<!ENTITY % XYZ "CDATA">



<!ELEMENT greeting (profile)*>
<!ATTLIST greeting
features %FTRS; #IMPLIED
localize %LOCS; "i-default">

<!ELEMENT start (profile)+>
<!ATTLIST start
number %CHAN; #REQUIRED
serverName CDATA #IMPLIED>


<!ELEMENT profile (#PCDATA)>
<!ATTLIST profile
uri %URI; #REQUIRED
encoding (none|base64) "none">

<!ELEMENT close (#PCDATA)>
<!ATTLIST close
number %CHAN; "0"
code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED>

<!ELEMENT ok EMPTY>

<!ELEMENT error (#PCDATA)>
<!ATTLIST error
code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED>

7.2 TLS Transport Security Profile DTD





<!ELEMENT ready EMPTY>
<!ATTLIST ready
version CDATA "1">

<!ELEMENT proceed EMPTY>

7.3 SASL Family of Profiles DTD





<!ELEMENT blob (#PCDATA)>
<!ATTLIST blob
xml:space (default|preserve)
"preserve"
status (abort|complete|continue)
"continue">

8. Reply Codes

code meaning
==== =======
200 success

421 service not available

450 requested action not taken
(e.g., lock already in use)

451 requested action aborted
(e.g., local error in processing)

454 temporary authentication failure

500 general syntax error
(e.g., poorly-formed XML)

501 syntax error in parameters
(e.g., non-valid XML)

504 parameter not implemented

530 authentication required

534 authentication mechanism insufficient
(e.g., too weak, sequence exhausted, etc.)

535 authentication failure

537 action not authorized for user

538 authentication mechanism requires encryption

550 requested action not taken
(e.g., no requested profiles are acceptable)

553 parameter invalid

554 transaction failed
(e.g., policy violation)

9. Security Considerations

The BEEP framing mechanism, per se, provides no protection against
attack; however, judicious use of initial tuning profiles provides
varying degrees of assurance:

1. If one of the profiles from the SASL family is used, refer to
[4]'s Section 9 for a discussion of security considerations.

2. If the TLS transport security profile is used (or if a SASL
security layer is negotiated), then:

1. A man-in-the-middle may remove the security-related profiles
from the BEEP greeting or generate a negative reply to the
"ready" element of the TLS transport security profile. A
BEEP peer may be configurable to refuse to proceed without an
acceptable level of privacy.

2. A man-in-the-middle may cause a down-negotiation to the
weakest cipher suite available. A BEEP peer should be
configurable to refuse weak cipher suites.

3. A man-in-the-middle may modify any protocol exchanges prior
to a successful negotiation. Upon completing the
negotiation, a BEEP peer must discard previously cached
information about the BEEP session.

As different TLS ciphersuites provide varying levels of security,
administrators should carefully choose which ciphersuites are
provisioned.

As BEEP is peer-to-peer in nature, before performing any task
associated with a message, each channel should apply the appropriate
access control based on the authenticated identity and privacy level
associated with the BEEP session.

References

[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC2045, November 1996.

[2] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-
xml-19980210>.

[3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC2246, January
1999.

[4] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC2222, October 1997.

[5] Rose, M., "Mapping the BEEP Core onto TCP", RFC3081, March
2001.

[6] Postel, J., "Transmission Control Protocol", STD 7, RFC793,
September 1981.

[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC2234, November 1997.

[8] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC1982,
August 1996.

[9] Alvestrand, H., "Tags for the Identification of Languages", RFC
BCP 47, RFC3066, January 2001.

[10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC2396, August
1998.

[11] Newman, C., "The One-Time-Password SASL Mechanism", RFC2444,
October 1998.

[12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.

[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.

[14] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC2078, January 1997.

[15] <http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms>

Author's Address

Marshall T. Rose
Invisible Worlds, Inc.
1179 North McDowell Boulevard
Petaluma, CA 94954-6559
US

Phone: +1 707 789 3700
EMail: mrose@invisible.net
URI: http://invisible.net/

Appendix A. Acknowledgements

The author gratefully acknowledges the contributions of: David Clark,
Dave Crocker, Steve Deering, Wesley Michael Eddy, Huston Franklin,
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.

Appendix B. IANA Considerations

The IANA registers "beep" as a GSSAPI [14] service name, as specified
in Section 4.1.

The IANA maintains a list of:

o standards-track BEEP profiles, c.f., Section 5.1; and,

o standards-track features for the channel management profile, c.f.,
Section 5.2.

For each list, the IESG is responsible for assigning a designated
expert to review the specification prior to the IANA making the
assignment. As a courtesy to developers of non-standards track BEEP
profiles and channel management features, the mailing list
bxxpwg@invisible.net may be used to solicit commentary.

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.

Full Copyright Statement

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFCEditor function is currently provided by the
Internet Society.

协议分析网

搜索

RFC3080 - The Blocks Extensible Exchange Protocol Core(2)