rfc3080.txt

最新的RFC

   and immediately begins the underlying negotiation process for
   transport security.



















Rose                        Standards Track                    [Page 36]

RFC 3080                     The BEEP Core                    March 2001


4. User Authentication

   When a BEEP session is established, anonymous access, without trace
   information, is provided.  Accordingly, user authentication in BEEP
   is achieved using an initial tuning profile.

   This document defines a family of profiles based on SASL mechanisms:

   o  each mechanism in the IANA SASL registry [15] has an associated
      profile.

   Other profiles may be defined and deployed on a bilateral basis.

   Whenever a successful authentication occurs, on any channel, the
   authenticated identity is updated for all existing and future
   channels on the BEEP session; further, no additional attempts at
   authentication are allowed.

   Note that regardless of transport security and user authentication,
   authorization is an internal matter for each BEEP peer.  As such,
   each peer may choose to restrict the operations it allows based on
   the authentication credentials provided (i.e., unauthorized
   operations might be rejected with error code 530).




























Rose                        Standards Track                    [Page 37]

RFC 3080                     The BEEP Core                    March 2001


4.1 The SASL Family of Profiles

   Section 6.3 contains the registration for this profile.

   Note that SASL may provide both user authentication and transport
   security.  Once transport security is successfully negotiated for a
   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.











Rose                        Standards Track                    [Page 38]

RFC 3080                     The BEEP Core                    March 2001


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


























Rose                        Standards Track                    [Page 39]

RFC 3080                     The BEEP Core                    March 2001


   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





Rose                        Standards Track                    [Page 40]

RFC 3080                     The BEEP Core                    March 2001


   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

















Rose                        Standards Track                    [Page 41]

RFC 3080                     The BEEP Core                    March 2001


   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.





















Rose                        Standards Track                    [Page 42]

RFC 3080                     The BEEP Core                    March 2001


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).
















Rose                        Standards Track                    [Page 43]

RFC 3080                     The BEEP Core                    March 2001


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.





Rose                        Standards Track                    [Page 44]

RFC 3080                     The BEEP Core                    March 2001


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 "Aut